Payment Points Series:
Payment Points Part 2: “Stuckless” Payments
Payment Points Part 3: Escrow Contracts
Payment Points Part 4: Selling Signatures
In Lightning v1.0, routed payments are enabled by Hashed Timelock Contracts (HTLCs). These are contracts for conditional payment that say Alice will send Bob the specified bitcoin if Bob reveals the pre-image to a specified hash. Otherwise Alice gets her bitcoin back after some specified time.
These contracts can then be linked together using a unified “payment hash”. We have discussed these in the previous posts, but here’s a refresher:
Say Alice wishes to pay Carol one bitcoin through Bob. Then Alice can give Bob an HTLC for 1.01 bitcoin using the condition that he must provide Alice with a pre-image to H, which Carol knows. Bob is then told to go to Carol with an HTLC worth one bitcoin in return for the pre-image to the same hash, H. Carol can then collect her money by revealing the pre-image to Bob, and only then can Bob collect his 1.01 bitcoin from Alice.
This gets the job done and successfully makes lightning routing atomic (meaning that either all payments in a route succeed or they all fail). But using payment hashes to do this comes with a couple of drawbacks. Primarily, all payments along a given route can be linked by their hash! This means that two nodes sharing information (for example, because they’re owned by the same person) can know if they are in a route together by seeing that they have received HTLCs with the same hash. This not only gives them information about routing that we don’t want them to have access to, but it also allows them to perform a “wormhole attack” which consists of them working together to steal the fees of all intermediate hops between them [1].
Say Mallory and Mike are malicious and discover that they are in a route together. Further, assume Mallory has an incoming HTLC with 1.1 bitcoin and Mike has an incoming HTLC with the same hash for 1 bitcoin. (The 0.1 bitcoin difference accounts for the sum of all fees for intermediate hops between Mallory and Mike). If Mike forwards the payment and eventually ends up paying 1 bitcoin and learning the hash pre-image, he can give this pre-image directly to Mallory who can now claim 1.1 bitcoin – without paying anything! Once she reveals this pre-image routing continues as usual and no node before Mallory or after Mike will know that anything has happened. Meanwhile, Mallory and Mike combined have paid 1 bitcoin and gained 1.1 bitcoin, collecting all of the fees of intermediate hops. And what’s worse, these intermediate hops are left having their funds locked up in an unusable state until the payment times out (because Mike is malicious and doesn’t inform them of anything); the intermediate nodes cannot tell the difference between a payment stalling and failing for benign reasons versus a malicious fee-stealing attack!
There is an outstanding proposal that fixes this problem (as well as introducing a bunch of cool new features) in which we replace pre-images and hashes with “scalars” and “payment points”. This means that rather than making payments atomic by using some hash, h(a), with some pre-image, a, we instead treat a as a private key and create a contract that requires that the payee must reveal the private key to a public key A = a*G in order to claim funds (where G is a point on an elliptic curve, and thus a*G = G + G + … + G (a times) reveals no information about the private key, a).
So far no problems have been solved, but moving from hashes to (homomorphic) one-way functions means that we can do operations (namely addition and subtraction) on our public output points where that operation is then reflected in the private input scalars: (a*G) + (b*G) = (a + b)*G whereas hash(a) + hash(b) is completely unrelated to hash(a+b). Essentially, the problem with hashes in this context is that they destroy information, whereas not all information is destroyed by homomorphic one-way functions. Now we use this to our advantage to de-correlate payments.
Example: Alice wants to pay Carol through Bob.
- Carol has a secret z and gives z*G to Alice (in an invoice).
- Alice now chooses 2 random numbers x and y.
- She gives Bob an HTLC-like contract where he receives bitcoin if he reveals the private key associated with (x + z)*G, which is just (x+z).
- Alice gives Bob y and tells him that Carol knows the pre-image to (x + z)*G + y*G, which is (x + y + z), so Bob can use it to discover (x + y + z) – y = x + z.
- Alice gives Carol (x + y) which reveals nothing about x or y.
- Bob gives Carol an HTLC-like contract where she receives bitcoin if she reveals the private key associated with (x + y + z)*G, which is (x + y + z).
- Carol reveals (x + y) + z to Bob to claim her bitcoin.
- Bob computes (x + z) and reveals this to Alice to receive his bitcoin.
- Alice computes (x + z) – x = z which acts as her PoP! (Except this PoP is even better than our current hash pre-images since only Alice learns z, and Bob doesn’t)
This scheme generalizes to an arbitrary number of hops by using a new random number for each hop. Thus every hop uses a completely different condition (since a random number is added each time) so we now have payment decorrelation! Even better, it turns out that Poelstra has shown this scheme to be possible using simple aggregated Schnorr signatures by using partial and adaptor signatures [2] (where Taproot can be used for timelocks), so that lightning channels can be accomplished with small, simple outputs, making privacy and fees during unilateral closes better [3].
For an in depth explanation of Schnorr signatures, partial and adaptor signatures and how they can be used to implement out payment point scheme, checkout Rene Pickhardt’s video series.
Using payment points and their scalars, we can now atomically route payments in a decorrolated fashion. But what other new things does this scheme enable? My three favorites are a proposal for safely retrying “stuck” payments, enabling escrow contracts in lightning channels, and enabling trustless signature selling.
We will discuss these proposed new features that rely on payment points in a follow-up post.
References:
[2] Adaptor and Partial Signatures
[3] Payment Points with Schnorr
Contact us @Suredbits
Contact Nadav @Nadav_Kohen
All of our API services are built using Lightning technology and the Lightning Network. All API services are live on Bitcoin’s mainnet. Our fully customizable data service allows customers to stream as much or as little data as they wish and pay using bitcoin.
You can connect to our Lightning node at the url:
038bdb5538a4e415c42f8fb09750729752c1a1800d321f4bb056a9f582569fbf8e@ln.suredbits.com
To learn more about how our Lightning APIs work please visit our API documentation or checkout our new websocket playground to start exploring custom data feeds.
If you are a company or cryptocurrency exchange interested in learning more about how Lightning can help grow your business, contact us at [email protected].