20 Brainstorming

Christian Decker edited this page 2018-07-16 23:07:45 +02:00

Table of Contents

• Payment Decorrelation
• Symmetric CSV Delay
• Signature Aggregation
• Splice-in/-out / Reanchoring
• Multi-currency support / Atomic Swaps
• Dual funded channels
• Combining HTLC Transactions
• Combining other transactions
• Spontaneous Payments
• Passing a transfer secret in the onion
• Invoicing Key
• Outsourcing Watching
• Backup and Recovery
• Using Multiple hops_data Cells in the Onion
• Streaming Payments
• Refunds
• Fast Failure
• Open Questions

Payment Decorrelation

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

Symmetric CSV Delay

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.

Signature Aggregation

Once in bitcoin, we can shrink the scripts and sigs FTW.

Splice-in/-out / Reanchoring

• Might interfere with the option_upfront_shutdown_script because splicing allows to sidestep that safety feature

Multi-currency support / Atomic Swaps

Dual funded channels

Combining HTLC Transactions

We should use SIGHASH_SINGLE|SIGHASH_ANYONECANPAY to allow combination and fee-bumping.

Combining other transactions

We could also use SIGHASH_SINGLE|SIGHASH_ANYONECANPAY for other no-dependents cases:

1. Commitment tx with no HTLC outputs.
2. The closing transaction (in which case we should change nVersion from 1 to 2!)

Spontaneous Payments

Passing a transfer secret in the onion

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.

Invoicing Key

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.

Outsourcing Watching

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

Backup and Recovery

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.

Using Multiple hops_data Cells in the Onion

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.

Streaming Payments

See https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-September/000757.html

Refunds

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.

Fast Failure

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.

Open Questions