Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-19 📝 Original message: On Sat, Oct 09, 2021 at ...
📅 Original date posted:2021-10-19
📝 Original message:
On Sat, Oct 09, 2021 at 11:12:07AM +1000, Anthony Towns wrote:
> Here's my proposal for replacing BOLT#2 and BOLT#3 to take advantage of
> taproot and implement PTLCs.
I think the conclusion from the discussions at the in-person LN summit
was to split these features up an implement them gradually. I think that
would look like:
1) taproot funding/anchor output
benefits:
* LN utxos just look normal, so better privacy
* mutual closes also look normal, and only need one sig and no
script, better privacy and lower fees
* doesn't require updating any HTLC scripts
complexities:
* requires implementing musig/musig2/similar for mutual
closes and signing commitment txs
* affects gossip, which wants to link channels with utxos so needs
to understand the new utxo format
* affects splicing -- maybe it's literally an update to the
splicing spec, and takes effect only when you open new channels
or splice existing ones?
2) update commitment outputs to taproot
benefits:
* slightly cheaper unilateral closes, maybe more private?
complexities:
* just need to support taproot script path spends
3) PTLC outputs
benefits:
* has a different "hash" at every hop, arguably better privacy
* can easily do cool things with points/secrets that would require
zkp's to do with hashes/secrets
* no need to remember PTLCs indefinitely in case of old
complexities:
* needs a routing feature bit
* not usable unless lots of the network upgrades to support PTLCs
* requires implementing adaptor signatures
4) symmetric commitment tx (revocation via signature info)
benefits:
* reduces complexity of layered txs?
* reduces gamesmanship of who posts the commitment tx?
* enables low-latency/offline payments?
complexities:
* requires careful nonce management?
5) low-latency payments?
benefits:
* for payments that have no problems, halves the time to complete
* the latency introduced by synchronous commitment updates doesn't
matter for successful payments, so peer protocol can be simplified
complexities:
* ?
6) offline receipt?
7) eltoo channels?
8) eltoo factories?
Cheers,
aj
📝 Original message:
On Sat, Oct 09, 2021 at 11:12:07AM +1000, Anthony Towns wrote:
> Here's my proposal for replacing BOLT#2 and BOLT#3 to take advantage of
> taproot and implement PTLCs.
I think the conclusion from the discussions at the in-person LN summit
was to split these features up an implement them gradually. I think that
would look like:
1) taproot funding/anchor output
benefits:
* LN utxos just look normal, so better privacy
* mutual closes also look normal, and only need one sig and no
script, better privacy and lower fees
* doesn't require updating any HTLC scripts
complexities:
* requires implementing musig/musig2/similar for mutual
closes and signing commitment txs
* affects gossip, which wants to link channels with utxos so needs
to understand the new utxo format
* affects splicing -- maybe it's literally an update to the
splicing spec, and takes effect only when you open new channels
or splice existing ones?
2) update commitment outputs to taproot
benefits:
* slightly cheaper unilateral closes, maybe more private?
complexities:
* just need to support taproot script path spends
3) PTLC outputs
benefits:
* has a different "hash" at every hop, arguably better privacy
* can easily do cool things with points/secrets that would require
zkp's to do with hashes/secrets
* no need to remember PTLCs indefinitely in case of old
complexities:
* needs a routing feature bit
* not usable unless lots of the network upgrades to support PTLCs
* requires implementing adaptor signatures
4) symmetric commitment tx (revocation via signature info)
benefits:
* reduces complexity of layered txs?
* reduces gamesmanship of who posts the commitment tx?
* enables low-latency/offline payments?
complexities:
* requires careful nonce management?
5) low-latency payments?
benefits:
* for payments that have no problems, halves the time to complete
* the latency introduced by synchronous commitment updates doesn't
matter for successful payments, so peer protocol can be simplified
complexities:
* ?
6) offline receipt?
7) eltoo channels?
8) eltoo factories?
Cheers,
aj