📅 Original date posted:2021-12-21
📝 Original message:
On Tue, Dec 21, 2021 at 04:25:41PM +0100, Bastien TEINTURIER wrote:
> 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).
I think "toxic waste" refers to having old data around that, if used,
could cause you to lose all the funds in your channel -- that's why it's
toxic. This is more just regular landfill :)
> *_anchor: dust, who cares -- might be better if local_anchor used key =
> > revkey
> I don't think we can use revkey,
musig(revkey, remote_key)
--> allows them to spend after you've revealed the secret for revkey
you can never spend because you'll never know the secret for
remote_key
but if you just say:
(revkey)
then you can spend (because you know revkey) immediately (because it's
an anchor output, so intended to be immediately spent) or they can spend
if it's an obsolete commitment and you've revealed the revkey secret.
> 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).
If we're going to bump someone else's commitment, we'll use the
remote_anchor they provided, not the local_anchor, so I think this is
fine (as long as I haven't gotten local/remote confused somewhere along
the way).
Cheers,
aj
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 13:04:41
in reply to nevent1q…v8kk
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 13:04:41Event JSON
{
"id": "ca63b975371eee3a4c07339e96e4ffabb484809f64c38042f92f2b1d1eb414eb",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686315881,
"kind": 1,
"tags": [
[
"e",
"86d882af7142eecbdb4ce698181b82aaa475c9b46541e1e4831400616b496e77",
"",
"root"
],
[
"e",
"60cf173f30b087f328c2bb80edf29fec6fa5408d104c4c569f356ee694f40ecd",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "📅 Original date posted:2021-12-21\n📝 Original message:\nOn Tue, Dec 21, 2021 at 04:25:41PM +0100, Bastien TEINTURIER wrote:\n\u003e The reason we have \"toxic waste\" with HTLCs is because we commit to the\n\u003e payment_hash directly inside the transaction scripts, so we need to\n\u003e remember all the payment_hash we've seen to be able to recreate the\n\u003e scripts (and spend the outputs, even if they are revoked).\n\nI think \"toxic waste\" refers to having old data around that, if used,\ncould cause you to lose all the funds in your channel -- that's why it's\ntoxic. This is more just regular landfill :)\n\n\u003e *_anchor: dust, who cares -- might be better if local_anchor used key =\n\u003e \u003e revkey\n\u003e I don't think we can use revkey, \n\nmusig(revkey, remote_key) \n --\u003e allows them to spend after you've revealed the secret for revkey\n you can never spend because you'll never know the secret for\n remote_key\n\nbut if you just say:\n\n(revkey)\n\nthen you can spend (because you know revkey) immediately (because it's\nan anchor output, so intended to be immediately spent) or they can spend\nif it's an obsolete commitment and you've revealed the revkey secret.\n\n\u003e this would prevent us from bumping the\n\u003e current remote commitment if it appears on-chain (because we don't know\n\u003e the private revkey yet if this is the latest commitment). Usually the\n\u003e remote peer should bump it, but if they don't, we may want to bump it\n\u003e ourselves instead of publishing our own commitment (where our main\n\u003e output has a long CSV).\n\nIf we're going to bump someone else's commitment, we'll use the\nremote_anchor they provided, not the local_anchor, so I think this is\nfine (as long as I haven't gotten local/remote confused somewhere along\nthe way).\n\nCheers,\naj",
"sig": "7d4155bbabacef388326889c8b2e1cbfc2667017ac6578a61734d652c6f716510bb9101edf01371a6d0b3b7ba58aba999c2c18d52d444a6ee788b69a7e4abbff"
}