Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-31 📝 Original message: > > On Oct 30, 2019, at ...
📅 Original date posted:2019-10-31
📝 Original message:
>
> On Oct 30, 2019, at 06:04, Joost Jager <joost.jager at gmail.com> wrote:
>
> > For the anchor outputs we consider:
>> >
>> > * Output type: normal P2WKH. At one point, an additional spending path
>> was
>> > proposed that was unconditional except for a 10 block csv lock. The
>> > intention of this was to prevent utxo set pollution by allowing anyone
>> to
>> > clean up. This however also opens up the possibility for an attacker to
>> > 'use up' the cpfp carve-out after those 10 blocks. If the user A is
>> offli=
>> ne
>> > for that period of time, a malicious peer B may already have broadcasted
>> > the commitment tx and pinned down user A's anchor output with a low fee
>> > child. That way, the commitment tx could still remain unconfirmed while
>> an
>> > important htlc expires.
>>
>> Agreed, this doesn't really work. We actually needed a bitcoin rule
>> that allowed a single anyone-can-spend output. Seems like we didn't get
>> that.
>>
>
> With the mempool acceptance carve-out in bitcoind 0.19, we indeed won't be
> able to safely produce a single OP_TRUE output for anyone to spend. An
> attacker could attach low fee child transactions, reach the limits and
> block further fee bumping.
>
>
> Quick correction. This is only partially true. You can still RBF the
> sub-package, the only issue I see immediately is you have to pay for the
> otherwise-free relay of everything the attacker relayed.
>
Ok, so this is always possible because the commitment transaction is
signaling opt-in rbf and therefore any child txes are too? From bip125:
"Transactions that don't explicitly signal replaceability are replaceable
under this policy for as long as any one of their ancestors signals
replaceability and remains unconfirmed." But yes, it can get unnecessarily
expensive to replace everything that the attacker added.
> Why not stick with the original design from Adelaide with a spending path
> with a 1CSV that is anyone can spend (or that is revealed by spending
> another output).
>
What script would this be exactly? While still unconfirmed, the anchor
needs to be protected from being spent by anyone for the carve-out to work.
This also means that anyone spending after the csv needs to know that
script too. But how can they know if there is something like a pubkey (that
protected it during the unconfirmed phase) in it?
Joost.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191031/2ce49811/attachment.html>;
📝 Original message:
>
> On Oct 30, 2019, at 06:04, Joost Jager <joost.jager at gmail.com> wrote:
>
> > For the anchor outputs we consider:
>> >
>> > * Output type: normal P2WKH. At one point, an additional spending path
>> was
>> > proposed that was unconditional except for a 10 block csv lock. The
>> > intention of this was to prevent utxo set pollution by allowing anyone
>> to
>> > clean up. This however also opens up the possibility for an attacker to
>> > 'use up' the cpfp carve-out after those 10 blocks. If the user A is
>> offli=
>> ne
>> > for that period of time, a malicious peer B may already have broadcasted
>> > the commitment tx and pinned down user A's anchor output with a low fee
>> > child. That way, the commitment tx could still remain unconfirmed while
>> an
>> > important htlc expires.
>>
>> Agreed, this doesn't really work. We actually needed a bitcoin rule
>> that allowed a single anyone-can-spend output. Seems like we didn't get
>> that.
>>
>
> With the mempool acceptance carve-out in bitcoind 0.19, we indeed won't be
> able to safely produce a single OP_TRUE output for anyone to spend. An
> attacker could attach low fee child transactions, reach the limits and
> block further fee bumping.
>
>
> Quick correction. This is only partially true. You can still RBF the
> sub-package, the only issue I see immediately is you have to pay for the
> otherwise-free relay of everything the attacker relayed.
>
Ok, so this is always possible because the commitment transaction is
signaling opt-in rbf and therefore any child txes are too? From bip125:
"Transactions that don't explicitly signal replaceability are replaceable
under this policy for as long as any one of their ancestors signals
replaceability and remains unconfirmed." But yes, it can get unnecessarily
expensive to replace everything that the attacker added.
> Why not stick with the original design from Adelaide with a spending path
> with a 1CSV that is anyone can spend (or that is revealed by spending
> another output).
>
What script would this be exactly? While still unconfirmed, the anchor
needs to be protected from being spent by anyone for the carve-out to work.
This also means that anyone spending after the csv needs to know that
script too. But how can they know if there is something like a pubkey (that
protected it during the unconfirmed phase) in it?
Joost.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191031/2ce49811/attachment.html>;