From: Peter Todd <pete@petertodd•org>
To: Adrian Macneil <adrian@coinbase•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Date: Fri, 19 Jun 2015 12:37:46 -0400 [thread overview]
Message-ID: <20150619163745.GA26347@savin.petertodd.org> (raw)
In-Reply-To: <CAMK47c84w=2c9y8MKHTzFf05DmKXz74a=iFViA-oZ1uRDZCAWg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3767 bytes --]
On Fri, Jun 19, 2015 at 09:18:54AM -0700, Adrian Macneil wrote:
> >
> > > So connecting to many nodes just because we can and it's not technically
> > > prevented is bad for the network and creating systemic risks of failure,
> >
> > Well it is actually; that's why myself, Wladimir van der Laan, and
> > Gregory Maxwell all specifically¹ called Chainalysis's actions a sybil
> > attack.
> >
> > The Bitcoin P2P network is resilliant to failure when the chance of any
> > one node going down is uncorrelated with others. For instance if you
> > accidentally introduced a bug in your nodes that failed to relay
> > transactions/blocks properly, you'd simultaneously be disrupting a large
> > portion of the network all at once.
> >
>
> This is exactly what your RBF patch is doing. By your own logic, nodes on
> the network should be allowed to relay (or not relay) whatever they wish.
Ah, seems you misunderstand the problem.
By properly we're concerned that things do get relayed, not that they do
not. In particularl with blocks a fairly to relay valid blocks will
quickly lead to a loss of consensus.
> > How many nodes is Coinbase connecting too? What software are they
> > running? What subnets are they using? In particular, are they all on one
> > subnet or multiple?
> >
>
> We're running about a dozen nodes running regular Bitcoin Core in various
> subnets. We aren't doing anything particularly out of the ordinary here.
> Nothing that would fall under your definition of a sybil attack or harmful
> to the network.
Right, so those dozen nodes, how many outgoing connections are they
making?
> > But of course, you'd never 51% the network right? After all it's not
> > possible to guarantee that your miner won't mine double-spends, as there
> > is no single consensus definition of which transaction came first, nor
> > can there be.
> >
> > Or do you see things differently? If I'm a small miner should I be
> > worried my blocks might be rejected by the majority with hashing power
> > contracts because I'm unable to predict which transactions Coinbase
> > believes should go in the blockchain?
> >
>
> You seem so concerned that we are actively trying to harm or control the
> network. We're simply trying to drive bitcoin adoption by making it easy
> for people to spend their bitcoin with merchants online. The problems we
> face are no different from other merchant processors, or small independent
> merchants accepting online or point-of-sale payments.
>
> We've historically had relatively little interest in what miners were doing
> (until RBF came out) - for the most part it didn't affect our business.
> However, most large merchants would be simply uninterested in accepting
> bitcoin if we forced their customers to wait 10-60 minutes for their
> payments to confirm. Many have inventory management systems which can not
> even place items on hold that long.
While your goals may be reasonable, again, the question is how are you
going to achieve them? Do you accept that you may be in a position where
you can't guarantee confirmations? Again, what's your plan to deal with
this? For instance, I know Coinbase is contractually obliged to accept
zeroconf payments with at least some of your customers - how strong are
those agreements?
What we're worried about is your plan appears to include nothing
concrete beyond the possibility of getting contracts with hashing power,
maybe even just a majority of hashing power. This is something that
should concern everyone in the Bitcoin ecosystem, and it'd help if you
clearly stated what your intentions are.
--
'peter'[:-1]@petertodd.org
00000000000000001128683847671e0ca022f9c74df90a3dc718545379101b72
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-06-19 16:38 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 10:39 Peter Todd
2015-06-19 13:33 ` Gavin Andresen
2015-06-19 13:52 ` Peter Todd
2015-06-19 14:00 ` Adrian Macneil
2015-06-19 14:08 ` Peter Todd
2015-06-19 14:30 ` Adrian Macneil
2015-06-19 14:59 ` Peter Todd
2015-06-19 15:20 ` Adrian Macneil
2015-06-19 15:40 ` Peter Todd
2015-06-19 16:18 ` Adrian Macneil
2015-06-19 16:37 ` Peter Todd [this message]
2015-06-19 20:39 ` Matt Whitlock
2015-06-19 21:05 ` Frank Flores
2015-06-19 21:15 ` Jeff Garzik
2015-06-20 0:47 ` Andreas Petersson
2015-06-20 1:09 ` Mark Friedenbach
2015-06-20 1:23 ` Aaron Voisine
2015-06-20 3:07 ` Eric Lombrozo
2015-06-20 3:48 ` Luke Dashjr
2015-06-20 4:02 ` Eric Lombrozo
2015-06-20 16:43 ` Ivan Brightly
2015-06-20 17:38 ` Cameron Hejazi
2015-06-19 14:40 ` Chun Wang
2015-06-19 15:22 ` Adrian Macneil
2015-06-19 13:33 ` Stephen Morse
2015-06-19 13:37 ` Chun Wang
2015-06-19 13:48 ` Peter Todd
2015-06-19 14:16 ` Lawrence Nahum
2015-06-19 13:40 ` Adrian Macneil
2015-06-19 13:44 ` Peter Todd
2015-06-19 13:52 ` Chun Wang
2015-06-19 15:43 ` Jeff Garzik
2015-06-19 19:49 ` Jeffrey Paul
2015-06-19 15:42 ` Jeff Garzik
2015-06-19 16:15 ` Peter Todd
2015-06-19 15:00 ` justusranvier
2015-06-19 15:11 ` Peter Todd
2015-06-19 15:37 ` Eric Lombrozo
2015-06-19 15:53 ` justusranvier
2015-06-19 16:36 ` Matt Whitlock
2015-06-19 16:42 ` Eric Lombrozo
2015-06-19 16:46 ` Matt Whitlock
2015-06-19 16:53 ` Peter Todd
2015-06-19 16:54 ` justusranvier
2015-06-19 17:00 ` Tier Nolan
2015-06-20 23:20 ` Jorge Timón
2015-06-20 23:37 ` justusranvier
2015-06-21 0:19 ` Eric Lombrozo
2015-06-21 0:27 ` justusranvier
2015-06-21 0:36 ` Eric Lombrozo
2015-06-21 0:54 ` Eric Lombrozo
2015-06-21 5:56 ` Tom Harding
2015-06-21 6:45 ` Jeff Garzik
2015-06-21 7:42 ` Eric Lombrozo
2015-06-21 8:35 ` Eric Lombrozo
2015-06-21 8:41 ` Btc Drak
2015-06-21 8:51 ` Eric Lombrozo
2015-06-21 19:49 ` Jeff Garzik
2015-06-21 18:23 ` Aaron Voisine
2015-06-19 16:44 ` justusranvier
2015-06-19 17:40 ` Jeff Garzik
2015-06-19 17:48 ` justusranvier
2015-06-19 17:50 ` Jeff Garzik
2015-06-19 18:00 ` justusranvier
2015-06-19 16:50 ` Milly Bitcoin
2015-06-19 16:41 ` [Bitcoin-development] Remove Us Please Gigas Gaming Inc.
2015-06-19 18:34 ` Jameson Lopp
2015-06-19 19:55 ` John Bodeen
2015-06-19 20:01 ` Brian Hoffman
2015-06-19 20:27 ` Jameson Lopp
2015-06-20 23:16 ` [Bitcoin-development] F2Pool has enabled full replace-by-fee Jorge Timón
2015-06-20 23:47 ` Eric Lombrozo
2015-06-20 23:52 ` Eric Lombrozo
2015-06-20 23:56 ` Eric Lombrozo
2015-06-19 15:39 ` justusranvier
2015-06-19 15:39 ` Jeff Garzik
2015-06-20 20:04 ` odinn
2015-06-21 2:11 ` Dario Sneidermanis
2015-06-21 2:23 ` Dario Sneidermanis
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=20150619163745.GA26347@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=adrian@coinbase$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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