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

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

[simongreen]

With my black hat on I recently performed numerous profitable 
double-spend attacks against zeroconf accepting fools. With my white hat 
on, I'm warning everyone. The strategy is simple:

tx1: To merchant, but dust/low-fee/reused-address/large-size/etc. 
anything that miners don't always accept.

tx2: After merchant gives up valuable thing in return, normal tx without 
triggering spam protections. (loltasticly a Mike Hearn Bitcoin XT node 
was used to relay the double-spends)

Example success story: tx1 paying Shapeshift.io with 6uBTC output is not 
dust under post-Hearn-relay-drop rules, but is dust under 
pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not 
paying Shapeshift.io. F2Pool/Eligius/BTCChina/AntPool etc. are all 
miners who have reverted Hearn's 10x relay fee drop as recommended by 
v0.11.0 release notes and accept these double-spends. Shapeshift.io lost 
~3 BTC this week in multiple txs. (they're no longer accepting zeroconf)

Example success story #2: tx1 with post-Hearn-relay drop fee, followed 
by tx2 with higher fee. Such stupidly low fee txs just don't get mined, 
so wait for a miner to mine tx2. Bought a silly amount of reddit gold 
off Coinbase this way among other things. I'm surprised that reddit 
didn't cancel the "fools-gold" after tx reversal. (did Coinbase 
guarantee those txs?) Also found multiple Bitcoin ATMs vulnerable to 
this attack. (but simulated attack with tx2s still paying ATM because 
didn't want to go to trouble of good phys opsec)

Shoutouts to BitPay who did things right and notified merchant properly 
when tx was reversed.

In summary, every target depending on zeroconf vulnerable and lost 
significant sums of money to totally trivial attacks with high 
probability. No need for RBF to do this, just normal variations in miner 
policy. Shapeshift claims to use Super Sophisticated Network Sybil 
Attacking Monitoring from Blockcypher, but relay nodes != miner policy.

Consider yourself warned! My hat is whiter than most, and my skills not 
particularly good.

What to do? Users: Listen to the experts and stop relying on zeroconf. 
Black hats: Profit!

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

[Tom Harding]

You perform a valuable service with your demonstration, but you
neglected to include the txid's to show that you actually did it.

Your advice is must-follow for anyone relying on an unconfirmed tx: it
must pay a good fee and be highly relayable/minable.


On 7/14/2015 8:29 PM, simongreen--- via bitcoin-dev wrote:
> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc.
> anything that miners don't always accept. 

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

[Peter Todd]

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

On Wed, Jul 15, 2015 at 07:35:21AM -0700, Tom Harding via bitcoin-dev wrote:
> 
> You perform a valuable service with your demonstration, but you
> neglected to include the txid's to show that you actually did it.
 
> Your advice is must-follow for anyone relying on an unconfirmed tx: it
> must pay a good fee and be highly relayable/minable.

Actually, I was looking at what I believe was (part of?) this attack
yesterday in the logs on my full-RBF nodes and the txs involved *did*
have good fees and were highly relayable/minable - the double-spent txs
had near 100% propagation on blockchain.info (who has unfortunately
purged the relevant data already)

Shapeshift.io depends on Blockcypher's "confidence factor" model(1)
under the hood - yet another one of those sybil attacking network
monitoring things - to estimate tx confirmation probability by looking
at the % of nodes a tx has propagated too. But miners frequently use
customized Bitcoin Core codebases that don't follow normal policies, so
those measurements don't actually tell you what you need to know.

hapeshift confirmed(2) the attack - confirming that they disabled
unconfirmed tx acceptance - said they're going to "improve" their
system... It'll be interesting to see what that actually entails.

1) https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
2) https://www.reddit.com/r/Bitcoin/comments/3ddkhy/bitcoindev_significant_losses_by_doublespending/ct468p7

-- 
'peter'[:-1]@petertodd.org
000000000000000010bf087ed645cba129e2523930d5cde636ddbae9e03aef9c

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

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

[Me]

Thank you Simon for sharing your tests, if possible can you share TX hashes please. I would recommend to send them money post-mortem. What you did is really valuable information, however it can be classified as fraud. I really don’t want open this topic here, just suggesting to keep your record clean :-) 



> the double-spent txs
> had near 100% propagation on blockchain.info (who has unfortunately
> purged the relevant data already)


Can you please share the TX Hash



> Blockcypher's "confidence factor" model(1)
> under the hood - yet another one of those sybil attacking network
> monitoring things


Peter, I noticed on your twitter you have a lot of bad things to say about Blockcypher and their business model (which I might not full agree, but totally respect), can you share any evidence they perform any form of Sybil attack on the network, please. 






> On Jul 15, 2015, at 8:18 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> On Wed, Jul 15, 2015 at 07:35:21AM -0700, Tom Harding via bitcoin-dev wrote:
>> 
>> You perform a valuable service with your demonstration, but you
>> neglected to include the txid's to show that you actually did it.
> 
>> Your advice is must-follow for anyone relying on an unconfirmed tx: it
>> must pay a good fee and be highly relayable/minable.
> 
> Actually, I was looking at what I believe was (part of?) this attack
> yesterday in the logs on my full-RBF nodes and the txs involved *did*
> have good fees and were highly relayable/minable - the double-spent txs
> had near 100% propagation on blockchain.info (who has unfortunately
> purged the relevant data already)
> 
> Shapeshift.io depends on Blockcypher's "confidence factor" model(1)
> under the hood - yet another one of those sybil attacking network
> monitoring things - to estimate tx confirmation probability by looking
> at the % of nodes a tx has propagated too. But miners frequently use
> customized Bitcoin Core codebases that don't follow normal policies, so
> those measurements don't actually tell you what you need to know.
> 
> hapeshift confirmed(2) the attack - confirming that they disabled
> unconfirmed tx acceptance - said they're going to "improve" their
> system... It'll be interesting to see what that actually entails.
> 
> 1) https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
> 2) https://www.reddit.com/r/Bitcoin/comments/3ddkhy/bitcoindev_significant_losses_by_doublespending/ct468p7
> 
> -- 
> 'peter'[:-1]@petertodd.org
> 000000000000000010bf087ed645cba129e2523930d5cde636ddbae9e03aef9c
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Bastiaan van den Berg]

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

On Wed, Jul 15, 2015 at 5:49 PM, Me via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > Blockcypher's "confidence factor" model(1)
> > under the hood - yet another one of those sybil attacking network
> > monitoring things
>
>
> Peter, I noticed on your twitter you have a lot of bad things to say about
> Blockcypher and their business model (which I might not full agree, but
> totally respect), can you share any evidence they perform any form of Sybil
> attack on the network, please.


? He says it -monitors- for such a attack, usually monitoring does not
include causing it ;)

--
buZz

[-- Attachment #2: Type: text/html, Size: 1033 bytes --]

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

[Peter Todd]

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

On Wed, Jul 15, 2015 at 08:49:13AM -0700, Me wrote:
> > Blockcypher's "confidence factor" model(1)
> > under the hood - yet another one of those sybil attacking network
> > monitoring things
> 
> 
> Peter, I noticed on your twitter you have a lot of bad things to say about Blockcypher and their business model (which I might not full agree, but totally respect), can you share any evidence they perform any form of Sybil attack on the network, please. 

For Blockcypher to succesfully do what they claim to do they need to
connect to a large % of nodes on the network; that right there is a
sybil attack. It's an approach that uses up connection slots for the
entire network and isn't scalable; if more than a few services were
doing that the Bitcoin network would become significantly less reliable,
at some point collapsing entirely.

-- 
'peter'[:-1]@petertodd.org
0000000000000000093f699ccdb323aa638af1131249ec2e1bacbf367163807a

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

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

[Me]

Have you talk to them? If not, how can you be sure they don’t run large number of standard nodes and actually make the network stronger? Personally I never bring claims like this if I just assume. A lot of people in the community really trust you, do you realize you potentially hurt them for no reason?


btw I do not work for them nor have any money invested in them in case anybody asks





> On Jul 15, 2015, at 8:59 AM, Peter Todd <pete@petertodd.org> wrote:
> 
> On Wed, Jul 15, 2015 at 08:49:13AM -0700, Me wrote:
>>> Blockcypher's "confidence factor" model(1)
>>> under the hood - yet another one of those sybil attacking network
>>> monitoring things
>> 
>> 
>> Peter, I noticed on your twitter you have a lot of bad things to say about Blockcypher and their business model (which I might not full agree, but totally respect), can you share any evidence they perform any form of Sybil attack on the network, please. 
> 
> For Blockcypher to succesfully do what they claim to do they need to
> connect to a large % of nodes on the network; that right there is a
> sybil attack. It's an approach that uses up connection slots for the
> entire network and isn't scalable; if more than a few services were
> doing that the Bitcoin network would become significantly less reliable,
> at some point collapsing entirely.
> 
> -- 
> 'peter'[:-1]@petertodd.org
> 0000000000000000093f699ccdb323aa638af1131249ec2e1bacbf367163807a

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

[Pieter Wuille]

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

On Wed, Jul 15, 2015 at 12:06 PM, Me via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Have you talk to them? If not, how can you be sure they don’t run large
> number of standard nodes and actually make the network stronger? Personally
> I never bring claims like this if I just assume. A lot of people in the
> community really trust you, do you realize you potentially hurt them for no
> reason?
>

Running normal full nodes only provides extra service to nodes
synchronizing and lightweight clients. It does not "make the network
stronger" in the sense that it does not reduce the trust the participants
need to have in each other.

It's such a misconception that running many nodes somehow helps. It's much
better that you run and control one or a few full nodes which you actually
use to validate your transactions, than to run 1000s of nodes in third
party datacenters. The latter only looks more decentralized.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 1344 bytes --]

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

[Me]

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

> It's such a misconception that running many nodes somehow helps. It's much better that you run and control one or a few full nodes which you actually use to validate your transactions, than to run 1000s of nodes in third party datacenters. The latter only looks more decentralized.


I guess we sort of disagree here, perhaps my word “strength” was not the right word. Yes, running 6000 vs 7000 nodes makes no difference for the network strength, but (a) running 50 nodes vs 5000 does make a difference. I would love to see how the number of nodes drop if companies like blockcypher turn off their servers. Obviously it would not go 50. (b) running different clients (if blockcypher runs non-reference-bitcoinD client) makes the network less open wide-spread bugs


I feel we are really derailing the original topic btw  :-)





> On Jul 15, 2015, at 9:11 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> 
> On Wed, Jul 15, 2015 at 12:06 PM, Me via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> Have you talk to them? If not, how can you be sure they don’t run large number of standard nodes and actually make the network stronger? Personally I never bring claims like this if I just assume. A lot of people in the community really trust you, do you realize you potentially hurt them for no reason?
> 
> Running normal full nodes only provides extra service to nodes synchronizing and lightweight clients. It does not "make the network stronger" in the sense that it does not reduce the trust the participants need to have in each other.
> 
> It's such a misconception that running many nodes somehow helps. It's much better that you run and control one or a few full nodes which you actually use to validate your transactions, than to run 1000s of nodes in third party datacenters. The latter only looks more decentralized.
> 
> -- 
> Pieter
> 


[-- Attachment #2: Type: text/html, Size: 3270 bytes --]

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

[Milly Bitcoin]

Below are 2 examples why a systematic risk analysis needs to be used. 
The current situation is that you have developers making hyperbolic, 
demonizing statements that users are "spammers" and engaged in Sybil 
"attacks."  Characterizing these activities as spam and Sybil attacks is 
not a systematic analysis, it is closer to the process used at the Salem 
Witch trials.

If this process of demonetization is to take its natural course then 
these statements are "developer attacks" from a developer system that 
lacks proper incentives and is rife with conflicts of interest.

Russ


>... they need to
> connect to a large % of nodes on the network; that right there is a
> sybil attack. It's an approach that uses up connection slots for the
> entire network and isn't scalable; if more than a few services were
> doing that the Bitcoin network would become significantly less reliable,
> at some point collapsing entirely.

...

 > Spammers out there are being very disrepectful of my fullnode resources

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

[Matthieu Riou]

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

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.

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.

Thanks,
Matthieu

On Wed, Jul 15, 2015 at 9:12 AM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Below are 2 examples why a systematic risk analysis needs to be used. The
> current situation is that you have developers making hyperbolic, demonizing
> statements that users are "spammers" and engaged in Sybil "attacks."
> Characterizing these activities as spam and Sybil attacks is not a
> systematic analysis, it is closer to the process used at the Salem Witch
> trials.
>
> If this process of demonetization is to take its natural course then these
> statements are "developer attacks" from a developer system that lacks
> proper incentives and is rife with conflicts of interest.
>
> Russ
>
>
>  ... they need to
>> connect to a large % of nodes on the network; that right there is a
>> sybil attack. It's an approach that uses up connection slots for the
>> entire network and isn't scalable; if more than a few services were
>> doing that the Bitcoin network would become significantly less reliable,
>> at some point collapsing entirely.
>>
>
> ...
>
> > Spammers out there are being very disrepectful of my fullnode resources
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3511 bytes --]

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

[Peter Todd]

[-- 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 --]

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

[Milly Bitcoin]

> (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)

As far as I know none of those people are security experts nor do they 
engage in systematic risk and threat analysis.  Simply because they are 
experts in Bitcoin development does not make them expert in other areas. 
  Many of those involved in Bitcoin think that because they know Bitcoin 
that they somehow have become experts in other areas.  That is one 
reason why so many Bitcoin companies have been hacked.

An "attack" according to ISO/IEC 27000 "is any attempt to destroy, 
expose, alter, disable, steal or gain unauthorized access to or make 
unauthorized use of an asset."  The situation you are describing is not 
an "attack," they are providing a service.  Satoshi Dice is also not 
"spam," it is again providing a service within the rules set forth in 
the software.  The people going around claiming these are "spam" and 
"attacks" spend too much time of Reddit or they have an ulterior motive. 
  In any case these baseless accusations and arguments waste inordinate 
amounts of time.

Russ

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

[Matthieu Riou]

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

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.

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.

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.


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

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.

Thanks,
Matthieu
CTO and Founder, BlockCypher

[1]
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008864.html

[-- Attachment #2: Type: text/html, Size: 3779 bytes --]

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

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Personally, I hope more people develop on-chain microtransaction
systems (so long as open source, etc) ~ see
http://dev.blockcypher.com/#microtransaction-api ~ and I hope the
bitcoin community figures out ways to re-examine dust, rather than
viewing it as a "problem," but instead, to re-examine this and
interpret it as an "opportunity" for microgiving. (I won't claim there
aren't challenges there, but I'll just throw that out there again..)

- - Please see, my little project, http://abis.io

On 07/15/2015 05:08 PM, Matthieu Riou via bitcoin-dev wrote:
> On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd <pete@petertodd.org 
> <mailto: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.
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> 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.
> 
> Thanks, Matthieu CTO and Founder, BlockCypher
> 
> [1]
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/00886
4.html
>
> 
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVpz6hAAoJEGxwq/inSG8CdAMIAJfJcJaXyFjUVLi6iA03tpot
8e0SONC+kadLRTUn8GzAlpSgvKLcfqO5WvNKsjJenckrP+B6oSlT2e2u0QGehxl4
gGfTksOPzrBFCfWOZnVAaDr4uR7OAHM/AjXkpn1gQJsh+xBhyeUF1xapPeR/M+9e
yXFtV0itZve93sKrtlo+J/VShEi9mPBYrFrJBK9o17ir5chXW/xzqGm1Ny3fS72U
/g9zkdt+LBidaLXdPvfBjjmux18BM+IAifO41C9Q0eIN6x0zajvPd/Y3Mm5J/QUe
p8qvj2Px75AYSCV0qzgMhETZdwYFor04f2zJ8u3WUB+AbupM9hewqvfPGiUi1qU=
=S/aI
-----END PGP SIGNATURE-----

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

[Peter Todd]

[-- 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 --]

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

[Milly Bitcoin]

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

Your actions make it appear as if you attack companies with the hope of 
landing consulting fees.  I assume if companies hire you as a consultant 
or put you on some advisory board then you stop badmouthing them.  These 
type of developer attacks are a high risk issue due to the small number 
of developers who have been given authority by the github gatekeeper and 
the lack of an incentive system for Bitcoin devlelopers.

I have been suggesting a systematic risk analysis to reduce the 
probability of such an attack.  If you have a systematic risk analysis 
then when there are issue you judge it against a standard.  That 
replaces the current situation where developers haphazardly make claims 
in twitter, Reddit, and blog posts and create drama and confusion.

Russ

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

[Adrian Macneil]

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

> With my white hat on

> Shapeshift.io lost ~3 BTC this week in multiple txs

I assume as a self proclaimed "white hat", you contacted the relevant
companies and returned their funds? Theft is still theft, regardless of
whether you are doing it for research or not.

On Tue, Jul 14, 2015 at 8:29 PM, simongreen--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> With my black hat on I recently performed numerous profitable double-spend
> attacks against zeroconf accepting fools. With my white hat on, I'm warning
> everyone. The strategy is simple:
>
> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc. anything
> that miners don't always accept.
>
> tx2: After merchant gives up valuable thing in return, normal tx without
> triggering spam protections. (loltasticly a Mike Hearn Bitcoin XT node was
> used to relay the double-spends)
>
> Example success story: tx1 paying Shapeshift.io with 6uBTC output is not
> dust under post-Hearn-relay-drop rules, but is dust under
> pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not paying
> Shapeshift.io. F2Pool/Eligius/BTCChina/AntPool etc. are all miners who have
> reverted Hearn's 10x relay fee drop as recommended by v0.11.0 release notes
> and accept these double-spends. Shapeshift.io lost ~3 BTC this week in
> multiple txs. (they're no longer accepting zeroconf)
>
> Example success story #2: tx1 with post-Hearn-relay drop fee, followed by
> tx2 with higher fee. Such stupidly low fee txs just don't get mined, so
> wait for a miner to mine tx2. Bought a silly amount of reddit gold off
> Coinbase this way among other things. I'm surprised that reddit didn't
> cancel the "fools-gold" after tx reversal. (did Coinbase guarantee those
> txs?) Also found multiple Bitcoin ATMs vulnerable to this attack. (but
> simulated attack with tx2s still paying ATM because didn't want to go to
> trouble of good phys opsec)
>
> Shoutouts to BitPay who did things right and notified merchant properly
> when tx was reversed.
>
> In summary, every target depending on zeroconf vulnerable and lost
> significant sums of money to totally trivial attacks with high probability.
> No need for RBF to do this, just normal variations in miner policy.
> Shapeshift claims to use Super Sophisticated Network Sybil Attacking
> Monitoring from Blockcypher, but relay nodes != miner policy.
>
> Consider yourself warned! My hat is whiter than most, and my skills not
> particularly good.
>
> What to do? Users: Listen to the experts and stop relying on zeroconf.
> Black hats: Profit!
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3604 bytes --]

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

[Arne Brutschy]

Hello,

What are these pre- and post-Hearn-relay drop rules you are speaking
about? Can anybody shed some light on this? (I am aware of the
minrelaytxfee setting proposed in the 0.11.0 release notes, I just
don't see what this has to do with Mike Hearn, BitcoinXT, and whether
there's a code change related to this that I missed).

Related: is there somewhere a chart that plots `estimatefee` over
time? Would be interesting to see how the fee market evolved over
these past weeks.

Regards
Arne

On 15/07/15 05:29, simongreen--- via bitcoin-dev wrote:
> With my black hat on I recently performed numerous profitable 
> double-spend attacks against zeroconf accepting fools. With my
> white hat on, I'm warning everyone. The strategy is simple:
> 
> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc. 
> anything that miners don't always accept.
> 
> tx2: After merchant gives up valuable thing in return, normal tx
> without triggering spam protections. (loltasticly a Mike Hearn
> Bitcoin XT node was used to relay the double-spends)
> 
> Example success story: tx1 paying Shapeshift.io with 6uBTC output
> is not dust under post-Hearn-relay-drop rules, but is dust under 
> pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not 
> paying Shapeshift.io. F2Pool/Eligius/BTCChina/AntPool etc. are all 
> miners who have reverted Hearn's 10x relay fee drop as recommended
> by v0.11.0 release notes and accept these double-spends.
> Shapeshift.io lost ~3 BTC this week in multiple txs. (they're no
> longer accepting zeroconf)
> 
> Example success story #2: tx1 with post-Hearn-relay drop fee,
> followed by tx2 with higher fee. Such stupidly low fee txs just
> don't get mined, so wait for a miner to mine tx2. Bought a silly
> amount of reddit gold off Coinbase this way among other things. I'm
> surprised that reddit didn't cancel the "fools-gold" after tx
> reversal. (did Coinbase guarantee those txs?) Also found multiple
> Bitcoin ATMs vulnerable to this attack. (but simulated attack with
> tx2s still paying ATM because didn't want to go to trouble of good
> phys opsec)
> 
> Shoutouts to BitPay who did things right and notified merchant
> properly when tx was reversed.
> 
> In summary, every target depending on zeroconf vulnerable and lost 
> significant sums of money to totally trivial attacks with high 
> probability. No need for RBF to do this, just normal variations in
> miner policy. Shapeshift claims to use Super Sophisticated Network
> Sybil Attacking Monitoring from Blockcypher, but relay nodes !=
> miner policy.
> 
> Consider yourself warned! My hat is whiter than most, and my skills
> not particularly good.
> 
> What to do? Users: Listen to the experts and stop relying on
> zeroconf. Black hats: Profit!
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Arne Brutschy <abrutschy@xylon.de>

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

[Me]

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

> minrelaytxfee setting proposed in the 0.11.0 release notes

my guess, he is talking about this https://bitcoin.org/en/glossary/minimum-relay-fee <https://bitcoin.org/en/glossary/minimum-relay-fee> - slam dunk technique for doublespend



> Related: is there somewhere a chart that plots `estimatefee` over
> time? Would be interesting to see how the fee market evolved over
> these past weeks.

I find this useful
https://bitcoinfees.github.io/ <https://bitcoinfees.github.io/>





> On Jul 16, 2015, at 7:30 AM, Arne Brutschy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> Hello,
> 
> What are these pre- and post-Hearn-relay drop rules you are speaking
> about? Can anybody shed some light on this? (I am aware of the
> minrelaytxfee setting proposed in the 0.11.0 release notes, I just
> don't see what this has to do with Mike Hearn, BitcoinXT, and whether
> there's a code change related to this that I missed).
> 
> Related: is there somewhere a chart that plots `estimatefee` over
> time? Would be interesting to see how the fee market evolved over
> these past weeks.
> 
> Regards
> Arne
> 
> On 15/07/15 05:29, simongreen--- via bitcoin-dev wrote:
>> With my black hat on I recently performed numerous profitable 
>> double-spend attacks against zeroconf accepting fools. With my
>> white hat on, I'm warning everyone. The strategy is simple:
>> 
>> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc. 
>> anything that miners don't always accept.
>> 
>> tx2: After merchant gives up valuable thing in return, normal tx
>> without triggering spam protections. (loltasticly a Mike Hearn
>> Bitcoin XT node was used to relay the double-spends)
>> 
>> Example success story: tx1 paying Shapeshift.io with 6uBTC output
>> is not dust under post-Hearn-relay-drop rules, but is dust under 
>> pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not 
>> paying Shapeshift.io. F2Pool/Eligius/BTCChina/AntPool etc. are all 
>> miners who have reverted Hearn's 10x relay fee drop as recommended
>> by v0.11.0 release notes and accept these double-spends.
>> Shapeshift.io lost ~3 BTC this week in multiple txs. (they're no
>> longer accepting zeroconf)
>> 
>> Example success story #2: tx1 with post-Hearn-relay drop fee,
>> followed by tx2 with higher fee. Such stupidly low fee txs just
>> don't get mined, so wait for a miner to mine tx2. Bought a silly
>> amount of reddit gold off Coinbase this way among other things. I'm
>> surprised that reddit didn't cancel the "fools-gold" after tx
>> reversal. (did Coinbase guarantee those txs?) Also found multiple
>> Bitcoin ATMs vulnerable to this attack. (but simulated attack with
>> tx2s still paying ATM because didn't want to go to trouble of good
>> phys opsec)
>> 
>> Shoutouts to BitPay who did things right and notified merchant
>> properly when tx was reversed.
>> 
>> In summary, every target depending on zeroconf vulnerable and lost 
>> significant sums of money to totally trivial attacks with high 
>> probability. No need for RBF to do this, just normal variations in
>> miner policy. Shapeshift claims to use Super Sophisticated Network
>> Sybil Attacking Monitoring from Blockcypher, but relay nodes !=
>> miner policy.
>> 
>> Consider yourself warned! My hat is whiter than most, and my skills
>> not particularly good.
>> 
>> What to do? Users: Listen to the experts and stop relying on
>> zeroconf. Black hats: Profit!
>> 
>> _______________________________________________ bitcoin-dev mailing
>> list bitcoin-dev@lists.linuxfoundation.org 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> -- 
> Arne Brutschy <abrutschy@xylon.de>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Type: text/html, Size: 5930 bytes --]

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

[Greg Schvey]

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

Simon - tx hashes or it didn't happen

Kidding aside, would be great if you could share the confirmed and
double-spent hashes so the rest of us can dive in and learn from this.

On Thu, Jul 16, 2015 at 7:50 AM, Me via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> minrelaytxfee setting proposed in the 0.11.0 release notes
>
> my guess, he is talking about this
> https://bitcoin.org/en/glossary/minimum-relay-fee - slam dunk technique
> for doublespend
>
>
>
> Related: is there somewhere a chart that plots `estimatefee` over
> time? Would be interesting to see how the fee market evolved over
> these past weeks.
>
>
> I find this useful
> https://bitcoinfees.github.io/
>
>
>
>
>
> On Jul 16, 2015, at 7:30 AM, Arne Brutschy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hello,
>
> What are these pre- and post-Hearn-relay drop rules you are speaking
> about? Can anybody shed some light on this? (I am aware of the
> minrelaytxfee setting proposed in the 0.11.0 release notes, I just
> don't see what this has to do with Mike Hearn, BitcoinXT, and whether
> there's a code change related to this that I missed).
>
> Related: is there somewhere a chart that plots `estimatefee` over
> time? Would be interesting to see how the fee market evolved over
> these past weeks.
>
> Regards
> Arne
>
> On 15/07/15 05:29, simongreen--- via bitcoin-dev wrote:
>
> With my black hat on I recently performed numerous profitable
> double-spend attacks against zeroconf accepting fools. With my
> white hat on, I'm warning everyone. The strategy is simple:
>
> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc.
> anything that miners don't always accept.
>
> tx2: After merchant gives up valuable thing in return, normal tx
> without triggering spam protections. (loltasticly a Mike Hearn
> Bitcoin XT node was used to relay the double-spends)
>
> Example success story: tx1 paying Shapeshift.io <http://shapeshift.io>
> with 6uBTC output
> is not dust under post-Hearn-relay-drop rules, but is dust under
> pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not
> paying Shapeshift.io <http://shapeshift.io>.
> F2Pool/Eligius/BTCChina/AntPool etc. are all
> miners who have reverted Hearn's 10x relay fee drop as recommended
> by v0.11.0 release notes and accept these double-spends.
> Shapeshift.io <http://shapeshift.io> lost ~3 BTC this week in multiple
> txs. (they're no
> longer accepting zeroconf)
>
> Example success story #2: tx1 with post-Hearn-relay drop fee,
> followed by tx2 with higher fee. Such stupidly low fee txs just
> don't get mined, so wait for a miner to mine tx2. Bought a silly
> amount of reddit gold off Coinbase this way among other things. I'm
> surprised that reddit didn't cancel the "fools-gold" after tx
> reversal. (did Coinbase guarantee those txs?) Also found multiple
> Bitcoin ATMs vulnerable to this attack. (but simulated attack with
> tx2s still paying ATM because didn't want to go to trouble of good
> phys opsec)
>
> Shoutouts to BitPay who did things right and notified merchant
> properly when tx was reversed.
>
> In summary, every target depending on zeroconf vulnerable and lost
> significant sums of money to totally trivial attacks with high
> probability. No need for RBF to do this, just normal variations in
> miner policy. Shapeshift claims to use Super Sophisticated Network
> Sybil Attacking Monitoring from Blockcypher, but relay nodes !=
> miner policy.
>
> Consider yourself warned! My hat is whiter than most, and my skills
> not particularly good.
>
> What to do? Users: Listen to the experts and stop relying on
> zeroconf. Black hats: Profit!
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> --
> Arne Brutschy <abrutschy@xylon.de>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 6069 bytes --]

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

[Mike Hearn]

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

>
> What are these pre- and post-Hearn-relay drop rules you are speaking
> about?


He's talking about patches I didn't even write (Gavin and Tom did), but
have included in Bitcoin XT:

   https://github.com/bitcoinxt/bitcoinxt

See the README section starting with "Relaying of double spends"

[-- Attachment #2: Type: text/html, Size: 712 bytes --]

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

[Peter Todd]

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

On Sat, Jul 18, 2015 at 01:43:14PM +0200, Mike Hearn via bitcoin-dev wrote:
> >
> > What are these pre- and post-Hearn-relay drop rules you are speaking
> > about?
> 
> 
> He's talking about patches I didn't even write (Gavin and Tom did), but
> have included in Bitcoin XT:

No, he's talking about the min-relay-fee drop that you wrote:

https://github.com/bitcoin/bitcoin/pull/3305

Based on what I saw in my logs, the double-spends were mainly being done
by exploiting the fact that much of the hashing power has reverted your
10x relay fee drop as it makes wasting bandwidth and mempool RAM easy.
(so much so that crashing nodes with OOM's is fairly cheap)

-- 
'peter'[:-1]@petertodd.org
00000000000000000a56b9b96af356cc8411cea940bb6c25b9cd934f99f9e174

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