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

[simongreen--- via bitcoin-dev]

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!

[Tom Harding via bitcoin-dev]

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.

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

[Peter Todd via bitcoin-dev]

Post by Tom Harding via bitcoin-dev
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

[Me via bitcoin-dev]

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

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev

Post by Tom Harding via bitcoin-dev
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
--
000000000000000010bf087ed645cba129e2523930d5cde636ddbae9e03aef9c
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Bastiaan van den Berg via bitcoin-dev]

On Wed, Jul 15, 2015 at 5:49 PM, Me via bitcoin-dev <

Post by Me via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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

[Peter Todd via bitcoin-dev]

Post by Me via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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.

[Me via bitcoin-dev]

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

Post by Peter Todd via bitcoin-dev

Post by Me via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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.
--
0000000000000000093f699ccdb323aa638af1131249ec2e1bacbf367163807a

[Pieter Wuille via bitcoin-dev]

On Wed, Jul 15, 2015 at 12:06 PM, Me via bitcoin-dev <

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.

[Me via bitcoin-dev]

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

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

[Milly Bitcoin via bitcoin-dev]

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

[Matthieu Riou via bitcoin-dev]

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 <

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

Post by Peter Todd via bitcoin-dev
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.

...

Post by Peter Todd via bitcoin-dev
Spammers out there are being very disrepectful of my fullnode resources

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Peter Todd via bitcoin-dev]

Post by Matthieu Riou via bitcoin-dev
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?

Post by Matthieu Riou via bitcoin-dev
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/

[Milly Bitcoin via bitcoin-dev]

Post by Peter Todd via bitcoin-dev
(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

[Matthieu Riou via bitcoin-dev]

Post by Peter Todd via bitcoin-dev
"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

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
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

[odinn via bitcoin-dev]

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

Post by Peter Todd via bitcoin-dev
"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

Post by Peter Todd via bitcoin-dev
_______________________________________________ bitcoin-dev mailing
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

[Peter Todd via bitcoin-dev]

Post by Matthieu Riou via bitcoin-dev

Post by Peter Todd via bitcoin-dev
"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.

Post by Matthieu Riou via bitcoin-dev
In the case of Bitcoin, there's something like 6,000 nodes, so if that

Post by Peter Todd via bitcoin-dev
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.

Post by Matthieu Riou via bitcoin-dev
If you are achieving that via incoming connections, you're placing a big

Post by Peter Todd via bitcoin-dev
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)

Post by Matthieu Riou via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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.

Post by Matthieu Riou via bitcoin-dev
Question: Do you have relationships with mining pools? For instance, are

Post by Peter Todd via bitcoin-dev
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.

[Milly Bitcoin via bitcoin-dev]

Post by Peter Todd via bitcoin-dev
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

[Adrian Macneil via bitcoin-dev]

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 <

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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Arne Brutschy via bitcoin-dev]

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

Post by simongreen--- via bitcoin-dev
With my black hat on I recently performed numerous profitable
double-spend attacks against zeroconf accepting fools. With my
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Me via bitcoin-dev]

Post by Arne Brutschy via bitcoin-dev
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

Post by Arne Brutschy via bitcoin-dev
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/>

Post by Arne Brutschy via bitcoin-dev
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

Post by simongreen--- via bitcoin-dev
With my black hat on I recently performed numerous profitable
double-spend attacks against zeroconf accepting fools. With my
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Greg Schvey via bitcoin-dev]

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 <

Post by Arne Brutschy via bitcoin-dev
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 <
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
With my black hat on I recently performed numerous profitable
double-spend attacks against zeroconf accepting fools. With my
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Mike Hearn via bitcoin-dev]

Post by Arne Brutschy via bitcoin-dev
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"

[Peter Todd via bitcoin-dev]

Post by Mike Hearn via bitcoin-dev

Post by Arne Brutschy via bitcoin-dev
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

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)