En begränsning i Lightning Network är att det finns en avvägning att göra mellan hur många kanaler man väljer att ha öppna och hur mycket kapacitet man vill ha för att kunna skicka och ta emot betalningar. Om du t.ex. väljer att sätta in 1200 kronor i din Lightningplånbok så kan du antingen öppna bara en kanal där du stoppar in hela summan eller öppna flera kanaler, t.ex. 3 st med 400 kronor i varje. I det förstnämnda fallet kommer du att maximera summan du kan skicka eller ta emot medan du i det sistnämnda fallet minskar risken för att en transaktion inte skulle komma fram, genom att ha fler möjliga vägar betalningen kan ta mellan dig och din mottagare.
Med det som kallas Atomic Multipath Payments ämnar man att lösa detta genom att i praktiken låta en transaktion ta “flera vägar samtidigt”. Låt oss plocka fram några bilder som vi använde i en tidigare artikel.
Tänk dig nu att A vill skicka pengar till C. Den mest uppenbara vägen går via B och tillåter A att skicka 2 satoshis. Det finns också en annan väg via D, H och F som också tillåter A att skicka 2 satoshis. Om A behöver betala 4 satoshis till C så skulle det förstås gå att skicka 2 separata transaktioner som åstadkommer detta men problemet med en sådan lösning är att man skulle kunna hamna i en situationen där den första transaktionen lyckas och den andra misslyckas, och man hamnar då i ett mellanläge då man utfört bara halva den överenskomna betalningen.
Ordet “atomic” i Atomic Multipath Payments syftar just på att man kan göra en “atomär” transaktion som är en kombination av de båda vägarna, d.v.s. en transaktion där C antingen får alla 4 satoshis eller ingen alls, där man aldrig kan hamna i en situation där transaktionen bara delvis lyckats. I nedanstående figur sker alltså antingen alla förflyttningar eller ingen alls.
Detta innebär alltså att det rent generellt kommer att gå att göra större betalningar på Lightning Network eftersom man inte längre är begränsad till att hitta 1 framkomlig väg som kan hantera hela beloppet. För den individuella noden innebär det att avvägningen mellan att öppna en stor eller flera små kanaler blir enklare. En annan fördel är att integritetsegenskaperna förbättras ytterligare då en mellanliggande nod eventuellt endast hanterar en del av den totala transaktionen, utan att veta några detaljer om huruvida det är så eller inte. Vissa nackdelar med förslaget finns också i att en överföring blir något långsammare och något dyrare, vilket dock knappt bör vara märkbart.
Status för implementation av AMP är att det nu finns ett konkret förslag till specifikation som diskuteras för fullt. För den som vill förstå mer av tekniska detaljerna går det att följa den diskussionen här:
Vill du själv experimentera med att visualisera hur olika betalningar på Lightning Network hanteras finns här en enkel emulator:
- Bitcoin Lightning Network Atomic Multi Path Emulator [sidan borttagen]