Mimblewimble-transacties uitgelegd
- Overzicht op hoog niveau
- Transacties uitgelegd
- Transactieverificatie en -propagatie
- Fraude stoppen
- Transactieoverzicht
- Referenties
- medewerkers
Overzicht op hoog niveau
Mimblewimble is een op privacy gerichte cryptocurrency-technologie. Het verschilt op een aantal belangrijke gebieden van Bitcoin:
- Geen adressen. Het concept van Mimblewimble-adressen bestaat niet.
- Volledig privé. Elke transactie is vertrouwelijk.
- Compacte blockchain. Mimblewimble gebruikt een andere reeks veiligheidsgaranties dan Bitcoin, wat leidt tot een veel compactere blockchain.
Transacties uitgelegd
Vertrouwelijke transacties [1] zijn uitgevonden door Dr. Adam Back en worden gebruikt in verschillende cryptocurrency-projecten, waaronder Monero en Tari - via Mimblewimble.
Ontvangers van Tari creëren de privésleutels voor het direct ontvangen van munten. Daarom moeten zij betrokken worden bij de constructie van een Tari-transactie.
Dit betekent niet noodzakelijkerwijs dat ontvangers online moeten zijn. Ze moeten echter wel kunnen communiceren, of dat nu via e-mail, Instant Messaging (IM) of postduif is.
Basistransactie
We leggen uit hoe Alice Tari naar Bob kan sturen met behulp van een tweepartijenprotocol voor Mimblewimble. Transacties met meerdere partijen zijn vergelijkbaar, maar de informatiestroom is iets anders en vindt plaats via aanvullende communicatierondes.
Stel dat Alice 300 µT heeft en zij wil 200 µT naar Bob sturen.
Dit is de basistransactie:
| Ingangen | Uitgangen | ||
|---|---|---|---|
| 300 | 200 | 90 | 10 |
| De UTXO van Alice | Aan Bob | Veranderen | honorarium |
Als we dit als een wiskundige vergelijking schrijven, waarbij de output positief is en de input negatief, zouden we de zaken in evenwicht moeten kunnen brengen, zodat er geen munten uit het niets ontstaan:
$$ -300 + 200 + 90 + 10 = 0 $$
Dit is feitelijk de informatie die zich in de Bitcoin-blockchain bevindt. Iedereen kan de transacties van iemand anders controleren door simpelweg de transactiegeschiedenis van het grootboek te inspecteren. Dit is niet goed voor de privacy.
Hier komen vertrouwelijke transacties om de hoek kijken. We kunnen beginnen door beide zijden van de voorgaande vergelijking met een bepaald generatorpunt te vermenigvuldigen H over de elliptische curve (voor een inleiding tot de wiskunde van elliptische curven, zie deze presentatie):
$$ 300.H = 200.H + 90.H + 10.H $$
Sinds H een constante is, geldt de bovenstaande wiskunde nog steeds, dus we kunnen valideren dat Alice niet steelt door dat te controleren
$$(3.H) - (2.H) - (1.H) - (fH) \equiv 0.H = 0 $$
Merk op dat wij zie alleen publieke sleutels en dus zijn de waarden verborgen. Koel!
In het kort, ja. We zijn dus nog niet klaar.
"Dit wordt een pre-image-aanval genoemd."
Verblindende factoren
Om te voorkomen dat een pre-image-aanval alle waarden in Tari-transacties ontblindt, moeten we willekeur toevoegen aan elke invoer en uitvoer. Het basisidee is om dit te doen door een tweede publieke sleutel toe te voegen aan elke transactie-uitvoer.
Dus als we de invoer en uitvoer als volgt herschrijven:
$$ C_i = n_i.H + k_i.G $$
WAAR G is een andere generator op dezelfde curve, dit volledig blinds de in- en uitgangen zodat er geen pre-image-aanval mogelijk is. Deze formulering heet a Pedersen-toezegging [3].
Als iemand dit kan achterhalen k, valt de hele veiligheid van vertrouwelijke transacties uiteen. Het blijft een oefening voor de lezer om erachter te komen waarom.
Voor een semi-zachte introductie tot deze concepten is het artikel van Adam Gibson over dit onderwerp uitstekend.5].
Alice bereidt een transactie voor
Alice kan nu beginnen met het opbouwen van een transactie.
| Type | Formule | Naam |
|---|---|---|
| Invoer | $$ -300.H - k_1.G $$ | C1 |
| Wijzig de uitvoer | $$ 90.H + k_2.G $$ | C2 |
| Tarief | $$ 10.H + 0.G $$ | f |
| Totaal uitgegeven | $$ 200.H + 0.G $$ | C* |
| Som | $$ 0.H + (k_2-k_1).G $$ | X |
De \( k_i \)-waarden, \(k_1, k_2\) zijn de bestedingssleutels voor die outputs.
Daarom zou de portemonnee van Alice, die al haar niet-uitgegeven outputs van Tari bijhoudt, voor deze transactie de verblindende factor en de waarde '300' hebben geleverd om de toezegging te voltooien. C1.
Merk op dat wanneer alle inputs en outputs worden opgeteld (inclusief de kosten), alle waarden op nul komen te staan, zoals het hoort. Merk ook op dat de enige overgebleven term wordt vermenigvuldigd met het punt G. Al de H termen zijn verdwenen. Dit bedrag noemen we de publieke excessen voor Alice's deel van de transactie.
We definiëren de teveel van de transactie te zijn
$$ x_s = k_2 - k_1 $$
Een eenvoudige manier voor Alice om haar eigen risico te berekenen (en hoe de Tari-portemonneesoftware dat doet) is door haar output-blinde factoren op te tellen en de som van haar input-blinde factoren af te trekken.
Laten we zeggen dat Alice wat geld voor zichzelf probeerde te creëren en de verandering 100 µT maakte in plaats van 90. In dit geval zou de som van de outputs en inputs niet opheffen. H en dat zouden we hebben gedaan
$$X^* = 10.H + x_s.G$$
We zullen straks zien hoe het Mimblewimble-protocol Alice betrapt als ze dit soort streken probeert uit te halen.
Alice kiest ook een willekeurige nuntius,
$$ r_a $$
en berekent de overeenkomstige publieke nonce,
$$ R_a = r_a.G $$
Alice stuurt vervolgens de volgende informatie naar Bob:
| Veld | Waarde |
|---|---|
| Ingangen | C1 |
| Uitgangen | C2 |
| Tarief | 10 |
| Bedrag betaald aan Bob | 200 |
| Publieke nonce | $$ R_a $$ |
| Publieke excessen | X |
| Metadata | m |
De metagegevens van het bericht bestaan uit enkele extra stukjes informatie die betrekking hebben op de transactie (zoals wanneer de uitvoer kan worden uitgegeven).
Bob bereidt zijn reactie voor
Bob ontvangt deze informatie en begint vervolgens met het voltooien van zijn deel van de transactie.
Ten eerste kan hij verifiëren dat Alice de juiste informatie heeft verzonden door te controleren of het publieke eigen risico, X, is correct door dezelfde procedure te volgen die Alice gebruikte om het hierboven te berekenen. Deze stap is niet strikt noodzakelijk, omdat hij op dit moment niet over voldoende informatie beschikt om eventuele fraude op te sporen.
Vervolgens bouwt hij een commitment op vanuit de amount veld dat Alice naar hem stuurt:
$$ C_b = 200.H + k_b.G $$
waarbij \(k_b\) de privé-bestedingssleutel van Bob is. Hij rekent
$$P_b = k_b.G$$
en genereert een bereikbewijs voor de verbintenis.
Bob moet dan tekenen dat hij blij is dat alles naar zijn tevredenheid is voltooid. Hij creëert een gedeeltelijke Schnorr-handtekening met de uitdaging,
$$ e = H(R_a + R_b \Vert X + P_b \Vert f \Vert m) $$
en de handtekening is gezet door
$$ s_b = r_b + ek_b $$
Bob stuurt terug
| Veld | Waarde |
|---|---|
| Output (commitment en bereikbestendig) | $$C_b$$ |
| Publieke nonce | $$R_b$$ |
| Signatuur | $$s_b$$ |
| Publieke sleutel | $$P_b$$ |
Alice voltooit en verzendt de transactie
Nadat ze iets van Bob heeft gehoord, kan Alice de zaken afronden.
Ten eerste kan ze nu de publieke nonce en de publieke sleutel van Bob gebruiken om onafhankelijk dezelfde uitdaging te berekenen die Bob heeft ondertekend:
$$ e = H(R_a + R_b \Vert X + P_b \Vert f \Vert m) $$
Alice creëert vervolgens haar eigen gedeeltelijke handtekening,
$$ s_a = r_a + e.x_s $$
en de gecombineerde geaggregeerde handtekening, $$ s = s_a + s_b, R = R_a + R_b $$.
Alice kan deze transactie nu naar het netwerk uitzenden. De uiteindelijke transactie ziet er als volgt uit:
| Transactiekernel | |
|---|---|
| Publieke excessen | $$ X + P_b $$ |
| Signatuur | $$ (s, R) $$ |
| Tarief | 10 |
| Metagegevens van transacties | m |
| Transactielichaam | |
|---|---|
| Ingangen met bereikbewijzen | $$[C_1]$$ |
| Uitgangen met bereikbewijzen | $$[C_2, C_B]$$ |
Transactieverificatie en -propagatie
Wanneer een volledig knooppunt de transactie van Alice ontvangt, moet het verifiëren dat deze zich op hetzelfde niveau bevindt voordat deze naar zijn collega's wordt verzonden. Het knooppunt wil het volgende controleren:
-
Alle invoer is afkomstig van de huidige UTXO-set
Alle volledige knooppunten houden de reeks niet-bestede uitvoer bij, dus het knooppunt zal dat controleren C1 staat in die lijst.
-
Alle uitgangen hebben een geldig bereikbewijs
Het bereikbewijs wordt getoetst aan de bijbehorende verplichting.
-
De waarden zijn in evenwicht
Bij deze controle wil het knooppunt ervoor zorgen dat er tijdens de transactie geen munten worden aangemaakt of vernietigd. Maar hoe kan het dit doen als de waarden verblind zijn?
Bedenk dat bij een eerlijke transactie alle waarden (die worden vermenigvuldigd met H) annuleren, en je houdt de som over van de publieke sleutels van de uitgangen minus de publieke sleutels van de ingangen. Dit is niet toevallig dezelfde waarde die in de kernel is opgeslagen als het publieke overschot.
De opgetelde publieke nonces, R worden ook opgeslagen in de kernel, zodat het knooppunt de handtekening kan verifiëren door het volgende te controleren, waar de uitdaging e wordt berekend zoals voorheen:
$$ sG \stackrel{?}{=} R + e(X + P_b) $$
-
De handtekening in de kernel is geldig
Door de kernelhandtekening te valideren, bewijzen we dus ook aan onszelf dat de transactieboekhouding correct is.
-
Diverse andere consensuscontroles
Bijvoorbeeld of de vergoeding hoger is dan het minimum.
Als al deze controles slagen, stuurt het knooppunt de transactie door naar zijn collega's en wordt deze uiteindelijk gemined en toegevoegd aan de blockchain.
Fraude stoppen
Laten we nu zeggen dat Alice stiekem probeerde te zijn en \( X^* \) als haar eigen risico gebruikte; degene waarbij ze zichzelf 100 µT wisselgeld gaf in plaats van 90 µT. Nu zijn de waarden niet in evenwicht. De som van outputs, inputs en vergoedingen ziet er ongeveer zo uit:
$$ 10.H + (x_s + k_b).G $$
Dus wanneer een volledig knooppunt de handtekening controleert:
$$ \begin{align} R + e(X^* + P_b) &\stackrel{?}{=} sG \\ R + e(10.H + x_s.G + P_b) &\stackrel{?}{ =} (r_a + r_b + e(x_s + k_b)).G \\ R + e(10.H + X + P_b) &\stackrel{?}{=} (r_a + r_b).G + e(x_s + k_b).G \\ \mathbf{10e.H} + R + e(X + P_b) &\stackrel{?}{=} R + e(X + P_b) \\ \end{align} $$
De handtekening verifieert niet! Het knooppunt kan niet precies vertellen wat er mis is met de transactie, maar het weet wel dat er iets aan de hand is, en dus zal het de transactie stilletjes laten vallen en verder gaan met zijn leven.
Transactieoverzicht
Samenvattend: een Tari/MimbleWimble-transactie omvat het volgende:
- Van Alice: een set inputs die verwijzen naar een set eerdere outputs en deze uitgeven.
- Van Alice en Bob, een reeks nieuwe producten, waaronder:
- Een waarde en een verblindende factor (die slechts een nieuwe privésleutel is).
- Een bereikbewijs dat aantoont dat de waarde niet-negatief is.
- De transactiekosten, in duidelijke tekst,
- Het publieke exces, dat de som is van alle verblindende factoren die bij de transactie worden gebruikt.
- Metagegevens van transacties.
- De overtollige verblindende waarde die wordt gebruikt als de privésleutel om een bericht te ondertekenen dat de metagegevens van de transactie bevestigt, en de publieke overmaat.
Referenties
[1] "Wat zijn vertrouwelijke Bitcoin-transacties?" [Online.] Beschikbaar: https://www.mycryptopedia.com/what-are-confidential-transactions/ Datum van toegang: 2019-04-09.
[2] "Niets op mijn mouwnummer" [online].
Beschikbaar:
https://en.wikipedia.org/w/index.php?title=Nothing-up-my-sleeve_number&oldid=889582749. Datum van toegang: 2019-04-09.
[3] Wikipedia: "Commitment Scheme" [online]. Beschikbaar: https://en.wikipedia.org/wiki/Commitment_scheme. Datum van toegang: 2019-04-09.
[4] "Kernel-offsets, inleiding tot MimbleWimble en Grin" [online]. Beschikbaar: https://github.com/mimblewimble/grin/blob/master/doc/intro.md#kernel-offsets. Datum van toegang: 2019-04-09.
[5] A. Gibson, "Van nul (kennis) tot BulletProofs" [online]. Beschikbaar: https://joinmarket.me/static/FromZK2BPs_v1.pdf. Datum van toegang: 2019-04-10.