* [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
@ 2015-07-15 3:29 simongreen
2015-07-15 14:35 ` Tom Harding
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: simongreen @ 2015-07-15 3:29 UTC (permalink / raw)
To: 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!
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 3:29 [bitcoin-dev] Significant losses by double-spending unconfirmed transactions simongreen
@ 2015-07-15 14:35 ` Tom Harding
2015-07-15 15:18 ` Peter Todd
2015-07-15 17:01 ` Adrian Macneil
2015-07-16 14:30 ` Arne Brutschy
2 siblings, 1 reply; 23+ messages in thread
From: Tom Harding @ 2015-07-15 14:35 UTC (permalink / raw)
To: 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.
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 14:35 ` Tom Harding
@ 2015-07-15 15:18 ` Peter Todd
2015-07-15 15:49 ` Me
0 siblings, 1 reply; 23+ messages in thread
From: Peter Todd @ 2015-07-15 15:18 UTC (permalink / raw)
To: Tom Harding; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]
On Wed, Jul 15, 2015 at 07:35:21AM -0700, Tom Harding via bitcoin-dev wrote:
>
> You perform a valuable service with your demonstration, but you
> neglected to include the txid's to show that you actually did it.
> Your advice is must-follow for anyone relying on an unconfirmed tx: it
> must pay a good fee and be highly relayable/minable.
Actually, I was looking at what I believe was (part of?) this attack
yesterday in the logs on my full-RBF nodes and the txs involved *did*
have good fees and were highly relayable/minable - the double-spent txs
had near 100% propagation on blockchain.info (who has unfortunately
purged the relevant data already)
Shapeshift.io depends on Blockcypher's "confidence factor" model(1)
under the hood - yet another one of those sybil attacking network
monitoring things - to estimate tx confirmation probability by looking
at the % of nodes a tx has propagated too. But miners frequently use
customized Bitcoin Core codebases that don't follow normal policies, so
those measurements don't actually tell you what you need to know.
hapeshift confirmed(2) the attack - confirming that they disabled
unconfirmed tx acceptance - said they're going to "improve" their
system... It'll be interesting to see what that actually entails.
1) https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
2) https://www.reddit.com/r/Bitcoin/comments/3ddkhy/bitcoindev_significant_losses_by_doublespending/ct468p7
--
'peter'[:-1]@petertodd.org
000000000000000010bf087ed645cba129e2523930d5cde636ddbae9e03aef9c
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 15:18 ` Peter Todd
@ 2015-07-15 15:49 ` Me
2015-07-15 15:53 ` Bastiaan van den Berg
2015-07-15 15:59 ` Peter Todd
0 siblings, 2 replies; 23+ messages in thread
From: Me @ 2015-07-15 15:49 UTC (permalink / raw)
To: Peter Todd; +Cc: 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 :-)
> the double-spent txs
> had near 100% propagation on blockchain.info (who has unfortunately
> purged the relevant data already)
Can you please share the TX Hash
> Blockcypher's "confidence factor" model(1)
> under the hood - yet another one of those sybil attacking network
> monitoring things
Peter, I noticed on your twitter you have a lot of bad things to say about Blockcypher and their business model (which I might not full agree, but totally respect), can you share any evidence they perform any form of Sybil attack on the network, please.
> On Jul 15, 2015, at 8:18 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> On Wed, Jul 15, 2015 at 07:35:21AM -0700, Tom Harding via bitcoin-dev wrote:
>>
>> You perform a valuable service with your demonstration, but you
>> neglected to include the txid's to show that you actually did it.
>
>> Your advice is must-follow for anyone relying on an unconfirmed tx: it
>> must pay a good fee and be highly relayable/minable.
>
> Actually, I was looking at what I believe was (part of?) this attack
> yesterday in the logs on my full-RBF nodes and the txs involved *did*
> have good fees and were highly relayable/minable - the double-spent txs
> had near 100% propagation on blockchain.info (who has unfortunately
> purged the relevant data already)
>
> Shapeshift.io depends on Blockcypher's "confidence factor" model(1)
> under the hood - yet another one of those sybil attacking network
> monitoring things - to estimate tx confirmation probability by looking
> at the % of nodes a tx has propagated too. But miners frequently use
> customized Bitcoin Core codebases that don't follow normal policies, so
> those measurements don't actually tell you what you need to know.
>
> hapeshift confirmed(2) the attack - confirming that they disabled
> unconfirmed tx acceptance - said they're going to "improve" their
> system... It'll be interesting to see what that actually entails.
>
> 1) https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactions-in-8-seconds-7c9edcb3b734
> 2) https://www.reddit.com/r/Bitcoin/comments/3ddkhy/bitcoindev_significant_losses_by_doublespending/ct468p7
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000010bf087ed645cba129e2523930d5cde636ddbae9e03aef9c
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 15:49 ` Me
@ 2015-07-15 15:53 ` Bastiaan van den Berg
2015-07-15 15:59 ` Peter Todd
1 sibling, 0 replies; 23+ messages in thread
From: Bastiaan van den Berg @ 2015-07-15 15:53 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
On Wed, Jul 15, 2015 at 5:49 PM, Me via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> > Blockcypher's "confidence factor" model(1)
> > under the hood - yet another one of those sybil attacking network
> > monitoring things
>
>
> Peter, I noticed on your twitter you have a lot of bad things to say about
> Blockcypher and their business model (which I might not full agree, but
> totally respect), can you share any evidence they perform any form of Sybil
> attack on the network, please.
? He says it -monitors- for such a attack, usually monitoring does not
include causing it ;)
--
buZz
[-- Attachment #2: Type: text/html, Size: 1033 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 15:49 ` Me
2015-07-15 15:53 ` Bastiaan van den Berg
@ 2015-07-15 15:59 ` Peter Todd
2015-07-15 16:06 ` Me
2015-07-15 16:12 ` Milly Bitcoin
1 sibling, 2 replies; 23+ messages in thread
From: Peter Todd @ 2015-07-15 15:59 UTC (permalink / raw)
To: Me; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 952 bytes --]
On Wed, Jul 15, 2015 at 08:49:13AM -0700, Me wrote:
> > Blockcypher's "confidence factor" model(1)
> > under the hood - yet another one of those sybil attacking network
> > monitoring things
>
>
> Peter, I noticed on your twitter you have a lot of bad things to say about Blockcypher and their business model (which I might not full agree, but totally respect), can you share any evidence they perform any form of Sybil attack on the network, please.
For Blockcypher to succesfully do what they claim to do they need to
connect to a large % of nodes on the network; that right there is a
sybil attack. It's an approach that uses up connection slots for the
entire network and isn't scalable; if more than a few services were
doing that the Bitcoin network would become significantly less reliable,
at some point collapsing entirely.
--
'peter'[:-1]@petertodd.org
0000000000000000093f699ccdb323aa638af1131249ec2e1bacbf367163807a
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 15:59 ` Peter Todd
@ 2015-07-15 16:06 ` Me
2015-07-15 16:11 ` Pieter Wuille
2015-07-15 16:12 ` Milly Bitcoin
1 sibling, 1 reply; 23+ messages in thread
From: Me @ 2015-07-15 16:06 UTC (permalink / raw)
To: Peter Todd; +Cc: 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
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 16:06 ` Me
@ 2015-07-15 16:11 ` Pieter Wuille
2015-07-15 16:41 ` Me
0 siblings, 1 reply; 23+ messages in thread
From: Pieter Wuille @ 2015-07-15 16:11 UTC (permalink / raw)
To: Me; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 972 bytes --]
On Wed, Jul 15, 2015 at 12:06 PM, Me via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Have you talk to them? If not, how can you be sure they don’t run large
> number of standard nodes and actually make the network stronger? Personally
> I never bring claims like this if I just assume. A lot of people in the
> community really trust you, do you realize you potentially hurt them for no
> reason?
>
Running normal full nodes only provides extra service to nodes
synchronizing and lightweight clients. It does not "make the network
stronger" in the sense that it does not reduce the trust the participants
need to have in each other.
It's such a misconception that running many nodes somehow helps. It's much
better that you run and control one or a few full nodes which you actually
use to validate your transactions, than to run 1000s of nodes in third
party datacenters. The latter only looks more decentralized.
--
Pieter
[-- Attachment #2: Type: text/html, Size: 1344 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 15:59 ` Peter Todd
2015-07-15 16:06 ` Me
@ 2015-07-15 16:12 ` Milly Bitcoin
2015-07-15 18:25 ` Matthieu Riou
1 sibling, 1 reply; 23+ messages in thread
From: Milly Bitcoin @ 2015-07-15 16:12 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 16:11 ` Pieter Wuille
@ 2015-07-15 16:41 ` Me
0 siblings, 0 replies; 23+ messages in thread
From: Me @ 2015-07-15 16:41 UTC (permalink / raw)
To: Pieter Wuille; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]
> It's such a misconception that running many nodes somehow helps. It's much better that you run and control one or a few full nodes which you actually use to validate your transactions, than to run 1000s of nodes in third party datacenters. The latter only looks more decentralized.
I guess we sort of disagree here, perhaps my word “strength” was not the right word. Yes, running 6000 vs 7000 nodes makes no difference for the network strength, but (a) running 50 nodes vs 5000 does make a difference. I would love to see how the number of nodes drop if companies like blockcypher turn off their servers. Obviously it would not go 50. (b) running different clients (if blockcypher runs non-reference-bitcoinD client) makes the network less open wide-spread bugs
I feel we are really derailing the original topic btw :-)
> On Jul 15, 2015, at 9:11 AM, Pieter Wuille <pieter.wuille@gmail•com> wrote:
>
> On Wed, Jul 15, 2015 at 12:06 PM, Me via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
> Have you talk to them? If not, how can you be sure they don’t run large number of standard nodes and actually make the network stronger? Personally I never bring claims like this if I just assume. A lot of people in the community really trust you, do you realize you potentially hurt them for no reason?
>
> Running normal full nodes only provides extra service to nodes synchronizing and lightweight clients. It does not "make the network stronger" in the sense that it does not reduce the trust the participants need to have in each other.
>
> It's such a misconception that running many nodes somehow helps. It's much better that you run and control one or a few full nodes which you actually use to validate your transactions, than to run 1000s of nodes in third party datacenters. The latter only looks more decentralized.
>
> --
> Pieter
>
[-- Attachment #2: Type: text/html, Size: 3270 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 3:29 [bitcoin-dev] Significant losses by double-spending unconfirmed transactions simongreen
2015-07-15 14:35 ` Tom Harding
@ 2015-07-15 17:01 ` Adrian Macneil
2015-07-16 14:30 ` Arne Brutschy
2 siblings, 0 replies; 23+ messages in thread
From: Adrian Macneil @ 2015-07-15 17:01 UTC (permalink / raw)
To: simongreen; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2758 bytes --]
> With my white hat on
> Shapeshift.io lost ~3 BTC this week in multiple txs
I assume as a self proclaimed "white hat", you contacted the relevant
companies and returned their funds? Theft is still theft, regardless of
whether you are doing it for research or not.
On Tue, Jul 14, 2015 at 8:29 PM, simongreen--- via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> With my black hat on I recently performed numerous profitable double-spend
> attacks against zeroconf accepting fools. With my white hat on, I'm warning
> everyone. The strategy is simple:
>
> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc. anything
> that miners don't always accept.
>
> tx2: After merchant gives up valuable thing in return, normal tx without
> triggering spam protections. (loltasticly a Mike Hearn Bitcoin XT node was
> used to relay the double-spends)
>
> Example success story: tx1 paying Shapeshift.io with 6uBTC output is not
> dust under post-Hearn-relay-drop rules, but is dust under
> pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not paying
> Shapeshift.io. F2Pool/Eligius/BTCChina/AntPool etc. are all miners who have
> reverted Hearn's 10x relay fee drop as recommended by v0.11.0 release notes
> and accept these double-spends. Shapeshift.io lost ~3 BTC this week in
> multiple txs. (they're no longer accepting zeroconf)
>
> Example success story #2: tx1 with post-Hearn-relay drop fee, followed by
> tx2 with higher fee. Such stupidly low fee txs just don't get mined, so
> wait for a miner to mine tx2. Bought a silly amount of reddit gold off
> Coinbase this way among other things. I'm surprised that reddit didn't
> cancel the "fools-gold" after tx reversal. (did Coinbase guarantee those
> txs?) Also found multiple Bitcoin ATMs vulnerable to this attack. (but
> simulated attack with tx2s still paying ATM because didn't want to go to
> trouble of good phys opsec)
>
> Shoutouts to BitPay who did things right and notified merchant properly
> when tx was reversed.
>
> In summary, every target depending on zeroconf vulnerable and lost
> significant sums of money to totally trivial attacks with high probability.
> No need for RBF to do this, just normal variations in miner policy.
> Shapeshift claims to use Super Sophisticated Network Sybil Attacking
> Monitoring from Blockcypher, but relay nodes != miner policy.
>
> Consider yourself warned! My hat is whiter than most, and my skills not
> particularly good.
>
> What to do? Users: Listen to the experts and stop relying on zeroconf.
> Black hats: Profit!
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 3604 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 16:12 ` Milly Bitcoin
@ 2015-07-15 18:25 ` Matthieu Riou
2015-07-15 19:32 ` Peter Todd
0 siblings, 1 reply; 23+ messages in thread
From: Matthieu Riou @ 2015-07-15 18:25 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2614 bytes --]
Hi,
Thanks for the bug report Simon, "responsible" disclosure on public forums
is always appreciated. We're working with ShapeShift to make sure we can
protect them appropriately against this specific attack in the future. As
"Me" and Adrian advised, I would also encourage you return the funds.
Regarding Peter's accusations on Twitter/Reddit/listserve, we have no idea
why we are his target. He has never met with our CEO, has no idea of our
business model, nor our company objectives. All his comments about us are
his speculations. I'm sure Peter knows what a Sybil attack actually is and
making such claims on a public forum is completely unfounded and uncalled
for. Stretching definitions beyond the point where they make sense is a
common rhetoric and political tool, not necessarily appropriate in a
professional or technical context.
We offer useful services for many startups like ourselves. We are good
actors in this space. As a startup we are also constrained by limited
resources (we're funded but far from larger companies resources). Companies
aren't built in a single day and we hope to do more to help
decentralization in the future as well. We're trying to further the
ecosystem with our small team, so the pot shots are puzzling.
Thanks,
Matthieu
On Wed, Jul 15, 2015 at 9:12 AM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Below are 2 examples why a systematic risk analysis needs to be used. The
> current situation is that you have developers making hyperbolic, demonizing
> statements that users are "spammers" and engaged in Sybil "attacks."
> Characterizing these activities as spam and Sybil attacks is not a
> systematic analysis, it is closer to the process used at the Salem Witch
> trials.
>
> If this process of demonetization is to take its natural course then these
> statements are "developer attacks" from a developer system that lacks
> proper incentives and is rife with conflicts of interest.
>
> Russ
>
>
> ... they need to
>> connect to a large % of nodes on the network; that right there is a
>> sybil attack. It's an approach that uses up connection slots for the
>> entire network and isn't scalable; if more than a few services were
>> doing that the Bitcoin network would become significantly less reliable,
>> at some point collapsing entirely.
>>
>
> ...
>
> > Spammers out there are being very disrepectful of my fullnode resources
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3511 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 18:25 ` Matthieu Riou
@ 2015-07-15 19:32 ` Peter Todd
2015-07-15 19:57 ` Milly Bitcoin
2015-07-16 0:08 ` Matthieu Riou
0 siblings, 2 replies; 23+ messages in thread
From: Peter Todd @ 2015-07-15 19:32 UTC (permalink / raw)
To: Matthieu Riou; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3810 bytes --]
On Wed, Jul 15, 2015 at 11:25:17AM -0700, Matthieu Riou via bitcoin-dev wrote:
> Hi,
>
> Thanks for the bug report Simon, "responsible" disclosure on public forums
> is always appreciated. We're working with ShapeShift to make sure we can
> protect them appropriately against this specific attack in the future. As
> "Me" and Adrian advised, I would also encourage you return the funds.
>
> Regarding Peter's accusations on Twitter/Reddit/listserve, we have no idea
> why we are his target. He has never met with our CEO, has no idea of our
> business model, nor our company objectives. All his comments about us are
> his speculations. I'm sure Peter knows what a Sybil attack actually is and
> making such claims on a public forum is completely unfounded and uncalled
> for. Stretching definitions beyond the point where they make sense is a
> common rhetoric and political tool, not necessarily appropriate in a
> professional or technical context.
"In a Sybil attack the attacker subverts the reputation system of a
peer-to-peer network by creating a large number of pseudonymous
identities, using them to gain a disproportionately large influence."
Quoting your API docs:
"[Blockcypher is] always connected to a statistically significant number
of nodes on the network - we target anywhere between 10 to 20% of the
active nodes on any given blockchain"
-http://dev.blockcypher.com/#confidence-factor
In the case of Bitcoin, there's something like 6,000 nodes, so if that
20% is achived via outgoing connections you'd have 600 to 1200 active
outgoing connections using up network resources. Meanwhile, the default
is 8 outgoing connections - you're using about two orders of magnitude
more resources.
If you are achieving that via incoming connections, you're placing a big
part of the relay network under central control. As we've seen in the
case of Chainalysis's sybil attack, even unintentional confirguation
screwups can cause serious and widespread issues due to the large number
of nodes that can fail in one go. (note how Chainalysis's actions were
described(1) as a sybil attack by multiple Bitcoin devs, including
Gregory Maxwell, Wladimir van der Laan, and myself)
Right now the P2P network has relatively weak protections against sybil
attacks, but efforts are being made to find ways to defend against them.
As anti-sybil attack technology improves, you'll be able to
simultaneously connect to a smaller and smaller % of the network, and
your confidence factor technology will degrade further.
Questions: How exactly does your monitoring network work? Do you make
incoming, outgoing, or both types of connections? What subnet(s) do the
connections come from? What software makes those connections?
> We offer useful services for many startups like ourselves. We are good
> actors in this space. As a startup we are also constrained by limited
> resources (we're funded but far from larger companies resources). Companies
> aren't built in a single day and we hope to do more to help
> decentralization in the future as well. We're trying to further the
> ecosystem with our small team, so the pot shots are puzzling.
What you are doing is inherently incompatible with decentralization.
Your service simply doesn't scale; it's a server only a small number of
centralized entities can provide without causing the P2P network to
collapse due to resource exhaustion.
Question: Do you have relationships with mining pools? For instance, are
you looking at contracts to have transactions mined to guarantee
confirmations?
1) http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/
--
'peter'[:-1]@petertodd.org
00000000000000000b675c4d825a10c278b8d63ee4df90a19393f3b6498fd073
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 19:32 ` Peter Todd
@ 2015-07-15 19:57 ` Milly Bitcoin
2015-07-16 0:08 ` Matthieu Riou
1 sibling, 0 replies; 23+ messages in thread
From: Milly Bitcoin @ 2015-07-15 19:57 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 19:32 ` Peter Todd
2015-07-15 19:57 ` Milly Bitcoin
@ 2015-07-16 0:08 ` Matthieu Riou
2015-07-16 5:18 ` odinn
2015-07-17 11:59 ` Peter Todd
1 sibling, 2 replies; 23+ messages in thread
From: Matthieu Riou @ 2015-07-16 0:08 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2125 bytes --]
On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd <pete@petertodd•org> wrote:
>
> "In a Sybil attack the attacker subverts the reputation system of a
> peer-to-peer network by creating a large number of pseudonymous
> identities, using them to gain a disproportionately large influence."
>
Our "identities" aren't pseudonymous.
In the case of Bitcoin, there's something like 6,000 nodes, so if that
> 20% is achived via outgoing connections you'd have 600 to 1200 active
> outgoing connections using up network resources. Meanwhile, the default
> is 8 outgoing connections - you're using about two orders of magnitude
> more resources.
>
You're not talking about a Sybil attack anymore, just resource use. We do
know how to change default configurations to offer more connections.
If you are achieving that via incoming connections, you're placing a big
> part of the relay network under central control. As we've seen in the
> case of Chainalysis's sybil attack, even unintentional confirguation
> screwups can cause serious and widespread issues due to the large number
> of nodes that can fail in one go. (note how Chainalysis's actions were
> described(1) as a sybil attack by multiple Bitcoin devs, including
> Gregory Maxwell, Wladimir van der Laan, and myself)
>
We're not Chainanalysis and we do not run hundreds of distinct nodes. Just
a few well-tuned ones.
> What you are doing is inherently incompatible with decentralization.
>
That's a matter of opinion. One could argue your actions and control
attempts hurt decentralization. Either way, no one should play the
decentralization police or act as a gatekeeper.
Question: Do you have relationships with mining pools? For instance, are
> you looking at contracts to have transactions mined to guarantee
> confirmations?
>
No, we do not. We do not know anyone else having such contracts. As you
know, Coinbase also denied having such contracts in place [1]. But you seem
to have more relationships with mining pools than we do.
Thanks,
Matthieu
CTO and Founder, BlockCypher
[1]
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008864.html
[-- Attachment #2: Type: text/html, Size: 3779 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-16 0:08 ` Matthieu Riou
@ 2015-07-16 5:18 ` odinn
2015-07-17 11:59 ` Peter Todd
1 sibling, 0 replies; 23+ messages in thread
From: odinn @ 2015-07-16 5:18 UTC (permalink / raw)
To: Matthieu Riou, bitcoin-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Personally, I hope more people develop on-chain microtransaction
systems (so long as open source, etc) ~ see
http://dev.blockcypher.com/#microtransaction-api ~ and I hope the
bitcoin community figures out ways to re-examine dust, rather than
viewing it as a "problem," but instead, to re-examine this and
interpret it as an "opportunity" for microgiving. (I won't claim there
aren't challenges there, but I'll just throw that out there again..)
- - Please see, my little project, http://abis.io
On 07/15/2015 05:08 PM, Matthieu Riou via bitcoin-dev wrote:
> On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd <pete@petertodd•org
> <mailto:pete@petertodd•org>> wrote:
>
>
> "In a Sybil attack the attacker subverts the reputation system of
> a peer-to-peer network by creating a large number of pseudonymous
> identities, using them to gain a disproportionately large
> influence."
>
>
> Our "identities" aren't pseudonymous.
>
> In the case of Bitcoin, there's something like 6,000 nodes, so if
> that 20% is achived via outgoing connections you'd have 600 to 1200
> active outgoing connections using up network resources. Meanwhile,
> the default is 8 outgoing connections - you're using about two
> orders of magnitude more resources.
>
>
> You're not talking about a Sybil attack anymore, just resource use.
> We do know how to change default configurations to offer more
> connections.
>
> If you are achieving that via incoming connections, you're placing
> a big part of the relay network under central control. As we've
> seen in the case of Chainalysis's sybil attack, even unintentional
> confirguation screwups can cause serious and widespread issues due
> to the large number of nodes that can fail in one go. (note how
> Chainalysis's actions were described(1) as a sybil attack by
> multiple Bitcoin devs, including Gregory Maxwell, Wladimir van der
> Laan, and myself)
>
>
> We're not Chainanalysis and we do not run hundreds of distinct
> nodes. Just a few well-tuned ones.
>
>
> What you are doing is inherently incompatible with
> decentralization.
>
>
> That's a matter of opinion. One could argue your actions and
> control attempts hurt decentralization. Either way, no one should
> play the decentralization police or act as a gatekeeper.
>
> Question: Do you have relationships with mining pools? For
> instance, are you looking at contracts to have transactions mined
> to guarantee confirmations?
>
>
> No, we do not. We do not know anyone else having such contracts. As
> you know, Coinbase also denied having such contracts in place [1].
> But you seem to have more relationships with mining pools than we
> do.
>
> Thanks, Matthieu CTO and Founder, BlockCypher
>
> [1]
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/00886
4.html
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVpz6hAAoJEGxwq/inSG8CdAMIAJfJcJaXyFjUVLi6iA03tpot
8e0SONC+kadLRTUn8GzAlpSgvKLcfqO5WvNKsjJenckrP+B6oSlT2e2u0QGehxl4
gGfTksOPzrBFCfWOZnVAaDr4uR7OAHM/AjXkpn1gQJsh+xBhyeUF1xapPeR/M+9e
yXFtV0itZve93sKrtlo+J/VShEi9mPBYrFrJBK9o17ir5chXW/xzqGm1Ny3fS72U
/g9zkdt+LBidaLXdPvfBjjmux18BM+IAifO41C9Q0eIN6x0zajvPd/Y3Mm5J/QUe
p8qvj2Px75AYSCV0qzgMhETZdwYFor04f2zJ8u3WUB+AbupM9hewqvfPGiUi1qU=
=S/aI
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-15 3:29 [bitcoin-dev] Significant losses by double-spending unconfirmed transactions simongreen
2015-07-15 14:35 ` Tom Harding
2015-07-15 17:01 ` Adrian Macneil
@ 2015-07-16 14:30 ` Arne Brutschy
2015-07-16 14:50 ` Me
2015-07-18 11:43 ` Mike Hearn
2 siblings, 2 replies; 23+ messages in thread
From: Arne Brutschy @ 2015-07-16 14:30 UTC (permalink / raw)
To: 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
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>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-16 14:30 ` Arne Brutschy
@ 2015-07-16 14:50 ` Me
2015-07-16 15:33 ` Greg Schvey
2015-07-18 11:43 ` Mike Hearn
1 sibling, 1 reply; 23+ messages in thread
From: Me @ 2015-07-16 14:50 UTC (permalink / raw)
To: Arne Brutschy; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3946 bytes --]
> minrelaytxfee setting proposed in the 0.11.0 release notes
my guess, he is talking about this https://bitcoin.org/en/glossary/minimum-relay-fee <https://bitcoin.org/en/glossary/minimum-relay-fee> - slam dunk technique for doublespend
> Related: is there somewhere a chart that plots `estimatefee` over
> time? Would be interesting to see how the fee market evolved over
> these past weeks.
I find this useful
https://bitcoinfees.github.io/ <https://bitcoinfees.github.io/>
> On Jul 16, 2015, at 7:30 AM, Arne Brutschy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hello,
>
> What are these pre- and post-Hearn-relay drop rules you are speaking
> about? Can anybody shed some light on this? (I am aware of the
> minrelaytxfee setting proposed in the 0.11.0 release notes, I just
> don't see what this has to do with Mike Hearn, BitcoinXT, and whether
> there's a code change related to this that I missed).
>
> Related: is there somewhere a chart that plots `estimatefee` over
> time? Would be interesting to see how the fee market evolved over
> these past weeks.
>
> Regards
> Arne
>
> On 15/07/15 05:29, simongreen--- via bitcoin-dev wrote:
>> With my black hat on I recently performed numerous profitable
>> double-spend attacks against zeroconf accepting fools. With my
>> white hat on, I'm warning everyone. The strategy is simple:
>>
>> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc.
>> anything that miners don't always accept.
>>
>> tx2: After merchant gives up valuable thing in return, normal tx
>> without triggering spam protections. (loltasticly a Mike Hearn
>> Bitcoin XT node was used to relay the double-spends)
>>
>> Example success story: tx1 paying Shapeshift.io with 6uBTC output
>> is not dust under post-Hearn-relay-drop rules, but is dust under
>> pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not
>> paying Shapeshift.io. F2Pool/Eligius/BTCChina/AntPool etc. are all
>> miners who have reverted Hearn's 10x relay fee drop as recommended
>> by v0.11.0 release notes and accept these double-spends.
>> Shapeshift.io lost ~3 BTC this week in multiple txs. (they're no
>> longer accepting zeroconf)
>>
>> Example success story #2: tx1 with post-Hearn-relay drop fee,
>> followed by tx2 with higher fee. Such stupidly low fee txs just
>> don't get mined, so wait for a miner to mine tx2. Bought a silly
>> amount of reddit gold off Coinbase this way among other things. I'm
>> surprised that reddit didn't cancel the "fools-gold" after tx
>> reversal. (did Coinbase guarantee those txs?) Also found multiple
>> Bitcoin ATMs vulnerable to this attack. (but simulated attack with
>> tx2s still paying ATM because didn't want to go to trouble of good
>> phys opsec)
>>
>> Shoutouts to BitPay who did things right and notified merchant
>> properly when tx was reversed.
>>
>> In summary, every target depending on zeroconf vulnerable and lost
>> significant sums of money to totally trivial attacks with high
>> probability. No need for RBF to do this, just normal variations in
>> miner policy. Shapeshift claims to use Super Sophisticated Network
>> Sybil Attacking Monitoring from Blockcypher, but relay nodes !=
>> miner policy.
>>
>> Consider yourself warned! My hat is whiter than most, and my skills
>> not particularly good.
>>
>> What to do? Users: Listen to the experts and stop relying on
>> zeroconf. Black hats: Profit!
>>
>> _______________________________________________ bitcoin-dev mailing
>> list bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Arne Brutschy <abrutschy@xylon•de>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 5930 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-16 14:50 ` Me
@ 2015-07-16 15:33 ` Greg Schvey
0 siblings, 0 replies; 23+ messages in thread
From: Greg Schvey @ 2015-07-16 15:33 UTC (permalink / raw)
To: Me; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4270 bytes --]
Simon - tx hashes or it didn't happen
Kidding aside, would be great if you could share the confirmed and
double-spent hashes so the rest of us can dive in and learn from this.
On Thu, Jul 16, 2015 at 7:50 AM, Me via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> minrelaytxfee setting proposed in the 0.11.0 release notes
>
> my guess, he is talking about this
> https://bitcoin.org/en/glossary/minimum-relay-fee - slam dunk technique
> for doublespend
>
>
>
> Related: is there somewhere a chart that plots `estimatefee` over
> time? Would be interesting to see how the fee market evolved over
> these past weeks.
>
>
> I find this useful
> https://bitcoinfees.github.io/
>
>
>
>
>
> On Jul 16, 2015, at 7:30 AM, Arne Brutschy via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hello,
>
> What are these pre- and post-Hearn-relay drop rules you are speaking
> about? Can anybody shed some light on this? (I am aware of the
> minrelaytxfee setting proposed in the 0.11.0 release notes, I just
> don't see what this has to do with Mike Hearn, BitcoinXT, and whether
> there's a code change related to this that I missed).
>
> Related: is there somewhere a chart that plots `estimatefee` over
> time? Would be interesting to see how the fee market evolved over
> these past weeks.
>
> Regards
> Arne
>
> On 15/07/15 05:29, simongreen--- via bitcoin-dev wrote:
>
> With my black hat on I recently performed numerous profitable
> double-spend attacks against zeroconf accepting fools. With my
> white hat on, I'm warning everyone. The strategy is simple:
>
> tx1: To merchant, but dust/low-fee/reused-address/large-size/etc.
> anything that miners don't always accept.
>
> tx2: After merchant gives up valuable thing in return, normal tx
> without triggering spam protections. (loltasticly a Mike Hearn
> Bitcoin XT node was used to relay the double-spends)
>
> Example success story: tx1 paying Shapeshift.io <http://shapeshift.io>
> with 6uBTC output
> is not dust under post-Hearn-relay-drop rules, but is dust under
> pre-Hearn-relay-drop rules, followed by tx2 w/o the output and not
> paying Shapeshift.io <http://shapeshift.io>.
> F2Pool/Eligius/BTCChina/AntPool etc. are all
> miners who have reverted Hearn's 10x relay fee drop as recommended
> by v0.11.0 release notes and accept these double-spends.
> Shapeshift.io <http://shapeshift.io> lost ~3 BTC this week in multiple
> txs. (they're no
> longer accepting zeroconf)
>
> Example success story #2: tx1 with post-Hearn-relay drop fee,
> followed by tx2 with higher fee. Such stupidly low fee txs just
> don't get mined, so wait for a miner to mine tx2. Bought a silly
> amount of reddit gold off Coinbase this way among other things. I'm
> surprised that reddit didn't cancel the "fools-gold" after tx
> reversal. (did Coinbase guarantee those txs?) Also found multiple
> Bitcoin ATMs vulnerable to this attack. (but simulated attack with
> tx2s still paying ATM because didn't want to go to trouble of good
> phys opsec)
>
> Shoutouts to BitPay who did things right and notified merchant
> properly when tx was reversed.
>
> In summary, every target depending on zeroconf vulnerable and lost
> significant sums of money to totally trivial attacks with high
> probability. No need for RBF to do this, just normal variations in
> miner policy. Shapeshift claims to use Super Sophisticated Network
> Sybil Attacking Monitoring from Blockcypher, but relay nodes !=
> miner policy.
>
> Consider yourself warned! My hat is whiter than most, and my skills
> not particularly good.
>
> What to do? Users: Listen to the experts and stop relying on
> zeroconf. Black hats: Profit!
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> --
> Arne Brutschy <abrutschy@xylon•de>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 6069 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-16 0:08 ` Matthieu Riou
2015-07-16 5:18 ` odinn
@ 2015-07-17 11:59 ` Peter Todd
2015-07-17 12:56 ` Milly Bitcoin
1 sibling, 1 reply; 23+ messages in thread
From: Peter Todd @ 2015-07-17 11:59 UTC (permalink / raw)
To: Matthieu Riou; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3993 bytes --]
On Wed, Jul 15, 2015 at 05:08:05PM -0700, Matthieu Riou via bitcoin-dev wrote:
> On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd <pete@petertodd•org> wrote:
>
> >
> > "In a Sybil attack the attacker subverts the reputation system of a
> > peer-to-peer network by creating a large number of pseudonymous
> > identities, using them to gain a disproportionately large influence."
> >
>
> Our "identities" aren't pseudonymous.
Then are you willing to tell us what IP addresses your nodes connect
from? This is important network stability information due to how nodes
prevent a lack of diversity in their outgoing connections.
> In the case of Bitcoin, there's something like 6,000 nodes, so if that
> > 20% is achived via outgoing connections you'd have 600 to 1200 active
> > outgoing connections using up network resources. Meanwhile, the default
> > is 8 outgoing connections - you're using about two orders of magnitude
> > more resources.
> >
>
> You're not talking about a Sybil attack anymore, just resource use. We do
> know how to change default configurations to offer more connections.
The Bitcoin P2P network's primary concern is reliability through
diversity; you are harming that resource.
So to be clear, you have both a high level of outgoing and incoming
connections? Given that Bitcoin nodes only connect to eight outgoing
peers, how do you manage to connect to your claimed 10%-20% of all
reachable nodes? Obviously you can't be doing that with just incoming
connections, unless you're running hundreds of nodes, or doing an addr
spamming attack.
> If you are achieving that via incoming connections, you're placing a big
> > part of the relay network under central control. As we've seen in the
> > case of Chainalysis's sybil attack, even unintentional confirguation
> > screwups can cause serious and widespread issues due to the large number
> > of nodes that can fail in one go. (note how Chainalysis's actions were
> > described(1) as a sybil attack by multiple Bitcoin devs, including
> > Gregory Maxwell, Wladimir van der Laan, and myself)
> >
>
> We're not Chainanalysis and we do not run hundreds of distinct nodes. Just
> a few well-tuned ones.
It's actually marginally better for the network if you're using hundreds
of distinct nodes rather than just a few to do this sybil attack - the
chance of your small number of nodes suddenly going off-line and causing
propagation issues is more than hundreds of nodes all going off-line
suddenly. Additionally it's easier for bad actors to survail your few
internet connections to easily get tx propagation information from the
network than it is to survail Chainalysis's setup. (ironic I know)
> > What you are doing is inherently incompatible with decentralization.
> >
>
> That's a matter of opinion. One could argue your actions and control
> attempts hurt decentralization. Either way, no one should play the
> decentralization police or act as a gatekeeper.
"Control attempts"? Care to explain?
Re: "gatekeeping" - fact is your business model and technology can only
be succesfully run by a small number of entities at once, resulting in a
situation where those few companies act as gatekeepers for access to
zeroconf confirmation probability information.
> Question: Do you have relationships with mining pools? For instance, are
> > you looking at contracts to have transactions mined to guarantee
> > confirmations?
> >
>
> No, we do not. We do not know anyone else having such contracts. As you
> know, Coinbase also denied having such contracts in place [1]. But you seem
> to have more relationships with mining pools than we do.
Nice cheap shot there. My "relationships" are nothing more than people
being willing to talk to me, ask me for advice, and warn me about
possible threats. They're not legal contracts.
--
'peter'[:-1]@petertodd.org
0000000000000000138147be90db48b8338de6d58cc6b60e6ad360f6ef486d8c
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-17 11:59 ` Peter Todd
@ 2015-07-17 12:56 ` Milly Bitcoin
0 siblings, 0 replies; 23+ messages in thread
From: Milly Bitcoin @ 2015-07-17 12:56 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-16 14:30 ` Arne Brutschy
2015-07-16 14:50 ` Me
@ 2015-07-18 11:43 ` Mike Hearn
2015-07-18 15:09 ` Peter Todd
1 sibling, 1 reply; 23+ messages in thread
From: Mike Hearn @ 2015-07-18 11:43 UTC (permalink / raw)
To: Arne Brutschy; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 294 bytes --]
>
> What are these pre- and post-Hearn-relay drop rules you are speaking
> about?
He's talking about patches I didn't even write (Gavin and Tom did), but
have included in Bitcoin XT:
https://github.com/bitcoinxt/bitcoinxt
See the README section starting with "Relaying of double spends"
[-- Attachment #2: Type: text/html, Size: 712 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
2015-07-18 11:43 ` Mike Hearn
@ 2015-07-18 15:09 ` Peter Todd
0 siblings, 0 replies; 23+ messages in thread
From: Peter Todd @ 2015-07-18 15:09 UTC (permalink / raw)
To: Mike Hearn; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 779 bytes --]
On Sat, Jul 18, 2015 at 01:43:14PM +0200, Mike Hearn via bitcoin-dev wrote:
> >
> > What are these pre- and post-Hearn-relay drop rules you are speaking
> > about?
>
>
> He's talking about patches I didn't even write (Gavin and Tom did), but
> have included in Bitcoin XT:
No, he's talking about the min-relay-fee drop that you wrote:
https://github.com/bitcoin/bitcoin/pull/3305
Based on what I saw in my logs, the double-spends were mainly being done
by exploiting the fact that much of the hashing power has reverted your
10x relay fee drop as it makes wasting bandwidth and mempool RAM easy.
(so much so that crashing nodes with OOM's is fairly cheap)
--
'peter'[:-1]@petertodd.org
00000000000000000a56b9b96af356cc8411cea940bb6c25b9cd934f99f9e174
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2015-07-18 15:09 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-15 3:29 [bitcoin-dev] Significant losses by double-spending unconfirmed transactions simongreen
2015-07-15 14:35 ` Tom Harding
2015-07-15 15:18 ` Peter Todd
2015-07-15 15:49 ` Me
2015-07-15 15:53 ` Bastiaan van den Berg
2015-07-15 15:59 ` Peter Todd
2015-07-15 16:06 ` Me
2015-07-15 16:11 ` Pieter Wuille
2015-07-15 16:41 ` Me
2015-07-15 16:12 ` Milly Bitcoin
2015-07-15 18:25 ` Matthieu Riou
2015-07-15 19:32 ` Peter Todd
2015-07-15 19:57 ` Milly Bitcoin
2015-07-16 0:08 ` Matthieu Riou
2015-07-16 5:18 ` odinn
2015-07-17 11:59 ` Peter Todd
2015-07-17 12:56 ` Milly Bitcoin
2015-07-15 17:01 ` Adrian Macneil
2015-07-16 14:30 ` Arne Brutschy
2015-07-16 14:50 ` Me
2015-07-16 15:33 ` Greg Schvey
2015-07-18 11:43 ` Mike Hearn
2015-07-18 15:09 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox