A bitcoin a digitális áttörés egyik legjelentősebb áttörése ember közötti értékátadás szempontjából. Nem igényel közvetítőket. Ezt a bányászok decentralizált kvóruma biztosítja, és a hálózat minden olyan résztvevője érvényesíti, aki ezt választja, hogy garantálja az egyes fizetések érvényességét. A rendszer architektúráját úgy alakították ki, hogy a bolygó bármely pontjáról bárki pénzt kaphasson mástól, függetlenül attól, hogy hol van. A közösségi finanszírozás, a jótékonyság, a finanszírozás, amit csak akarsz, azonnal lehetségessé válik anélkül, hogy bárki engedélyére lenne szükséged, anélkül, hogy bármilyen kapuőrrel kellene foglalkoznod, minden bürokrácia nélkül. Elméletileg zseniális ötlet, de a valóságban egy hatalmas hiányossága van: a magánélet.
Push alapú fizetési rendszerként (senki sem húzhat ki fizetéseket, ezt kifejezetten meg kell tennie) saját maga engedélyezze őket, és „tolja” másoknak), a Bitcoin megköveteli a feladótól, hogy rendelkezzen a küldött pénz célállomásának meghatározásához szükséges információkkal. Ez megköveteli, hogy a címzett ilyen vagy olyan módon közölje a feladóval a Bitcoin-címét. Abban az esetben, ha a nagyközönségtől próbálnak pénzt gyűjteni, ennek súlyos következményei vannak a magánélet védelmét vagy az állandó interaktív online jelenlét szükségességét illetően. Bárki teljesen képes egyszerűen közzétenni egy Bitcoin-címet valahol az interneten, és onnantól kezdve bárki, aki pénzt szeretne küldeni az adott személynek, egyszerűen megteheti, de nincs magánélet védelme az ilyen módon történő pénzgyűjtésben. Egyszerűen vedd fel ezt a címet, és nézd meg a blokkláncon, és nem csak azt láthatod, hogy mennyi pénzt küldtek neki, hanem mindenki lábnyomát is láthatja a blokkláncon, aki pénzt küldött neki. A pénzgyűjtést megkísérlő személynek és mindenkinek, aki adományozott nekik, semmiféle magánélete nincs; minden teljesen nyitott és korrelál, hogy az egész világ lássa.
A címek újrafelhasználásának egyetlen alternatívája egyetlen statikus cím nyilvános közzététele formájában, ha olyan szervert kell futtatni, amely folyamatosan online marad, így az emberek minden alkalommal új, nem használt címet kérhetnek, amikor valaki új pénzt szeretne adományozni. Noha a digitális korban nem tűnik problémának, hogy valami állandóan online legyen, ennek költsége és bonyolultsága van, különösen, ha valaki saját maga próbálja meg futtatni otthon a saját hardverén. És mi a helyzet azokkal, akiknek csak mobileszközük van? Manapság az operációs rendszer jelenlegi funkciói mellett szinte lehetetlen az akkumulátorhasználatot úgy optimalizálni, hogy valami egész nap a háttérben működjön, és még ha lehet is, lemeríti az akkumulátort.
BIP47
Írja be a BIP47 kódot írta Justus Ranvier. Ennek a javaslatnak az a célja, hogy lehetővé tegye valaki számára, hogy elegendő információt tegyen közzé nyilvánosan ahhoz, hogy pénzt kaphasson bárkitől, aki úgy dönt, anélkül, hogy ez a nyilvános információ elegendő lenne ahhoz, hogy (1) nyomon kövesse, mennyi pénzt tett közzé a közzétevő személy. megkapta és (2) a közönség elé tárt minden információt arról, hogy ki küldött pénzt az azt kérő személynek. Az alapötlet az, hogy a nyilvánosan közzétett információkat (vagy fizetési kódot) vegyük, és onnan kombinálják a saját fizetési kódjukat, hogy létrehozzanak egy új címkészletet, amelyhez a címzett létrehozhatja a privát kulcsokat. Ez az új címkészlet az egyetlen küldő és a fogadó közötti kapcsolatra jellemző, és minden alkalommal, amikor egy új feladó ezt a protokollt használja pénz küldésére a fogadónak, új címkészletet generál, amely a kettőjük számára egyedi.
Magas szinten az általános áramlás a következőképpen zajlik: Az a személy, aki pénzt szeretne kapni, egy új kiterjesztett nyilvános kulcsot generál a HD tárcájából egy új származási útvonalon, és ezt nyilvánosan közzéteszi. Ez az új nyilvános kulcs „fizetési kódként” funkcionál. Innentől valaki, aki pénzt szeretne küldeni nekik, megkapja ezt az új fizetési kódot, és minden szükséges információval rendelkezik ahhoz, hogy új címeket generáljon a pénzküldéshez. A probléma azonban az, hogy a küldőnek közölnie kell a saját fizetési kód információit a címzettel, különben nem tudja előállítani a neki küldött pénzeszközök tényleges elköltéséhez szükséges privát kulcsot. Ehhez speciális”értesítési tranzakció”szükséges.
Tegyük fel, hogy Alice fizetési kódok használatával szeretne tranzakciót bonyolítani Bobbal. Alice kiválaszt egy UTXO-t, amelyet el kell küldeni Bob értesítési címére, innen veszi az ehhez az UTXO-hoz társított privát kulcsot és a Bob értesítési címéhez társított nyilvános kulcsot. Összeszorozza őket, hogy létrehozzon egy titkos vakkulcsot. Ezzel titkosíthatja fizetési kódját, és kódolhatja azokat egy OP_RETURN kimenetben. Ez azt jelenti, hogy Bob, aki elviszi a privát kulcsot az értesítési címéhez, és Alice elköltött bemenetének nyilvános kulcsát, az egyetlen személy, aki képes visszafejteni és elolvasni ezeket az információkat. Ez azért működik, mert Alice privát kulcsát Bob nyilvános kulcsával megszorozva ugyanazt az értéket kapjuk, mint Bob privát kulcsának Alice nyilvános kulcsával.
Alice és Bob most egy új címkészletet tud levezetni, amelyről csak ők ketten tudnak, és Alice mostantól tetszőleges mennyiségű tranzakciót küldhet Bobnak egy új cím használatával anélkül, hogy külső megfigyelők kellenek. tudatában van a köztük lévő kapcsolatnak. Létezik egy második változat is, ahol ahelyett, hogy kimenőt küldene Bob értesítési tranzakciójához, Alice egy változáskimenetet hoz létre magának egy 1-2 multisig használatával, ahol az egyik kulcs a változási címe, a második pedig Bob fizetési kódjának azonosítója. Egy harmadik változat 1/3 multisig kimenetet használ kódolja a szükséges információkat az OP_RETURN helyett. Ezt leszámítva a dolgok ugyanúgy működnek.
A BIP47 egyetlen hiányossága az, hogy blokkterületet kell használni egy speciális tranzakció küldésére, amely értesíti a címzettet arról, hogy pénzt fog kapni, mielőtt azt ténylegesen elköltené. Ez nagyon nem hatékony olyan használati esetekben, amikor valaki csak egyetlen fizetést próbál küldeni. Fennáll a magánélet aktív sérelmének kockázata is, ha az értesítési tranzakcióhoz használt UTXO csatlakozik azokhoz az UTXO-khoz, amelyeket valaki BIP47-címére történő fizetéshez használnak. Gondoskodni kell e két dolog közötti elszigeteltségről, hogy ne jöjjön létre olyan összefüggés, amely a láncon nyomon követhető, és az UTXO-k tulajdonjogának társítása a különböző kifizetésekből eredően.
Csendes fizetés
A címzett elhelyez egy”csendes”nyilvános kulcsot egy elérhető helyen, majd a küldő elveszi ezt, és módosítja ezt a nyilvános kulcsot annak a bemenetnek a privát kulcsával, amelyet a fizetésre költ majd. vevő. Ez úgy történik, hogy a küldő privát kulcsát megszorozzuk a fogadó csendes nyilvános kulcsával, majd ismét hozzáadjuk a csendes nyilvános kulcsot. Ez egy új címet eredményez, amelyet a fogadó úgy tud visszaállítani, hogy megszorozza a privát kulcsát a küldő bemeneti nyilvános kulcsával, és hozzáadja a csendes nyilvános kulcsát. Ez ennyire egyszerű.
A nagy hátrány itt az, hogy a könnyű kliensek támogatása nagyon nehéz, mivel a vevőnek minden egyes blokkban minden tranzakciót át kell vizsgálnia, és ki kell számítania a kulcsukra módosított bemenetek kombinációit, hogy lássa, egyezik-e az adott kimenettel. egy tranzakció. Egy teljes csomópont felhasználó számára ez nem jelent elviselhetetlenül megnövekedett ellenőrzési költségeket, de a saját teljes csomópont nélküli könnyű pénztárcák esetében ez nagyon drágává válik. Ez még tovább optimalizálható az UTXO készlet egyszerű szkennelésével. Jonas Nick a Blockstreamtől benchmark tesztet végzett egy Intel i7-en, és úgy találta, hogy körülbelül három és fél órát vett igénybe a teljes készlet átvizsgálása és a számítások futtatása a címek ellenőrzéséhez. Ez nem tartalmazza azt az időt, amely az egyes UTXO-kat létrehozó tranzakciók megkereséséhez szükséges, hogy megtalálja a számítás futtatásához szükséges bemeneti nyilvános kulcsokat. Ezt még nem benchmarkolták vagy tesztelték, így a költségek és az idő továbbra is nyitott kérdés.
Egy további optimalizálási lehetőség a küldő tranzakció nyilvános kulcsának minden bemenetének felhasználása a módosítás részeként, ami csökkentené a szkennelés költségeit annak megállapítására, hogy kapott-e pénzt, mivel nem szükséges szkennelje be a tranzakció minden egyes bemenetét, és egyenként futtassa a számítást. Ez azonban megnehezítené a CoinJoin-tranzakciók végrehajtását, mivel minden résztvevőnek aktívan részt kell vennie a kulcsmódosításban. Azt is kiszivárogtatná nekik a kimenet, amelyért a naiv megvalósításban fizet. Ez azonban megakadályozná, hogy a címzett megtudja, milyen bemenetet használtak a fizetéshez, és a CoinJoin többi résztvevőjével megosztott információk kriptográfiai elvakításával megakadályozná, hogy megtanulják, melyik kimenet a csendes fizetés, így mérsékelhető minden adatvédelmi aggály.
Lehetőség van egy szkennelési és költési kulcs összeadására is a származtatási folyamatban, hogy a címzettnek egyetlen kulcsa legyen online, amely csak a bejövő fizetések észleléséhez szükséges, miközben megtartja a költéshez szükséges kulcsot érmék, amelyeket offline és hűtőházban kaptak. Ez megváltoztatná a levezetést úgy, hogy a küldő bemeneti privát kulcsát megszorozzák a szkennelési kulccsal, majd hozzáadják a költéshez szükséges kulcsot. Ez nagyobb biztonságot tesz lehetővé a fizetések fogadásakor, és csak az Ön személyes adatait hagyja veszélyben, ha a fogadó eszközét veszélyeztetik.
Az utolsó fontos dolog, amelyet figyelembe kell venni, a címek újrafelhasználásának lehetősége a küldő oldalon. Az alap megvalósításban, ha egy feladónak több UTXO-ja van ugyanazzal a nyilvános kulccsal, akkor ezek újrafelhasználása ugyanazon személynek csendes fizetéssel történő küldéshez ugyanazt a csendes címet eredményezné, és a cím újrafelhasználását jelenti. Ez megelőzhető lenne a sémában használt tranzakciós bemenet TXID-jének és bemeneti indexének felvételével, amelyeket előre ki lehetne számítani, mielőtt elküldenék a könnyű klienseknek, hogy ne jelentsenek további számítási terhet számukra.
Összességében az ötlet. minden tekintetben jelentős előrelépést jelent a BIP47-hez képest, kivéve a magasabb ellenőrzési költségeket, amelyeket a címzett az elküldött pénzek után kutat. Megőrzi a determinisztikus helyreállítási tulajdonságot, összekapcsolhatatlanságot biztosít a fogadónak küldött különböző fizetések között, és megszünteti annak szükségességét, hogy értesítési tranzakcióra kerüljön sor a kifizetések előtt. Somsen ismét egy nagyon szilárd ötlettel állt elő egy olyan protokollról, amely megvalósítható a Bitcoin hasznosságának javítására.
Ez Shinobi vendégbejegyzése. A kifejtett vélemények teljes mértékben a sajátjuk, és nem feltétlenül tükrözik a BTC Inc. vagy a Bitcoin Magazine véleményét.
