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.

Signature Aggregation

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

Splice-in/-out / Reanchoring

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.

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.

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. We have an existing way of secretly communicating information to any hop along the route, namely the onion packet and its per_hop fields. So we could use the per_hop field for the recipient to pass a random secret that can be mixed with some public information to create the payment_hash.

The whole thing would work like this:

1. Sender generates a 12 byte random secret
2. The sender constructs the routing onion, putting the secret into the per_hop field destined for the recipient
3. The sender computes a payment_hash as payment_hash = Hash(Hash(recipient_id || secret))
4. The sender initiates the payment
5. Upon receiving the transfer, the recipient notices that it is the last hop, and that it doesn't know the payment_preimage for the transfer
6. The recipient extracts secret from the routing onion and computes payment_preimage = Hash(recipient_id || secret)
7. The recipient can claim the transfer by using payment_preimage as the preimage.

The 12 byte limit is due to the fact that we are already using 20 bytes in the per_hop field for other data, but we could possibly reclaim some of the fields if it isn't used for validation of the transfer. Notice that the hash-function to generate the payment_preimage does not necessarily have to be the same used in the HTLC and could be any pseudo-random function.

The upside of this is that it still requires just one round-trip as compared to the hash-in-error method, but may produce weaker preimages since we only have 12 bytes of randomness available to mix in.

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.

Open Questions