Payment Points: Monotone Access Structures

In our past series about Payment Points on Lightning, we covered the foundations of Payment Points and explored some important features they enable.

In this new series we will highlight new discoveries in the capabilities enabled by the Lightning Network – when it replaces HTLCs with PTLCs. Topics covered in this series will include: mitigating the Free Option Problem on multi-asset Lightning, executing Discreet Log Contracts over Lightning, selling LN-enabled Discreet Log Contracts, and more. We will recap the last series at a high level and then move on to describe how PTLCs allow us to create payments conditional on multi-party interactions in the form of Monotone Access Structures.

For a recap in audio form, check out this talk from the Lightning Conference: Replacing Payment Hashes With Payment Points.

PTLC stands for Point-Time-Locked-Contract. It is analogous to an HTLC but where we have replaced the hash-lock with a point-lock. This means that rather than revealing a pre-image to a pre-specified hash to claim funds, one instead reveals the scalar (private key) to a pre-specified point (public key). This is desirable for many reasons but fundamentally the issue with using hash-locks is that the hashes destroy useful non-sensitive information. This problem manifests in various ways, the most prominent of which is payment correlation.

Payment correlation refers to the fact that hops on routed payments are all linked by the payment hash. This problem is AMPlified by Multi-Path-Payments, where an observer can monitor multiple payment paths, all using the same hash, to try and pinpoint where the sender node and/or receiver node are on the network. Not only is this a pretty bad privacy leak, but it actually makes Lightning vulnerable to what are called Wormhole Attacks. This is where two malicious (or just economically rational) nodes which are coordinating discover they are on the same route, and can steal the fees from all intermediate hops while locking up their HTLC funds, all without being detected. This problem is easily solved by PTLCs as unlike hashes, points are additive (Point(x) + Point(y) = Point(x+y)) so that each hop can have a random nonce point added to it.

Not only are HTLCs vulnerable to payment correlation and wormhole attacks, but they are also boring. There is not much you can do with them without some heavy hash-related zero knowledge proofs. As such, many LN proposals – such as AMPs and Stuckless Payments – come with trade-offs. Namely, that you can’t have your proposal use HTLCs and have Proof of Payment (PoP).

Any payment which is contingent on action from the payer (invoice-less payments, stuckless payments, OG AMPs, etc.) must have the hash pre-image generated by the payer and so there is nothing for them to learn on payment completion that can be used as PoP. This is fixed by PTLCs because again, points are additive so that both parties (as well as external parties) can add their own points together to arrive at one payment point.

Now that we’re caught up to speed on what Payment Points are and some of the things that they can accomplish, let us try to generalize what kinds of emergent contracts can be formed using PTLCs.

This leads us to the notion of an access structure. An access structure on the pre-image to a payment point P, is the set of all groups who can collaboratively construct the pre-image to P. To keep things restricted to relevant access structures, we will narrow scope to monotonic access structures, which are access structures that can be described using ANDs and ORs.

Some familiar examples that we have already encountered of access structures on payment points include

Buyer AND Seller
- adding PoP to a spontaneous payment
Buyer Point 1 AND Buyer Point 2 AND … AND Buyer Point n AND Seller
- Adding PoP to an AMP with n sub-payments
Seller AND Oracle Signature
- a payment conditional on an oracle signature of a specific event
Seller AND (Buyer OR Escrow)
- Lightning escrow contracts

As exemplified in all of the above examples, using AND in our Payment Point access structures is as simple as adding two points together. That is, to get a point that has the access structure A AND B, one can simply use the point A + B.

Constructing a Payment Point from two given points, A and B, such that knowledge of either the pre-image to A OR the pre-image to B is sufficient to construct the pre-image for the payment point is much trickier. This is largely because there are often contextual restrictions on which parties can interact (e.g. a Discreet Log Contract Oracle should not gain information about its users).

In the simpler case where all parties can interact freely, they can use their favorite Verifiable Secret Sharing scheme to create M-of-N threshold access structures. Specifically this allows for 1-of-N (OR) access structures.

Oftentimes however, it may be important to restrict interaction between certain parties, and so another procedure may be more fit. The following was proposed by Lloyd Fournier (see here).

Say that Alice wants to create a Payment Point that either she or Bob can compute the pre-image to. Alice has a point A, and Bob has a point/public key B. Alice verifiably encrypts the pre-image to A using B as to encrypt. Alice shares the encrypted pre-image to A with all relevant parties involved in this invoice. Once this is done, the point A has the access structure A OR B since only Bob can decrypt the encrypted A pre-image, and Alice already knows the pre-image as she generated it.

While this second method can be unwieldy at times, it does have the benefit that the second party (Bob in the example above) does not need to be part of any interactions when further composing the point A = A OR B. This is useful in the example of the Escrow Contract where it is preferable that the Escrow is only ever aware of its use in the case of a disagreement in which it has been invoked.

The second approach allows us to use the Seller’s Point + Buyer’s Point where the Seller has a copy of the Buyer’s pre-image encrypted with the Escrow’s public key so that they can ask the Escrow to compute the Buyer’s pre-image if necessary, but where the Escrow is in no way used in the cooperative execution case. This means that unless the buyer or seller reveal the existence of this contract to the Escrow, then that Escrow will not know about it and can do nothing to influence the contract outcome.

There are many other ways of creating monotonic access structures on pre-images to payment points that are suitable under various constraints. However, I am not an expert on the topic so I would like to continue the discussion on what we can actually do with payment points under the assumption that we have mechanisms for creating these AND-OR points generally.

A familiar access structure to most Bitcoiners is the M-of-N threshold structure. Which, as detailed above, we can now construct in a Payment Point Lightning Network. Meaning we can create payments for which M of N pre-images must combine in order to compute the payment pre-image. This has the potential of improving key management on the Lightning Network by allowing users to “shard” their points across multiple machines (like how many wallets use MultiSig for improved security), and even across multiple parties. All without requiring external (or internal) actors to know the access structures on “sub-points”.

We have reviewed why we need PTLCs, what makes them useful as well as a new way of viewing what we can now do with payment points using monotonic access structures. In the next post of this series, we will introduce an exciting new concept dubbed the Barrier Escrow. ZmnSCPxj and I came up with this idea which combines Payment Point powered AMPs with access structures to accomplish some awesome things including: a solution to the free-option problem in a multi-asset Lightning Network, multi-party Discreet Log Contracts over lightning, and payment/contract re-negotiation.

If you’re interested in learning or know of more cool uses for payment points, hit us up:

Contact Nadav @Nadav_Kohen or email at [email protected].

To discuss all things Bitcoin and Lightning, feel free to join our Suredbits Slack channel here.

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. Be sure to check out our recently released Historical Crypto Prices API!

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].