-
Notifications
You must be signed in to change notification settings - Fork 492
Brainstorming
The problem is that payment hashes are common across the entire payment route.
The basic idea to fix this is to use key pairs rather than payment hashes, with the payer specifying the (random) offset between them.
In a simple approach, user must reveal private key to collect funds (possible today with a fairly baroque bitcoin script), but could possibly be done with Schnorr signatures such that the signature itself reveals sufficient information to create the signature for the incoming tx (see https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/) : https://youtu.be/3pd6xHjLbhs?t=6918
Change the script of the remote output of all commitment transactions to require the full CSV delay. This acts as further incentive for both parties to mutually close instead of waiting for the other side to unilaterally close, and serves as punishment to misbehaving or unresponsive nodes that force the other endpoint to go to chain.
Once in bitcoin, we can shrink the scripts and sigs FTW.
- Might interfere with the
option_upfront_shutdown_scriptbecause splicing allows to sidestep that safety feature
We should use SIGHASH_SINGLE|SIGHASH_ANYONECANPAY to allow combination and fee-bumping.
We could also use SIGHASH_SINGLE|SIGHASH_ANYONECANPAY for other no-dependents cases:
- Commitment tx with no HTLC outputs.
- The closing transaction (in which case we should change nVersion from 1 to 2!)
The main problem of spontaneous transfers is that the recipient needs to be the only other party that is able to reconstruct the payment_secret for the given payment_hash.
The simplest construction is to use the SHA256() of the final onion shared secret as the payment_preimage (using the
shared secret itself would let the previous node decrypt the onion and see that this payment was terminating). This could be added to bolt11 by simply allowing the p field to be entirely omitted.
Note that this does not provide proof-of-payment: that would seem to require a signature returned from the recipient somehow.
BOLT 11 requires signing using the node id key, which is overkill. We should allow an "invoice key" in node_announce and allow this to send sign the invoices. This would not be backwards compatible, so would take a while to roll out.
We should standardize @tdryja's work on WatchTower, and perhaps include it so peers can offer it by default (so that all would have to defect if an attack was to succeed).
The watchtower protocol could allow us to ensure we have the latest state when we start, or we could entrust peers with an encrypted blob that it would return to us on restart, which we'd use to ensure we were up-to-date, or both.
There are 20 fixed-sized hops_data fields in the onion, but it would be possible to use (say) the high bit of the realm byte to indicate that the next hops_data is extra data to be consumed by this hop as well (perhaps followed by a number to indicate how many cells to consume). This would only require support on that particular node; it would be invisible to other nodes. This would give an extra 65 bytes of data per cell for that hop.
See https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-September/000757.html
It would be nice to be able to supply a (smaller) onion + metadata for anonymous return payments. This has better privacy than simply including a return BOLT 11 payment encoding. However, this doesn't work if the return onion has a failure, either.
We could add an htlc_will_fail advisory msg, which applies to uncommitted HTLCs, but otherwise looks like htlc_update_fail. Then we add update_unadd_htlc so if you receive the will-fail in time, you can unadd it before commitment. This speeds failure a little, without making any significant protocol changes.