From: Peter Todd <pete@petertodd.org>
To: Tom Harding <tomh@thinlink.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Significant losses by double-spending unconfirmed transactions
Date: Wed, 15 Jul 2015 11:18:25 -0400 [thread overview]
Message-ID: <20150715151825.GB20029@savin.petertodd.org> (raw)
In-Reply-To: <55A66FA9.4010506@thinlink.com>
[-- 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 --]
next prev parent reply other threads:[~2015-07-15 15:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150715151825.GB20029@savin.petertodd.org \
--to=pete@petertodd.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=tomh@thinlink.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox