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