public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: El_Hoy <eloyesp@gmail•com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	Daniel Lipshitz <daniel@gap600•com>
Subject: Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
Date: Tue, 6 Dec 2022 00:39:40 -0500	[thread overview]
Message-ID: <Y47VnGNMt/p5W32U@petertodd.org> (raw)
In-Reply-To: <CAPapNH3NEBP2-GVZZ_75K-QU0psGdAHyjdAus-vfq-0jffTstg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2022-12-06  5:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-02  9:26 Peter Todd
2022-11-02 19:02 ` alicexbt
2022-11-03 13:32   ` Erik Aronesty
2022-11-09 12:14     ` email
2022-11-08 18:16 ` Peter Todd
2022-11-15  5:36   ` Anthony Towns
2022-11-15 14:43     ` Peter Todd
2022-12-05 12:20       ` El_Hoy
2022-12-05 13:38         ` Greg Sanders
2022-12-05 14:12         ` Rijndael
2022-12-05 15:33           ` Michael Folkson
2022-12-05 17:00           ` Erik Aronesty
2022-12-06  4:48             ` El_Hoy
2022-12-05 17:25           ` El_Hoy
2022-12-06  5:39         ` Peter Todd [this message]
2022-12-06  7:37           ` Peter Todd
2022-12-09 16:04     ` 0xB10C
2022-12-09 21:16       ` Peter Todd
2022-12-10 11:59         ` 0xB10C
2022-12-10 18:07           ` Peter Todd
2022-12-13  4:01       ` Anthony Towns

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y47VnGNMt/p5W32U@petertodd.org \
    --to=pete@petertodd$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=daniel@gap600$(echo .)com \
    --cc=eloyesp@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox