Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-06 📝 Original message:On Mon, Dec 05, 2022 at ...
📅 Original date posted:2022-12-06
📝 Original message:On Mon, Dec 05, 2022 at 09:20:58AM -0300, El_Hoy wrote:
> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the network will add a risk to miners that enable full-rbf that
> would work as an incentive against that.
>
> Obviously that would require adding an option on bitcoin core (that is not
> technically but politically difficult to implement as Petter Todd already
> have commit access to the main repository).
For the record, I do not and have never had commit access to anything under
https://github.com/bitcoin
The last time I contributed to Bitcoin Core was in Mar 1st 2017, and that was
to add an explanatory comment. Pretty much the only reason why you know my name
is I'm very good at argument and critique, I come up with some good ideas, and
conference organizers love to put me on stage.
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality. As far as I understand the percolation model, with 10 to 20
> nodes running such a rule would create a significant risk for full-rbf
> miners.
You do not understand the percolation model.
10 or 20 nodes is completely meaningless. Pools run nodes themselves, which by
default connect to 8 outgoing peers. There's about 5000 IPv4 listening nodes on
the network. When a node learns of a new block, it tells all it's peers that
the new block exists.
For your censorship to work, there has to be a substantial propability that a
miner *only* runs a single node (they don't), that has no incoming peers, and
all 8 peers of that node happen to be one of your 20 censoring nodes.
Obviously, since the probability of a given peer being a censoring node is
20/5000, all 8 being censored is extraordinarily unlikely.
Even if you ran so many nodes that 20% of the entire network was censoring, the
probability of all 8 outgoing peers being censors is only 0.2^8 = 0.000256%
This is an example of information being hard to censor and easy to spread. In
fact, for full-rbf this same math works in our favor: for a node to have a 50%
chance of connecting to at least one full-rbf peer, just 8.3% of the network
needs to run full-rbf. 5000 IPv4 nodes * 8% = 400 nodes.
The percolation threshold doesn't need to be met for this to be succesful,
because someone to just run a full-rbf node that connects to every single
listening node simultaneously.
Anyway, as others' have pointed out, you're idea is also broken in other ways.
But I thought it'd be worth pointing out how futile it is to even try.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221206/1826ac5c/attachment-0001.sig>;
📝 Original message:On Mon, Dec 05, 2022 at 09:20:58AM -0300, El_Hoy wrote:
> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the network will add a risk to miners that enable full-rbf that
> would work as an incentive against that.
>
> Obviously that would require adding an option on bitcoin core (that is not
> technically but politically difficult to implement as Petter Todd already
> have commit access to the main repository).
For the record, I do not and have never had commit access to anything under
https://github.com/bitcoin
The last time I contributed to Bitcoin Core was in Mar 1st 2017, and that was
to add an explanatory comment. Pretty much the only reason why you know my name
is I'm very good at argument and critique, I come up with some good ideas, and
conference organizers love to put me on stage.
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality. As far as I understand the percolation model, with 10 to 20
> nodes running such a rule would create a significant risk for full-rbf
> miners.
You do not understand the percolation model.
10 or 20 nodes is completely meaningless. Pools run nodes themselves, which by
default connect to 8 outgoing peers. There's about 5000 IPv4 listening nodes on
the network. When a node learns of a new block, it tells all it's peers that
the new block exists.
For your censorship to work, there has to be a substantial propability that a
miner *only* runs a single node (they don't), that has no incoming peers, and
all 8 peers of that node happen to be one of your 20 censoring nodes.
Obviously, since the probability of a given peer being a censoring node is
20/5000, all 8 being censored is extraordinarily unlikely.
Even if you ran so many nodes that 20% of the entire network was censoring, the
probability of all 8 outgoing peers being censors is only 0.2^8 = 0.000256%
This is an example of information being hard to censor and easy to spread. In
fact, for full-rbf this same math works in our favor: for a node to have a 50%
chance of connecting to at least one full-rbf peer, just 8.3% of the network
needs to run full-rbf. 5000 IPv4 nodes * 8% = 400 nodes.
The percolation threshold doesn't need to be met for this to be succesful,
because someone to just run a full-rbf node that connects to every single
listening node simultaneously.
Anyway, as others' have pointed out, you're idea is also broken in other ways.
But I thought it'd be worth pointing out how futile it is to even try.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221206/1826ac5c/attachment-0001.sig>;