Å ta penger over nettet ved hjelp av Bitcoin - slik det ble designet

Tilbake i 2009 brukte Bitcoin en funksjon som muliggjorde IP-til-IP-utveksling av informasjon. 2009-lommeboken var ikke mer enn et bevis på konsept, og mange av de beste aspektene ved Bitcoin har blitt deaktivert ettersom de som utviklet programvaren ikke klarte å forstå den.

Forrige uke diskuterte jeg hvordan en nøkkel kunne brukes på et smartkort, mens personvern ble opprettholdt ved hjelp av brannmurens identitetsmodell til Bitcoin. I løpet av den kommende uken vil jeg vise både en metode som tillater en webserver å akseptere betalinger i bitcoin naivt og en metode som lar utveksle fiat og andre symboler mens jeg opprettholder et absolutt personvernnivå.

PKI-sertifikater - prosessen

Slikt - ikke gruvedrift - er peer-to-peer aspektet av Bitcoin, og det er noe av det første som Core-utviklerne fjernet.

I 2009 var det fortsatt nødvendig med mye arbeid.

I 2009 var systemet ennå ikke komplett. Flere mulige metoder som måtte testes, og metoden som ble brukt i 2009-klienten, etterlot mye å være ønsket. Så igjen, det var bare et bevis på konsept.

For å løse slike problemer, må vi starte med å forstå at noder og lommebøker er separate. Noder er gruvearbeidere, og lommebøker er det som brukes av brukeren for å tillate en P2P-transaksjon. I dagens innlegg vil jeg forklare hvordan et ECDSA-basert websertifikat, et SSL / TLS-server-sertifikat som lar deg surfe på internett sikkert, kan være grunnlaget for et selgerbetalingssystem - et system som forblir sikkert og privat, og men er også konstruert slik at den bare sender en betaling til en bestemt adresse en gang.

Med andre ord gjenbruker den aldri nøkler.

Det er to måter å sende penger på. Hvis mottakeren er online, du
kan oppgi IP-adressen deres og den vil koble seg, få en ny publikum
tast og send transaksjonen med kommentarer. Hvis mottakeren er det
ikke online, er det mulig å sende til deres Bitcoin-adresse, som
er en hasj av deres offentlige nøkkel som de gir deg. De vil motta
transaksjonen neste gang de kobler seg til og får blokkeringen
i. Denne metoden har den ulempen at ingen kommentarinformasjon
sendes, og litt privatliv kan gå tapt hvis adressen brukes
flere ganger, men det er et nyttig alternativ hvis begge brukerne ikke kan det
være online samtidig, eller mottakeren kan ikke motta innkommende
tilkoblinger.

Sertifikatet er noe som kan brukes i både S / MIME og HTTPS.

Hvis vi tar nøkkelen som er assosiert med et CA-registrert sertifikat, kan vi lage en offentlig registrering av alle mynter som blir sendt til selgeren og samtidig beholde personvernet.

Vi starter med Alice, en forbruker, og Bob, en nettforhandler med et ECDSA-basert websertifikat for nettstedet hans HTTPS://www.bob.com.

Alice har en Bitcoin-nøkkel. Hovednøkkelen brukes ikke til å sende eller motta bitcoin, og kan være en metode for å lage en identitetsnøkkel (og kan til og med være på et smartkort). Slik er nøkkelen som vi vil kalle P (Alice).

Bobs nettsted (jeg overlater det til andre å tenke på hvor enkelt det er å utvide mekanismen til e-post med S-MIME) har en hovednøkkel P (Bob).

Alice har et sett med mynter (det vil si UTXO-referanser) som kan være helt uten tilknytning til P (Alice) og som ikke har noen relasjon til hennes viktigste nøkkel i det hele tatt. Vi vil kalle det P (A-1-i); her (i) refererer nummeret til mynten som er brukt.

Alice kan opprette en felles hemmelighet (s1) ved å bruke prosessen som er dokumentert i følgende dokument:

BESTEMMELSE AV EN FELLES HEMMELSE FOR SIKKER UTBYTTE AV INFORMASJON OG HIERARKISKE, DETERMINISTISKE KRYPTOGRAFISKE Nøkler

For å bruke en slik mekanisme (ett av mange eksempler), går Alice til Bobs nettbutikk, og søker nå å betale. Alice kan beregne en delt hemmelighet med Bob. For å være tryggere, kan Alice bruke web-økt-IDen som hun deler med Bob, fakturanummeret eller noe annet. Det kan brukes i en HMAC-basert verdi for å legge til ytterligere sikkerhet og personvern, men for i dag vil jeg bruke en enkel hasj for å gjøre prosessen enklere å forstå.

Alice og Bob kan begge beregne en verdi S, som er knyttet til nøkler som Alice og Bob bruker på nettet. Alice kan ha en identitets- og autentiseringsnøkkel som ikke kobler offentlig til kjøpene hennes, men som sikrer all kommunikasjonen med Bob.

Alice sender en melding til Bob som er kryptert i en Bitcoin-transaksjon. Transaksjonen kan fullføres ved bruk av enten en offline eller online prosess. Hvis Bob er online, kan han lagre verdien av en nonce fra Alice som en del av nettkassen.

Hvis Bob ikke er online og har et ganske enkelt nettsted, kan han bruke blockchain til å registrere informasjon om betalingen og sjekke den.

Alice sender Bob en transaksjon til P (Bob). Bob bruker ikke en slik adresse, så betalingen er liten; uten støvgrensen vil bare en enkelt satoshi være tilstrekkelig. Alice sender meldingen om betalingen til P (Bob) -adressen, og Bob bruker den ikke til midler. Vi kan si at KUN Bob vil bruke fra adressen (den som er tilknyttet den offentlige nøkkelen P (Bob)) når sertifikatet er merket som utløpt. Prosessen fungerer som en form for distribuert "tilbakekallingsliste" der Bob kan kontrollere sin egen nøkkel. Hvis Bobs nøkkel og sertifikat noen gang blir angrepet og støvtransaksjonene her blir brukt av en angriper, fungerer det som et automatisert varsel. Bob kunne ha et lite beløp på kontoen som et middel til å la hackere tro at det er en gyldig adresse for bruk (f.eks. $ 2000) som bare ville gå tapt hvis kontoen ble hacket, men som også varsler alle Bobs kunder til angrepet.

Bob kan gjøre kontoen mer privat ved hjelp av en undernøkkel - se fig. 9 i patentet:

Fig. 9 fra patent 42

Bob kan til og med ha en prosess der fakturanummeret er tilknyttet en undernøkkel.

Alice sender nå til adressen tilknyttet P (Bob) - og i skriptet eller som en OP_RETURN inkluderer verdien en verdi som er kryptert (for eksempel ved bruk av en AES-krypteringsalgoritme). Ved å bruke metoden som er nevnt over, kan Bob beregne (S). Dataene i meldingen til Bob sendt med en enkelt satoshi (pluss gruvegebyr) inneholder alt Bob trenger å vite for å finne hvor Alice har sendt betalingen. Bob bruker den symmetriske nøkkelen (S) for å dekryptere dataene i meldingen:

  • Krypter (S) [M]

som gir Bob beskjeden fra Alice, M.

  • Dekrypter (S) [M]

Bob kan nå beregne en nøkkeladresse fra den avledede nøkkelen:

  • P (Bob-Paid) = P (Bob) + HMAC (M ~ S) xG
  • Meldingstasten er P (Delt melding) = HMAC (M ~ S) xG

KUN Bob og Alice vil kjenne den nye hemmelige HMAC (M ~ S).

Alice kan bevise at hun har sendt en betaling til Bob. Bob kan finne pengene fra Alice og bekrefte transaksjonen.

Samtidig kan ingen utenforstående bestemme adressen som Alice sendte sin betaling fra - P (A-1-i) til Bob på P (Bob-Paid).

Ettersom Bob har post på blockchain hos P (Bob), og har en komplett revisjonsspor av alle betalingsadressene han har mottatt. Posten kan kobles til fakturaer, innkjøpsordrer og mer, slik at Bob kan konstruere et komplett revisjonsspor av alle børser og en som ikke kan slettes, endres eller manipuleres. Metoden oppfyller alle nødvendige lovgivningsmessige regnskapsproblemer for Bob, og han kan ha en delt adresse der moms og andre omsetningsavgifter blir sendt til regjeringen når han blir betalt. Med andre ord trenger ikke Bob å oppleve dyre revisjoner, og skattemyndigheten kan utbetales umiddelbart uten forsinkelse.

Tokens og Bitcoin

Ved å bruke en protokoll som Tokenized eller en av de forskjellige som nChain har sendt inn patenter for, kan Alice og Bob også utveksle tokenised fiat. Det betyr at Alice kan betale Bob ved å bruke et GBP-token utstedt av en bank i Storbritannia. Et slikt symbol overføres ved hjelp av prosessen som er oppført over, slik at Alice og Bob kan trygt og sikkert handle med digitale kontanter i deres lokale valuta som de velger, mens de fremdeles bruker Bitcoin som "rørleggerarbeid" for utvekslingen.

Metanettkobling

Som sådan, selv om Bob kjører et offline nettsted - det vil si et enkelt system uten en back-end-database - kan postene som er mottatt mot P (Bob) -tasten nå fungere som en form for uforanderlig datalager.

Meldingen som Alice krypterer til Bob kan være den komplette rekkefølgen.

Det kan fullføres ved hjelp av eksisterende EDI-meldingstyper. I motsetning til EDI, er metoden trygg, sikker og privat.

Bedre, plata er uforanderlig. Det er ikke noe sted for regnskapssvindel. Du kan reversere transaksjoner, men å gjøre det krever tilbakelevering av midler til den opprinnelige kilden.

Alice og Bob kan spille inn hele den kommersielle prosessen.

Bob kan inneholde en serie hierarkiske adresser som registrerer alle stadier av bestillingen - fra fakturering og betaling til sending og levering. Hvis Bob nå har en underhovednøkkel for hver klient (se patentet ovenfor og fig. 9), kan han også konstruere en egen undernøkkel, som er kjent for seg selv, klienten og skattemyndigheten for revisjonsformål, men ikke andre, slik at han kan beholde et absolutt nivå av personvern, der andre kunder og leverandører ikke engang vet hvor mange transaksjoner han gjør. Mer kan han konstruere betalinger på en måte som gjør at han kan isolere interne ansatte og få dem til å bare kjenne informasjonen knyttet til egne avdelinger.

Mens den CA-koblede tasten ikke blir berørt, kan kontoene sendes til den gamle adressen. En sub-CA-nøkkel kan være knyttet til regnskapsåret og rullet hver skatteperiode også. Du lukker ut sertifikatet, samler inn eventuelle betalinger som støv, og lukker samtidig bøkene klare for det nye regnskapsåret.

EDI-melding

EDI er et eksisterende kodingsskjema for handel.

Vi kan se ANSI- og EDIFACT-meldingsformatene på bildet nedenfor:

ANSI vs EDIFACT

I systemet vårt bruker vi krypteringsnøkkelen for dataene i meldingen (ikke betalingen) som "gruppemelding." Det er ikke behov for en utvekslingsmelding. Slikt ville være en middelmann, og i Bitcoin har vi fjernet behovet for ham.

Standard EDI

Den nye modellen for handel er en der alle poster er uforanderlige, ikke kan gå tapt, og lar Alice og Bob handle privat.

Utveksling av Bitcoin data

Og verktøy for å kartlegge EDI til en Bitcoin-transaksjon vil ganske enkelt se ut som EDI-verktøy som de er i dag.

Til og med innebygd i en Bitcoin-transaksjon, kan det krypterte EDI XML-formatet ganske enkelt tas ut og vises eller skrives ut som en hvilken som helst annen faktura eller ordre:

Vist faktura

I den eksisterende EDI-verden belastes klienter ved å bruke modeller som opererer innenfor prisbånd basert på forventede volum av Kilo-Characters (KCs) eller dokumenter. Det er også skjulte kostnader som minimum postlengde hos mange leverandører som spesifiserer en rekordlengde på 128 til 512 tegn. Resultatet er at hvis du sender 12 dokumenter med 12 tegn, vil du bli belastet for opptil 5 120 tegn, selv om du bare sender 144 tegn.

For selgere med et stort antall små transaksjoner, kan de legge et betydelig beløp til den månedlige kostnaden.

En slik ting er ikke noe problem med Bitcoin.

Selv om den maksimale meldingsstørrelsen som er tillatt for NACCS EDI-meldinger, er 500 000 byte, er realiteten at EDI og andre relaterte meldinger generelt er i størrelsesorden 150 byte. Sendingen av et uforanderlig, privat, sikkert fakturerings- og regnskapssystem for brøkdeler av en cent per faktura - sammenlign dette med 2 til 3 dollar for noen EDI-løsninger og til og med $ 0,20 for en enkel Visa-transaksjon, og ... det er på tide å begynne å tenke nytt hvordan du gjør forretninger.

I en slik modell trenger ingen Bitcoin-adresse noensinne brukes mer enn en gang, og betalingene og fakturaene er koblet privat - noe som til og med kan være pseudonym, ettersom ID-en ikke trenger å være i et brukersertifikat.