Significant losses by double-spending unconfirmed transactions
23 messages, 15 to 18 Jul 2015. Started by simongreen.
Peter Todd (5), Me (4), Milly Bitcoin (3), Matthieu Riou (2), simongreen, Tom Harding, Bastiaan van den Berg, Pieter Wuille, +5 more
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!
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:
Quoted text (2 lines)
> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc. > anything that miners don't always accept.
On Wed, Jul 15, 2015 at 07:35:21AM -0700, Tom Harding via bitcoin-dev wrote:
Quoted text (5 lines)
> > 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
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 :-)
Quoted text (3 lines)
> 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
Quoted text (3 lines)
> 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.
Quoted text (37 lines)
> 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
On Wed, Jul 15, 2015 at 5:49 PM, Me via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (10 lines)
> > > 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 ;)
On Wed, Jul 15, 2015 at 08:49:13AM -0700, Me wrote:
Quoted text (6 lines)
> > 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.
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
Quoted text (20 lines)
> 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
On Wed, Jul 15, 2015 at 12:06 PM, Me via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (6 lines)
> 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.
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
Quoted text (6 lines)
>... 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.
...
Quoted text (1 line)
> Spammers out there are being very disrepectful of my fullnode resources
Quoted text (1 line)
> 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 :-)
Quoted text (12 lines)
> 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 >
Quoted text (2 lines)
> 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:
Quoted text (49 lines)
> 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 > >
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:
Quoted text (33 lines)
> 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 >
On Wed, Jul 15, 2015 at 11:25:17AM -0700, Matthieu Riou via bitcoin-dev wrote:
Quoted text (15 lines)
> 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?
Quoted text (6 lines)
> 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/
Quoted text (3 lines)
> (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
On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (5 lines)
> > "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
Quoted text (5 lines)
> 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
Quoted text (7 lines)
> 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.
Quoted text (2 lines)
> 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
Quoted text (3 lines)
> 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
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:
Quoted text (59 lines)
> 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
Quoted text (7 lines)
> > > > _______________________________________________ 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
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:
Quoted text (49 lines)
> 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
Quoted text (1 line)
> 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
Quoted text (3 lines)
> 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/>
Quoted text (74 lines)
> 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
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:
Quoted text (109 lines)
> 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 > >
On Wed, Jul 15, 2015 at 05:08:05PM -0700, Matthieu Riou via bitcoin-dev wrote:
Quoted text (9 lines)
> 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.
Quoted text (9 lines)
> 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.
Quoted text (11 lines)
> 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)
Quoted text (6 lines)
> > 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.
Quoted text (8 lines)
> 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.
Quoted text (3 lines)
> 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
Quoted text (3 lines)
> > 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"
On Sat, Jul 18, 2015 at 01:43:14PM +0200, Mike Hearn via bitcoin-dev wrote:
Quoted text (7 lines)
> > > > 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)