Upfront payment schemes are not like that, because they in one way or another rely on the honest behavior of route participants. We believe Stake Certificates we are going to introduce are satisfactory in both of these directions: they don’t inflate payment costs for honest users and don’t require trust. The main disadvantage of Stake Certificates seems to be the novel cryptography required. See more details in the “Evaluation” section.
Let’s say Alice wants to relay an HTLC to Carol through Bob. Per the Stake Certificates scheme, she has to commit to a particular channel UTXO by embedding an ownership proof in the onion packet while sending an HTLC to Bob.
Bob then unwraps the onion and verifies:
1) the channel identifier is pointing unambiguously to an on-chain UTXO;
2) the ownership proof (e.g., a signature) is valid against the previously disclosed UTXO witness script.
If all those checks succeed, Bob should see if Alice hasn’t exceeded her credit balance. In case she hasn’t, Bob has to “decrement Alice’s credit balance” and relay the HTLC to Carol.
Decrementing credit balance unconditionally of packet success or failure bounds liquidity abuse by malicious HTLC senders. Since there is no credit assigned initially, “decrementing the credit balance” means just remembering that “Alice spent X out of Y of the credit she received for her Stake Certificates”. Unfortunately, this naive protocol is a privacy nightmare, because routing nodes can now easily assign every HTLC they forward to the sender’s UTXO.
Let’s first define the terms here one more time, and then proceed to the non-naive, private Stake Certificates.
– Stake Certificate. Either means a solution we’re proposing or the primitive it is based on, namely proof of UTXO ownership. As we will argue later, it actually makes sense to use proof of LN channel UTXO ownership specifically rather than any funds ownership.
– Stake Certificate value. An amount of the corresponding UTXO or a ballpark this amount provably belongs to.
– Credit-to-value-transferred function defines how much value a sender can transfer along a given channel considering how much credit they might claim. The function may also consider different factors (e.g., the available capacity of a channel being used) to provide extra robustness.
Privacy-preserving Stake Certificates
The presented scheme could preserve privacy if it relied on zero-knowledge proofs of UTXO ownership by avoiding pointing to a particular UTXO.
More specifically, the verifier should be able to check that:
a) The staked UTXO is an element of the current UTXO set
b) The prover knows the witness script committed by the UTXO witness program
c) The prover knows a valid witness for the witness script
d) The staked UTXO was not used to produce a different Stake Certificate which is currently in use as well.
The verifier should also have a way to see a Stake Certificate value to properly account for the credit. This can be achieved by restricting the UTXO set being proved upon to only those UTXOs with a specific range of values: “I will prove that I own a UTXO among all UTXOs between 0.5 BTC and 1 BTC”.
Unfortunately, steps (b) and (c) require zero-knowledge protocols for general statements, which are more experimental primitives than most of the stuff we have in Bitcoin protocols,
although we assume it’s feasible to consider them for non-consensus stuff.
Stake Certificates, upfront payment schemes, and other potential solutions (given a particular configuration) may be compared along the following axis:
1) Economic feasibility
1a) What is the cost of overcoming the protection for an attacker? Likely a non-linear function: sats_spent =f(channels_to_jam, […])
1b) How does this solution limit honest users?
2) How sophisticated is this solution in terms of integration and making good UX?
3) How complex is this solution in terms of protocol design/implementation?
When it comes to (1a), both Stake Certificates and upfront payments are probably equal, in a way that they’re just best-effort ideas to increase the attack cost. Unfortunately, we currently don’t know how to design something as economically powerful as PoW in Bitcoin . This aspect can be properly evaluated by applying these ideas to different hypothetical kinds of LN in a simulation and observing the resulting trade-off between (1a) and (1b) considering different attack strategies.
In the previous sections of this post, we have argued that Stake Certificates may provide a much better (1b) for the cost of (3) because it relies on zero-knowledge. When it comes to (2), the design of Stake Certificates may vary in terms of UX burden, from completely automatic to requiring custom actions with private keys from users. Some of these trade-offs along with other interesting questions are discussed in the following section.
Design decisions and questions
Economically, these two approaches are likely to be equivalent, and it’s just a matter of stake-to-credit ratio. However, announcing credit spending to the network results in a privacy leak. It also imposes bandwidth and CPU overhead on the routing nodes.
Choosing a ZK system boils down to picking the right trade-offs of proving and verifying time, and assumptions. As we mentioned previously, we would need proving general statements. At the same time, we need something cheap in both proving and verification, because Lightning is supposed to be fast. At the same time, the setup probably doesn’t matter, because proofs are supposed to be verified only by one participant, a routing node this proof is generated for. Perhaps we can also pick any cryptographic assumptions we want since this stuff is not mission-critical and can be easily updated if someone breaks a cryptographic assumption and we observe an attack.
Should we allow holding *any* Bitcoins (not just LN channels) for Stake Certificates?
This idea might make sense if we’re worried that some LN users might want to send more payments than they can afford per their credit. However, we believe that allowing any UTXO would give an attacker more opportunities to use their cold funds for this attack, or even have a secondary market where holders sell their proofs (they have nothing to loose). Instead, we should a) design the credit-to-stake-functions better; b) encourage users send payments across different routing nodes (since credits are not tracked globally) .
What about the interactivity and lifetime of Stake Certificates?
If Stake Certificates are valid for N blocks after proof generation, does it mean that if the UTXO is spent during those N blocks, new proof can be generated from the same coins without invalidating the old proof?
Should spending a UTXO reveal all Stake Certificates generated from it?
This would also solve the problem in the previous question, but it would mean a retrospective privacy leak again. To avoid a privacy leak, we should prevent this. What if malicious Sybil *routing* nodes failing payments causing other honest routing nodes to reduce the credit of an honest payment sender?
The next step is a discussion of Stake Certificates. If the community finds it interesting, then we should discuss the design questions mentioned above, and choose a cryptosystem.
References and footnotes:
3. We don’t actually suggest PoW to solve these issues, because a) the trade-off between honest user cost and attacker cost is misaligned due to specialized hardware and b) smartphones would die too fast if they have to compute PoW; PoW is just an unreachable example of system robustness due to well-aligned game theory.
4. Secondary markets are still possible even if we restrict acceptable proofs to only LN channels, but supply would be much smaller, and markets would work much worse for an attacker.