From: Peter Todd <pete@petertodd•org>
To: Tom Harding <tomh@thinlink•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
Date: Mon, 29 Jun 2015 21:37:36 -0400 [thread overview]
Message-ID: <20150630013736.GA11508@savin.petertodd.org> (raw)
In-Reply-To: <5591E10F.9000008@thinlink.com>
[-- Attachment #1: Type: text/plain, Size: 2778 bytes --]
On Mon, Jun 29, 2015 at 05:21:35PM -0700, Tom Harding wrote:
> On 6/28/2015 10:07 PM, Peter Todd wrote:
> >Worryingly large payment providers have shown
> >willingness(4) to consider extreme measures such as entering into legal
> >contracts directly with large miners to ensure their transactions get mined.
> >This is a significant centralization risk and it is not practical or even
> >possible for small miners to enter into these contracts, leading to a situation
> >where moving your hashing power to a larger pool will result in higher profits
> >from hashing power contracts; if these payment providers secure a majority of
> >hashing power with these contracts inevitably there will be a temptation to
> >kick non-compliant miners off the network entirely with a 51% attack.
> >
>
> Your incomprehensible meddling with successful usage patterns
> threatens to have unintended consequences directly in opposition to
> your own stated goal of decentralization. And yet you persist.
>
> As we deliberately break things and turn the P2P network into a
> completely unpredictable hodge-podge of relay policies, we should
> expect many more participants to bypass the P2P network entirely.
>
> Many of the pieces are already in place.
>
> If we wanted the P2P network to have more predicable behavior, it
> would be possible for nodes to provide incentives to their
> neighbors. For example, if you had a pair of nodes, you could test
> your peers to see that they actually do relay "standard"
> transactions. This would have emergent usability benefits for the
> P2P network as a whole.
To be clear, full-RBF is a change that broadens what the P2P network
relays - transactions previously not relayed are now relayed. Under no
circumstance will full-RBF result in transactions *not* being relayed
that previously were relayed. This makes the P2P network more useful
rather than less, as it gives a predictable and uniform method to get
transactions to a wider variety of miners with a wider variety of
policies.
Note how even if no miners ever supported full-RBF, supporting full-RBF
on relay nodes would still be useful to users as it provides an easy and
cost-effective mechanism to rebroadcast transactions. In fact,
supporting full-RBF by default and disabling it if getblocktemplate is
called would be reasonable, if more than a bit of a hack!
In any case, my pull-req lets you set -fullrbfactivationtime=0 as a
simple and easy way to disable full-RBF functionality. Miners and relay
nodes who choose not to support it can easily do so, similar to how
OP_RETURN transactions can be disabled with -datacarrier=0
--
'peter'[:-1]@petertodd.org
00000000000000000bfe93181a10e2f12a45da877b5026ae26988e936a1322ae
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-06-30 1:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-29 5:07 Peter Todd
2015-06-29 5:40 ` Luke Dashjr
2015-06-29 5:43 ` Gregory Maxwell
2015-06-29 5:51 ` Luke Dashjr
2015-06-29 5:56 ` Peter Todd
2015-06-29 5:53 ` Peter Todd
2015-06-29 6:00 ` Luke Dashjr
2015-06-29 6:16 ` sickpig
2015-06-30 0:21 ` Tom Harding
2015-06-30 0:51 ` Natanael
2015-06-30 1:00 ` Tom Harding
2015-06-30 1:10 ` Natanael
2015-06-30 1:18 ` Tom Harding
2015-06-30 1:37 ` Peter Todd [this message]
2015-06-30 13:12 ` Adam Back
2015-06-30 13:49 ` Chris Pacia
2015-06-30 14:53 ` Peter Todd
2015-06-30 14:02 ` David A. Harding
2015-06-30 16:05 ` Peter Todd
2015-06-30 18:23 ` Chris Pacia
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=20150630013736.GA11508@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tomh@thinlink$(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