Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-19 📝 Original message: On Wed, Dec 08, 2021 at ...
📅 Original date posted:2021-12-19
📝 Original message:
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
📝 Original message:
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