Geld over internet nemen met Bitcoin - zoals het is ontworpen

In 2009 gebruikte Bitcoin een functie die de IP-naar-IP-uitwisseling van informatie mogelijk maakte. De portemonnee van 2009 was niet meer dan een proof of concept, en veel van de beste aspecten van Bitcoin zijn uitgeschakeld omdat degenen die de software ontwikkelden het niet begrepen.

Vorige week besprak ik hoe een sleutel in een smartcard kon worden gebruikt, terwijl de privacy werd gehandhaafd met behulp van het firewall's identiteitsmodel van Bitcoin. Voor de komende week zal ik zowel een methode laten zien waarmee een webserver veilig betalingen in bitcoin naïef kan accepteren als een methode waarmee fiat en andere tokens kunnen worden uitgewisseld met behoud van een absoluut niveau van privacy.

PKI-certificaten - het proces

Zo'n - niet mining - is het peer-to-peer-aspect van Bitcoin en het is een van de eerste dingen die de Core-ontwikkelaars hebben verwijderd.

In 2009 was nog veel werk vereist.

In 2009 was het systeem nog niet compleet. Verschillende mogelijke methoden moesten worden getest en de methode die in 2009 werd gebruikt, liet te wensen over. Aan de andere kant was het slechts een proof of concept.

Om dergelijke problemen op te lossen, moeten we beginnen te begrijpen dat knooppunten en portefeuilles gescheiden zijn. Nodes zijn mijnwerkers en wallets zijn wat de gebruiker gebruikt om een ​​P2P-transactie mogelijk te maken. In de post van vandaag zal ik uitleggen hoe een ECDSA-gebaseerd webcertificaat, een SSL / TLS-servercertificaat waarmee u veilig op internet kunt surfen, de basis kan zijn van een betaalsysteem voor verkopers - een systeem dat veilig en privé blijft, en maar is ook zo geconstrueerd dat een betaling slechts eenmaal naar een bepaald adres wordt verzonden.

Met andere woorden, sleutels worden nooit opnieuw gebruikt.

Er zijn twee manieren om geld te verzenden. Als de ontvanger online is, jij
kunnen hun IP-adres invoeren en het zal verbinding maken, een nieuw publiek krijgen
toets en verzend de transactie met opmerkingen. Als de ontvanger is
niet online, is het mogelijk om naar hun Bitcoin-adres te sturen, wat
is een hash van hun publieke sleutel die ze je geven. Ze zullen ontvangen
de transactie de volgende keer dat ze verbinding maken en het blok krijgen is het
Deze methode heeft het nadeel dat er geen commentaarinformatie is
wordt verzonden en er kan een beetje privacy verloren gaan als het adres wordt gebruikt
meerdere keren, maar het is een handig alternatief als beide gebruikers dat niet kunnen
tegelijkertijd online zijn of de ontvanger kan geen inkomende berichten ontvangen
verbindingen.

Het certificaat is iets dat zowel in S / MIME als HTTPS kan worden gebruikt.

Als we de sleutel nemen die is gekoppeld aan een door CA geregistreerd certificaat, kunnen we een openbaar register maken van alle munten die naar de handelaar worden verzonden en tegelijkertijd de privacy behouden.

We beginnen met Alice, een consument, en Bob, een webhandelaar met een ECDSA-gebaseerd webcertificaat voor zijn site HTTPS://www.bob.com.

Alice heeft een Bitcoin-hoofdsleutel. De hoofdsleutel wordt niet gebruikt om bitcoin te verzenden of te ontvangen en kan een methode zijn om een ​​identiteitssleutel te maken (en kan zelfs op een smartcard staan). Dat is de sleutel die we P (Alice) zullen noemen.

De website van Bob (ik laat het aan anderen over om na te denken over hoe eenvoudig het is om het mechanisme uit te breiden naar e-mail met S-MIME) heeft een hoofdsleutel P (Bob).

Alice heeft een set munten (dat wil zeggen UTXO-referenties) die volledig los kunnen staan ​​van P (Alice) en die helemaal geen relatie hebben met haar hoofdsleutel. We zullen het P (A-1-i) noemen; hier verwijst (i) naar het nummer van de gebruikte munt.

Alice kan een gemeenschappelijk geheim (s1) maken met behulp van het proces dat wordt beschreven in het volgende document:

BEPALING VAN EEN GEMEENSCHAPPELIJK GEHEIM VOOR DE VEILIGE UITWISSELING VAN INFORMATIE EN HIERARCHISCHE, DETERMINISTISCHE CRYPTOGRAFISCHE SLEUTELS

Om een ​​dergelijk mechanisme (een van de vele voorbeelden) te gebruiken, gaat Alice naar de webwinkel van Bob en wil ze nu betalen. Alice kan een gedeeld geheim met Bob berekenen. Voor de veiligheid kan Alice de websessie-ID gebruiken die ze deelt met Bob, het factuurnummer of iets anders. Het kan worden gebruikt in een op HMAC gebaseerde waarde om extra beveiliging en privacy toe te voegen, maar voor vandaag zal ik een eenvoudige hash gebruiken om het proces eenvoudiger te begrijpen te maken.

Alice en Bob kunnen beide een waarde S berekenen, die is gekoppeld aan sleutels die Alice en Bob op internet gebruiken. Alice kan een identiteits- en authenticatiesleutel hebben die niet openbaar is gekoppeld aan haar aankopen, maar al haar communicatie met Bob beveiligt.

Alice stuurt een bericht naar Bob dat is gecodeerd in een Bitcoin-transactie. De transactie kan worden voltooid met behulp van een offline of online proces. Als Bob online is, kan hij de waarde van een nonce van Alice opslaan als onderdeel van de webkassa.

Als Bob niet online is en een vrij eenvoudige site heeft, kan hij de blockchain gebruiken om informatie over de betaling vast te leggen en te controleren.

Alice stuurt Bob een transactie naar P (Bob). Bob gebruikt een dergelijk adres niet, dus de betaling is klein; zonder de stoflimiet volstaat een enkele satoshi. Alice stuurt het bericht voor de betaling naar het P (Bob) -adres en Bob gebruikt het niet voor geld. We kunnen zeggen dat Bob ALLEEN zal uitgeven van het adres (het adres dat is gekoppeld aan de openbare sleutel P (Bob)) wanneer het certificaat is gemarkeerd als verlopen. Het proces fungeert als een vorm van gedistribueerde 'intrekkingslijst' waar Bob zijn eigen sleutel kan bedienen. Meer nog, als de sleutel en het certificaat van Bob ooit worden aangevallen en de stoftransacties hier door een aanvaller worden besteed, fungeert dit als een geautomatiseerde waarschuwing. Bob kan een kleine hoeveelheid geld in het account houden als een manier om hackers te laten denken dat het een geldig gebruiksadres is (bijvoorbeeld $ 2.000) dat alleen verloren zou gaan als het account gehackt werd, maar dat ook alle klanten van Bob waarschuwt aan de aanval.

Bob kan het account privéer maken met behulp van een subsleutel - zie figuur 9 in het patent:

Fig. 9 van patent 42

Bob zou zelfs een proces kunnen hebben waarbij het factuurnummer is gekoppeld aan een subsleutel.

Alice verzendt nu naar het adres dat is gekoppeld aan P (Bob) - en bevat in het script of als een OP_RETURN-waarde een gecodeerde waarde (zoals bij het gebruik van een AES-coderingsalgoritme). Met behulp van de hierboven vermelde methode kan Bob berekenen (S). De gegevens in het bericht aan Bob verzonden met een enkele satoshi (plus mijnkosten) bevatten alles wat Bob moet weten om te weten waar Alice de betaling heeft verzonden. Bob gebruikt de symmetrische sleutel (S) om de gegevens in het bericht te decoderen:

  • Versleutelen (S) [M]

die Bob het bericht van Alice, M. geeft

  • Decrypteert (S) [M]

Bob kan nu een sleuteladres berekenen op basis van de afgeleide sleutel:

  • P (Bob-Paid) = P (Bob) + HMAC (M ~ S) xG
  • De berichtsleutel is P (gedeeld bericht) = HMAC (M ~ S) xG

ALLEEN Bob en Alice kennen de nieuwe geheime HMAC (M ~ S).

Alice kan bewijzen dat ze een betaling naar Bob heeft verzonden. Bob kan het geld van Alice vinden en de transactie verifiëren.

Tegelijkertijd kan geen externe partij het adres bepalen waar Alice haar betaling van - P (A-1-i) naar Bob om P (Bob-Paid) heeft gestuurd.

Omdat Bob een record heeft op de blockchain bij P (Bob), en een volledig controlespoor heeft van alle betalingsadressen die hij heeft ontvangen. Het record kan worden gekoppeld aan facturen, inkooporders en meer, waardoor Bob een volledig audittrail van alle uitwisselingen kan samenstellen en niet kan worden verwijderd, gewijzigd of gemanipuleerd. De methode voldoet aan alle vereiste wettelijke boekhoudkundige problemen voor Bob en hij kan een split-adres hebben waar btw en andere omzetbelastingen naar de overheid worden verzonden zodra hij wordt betaald. Met andere woorden, Bob hoeft geen dure controles te ondergaan en de belastingdienst kan onmiddellijk worden betaald zonder vertraging.

Tokens en Bitcoin

Met behulp van een protocol zoals Tokenized of een van de verschillende waarvoor nChain patenten heeft aangevraagd, kunnen Alice en Bob ook tokenised fiat uitwisselen. Het betekent dat Alice Bob zou kunnen betalen met een GBP-token uitgegeven door een bank in het VK. Een dergelijk token wordt verzonden met behulp van het hierboven vermelde proces, waardoor Alice en Bob veilig en beveiligd transacties kunnen uitvoeren met behulp van digitale contanten in hun lokale valuta naar keuze, terwijl ze nog steeds Bitcoin gebruiken als "loodgieter" voor de uitwisseling.

Metanet-koppeling

Als zodanig, zelfs als Bob een offline website heeft - dat wil zeggen, een eenvoudig systeem zonder back-enddatabase - kunnen de records die worden ontvangen tegen de P (Bob) -sleutel nu fungeren als een vorm van onveranderlijke gegevensopslag.

Het bericht dat Alice naar Bob codeert, kan de volledige bestelling zijn.

Het kan worden voltooid met behulp van bestaande EDI-berichttypen. In tegenstelling tot EDI is de methode veilig, beveiligd en privé.

Beter is het record onveranderlijk. Er is geen plaats voor boekhoudfraude. U kunt transacties ongedaan maken, maar om dit te doen moet u geld teruggeven aan de oorspronkelijke bron.

Alice en Bob kunnen het hele commerciële proces opnemen.

Bob kan een reeks hiërarchische adressen bevatten die alle fasen van de bestelling registreren - van facturering en betaling tot verzending en levering. Als Bob nu een sub-hoofdsleutel heeft voor elke klant (zie het patent hierboven en Fig. 9), kan hij ook een aparte subsleutel construeren, die hij, de klant en de belastingdienst voor auditdoeleinden kent, maar geen anderen, waardoor hij een absoluut niveau van privacy kan behouden, waar andere klanten en leveranciers niet eens weten hoeveel transacties hij doet. Bovendien kan hij betalingen zo construeren dat hij interne werknemers kan isoleren en hen alleen de informatie kan laten weten die verband houdt met hun eigen afdelingen.

Hoewel de CA-gekoppelde sleutel niet wordt aangeraakt, kunnen de accounts naar het oude adres worden verzonden. Een sub-CA-sleutel kan aan het boekjaar worden gekoppeld en ook elk belastingtijdvak worden opgerold. U sluit het certificaat, verzamelt alle betalingen die als stof zijn gedaan en sluit tegelijkertijd de boeken klaar voor het nieuwe boekjaar.

EDI-bericht

EDI is een bestaand coderingsschema voor handel.

We kunnen de ANSI- en EDIFACT-berichtindelingen zien in de onderstaande afbeelding:

ANSI versus EDIFACT

In ons systeem gebruiken we de coderingssleutel voor de gegevens in het bericht (niet de betaling) als het "groepsbericht". Er is geen uitwisselingsbericht nodig. Dat zou een middelste man zijn, en in Bitcoin hebben we de behoefte aan hem weggenomen.

Standaard EDI

Het nieuwe commerciële model is een model waarin alle records onveranderlijk zijn, niet verloren kunnen gaan en Alice en Bob in staat stellen privé te handelen.

Bitcoin-gegevensuitwisseling

En tools om EDI toe te wijzen aan een Bitcoin-transactie zouden er gewoon uitzien als EDI-tools zoals ze nu zijn.

Zelfs ingebed in een Bitcoin-transactie, kan het gecodeerde EDI XML-formaat eenvoudig worden geëxtraheerd en weergegeven of afgedrukt als elke andere factuur of bestelling:

Weergegeven factuur

In de bestaande EDI-wereld worden klanten gefactureerd met behulp van modellen die binnen prijsklassen werken op basis van verwachte volumes Kilo-tekens (KC's) of documenten. Er zijn ook verborgen kosten, zoals minimale recordlengtes bij veel providers die een recordlengte van 128 tot 512 tekens opgeven. Het resultaat is dat als u 12 documenten van 12 tekens verzendt, er maximaal 5.120 tekens in rekening worden gebracht, hoewel slechts 144 tekens worden verzonden.

Voor verkopers met een groot aantal kleine transacties kunnen ze een aanzienlijk bedrag toevoegen aan uw maandelijkse kosten.

Zoiets is geen probleem met Bitcoin.

Hoewel de maximale toegestane berichtgrootte voor NACCS EDI-berichten 500.000 bytes is, is de realiteit dat EDI en andere gerelateerde berichten in het algemeen in de orde van 150 bytes zijn. Het verzenden van een onveranderlijk, privé, veilig facturerings- en boekhoudsysteem voor fracties van een cent per factuur - vergelijk dit met 2 tot 3 dollar voor sommige EDI-oplossingen en zelfs $ 0,20 voor een eenvoudige Visa-transactie, en ... het is tijd om te heroverwegen hoe u zaken doet.

In een dergelijk model hoeft geen Bitcoin-adres ooit meer dan één keer te worden gebruikt en zijn de betalingen en facturen privé gekoppeld - wat zelfs pseudoniem kan zijn, omdat de ID niet in een gebruikerscertificaat hoeft te zijn.