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

[Peter Todd]

On Wed, Jul 15, 2015 at 11:25:17AM -0700, Matthieu Riou via bitcoin-dev wrote:
> Hi,
> 
> Thanks for the bug report Simon, "responsible" disclosure on public forums
> is always appreciated. We're working with ShapeShift to make sure we can
> protect them appropriately against this specific attack in the future. As
> "Me" and Adrian advised, I would also encourage you return the funds.
> 
> Regarding Peter's accusations on Twitter/Reddit/listserve, we have no idea
> why we are his target. He has never met with our CEO, has no idea of our
> business model, nor our company objectives. All his comments about us are
> his speculations. I'm sure Peter knows what a Sybil attack actually is and
> making such claims on a public forum is completely unfounded and uncalled
> for. Stretching definitions beyond the point where they make sense is a
> common rhetoric and political tool, not necessarily appropriate in a
> professional or technical context.

"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."

Quoting your API docs:

"[Blockcypher is] always connected to a statistically significant number
of nodes on the network - we target anywhere between 10 to 20% of the
active nodes on any given blockchain"
-http://dev.blockcypher.com/#confidence-factor

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.

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)

Right now the P2P network has relatively weak protections against sybil
attacks, but efforts are being made to find ways to defend against them.
As anti-sybil attack technology improves, you'll be able to
simultaneously connect to a smaller and smaller % of the network, and
your confidence factor technology will degrade further.

Questions: How exactly does your monitoring network work? Do you make
incoming, outgoing, or both types of connections? What subnet(s) do the
connections come from? What software makes those connections?

> We offer useful services for many startups like ourselves. We are good
> actors in this space. As a startup we are also constrained by limited
> resources (we're funded but far from larger companies resources). Companies
> aren't built in a single day and we hope to do more to help
> decentralization in the future as well. We're trying to further the
> ecosystem with our small team, so the pot shots are puzzling.

What you are doing is inherently incompatible with decentralization.
Your service simply doesn't scale; it's a server only a small number of
centralized entities can provide without causing the P2P network to
collapse due to resource exhaustion.

Question: Do you have relationships with mining pools? For instance, are
you looking at contracts to have transactions mined to guarantee
confirmations?

1) http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/

-- 
'peter'[:-1]@petertodd.org
00000000000000000b675c4d825a10c278b8d63ee4df90a19393f3b6498fd073
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150716/d8b266f6/attachment.sig>