📅 Original date posted:2018-11-25
📝 Original message:
Hmm, are we willing to consider CLTV sufficient? In case you have two
HTLCs, one of medium-small value that has a low CLTV and one of high
value that has a higher CLTV, you could potentially use the soon-CLTV to
delay the commitment transaction somewhat further if you broadcast it
right as the sooner HTLC expires. This may be a bit edge-case-y but to
keep things symmetric and simplify analysis it seems simpler to just CSV
everything by 1.
As for other RBF hacks, I think you may have a hard time convincing
people to accept free relay :p.
Will kick off the discussion on bitcoin-dev once we're clear on our design.
Matt
On 11/22/18 5:12 AM, Rusty Russell wrote:
> Matt Corallo <lf-lists at mattcorallo.com> writes:
>> Ah, oops, indeed, that is much cleaner :). Still need a CSV of 1, though :(.
>
> OK, let's walk through this:
>
> Locally offered HTLC:
> - Local HTLC-Timeout tx is CLTV delayed, but remote can fulfill without delay.
> Remote offered HTLC:
> - Local HTLC-Success tx can be done without delay, but remote timeout is CLTV.
>
> IOW:
> - HTLC output scripts get a `1 OP_CSV OP_DROP` in the non-revoked branch:
>
> OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
> OP_IF
> OP_CHECKSIG
> OP_ELSE
> + 1 OP_CHECKSEQUENCEVERIFY OP_DROP
> ...
> - HTLC-Success tx needs nSequence = 1.
> - Similarly any self-generated fulfullment tx needs nSequence = 1.
>
> Yech.
>
> I still want a new RBF rule where if you pay twice the current package
> *feerate* your tx is accepted, overriding RBF rules 3, 4 & 5. Probably
> need to increase the effective minrelay feerate for any txs adding to
> that package, similarly (using that double-previous-package-feerate).
>
> That would mean we're back to a single P2WSH(OP_TRUE) with less
> blockchain spam, and life is simple. But I'll debate this on
> bitcoin-dev :)
>
> Cheers,
> Rusty.
>
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-09 12:53:02
in reply to nevent1q…ekjm
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-09 12:53:02Event JSON
{
"id": "27831b469bd241f71bff3e5a756dc3a88cbceb2bab8346b8f0dd50e9d608b849",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686315182,
"kind": 1,
"tags": [
[
"e",
"61bdb1113c2be407a2b6f72754d78bf88b3bb4d02794bc6282368d740c0e6130",
"",
"root"
],
[
"e",
"9e099d51cfc8792885d2b3c87cd418e6bf41f3b4148be778f435b5cc89331aa5",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-11-25\n📝 Original message:\nHmm, are we willing to consider CLTV sufficient? In case you have two \nHTLCs, one of medium-small value that has a low CLTV and one of high \nvalue that has a higher CLTV, you could potentially use the soon-CLTV to \ndelay the commitment transaction somewhat further if you broadcast it \nright as the sooner HTLC expires. This may be a bit edge-case-y but to \nkeep things symmetric and simplify analysis it seems simpler to just CSV \neverything by 1.\n\nAs for other RBF hacks, I think you may have a hard time convincing \npeople to accept free relay :p.\n\nWill kick off the discussion on bitcoin-dev once we're clear on our design.\n\nMatt\n\nOn 11/22/18 5:12 AM, Rusty Russell wrote:\n\u003e Matt Corallo \u003clf-lists at mattcorallo.com\u003e writes:\n\u003e\u003e Ah, oops, indeed, that is much cleaner :). Still need a CSV of 1, though :(.\n\u003e \n\u003e OK, let's walk through this:\n\u003e \n\u003e Locally offered HTLC:\n\u003e - Local HTLC-Timeout tx is CLTV delayed, but remote can fulfill without delay.\n\u003e Remote offered HTLC:\n\u003e - Local HTLC-Success tx can be done without delay, but remote timeout is CLTV.\n\u003e \n\u003e IOW:\n\u003e - HTLC output scripts get a `1 OP_CSV OP_DROP` in the non-revoked branch:\n\u003e \n\u003e OP_DUP OP_HASH160 \u003cRIPEMD160(SHA256(revocationpubkey))\u003e OP_EQUAL\n\u003e OP_IF\n\u003e OP_CHECKSIG\n\u003e OP_ELSE\n\u003e + 1 OP_CHECKSEQUENCEVERIFY OP_DROP\n\u003e ...\n\u003e - HTLC-Success tx needs nSequence = 1.\n\u003e - Similarly any self-generated fulfullment tx needs nSequence = 1.\n\u003e \n\u003e Yech.\n\u003e \n\u003e I still want a new RBF rule where if you pay twice the current package\n\u003e *feerate* your tx is accepted, overriding RBF rules 3, 4 \u0026 5. Probably\n\u003e need to increase the effective minrelay feerate for any txs adding to\n\u003e that package, similarly (using that double-previous-package-feerate).\n\u003e \n\u003e That would mean we're back to a single P2WSH(OP_TRUE) with less\n\u003e blockchain spam, and life is simple. But I'll debate this on\n\u003e bitcoin-dev :)\n\u003e \n\u003e Cheers,\n\u003e Rusty.\n\u003e",
"sig": "e273900b6b88dd0da557b98ce79c1c0e190cc69458e3ef9a23ea76767c900913eb34cacb381ffd32a34be345e72d4cdaf2ae7d22fb1ba59e1979cfee2e64b1f6"
}