From: John Dillon <john.dillon892@googlemail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
Date: Mon, 19 Aug 2013 03:09:07 +0000 [thread overview]
Message-ID: <CAPaL=UXpitBWJOzY-TRGh4kaD2Mt6G92KTt307MfRnzygk6D3A@mail.gmail.com> (raw)
In-Reply-To: <20130816141536.GD16201@petertodd.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Aug 16, 2013 at 2:15 PM, Peter Todd <pete@petertodd•org> wrote:
> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
>> Doing this also makes it more difficult to sybil the network - for
>> instance right now you can create "SPV honeypots" that allow incoming
>> connections only from SPV nodes, thus attracting a disproportionate % of
>> the total SPV population given a relatively small number of nodes. You
>> can then use that to harm SPV nodes by, for instance, making a % of
>> transactions be dropped deterministicly, either by the bloom matching
>> code, or when sent. Users unlucky enough to be surrounded by sybil nodes
>> will have their transactions mysteriously fail to arrive in their
>> wallets, or have their transactions mysteriously never confirm. Given
>> how few full nodes there are, it probably won't take very many honeypots
>> to pull off this attack, especially if you combine it with a
>> simultaneous max connections or bloom io attack to degrade the capacity
>> of honest nodes.
>
> Oh, here's an even better way to do the "tx drop" attack: when you drop
> a transaction, make a fake one that pays the same scriptPubKeys with the
> same amount, and send it to the SPV peer instead. They'll see the
> transaction go through and show up in their wallet, but it'll look like
> it got stuck and never confirmed. They'll soon wind up with a wallet
> full of useless transactions, effectively locking them out of their
> money.
Excellent, and makes a mockery of zero-confirmation transactions to boot.
Can be prevented by passing along txin proofs, but they require the full
transaction, so the effective UTXO set size would go up greatly post-pruning. I
am sure Mike would love to demand that full nodes do this for their peers
though, at least until UTXO commitments are greated, at great cost to full
nodes.
On the other hand, a tx with some txin proofs can be safely relayed by SPV
nodes, an interesting concept. Do the UTXO commitment people have keeping proof
size small in mind?
> Here's another question for you Mike: So does bitcoinj have any
> protections against peers flooding you with useless garbage? It'd be
> easy to rack up a user's data bill for instance by just creating junk
> unconfirmed transactions matching the bloom filter.
That is good too.
I'll bounty 2.5BTC to implement the first attack, and 0.5BTC for the second.
Should be easy to do as a patch to satoshi bitcoin I think. The implementation
must include a RFC3514 compliant service bit to let peers know of the operators
intentions. Along those lines I'll donate 3BTC to adding service bit selection
to DNS seeds.
We should clearly show people the limitations of SPV before they depend too
much on it. Nothing wakes users up like a 21 million BTC transaction in their
wallet.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSEYvxAAoJEEWCsU4mNhiPxI8IAJaWJ9s0YG3Ex5h8Dr6oPJ9M
uXTXa/Rt0DqS6mmyD9O80sXfgPbPbQa2rDL6imlqONaWfpXFZl2W9vxRGaZJ9wrr
3KBHzK8lasDOKqlEX92h8ZmQBjw4w5bK/heRLo1PnSZ8ojKn8+My1JvZWOPzF0Ct
tDXXuCE94csKuGRdmdDdVoXqy4XZaMQhHrGbrWVotQs1HzX3iK146GoGaZC0YyBx
cdWg/xDPtAxgb5zf2RSeNHfXeY0wZawe8vBxaS56gCRl54PG7fJvqL+YPcarNb1p
zEmahJjoyQHskjFeDpgEiXnWu3K3JGTSA5GvekWvBbJCcV4o1E6EI6LG0f1SfIs=
=12DC
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2013-08-19 3:09 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-16 1:00 Gavin Andresen
2013-08-16 4:06 ` Melvin Carvalho
2013-08-16 12:11 ` Mike Hearn
2013-08-16 12:24 ` Mike Hearn
2013-08-16 13:41 ` Warren Togami Jr.
2013-08-16 13:46 ` Mike Hearn
2013-08-16 13:53 ` Warren Togami Jr.
2013-08-16 14:06 ` Peter Todd
2013-08-16 14:56 ` Gregory Maxwell
2013-08-16 14:01 ` Peter Todd
2013-08-16 14:15 ` Peter Todd
2013-08-16 14:27 ` Warren Togami Jr.
2013-08-16 14:36 ` Mike Hearn
2013-08-16 14:59 ` Peter Todd
2013-08-16 15:06 ` Warren Togami Jr.
2013-08-16 15:11 ` Mike Hearn
2013-08-16 15:13 ` Mike Hearn
2013-08-16 15:59 ` Peter Todd
2013-08-17 0:08 ` Warren Togami Jr.
2013-08-17 12:35 ` Mike Hearn
2013-08-17 13:41 ` Jeff Garzik
2013-08-19 3:09 ` John Dillon [this message]
2013-08-19 3:17 ` Peter Todd
2013-08-19 5:00 ` John Dillon
2013-08-19 5:34 ` John Dillon
2013-08-19 5:11 ` Mark Friedenbach
2013-08-19 9:16 ` Mike Hearn
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='CAPaL=UXpitBWJOzY-TRGh4kaD2Mt6G92KTt307MfRnzygk6D3A@mail.gmail.com' \
--to=john.dillon892@googlemail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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