From: Tom Harding <tomh@thinlink.com>
To: Peter Todd <pete@petertodd.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule
Date: Mon, 29 Jun 2015 17:21:35 -0700 [thread overview]
Message-ID: <5591E10F.9000008@thinlink.com> (raw)
In-Reply-To: <20150629050726.GA502@savin.petertodd.org>
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.
next prev parent reply other threads:[~2015-06-30 0:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-29 5:07 [bitcoin-dev] BIP: Full Replace-by-Fee deployment schedule 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 [this message]
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
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=5591E10F.9000008@thinlink.com \
--to=tomh@thinlink.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=pete@petertodd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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