From aj at erisian.com.au  Tue Oct 19 06:26:50 2021
From: aj at erisian.com.au (Anthony Towns)
Date: Tue, 19 Oct 2021 16:26:50 +1000
Subject: [Lightning-dev] Lightning over taproot with PTLCs
In-Reply-To: <20211009011207.GA3984@erisian.com.au>
References: <20211009011207.GA3984@erisian.com.au>
Message-ID: <20211019062650.GB1515@erisian.com.au>

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