Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
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 p...@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 138147be90db48b8338de6d58cc6b60e6ad360f6ef486d8c signature.asc Description: Digital signature ___ 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
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 abruts...@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
Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
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 abruts...@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 ___ 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
On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd p...@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 ___ 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
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. ___ 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
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 10bf087ed645cba129e2523930d5cde636ddbae9e03aef9c ___ 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
Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Significant losses by double-spending unconfirmed transactions
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
