Pénzkeresés az interneten keresztül a Bitcoin segítségével - ahogyan azt tervezték

2009-ben a Bitcoin olyan szolgáltatást használt, amely lehetővé tette az IP-IP közötti információcserét. A 2009-es pénztárca nem csupán a koncepció bizonyítéka volt, és a Bitcoin sok szempontját letiltották, mivel a szoftvert fejlesztők nem értették meg.

A múlt héten megvitatták, hogyan lehet egy kulcsot használni az intelligens kártyához, miközben a magánélet fenntartása a Bitcoin tűzfal azonosító modelljével történt. A következő hétre bemutatom mind azt a módszert, amely lehetővé teszi egy webszerver számára, hogy naiv módon biztonságosan fogadja el a kifizetéseket a bitcoinban, mind azt a módszert, amely lehetővé teszi a fiat és más jogkivonatok cseréjét, miközben megőrzi a magánélet abszolút szintjét.

PKI tanúsítványok - a folyamat

Az ilyen - nem a bányászat - a Bitcoin peer-to-peer aspektusa, és ez az egyik első dolog, amelyet a Core fejlesztők eltávolítottak.

2009-ben még sok munkára volt szükség.

2009-ben a rendszer még nem volt teljes. Számos lehetséges módszert kellett tesztelni, és a 2009-es ügyfélnél alkalmazott módszer nagyon sok kívánnivalót hagyott maga után. Aztán megint csak a koncepció bizonyítéka volt.

Az ilyen kérdések megoldásához meg kell kezdenünk annak megértését, hogy a csomópontok és a pénztárcák külön vannak. A csomópontok bányászok, és a pénztárcák használják a felhasználót a P2P tranzakció engedélyezéséhez. A mai bejegyzésben elmagyarázom, hogyan lehet az ECDSA-alapú webes tanúsítvány, az SSL / TLS-szerver tanúsítvány, amely lehetővé teszi az interneten biztonságos böngészést, a kereskedői fizetési rendszer alapját - egy biztonságos és magántulajdonban lévő rendszert, és mégis úgy van kialakítva, hogy csak egyszer küld kifizetést egy adott címre.

Más szavakkal, soha nem használja újra a kulcsokat.

Kétféle módon küldhet pénzt. Ha a címzett online, akkor te
beírhatja IP-címüket, és ez csatlakozni fog, új nyilvánosságot kap
kulcsot, és küldje el a tranzakciót megjegyzésekkel. Ha a címzett
nem online, el lehet küldeni a saját Bitcoin címükre, amely
egy nyilvános kulcsának kivonat, amelyet nekik adnak. Meg fogják kapni
a tranzakció, amikor legközelebb csatlakoznak, és megkapják a blokkot
Ennek a módszernek az a hátránya, hogy nincs megjegyzési információ
elküldésre kerül, és a cím használatakor elveszhet egy kis adatvédelem
többször is, de ez hasznos alternatíva, ha mindkét felhasználó nem tudja
ugyanakkor online lehet, vagy a címzett nem tudja fogadni a bejövőt
kapcsolatokat.

A tanúsítvány használható az S / MIME és a HTTPS formátumban is.

Ha elveszünk a CA-ban regisztrált tanúsítvánnyal kapcsolatos kulcsot, nyilvános nyilvántartást hozhatunk létre a kereskedőnek küldött összes érméről, és ezzel egyidejűleg megőrizhetjük a magánélet védelmét.

Kezdjük Alice-val, egy fogyasztóval, és Bob-val, egy internetes kereskedővel, amelynek ECDSA-alapú webes tanúsítványa van a webhelyére, a HTTPS://www.bob.com.

Alice rendelkezik Bitcoin mesterkulccsal. A mesterkulcsot nem használják a bitcoin küldésére vagy fogadására, hanem módszerként is felhasználhatók identitáskulcs létrehozására (és akár intelligens kártyán is lehet). Ezt a kulcsot hívjuk P (Alice) -nek.

Bob weboldalán (hagyom, hogy mások gondolkodjanak azon, mennyire egyszerű a mechanizmus e-mailbe történő kiterjesztése az S-MIME segítségével) van egy P (Bob) főkulcs.

Alice-nak van egy érmekészlete (azaz UTXO-referenciák), amelyek teljesen függetlenek P-vel (Alice), és amelyeknek semmilyen kapcsolatban nincs a főkulcsukkal. P (A-1-i) -nek hívjuk; itt (i) a használt érme számát jelenti.

Alice létrehozhat egy közös titkot (s1) a következő dokumentumban ismertetett folyamat felhasználásával:

KÖZÖS TITKOS MEGHATÁROZÁSA AZ INFORMÁCIÓK BIZTONSÁGOS CSERÉJÉRE ÉS A HIERARCHIKAI, DETERMINISZTIKAI KRYPTOGRAFIKAI KULCSOKKAL

Egy ilyen mechanizmus (a sok példa egyike) használatához Alice Bob webáruházába megy, és most meg akar fizetni. Alice kiszámíthat egy megosztott titkot Bob-tal. A biztonságosabbá tétele érdekében Alice felhasználhatja a Bob-szal megosztott webes munkamenet azonosítóját, a számla számát vagy bármi mást. Használható egy HMAC-alapú értékben további biztonság és adatvédelem hozzáadására, de manapság egy egyszerű kivonatot fogok használni a folyamat megértésének megkönnyítésére.

Alice és Bob egyaránt kiszámíthatnak egy S értéket, amely kapcsolódik azokhoz a kulcsokhoz, amelyeket Alice és Bob használnak az interneten. Alice-nek lehet egy azonosító és hitelesítési kulcsa, amely nem kapcsolódik nyilvánosan a vásárlásához, de biztosítja minden Bob-nal folytatott kommunikációját.

Alice üzenetet küld Bobnak, amely titkosítva van egy Bitcoin tranzakcióban. A tranzakció offline vagy online folyamattal is végrehajtható. Ha Bob online, akkor tárolja az Alice-ből származó nonce értékét az internetes fizetés részeként.

Ha Bob nem online és meglehetősen egyszerű webhelyével rendelkezik, akkor a blockchain segítségével rögzítheti a fizetéssel kapcsolatos információkat és ellenőrizheti azokat.

Alice tranzakciót küld Bobnak P-nek (Bob). Bob nem használ ilyen címet, tehát a fizetés kicsi; a porkorlát nélkül elegendő egy egyszerű satoshi. Alice a fizetésről szóló üzenetet a P (Bob) címre küldi, és Bob nem használja azt pénzeszközökhöz. Azt mondhatjuk, hogy Bob CSAK a címből (a P (Bob) nyilvános kulcshoz társított címből) fog költeni, amikor a tanúsítvány lejártként van megjelölve. A folyamat az elosztott „visszavonási lista” formájaként működik, ahol Bob vezérelheti a saját kulcsát. Sőt, ha a Bob kulcsát és tanúsítványát valaha is megtámadják, és az itt leírt porta-tranzakciókat egy támadó költi el, ez automatikus riasztásként működik. Bob kis összegű pénzeszközt tudott tartani a számlán annak érdekében, hogy a hackerek úgy gondolja, hogy egy érvényes felhasználási cím (pl. 2000 dollár), amelyet csak akkor veszítenek el, ha a fiókot feltörik, de ez figyelmezteti minden Bob ügyfelét a támadáshoz.

Bob egy alkulccsal személyre szabottabbá teheti a fiókot - lásd a szabadalom 9. ábráját:

9. ábra a 42. szabadalomból

Bobnak akár egy olyan folyamata is lehet, amelyben a számla száma egy alkulcshoz van társítva.

Alice most a P (Bob) -hoz társított címre küldi - és a szkriptben vagy az OP_RETURN érték tartalmaz egy titkosított értéket (például egy AES titkosítási algoritmus használatával). A fent említett módszerrel Bob kiszámítja (S). A Bobnak küldött üzenetben egyetlen satoshi-val küldött adatok (plusz bányászati ​​díjak) tartalmazzák az összes Bobnak, amelyet tudnia kell, hogy megtalálja, ahonnan Alice küldte a kifizetést. Bob a szimmetrikus kulcsot (S) használja az üzenetben szereplő adatok dekódolásához:

  • Encrypt (S) [M]

amely Bob üzenetet küld Alice, M.-tól.

  • Dekódolása (S) [M]

Bob kiszámíthatja egy kulcscímet a származtatott kulcsból:

  • P (Bob-Paid) = P (Bob) + HMAC (M ~ S) xG
  • Az üzenet kulcs P (megosztott üzenet) = HMAC (M ~ S) xG

CSAK Bob és Alice megismerik az új titkos HMAC-ot (M ~ S).

Alice bizonyítani tudja, hogy fizetést küldött Bobnak. Bob megtalálja a pénzt Alice-től, és ellenőrizheti a tranzakciót.

Ugyanakkor egyetlen külső fél sem tudja meghatározni azt a címet, ahonnan Alice megküldte fizetését - P (A-1-i) Bob-nak P-hez (Bob-Paid).

Mivel Bob rekordokkal rendelkezik a P (Bob) blokkláncán, és teljes ellenőrzési nyomkövetéssel rendelkezik az összes kapott fizetési címről. A rekord összekapcsolható számlákkal, beszerzési megrendelésekkel és egyebekkel, lehetővé téve Bob számára az összes csere teljes ellenőrzési nyomvonalának létrehozását, amelyet nem lehet törölni, megváltoztatni vagy manipulálni. Ez a módszer teljesíti minden Bob számára szükséges törvényi számviteli kérdést, és megosztott címe lehet annak, ahol az ÁFA-t és az egyéb forgalmi adókat megküldik a kormánynak fizetéskor. Más szavakkal, Bobnak nem kell költséges ellenőrzéseket végeznie, és az adóhatóságot azonnal, haladéktalanul meg lehet fizetni.

Tokenek és Bitcoin

Alice és Bob az olyan protokollok, mint például a Tokenized vagy az nChain által szabadalmaztatott protokollok valamelyikének alkalmazásával, tokenizált fiatot cserélhetnek. Ez azt jelenti, hogy Alice fizetni tudott Bobnak az Egyesült Királyság egyik bankja által kiállított GBP token felhasználásával. Egy ilyen tokent a fent felsorolt ​​eljárás alkalmazásával továbbítanak, lehetővé téve Alice és Bob számára a biztonságos és biztonságos tranzakciókat a digitális készpénzzel a választott helyi pénznemben, miközben továbbra is a Bitcoin-t használják a csere „vízvezetékének”.

Metanet összekapcsolás

Mint ilyen, még ha Bob is offline webhelyet működtet - vagyis egy egyszerű rendszert, háttér-adatbázis nélkül -, a P (Bob) kulcsmal kapott rekordok mostantól megváltoztathatatlan adattárolóként működhetnek.

Az üzenet, amelyet Alice Bobnak titkosít, a teljes rendelés lehet.

A meglévő EDI-üzenettípusokkal kiegészíthető. Az EDI-vel ellentétben a módszer biztonságos és magántulajdonban van.

Jobb, ha a rekord változatlan. Nincs helye számviteli csalásoknak. Visszafordíthatja a tranzakciókat, de ehhez pénzeszközök visszatérítésére van szükség a forráshoz.

Alice és Bob rögzítheti a teljes kereskedelmi folyamatot.

Bob egy sor hierarchikus címet tarthat, amelyek rögzítik a megrendelés minden szakaszát - a számlázástól és a fizetéstől a küldéséig és a kézbesítésig. Ha Bobnak minden egyes ügyféllel van sub-master kulcsa (lásd a fenti szabadalmat és a 9. ábrát), akkor külön alkulcsot is felépíthet, amely az önmaga, az ügyfél és az adóhatóság számára ismert az ellenőrzés céljából, de nem mások, lehetővé téve számára a magánélet abszolút szintjének megőrzését, ahol más ügyfelek és beszállítók még azt sem tudják, hány tranzakciót hajt végre. Sőt, a fizetéseket oly módon tudja felépíteni, hogy lehetővé tegye a belső alkalmazottak elszigetelését, és csak a saját szervezeti egységeikkel kapcsolatos információk ismeretét biztosítsa számukra.

Amíg a CA-hoz kapcsolt kulcsot nem érinti, a fiókok elküldhetők a régi címre. Egy CA-n belüli kulcsot össze lehet kapcsolni a számviteli évvel, és az egyes adóidőszakokat is gördíthetjük. Lezárja a tanúsítványt, összegyűjti a porként befizetett összegeket, ugyanakkor bezárja az új elszámolási évre kész könyveket.

EDI üzenet

Az EDI egy meglévő kódolási séma a kereskedelem számára.

Az ANSI és az EDIFACT üzenet formátumait az alábbi képen láthatjuk:

ANSI vs EDIFACT

Rendszerünkben az üzenetben szereplő adatok (nem a fizetés) titkosítási kulcsát használjuk „csoportüzenetként”. Nincs szükség cserélő üzenetre. Ilyen közép ember lenne, és a Bitcoinban megszüntettük a szükségét rá.

Normál EDI

Az új kereskedelempolitika olyan, ahol az összes rekord változatlan, nem veszíthető el, és lehetővé teszi Alice és Bob magánkereskedelmét.

Bitcoin adatcsere

És az EDI egy Bitcoin tranzakcióhoz való hozzárendelésére szolgáló eszközök egyszerűen olyan EDI eszközöknek tűnnek, mint manapság.

A Bitcoin tranzakcióba beágyazva a titkosított EDI XML formátumot egyszerűen kinyerhetik, megjeleníthetik vagy kinyomtathatják, mint bármely más számlát vagy megrendelést:

Megjelenített számla

A meglévő EDI-világban az ügyfeleknek modellekkel kell fizetniük, amelyek ársávban működnek, a Kilo-karakterek (KC) vagy a dokumentumok várható mennyisége alapján. Vannak rejtett díjak is, mint például a minimális rekordhossz, sok szolgáltató esetében a rekordhossz 128-512 karakter. Ennek eredményeként ha 12 dokumentumot küld 12 karakterből, akkor legfeljebb 5120 karakter kerül felszámolásra, még akkor is, ha csak 144 karakter küld.

Azok a kereskedők, akik nagyszámú kis tranzakcióval járnak, jelentős összeget adhatnak a havi díjhoz.

Ilyen nem a Bitcoin kérdése.

Noha a NACCS EDI üzenetek maximális megengedett üzenetszáma 500 000 bájt, a valóság az, hogy az EDI és más kapcsolódó üzenetek általában 150 bájt nagyságrendben vannak. Megváltoztathatatlan, magán, biztonságos számlázási és számviteli rendszer küldése egy százalékra számlánként - hasonlítsa össze ezt 2–3 dollárral néhány EDI megoldás esetén, és akár 0,20 dollárt egy egyszerű Visa tranzakciónál, és… itt az ideje, hogy újra gondolkodjon hogyan csinálsz üzletet.

Egy ilyen modellben egyetlen Bitcoin címet sem kell többször használni, és a fizetéseket és a számlákat privát módon kapcsolják össze - ami akár álnév is lehet, mivel az azonosítónak nem kell a felhasználói igazolványban lennie.