Brainstorming

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.

Splice-in/-out / Reanchoring

Multi-currency support / Atomic Swaps

Dual funded channels

Combining HTLC Transactions

Is there a way to allow combining htlc transactions by avoiding SIGHASH_ALL on the input?

Spontaneous Payments

Paymenthash passed as error

The sender of a spontaneous payment can start a bogus payment asking the recipient to return a paymenthash. The recipient generates a payment key and returns its hash as an error, so the sender can now perform a real payment using that hash. The advantage is that we still keep the receipt functionality of the payment key.

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.

Open Questions