From: Peter Todd <pete@petertodd•org>
To: Matthieu Riou <matthieu@blockcypher•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
Date: Thu, 16 Jul 2015 04:32:59 +0900 [thread overview]
Message-ID: <20150715193259.GC3064@muck> (raw)
In-Reply-To: <CAHUNwMp3-jNc9g0shCUCR76WEA5Qp+JpxZGPmAuK5wuy4p1yEw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3810 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-07-15 19:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-15 3:29 simongreen
2015-07-15 14:35 ` Tom Harding
2015-07-15 15:18 ` Peter Todd
2015-07-15 15:49 ` Me
2015-07-15 15:53 ` Bastiaan van den Berg
2015-07-15 15:59 ` Peter Todd
2015-07-15 16:06 ` Me
2015-07-15 16:11 ` Pieter Wuille
2015-07-15 16:41 ` Me
2015-07-15 16:12 ` Milly Bitcoin
2015-07-15 18:25 ` Matthieu Riou
2015-07-15 19:32 ` Peter Todd [this message]
2015-07-15 19:57 ` Milly Bitcoin
2015-07-16 0:08 ` Matthieu Riou
2015-07-16 5:18 ` odinn
2015-07-17 11:59 ` Peter Todd
2015-07-17 12:56 ` Milly Bitcoin
2015-07-15 17:01 ` Adrian Macneil
2015-07-16 14:30 ` Arne Brutschy
2015-07-16 14:50 ` Me
2015-07-16 15:33 ` Greg Schvey
2015-07-18 11:43 ` Mike Hearn
2015-07-18 15:09 ` Peter Todd
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=20150715193259.GC3064@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=matthieu@blockcypher$(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