Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions

[Peter Todd <pete@petertodd.org>]

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

On Wed, Jul 15, 2015 at 05:08:05PM -0700, Matthieu Riou via bitcoin-dev wrote:
> On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd <pete@petertodd.org> wrote:
> 
> >
> > "In a Sybil attack the attacker subverts the reputation system of a
> > peer-to-peer network by creating a large number of pseudonymous
> > identities, using them to gain a disproportionately large influence."
> >
> 
> Our "identities" aren't pseudonymous.

Then are you willing to tell us what IP addresses your nodes connect
from? This is important network stability information due to how nodes
prevent a lack of diversity in their outgoing connections.

> In the case of Bitcoin, there's something like 6,000 nodes, so if that
> > 20% is achived via outgoing connections you'd have 600 to 1200 active
> > outgoing connections using up network resources.  Meanwhile, the default
> > is 8 outgoing connections - you're using about two orders of magnitude
> > more resources.
> >
> 
> You're not talking about a Sybil attack anymore, just resource use. We do
> know how to change default configurations to offer more connections.

The Bitcoin P2P network's primary concern is reliability through
diversity; you are harming that resource.

So to be clear, you have both a high level of outgoing and incoming
connections? Given that Bitcoin nodes only connect to eight outgoing
peers, how do you manage to connect to your claimed 10%-20% of all
reachable nodes? Obviously you can't be doing that with just incoming
connections, unless you're running hundreds of nodes, or doing an addr
spamming attack.

> If you are achieving that via incoming connections, you're placing a big
> > part of the relay network under central control. As we've seen in the
> > case of Chainalysis's sybil attack, even unintentional confirguation
> > screwups can cause serious and widespread issues due to the large number
> > of nodes that can fail in one go. (note how Chainalysis's actions were
> > described(1) as a sybil attack by multiple Bitcoin devs, including
> > Gregory Maxwell, Wladimir van der Laan, and myself)
> >
> 
> We're not Chainanalysis and we do not run hundreds of distinct nodes. Just
> a few well-tuned ones.

It's actually marginally better for the network if you're using hundreds
of distinct nodes rather than just a few to do this sybil attack - the
chance of your small number of nodes suddenly going off-line and causing
propagation issues is more than hundreds of nodes all going off-line
suddenly. Additionally it's easier for bad actors to survail your few
internet connections to easily get tx propagation information from the
network than it is to survail Chainalysis's setup. (ironic I know)

> > What you are doing is inherently incompatible with decentralization.
> >
> 
> That's a matter of opinion. One could argue your actions and control
> attempts hurt decentralization. Either way, no one should play the
> decentralization police or act as a gatekeeper.

"Control attempts"? Care to explain?

Re: "gatekeeping" - fact is your business model and technology can only
be succesfully run by a small number of entities at once, resulting in a
situation where those few companies act as gatekeepers for access to
zeroconf confirmation probability information.

> Question: Do you have relationships with mining pools? For instance, are
> > you looking at contracts to have transactions mined to guarantee
> > confirmations?
> >
> 
> No, we do not. We do not know anyone else having such contracts. As you
> know, Coinbase also denied having such contracts in place [1]. But you seem
> to have more relationships with mining pools than we do.

Nice cheap shot there. My "relationships" are nothing more than people
being willing to talk to me, ask me for advice, and warn me about
possible threats. They're not legal contracts.

-- 
'peter'[:-1]@petertodd.org
0000000000000000138147be90db48b8338de6d58cc6b60e6ad360f6ef486d8c

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]