Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-13 📝 Original message:On Wed, Oct 12, 2022 at ...
📅 Original date posted:2022-10-13
📝 Original message:On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-dev wrote:
> In my view, it is just what I said: a step towards getting full RBF
> on the network, by allowing experimentation and socializing the notion
> that developers believe it is time.
We "believe it is time" for what exactly, though? (a) To start
deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or
18 months; or (b) to start switching mainnet mining and relay nodes over
to full RBF?
As far as experimentation goes, I don't really see this option as being
very likely to help: the default for this option is still false, so it's
likely going to be difficult to get non-opt-in RBF txs relayed or mined
anywhere, even on testnet or signet, no? (Maybe that's a difficulty that's
resolved by an addnode, but it's still a difficulty) If experimentation's
the goal, making the default be true for testnet/signet at least seems
like it would be pretty useful at least. Meaningful experimentation is
probably kind of difficult in the first place while fees are low and
there's often no backlog in the mempool, as well; something that perhaps
applies more to test nets than mainnet even.
If we're trying to socialise the idea that zeroconf deprecation is
happening and that your business now has a real deadline for migrating
away from accepting unconfirmed txs if the risk of being defrauded
concerns you, then enabling experimentation on test nets and not touching
mainnet until a later release seems fairly fine to me -- similar to
activating soft forks on test nets prior to activating it on mainnet.
> So I have a hard time imagining how it
> would change anything *immediately* on the network at large (without
> things like default on and/or preferential peering, ...), but I still
> believe it's an important step.
If we're instead trying to socialise the idea that relaying and mining
full RBF txs on mainnet should be starting now, then I think that's
exactly how this *would* change things almost immediately on the network
at large.
I think all it would take in practice to be able to repeatedly defraud
businesses accepting unconfirmed txs is perhaps 5% or 10% of blocks
to include full RBF txs [0] [1], and knowing some IP addresses to
addnode so that your txs relayed to those miners. And if core devs are
advocating that full RBF is ready now [2], and a patch to easily enable
it is included in a bitcoin core release, why wouldn't some small pools
start trying it out, leading to exactly that situation?
If most of the network doesn't relay your full-rbf txs, then that's
annoying for protocol developers who'd like to rely on it, but it's fine
for an attacker: it just means the business you're trying to trick has
less chance of noticing the attack before it's too late, because they'll
be less likely to see the conflicting tx via both their own node or
public explorers.
Cheers,
aj
[0] A few months ago, Peter Todd reported switching an OTS calendar to do
non-opt-in RBF, and didn't observe bumped txs being mined, which seems
to indicate there's not much hash power currently mining full RBF.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
[1] Also why I remain surprised that accepting zeroconf is safe enough
in practice for anyone to do it. I suppose 5% of hashpower is perhaps
$100M+ investment in ASICs and $900k/day in revenue, and perhaps
all the current ways of enabling full RBF are considered too risky
to mess around with at that level.
[2] Antoine Riard's mail from June (that Peter's mail above was in reply
to) announced such a public node, and encouraged miners to start
adoption: "If you're a mining operator looking to increase your
income, you might be interested to experiment with full-rbf
as a policy." Presuming the IRC channel "##uafrbf" stands
for "user-activated full rbf", that also seems in line with
the goal being to socialise doing full RBF on mainnet immediately...
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
📝 Original message:On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-dev wrote:
> In my view, it is just what I said: a step towards getting full RBF
> on the network, by allowing experimentation and socializing the notion
> that developers believe it is time.
We "believe it is time" for what exactly, though? (a) To start
deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or
18 months; or (b) to start switching mainnet mining and relay nodes over
to full RBF?
As far as experimentation goes, I don't really see this option as being
very likely to help: the default for this option is still false, so it's
likely going to be difficult to get non-opt-in RBF txs relayed or mined
anywhere, even on testnet or signet, no? (Maybe that's a difficulty that's
resolved by an addnode, but it's still a difficulty) If experimentation's
the goal, making the default be true for testnet/signet at least seems
like it would be pretty useful at least. Meaningful experimentation is
probably kind of difficult in the first place while fees are low and
there's often no backlog in the mempool, as well; something that perhaps
applies more to test nets than mainnet even.
If we're trying to socialise the idea that zeroconf deprecation is
happening and that your business now has a real deadline for migrating
away from accepting unconfirmed txs if the risk of being defrauded
concerns you, then enabling experimentation on test nets and not touching
mainnet until a later release seems fairly fine to me -- similar to
activating soft forks on test nets prior to activating it on mainnet.
> So I have a hard time imagining how it
> would change anything *immediately* on the network at large (without
> things like default on and/or preferential peering, ...), but I still
> believe it's an important step.
If we're instead trying to socialise the idea that relaying and mining
full RBF txs on mainnet should be starting now, then I think that's
exactly how this *would* change things almost immediately on the network
at large.
I think all it would take in practice to be able to repeatedly defraud
businesses accepting unconfirmed txs is perhaps 5% or 10% of blocks
to include full RBF txs [0] [1], and knowing some IP addresses to
addnode so that your txs relayed to those miners. And if core devs are
advocating that full RBF is ready now [2], and a patch to easily enable
it is included in a bitcoin core release, why wouldn't some small pools
start trying it out, leading to exactly that situation?
If most of the network doesn't relay your full-rbf txs, then that's
annoying for protocol developers who'd like to rely on it, but it's fine
for an attacker: it just means the business you're trying to trick has
less chance of noticing the attack before it's too late, because they'll
be less likely to see the conflicting tx via both their own node or
public explorers.
Cheers,
aj
[0] A few months ago, Peter Todd reported switching an OTS calendar to do
non-opt-in RBF, and didn't observe bumped txs being mined, which seems
to indicate there's not much hash power currently mining full RBF.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
[1] Also why I remain surprised that accepting zeroconf is safe enough
in practice for anyone to do it. I suppose 5% of hashpower is perhaps
$100M+ investment in ASICs and $900k/day in revenue, and perhaps
all the current ways of enabling full RBF are considered too risky
to mess around with at that level.
[2] Antoine Riard's mail from June (that Peter's mail above was in reply
to) announced such a public node, and encouraged miners to start
adoption: "If you're a mining operator looking to increase your
income, you might be interested to experiment with full-rbf
as a policy." Presuming the IRC channel "##uafrbf" stands
for "user-activated full rbf", that also seems in line with
the goal being to socialise doing full RBF on mainnet immediately...
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html