Atomic Multi-Path Payments
In het vorige artikel over het lightning netwerk gingen we in op het bijvullen van een payment channel op het lightning netwerk middels splicing. Het is echter niet altijd nodig een payment channel bij te vullen, we kunnen ook slim gebruik maken van meerdere open channels voor een betaling.
Vele wegen leiden naar Rome
Zie 1 - 2 voor achtergrond en 3 - 4 voor aanvullende informatie.
Herinner je dat het lightning netwerk bestaat uit een netwerk van payment channels tussen gebruikers. Een gebruiker kan meerdere payment channels open hebben met verschillende partijen. Een betaling van Alice naar Dave wordt gedaan door één van de mogelijke routes die Alice uiteindelijk met Dave linkt te gebruiken.
Stel nu dat Alice een betaling van 0,006 BTC wil gaan doen naar Dave, maar Alice niet voldoende bitcoins in haar payment channel met Bob heeft om deze betaling te kunnen uitvoeren. Of, stel nu, dat Bob niet voldoende bitcoins in zijn channel met Carol heeft, of dat er niet voldoende bitcoins tussen Carol en Dave beschikbaar zijn. Hoe kunnen we deze betaling dan alsnog uitvoeren zonder bitcoins bij te laden door middel van splicing één zonder het openen van een nieuw payment channel tussen Alice en Dave?
We kunnen gebruik maken van de andere payment channels die Alice open heeft om de betaling "op te splitsen" en via meerdere routes te laten verlopen. Het gehele netwerk van payment channels tussen Alice en andere partijen kan er bijvoorbeeld zo uitzien:
Gegeven dat Alice in totaal wel voldoende bitcoins in haar payment channels met Bob, Eve en Victor heeft, kan de betaling plaatsvinden door gebruik te maken van deze routes. Stel dat Alice in elk kanaal met Bob, Eve en Victor 0,002 BTC beschikbaar heeft en een betaling van 0,006 BTC naar Dave wil doen. Hoe kunnen we dit uitvoeren op zo'n manier dat de gehele betaling op hetzelfde moment aankomt en er niet delen van de betaling per ongeluk niet doorgaan?
We kunnen de betalingen zo inrichten dat Dave de gehele betaling pas kan claimen op het moment dat Dave alle onderdelen van de betaling ontvangen heeft. Herinner je uit het artikel over Hashed Time-Lock Contracts (HTLCs) het delen van een geheim voor het succesvol uitvoeren van een betaling via tussenpartijen. We gaan hier een soortgelijk trucje gebruiken genaamd Atomic Multi-Path Payments (AMP), een idee van Olaoluwa "roasbeef" Osuntokun.
De verzender, Alice, maakt in dit geval het geheime getal P aan en maakt drie verschillende betalingen aan waarvoor P nodig is om deze te claimen. Vervolgens splitst Alice P op in drie verschillende delen: P1 , P2 en P3 . Vervolgens voegt Alice P1 , P2 en P3 aan de verschillende betalingen die zij gaat versturen. Voor de betalingen maakt Alice gebruik van de payment channels die zij open heeft met Bob, Eve en Victor.
Wanneer alle betalingen zijn aangekomen bij Dave is hij in staat om de originele P te herconstrueren, welke nodig is om de betalingen te claimen. Dit doet Dave door P1 , P2 en P3 te combineren. Vervolgens kan Dave direct alle betalingen tegelijk claimen, waardoor de betaling in zijn geheel doorgaat. Zo is er succesvol een betaling van 0,006 BTC van Alice naar Dave verstuurd, zonder het openen van nieuwe payment channels en extra on-chain transacties.
De voordelen
Het op deze manier inrichten van een betaling via meerdere routes heeft als duidelijk voordeel dat we niet langer gebonden zijn aan een enkele route van verzender naar ontvanger. Hierdoor is niet noodzakelijk om payment channels met daarin grote bedragen open te hebben. Dit komt de decentraliteit ten goede, omdat er voorkomen kan worden dat iedereen via een paar grote hubs betalingen doet. Daarnaast helpt AMP voorkomen dat sommige payment channels een te kleine hoeveelheid bitcoins bevatten, terwijl andere payment channels een overschot hebben, waardoor een ongelijke liquiditeit ontstaat.
Ook heeft AMP effect op de hoeveelheid fee die betaald zal moeten worden voor een dergelijke betaling. Hoewel de fees voor lightning-transacties al laag zullen zijn, zorgt het vermijden van grote hubs er ook voor dat de fees voor een dergelijke betaling niet hoger dan normaal zijn.
Tot slot bevordert AMP de privacy. Bij een normale lightning-betaling weten de tussenpersonen hoeveel er verstuurd wordt, maar niet wie de afkomst en eindbestemming zijn. Het toepassen van AMP heeft het effect dat de tussenpersonen ook niet meer weten hoeveel bitcoins er precies van A naar B verstuurd worden, omdat zij niet weten hoe groot de totale betaling is. Daarnaast is er een groter aantal routes beschikbaar voor het doen van kleine betalingen, waardoor het moeilijker is om de geldstroom tussen payment channels te analyseren.
