email at yancy.lol [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-08 📝 Original message:Peter, It sounds like ...
📅 Original date posted:2022-11-08
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221108/b618d371/attachment.html>;
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221108/b618d371/attachment.html>;