email at yancy.lol [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-09 📝 Original message:> Bob has staked liquidity ...
📅 Original date posted:2022-11-09
📝 Original message:> Bob has staked liquidity in a payment channel with Alice who later
> double spends the same inputs (at a very low feerate) resulting in a
> stalemate where neither can spend the UTXOs.
I just realized I made a mistake. RBF will always mine the higher fee
transaction, so in this case, full-rbf would prevent a transaction from
being pinned.
On 2022-11-08 15:54, yancy via bitcoin-dev wrote:
> Peter,
>
> It sounds like there are two attack vectors; neither of which require
> full-rbf (correct me if I'm wrong).
>
> 1) Bob has staked liquidity in a payment channel with Alice who later
> double spends the same inputs (at a very low feerate) resulting in a
> stalemate where neither can spend the UTXOs. The TX that creates the
> payment channel with Bob will never be mined since the mining pool
> sees the double spend?
>
> 2) Alice spams the network with a double spend wide enough that the
> double spend makes it into a block before the remainder of the network
> sees the first spend.
>
> In that case of 1), what if Bob required a opt-in rbf? Wouldn't that
> solve the issue? Bob could just create a replacement transaction with
> enough fee to get back his UTXO?
>
> For 2) it seems to me that neither full-rbf or opt-in rbf resolves
> this, although it's a probabilistic attack and requires spamming many
> nodes.
>
> Cheers,
> -Yancy
>
> On 2022-11-07 15:32, Peter Todd wrote:
>
>> On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> AJ/Antoine et al
>>
>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
>> solve that problem if they have only opt-in RBF available?
>> Assuming Alice is a well funded advisory, with enough resources to
>> spam the network so that enough nodes see her malicious transaction
>> first, how does full-rbf solve this vs. opt-in rbf?
>
> First of all, to make things clear, remember that the attacks were
> talking about are aimed at _preventing_ a transaction from getting
> mined. Alice wants to cheaply broadcast something with low fees that
> won't get mined soon (if ever), that prevents a protocol from making
> forward progress.
>
> With full-rbf, who saw what transaction first doesn't matter: the
> higher fee paying transaction will always(*) replace the lower fee
> one. With opt-in RBF, spamming the network can beat out the
> alternative.
>
> *) So what's the catch? Well, due to limitations in today's mempool
> implementation, sometimes we can't fully evaluate which tx pays the
> higher fee. For example, if Alice spams the network with very _large_
> numbers transactions spending that input, the current mempool code
> doesn't even try to figure out if a replacement is better.
>
> But those limitations are likely to be fixable. And even right now,
> without fixing them, Alice still has to use a lot more money to pull
> off these attacks with full-rbf. So full-rbf definitely improves the
> situation even if it doesn't solve the problem completely.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221109/fa0bd0e1/attachment-0001.html>;
📝 Original message:> Bob has staked liquidity in a payment channel with Alice who later
> double spends the same inputs (at a very low feerate) resulting in a
> stalemate where neither can spend the UTXOs.
I just realized I made a mistake. RBF will always mine the higher fee
transaction, so in this case, full-rbf would prevent a transaction from
being pinned.
On 2022-11-08 15:54, yancy via bitcoin-dev wrote:
> Peter,
>
> It sounds like there are two attack vectors; neither of which require
> full-rbf (correct me if I'm wrong).
>
> 1) Bob has staked liquidity in a payment channel with Alice who later
> double spends the same inputs (at a very low feerate) resulting in a
> stalemate where neither can spend the UTXOs. The TX that creates the
> payment channel with Bob will never be mined since the mining pool
> sees the double spend?
>
> 2) Alice spams the network with a double spend wide enough that the
> double spend makes it into a block before the remainder of the network
> sees the first spend.
>
> In that case of 1), what if Bob required a opt-in rbf? Wouldn't that
> solve the issue? Bob could just create a replacement transaction with
> enough fee to get back his UTXO?
>
> For 2) it seems to me that neither full-rbf or opt-in rbf resolves
> this, although it's a probabilistic attack and requires spamming many
> nodes.
>
> Cheers,
> -Yancy
>
> On 2022-11-07 15:32, Peter Todd wrote:
>
>> On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> AJ/Antoine et al
>>
>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
>> solve that problem if they have only opt-in RBF available?
>> Assuming Alice is a well funded advisory, with enough resources to
>> spam the network so that enough nodes see her malicious transaction
>> first, how does full-rbf solve this vs. opt-in rbf?
>
> First of all, to make things clear, remember that the attacks were
> talking about are aimed at _preventing_ a transaction from getting
> mined. Alice wants to cheaply broadcast something with low fees that
> won't get mined soon (if ever), that prevents a protocol from making
> forward progress.
>
> With full-rbf, who saw what transaction first doesn't matter: the
> higher fee paying transaction will always(*) replace the lower fee
> one. With opt-in RBF, spamming the network can beat out the
> alternative.
>
> *) So what's the catch? Well, due to limitations in today's mempool
> implementation, sometimes we can't fully evaluate which tx pays the
> higher fee. For example, if Alice spams the network with very _large_
> numbers transactions spending that input, the current mempool code
> doesn't even try to figure out if a replacement is better.
>
> But those limitations are likely to be fixable. And even right now,
> without fixing them, Alice still has to use a lot more money to pull
> off these attacks with full-rbf. So full-rbf definitely improves the
> situation even if it doesn't solve the problem completely.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221109/fa0bd0e1/attachment-0001.html>;