Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-21 📝 Original message: Hey AJ and list, That's a ...
📅 Original date posted:2021-12-21
📝 Original message:
Hey AJ and list,
That's a very good point, it's really worth highlighting!
The reason we have "toxic waste" with HTLCs is because we commit to the
payment_hash directly inside the transaction scripts, so we need to
remember all the payment_hash we've seen to be able to recreate the
scripts (and spend the outputs, even if they are revoked).
But with PTLCs, we commit to a payment_point outside of the scripts (in
the adaptor signature that is exchanged), so we're able to recreate the
scripts independently of the payment details! This also means that the
payment_point never appears on-chain (which is good for privacy) whereas
the payment_hash does appear on-chain for HTLCs.
*_anchor: dust, who cares -- might be better if local_anchor used key =
> revkey
I don't think we can use revkey, this would prevent us from bumping the
current remote commitment if it appears on-chain (because we don't know
the private revkey yet if this is the latest commitment). Usually the
remote peer should bump it, but if they don't, we may want to bump it
ourselves instead of publishing our own commitment (where our main
output has a long CSV).
But as you already mentioned, who cares, it's dust and we don't even need
it to CPFP the revoked commitment, we can use any other output since the
revocation path isn't encumbered with a CSV 1.
Cheers,
Bastien
Le dim. 19 déc. 2021 à 23:23, Anthony Towns <aj at erisian.com.au> a écrit :
> On Wed, Dec 08, 2021 at 04:02:02PM +0100, Bastien TEINTURIER wrote:
> > I updated my article [0], people jumping on the thread now may find it
> > helpful to better understand this discussion.
> > [0] https://github.com/t-bast/lightning-docs/pull/16
>
> Since merged, so
> https://github.com/t-bast/lightning-docs/blob/master/taproot-updates.md
>
> So imagine that this proposal is finished and widely adopted/deployed
> and someone adds an additional feature bit that allows a channel to
> forward PTLCs only, no HTLCs.
>
> Then suppose that you forget every old PTLC, because you don't like
> having your channel state grow without bound. What happens if your
> counterparty broadcasts an old state?
>
> * the musig2 channel funding is irrelevant -- the funding tx has been
> spend at this point
>
> * the unspent commitment outputs pay to:
> to_local: ipk = musig(revkey, mykey) -- known ; scripts also known
> to_remote: claimable in 1 block, would be better if ipk was also musig
> *_anchor: dust, who cares -- might be better if local_anchor used
> key = revkey
> *_htlc: irrelevant by definition
> local_ptlc: ipk = musig(revkey, mykey) -- known; scripts also known
>
> * commitment outputs may be immediately spent via layered txs. if so,
> their outputs are: ipk = musig(revkey, mykey); with fixed scripts,
> that include a relative timelock
>
> So provided you know the revocation key (which you do, because it's an
> old transaction and that only requires log(states) data to reconstruct)
> and your own private key, you can reconstruct all the scripts and use
> key path spends for every output immediately (excepting the local_anchor,
> and to_remote is delayed by a block).
>
> So while this doesn't achieve eltoo's goal of "no toxic waste", I believe
> it does achieve the goal of "state information is bounded no matter
> how long you leave the channel open / how many transactions travel over
> the channel".
>
> (Provided you're willing to wait for the other party to attempt to claim
> a htlc via their layered transaction, you can use this strategy for
> htlcs as well as ptlcs -- however this leaves you the risk that they
> never attempt to claim the funds, which may leave you out of pocket,
> and may give them the opportunity to do an attack along the lines of
> "you don't get access to the $10,000 locked in old HTLCs unless you pay
> me $1,000". So I don't think that's really a smart thing to do)
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211221/471cbd0d/attachment.html>;
📝 Original message:
Hey AJ and list,
That's a very good point, it's really worth highlighting!
The reason we have "toxic waste" with HTLCs is because we commit to the
payment_hash directly inside the transaction scripts, so we need to
remember all the payment_hash we've seen to be able to recreate the
scripts (and spend the outputs, even if they are revoked).
But with PTLCs, we commit to a payment_point outside of the scripts (in
the adaptor signature that is exchanged), so we're able to recreate the
scripts independently of the payment details! This also means that the
payment_point never appears on-chain (which is good for privacy) whereas
the payment_hash does appear on-chain for HTLCs.
*_anchor: dust, who cares -- might be better if local_anchor used key =
> revkey
I don't think we can use revkey, this would prevent us from bumping the
current remote commitment if it appears on-chain (because we don't know
the private revkey yet if this is the latest commitment). Usually the
remote peer should bump it, but if they don't, we may want to bump it
ourselves instead of publishing our own commitment (where our main
output has a long CSV).
But as you already mentioned, who cares, it's dust and we don't even need
it to CPFP the revoked commitment, we can use any other output since the
revocation path isn't encumbered with a CSV 1.
Cheers,
Bastien
Le dim. 19 déc. 2021 à 23:23, Anthony Towns <aj at erisian.com.au> a écrit :
> On Wed, Dec 08, 2021 at 04:02:02PM +0100, Bastien TEINTURIER wrote:
> > I updated my article [0], people jumping on the thread now may find it
> > helpful to better understand this discussion.
> > [0] https://github.com/t-bast/lightning-docs/pull/16
>
> Since merged, so
> https://github.com/t-bast/lightning-docs/blob/master/taproot-updates.md
>
> So imagine that this proposal is finished and widely adopted/deployed
> and someone adds an additional feature bit that allows a channel to
> forward PTLCs only, no HTLCs.
>
> Then suppose that you forget every old PTLC, because you don't like
> having your channel state grow without bound. What happens if your
> counterparty broadcasts an old state?
>
> * the musig2 channel funding is irrelevant -- the funding tx has been
> spend at this point
>
> * the unspent commitment outputs pay to:
> to_local: ipk = musig(revkey, mykey) -- known ; scripts also known
> to_remote: claimable in 1 block, would be better if ipk was also musig
> *_anchor: dust, who cares -- might be better if local_anchor used
> key = revkey
> *_htlc: irrelevant by definition
> local_ptlc: ipk = musig(revkey, mykey) -- known; scripts also known
>
> * commitment outputs may be immediately spent via layered txs. if so,
> their outputs are: ipk = musig(revkey, mykey); with fixed scripts,
> that include a relative timelock
>
> So provided you know the revocation key (which you do, because it's an
> old transaction and that only requires log(states) data to reconstruct)
> and your own private key, you can reconstruct all the scripts and use
> key path spends for every output immediately (excepting the local_anchor,
> and to_remote is delayed by a block).
>
> So while this doesn't achieve eltoo's goal of "no toxic waste", I believe
> it does achieve the goal of "state information is bounded no matter
> how long you leave the channel open / how many transactions travel over
> the channel".
>
> (Provided you're willing to wait for the other party to attempt to claim
> a htlc via their layered transaction, you can use this strategy for
> htlcs as well as ptlcs -- however this leaves you the risk that they
> never attempt to claim the funds, which may leave you out of pocket,
> and may give them the opportunity to do an attack along the lines of
> "you don't get access to the $10,000 locked in old HTLCs unless you pay
> me $1,000". So I don't think that's really a smart thing to do)
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211221/471cbd0d/attachment.html>;