Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of googlemail.com
	designates 74.125.83.52 as permitted sender)
	client-ip=74.125.83.52;
	envelope-from=john.dillon892@googlemail.com;
	helo=mail-ee0-f52.google.com; 
MIME-Version: 1.0
In-Reply-To: <20130816141536.GD16201@petertodd.org>
References: <CABsx9T32q8mKgtmsaZgh7nuhHY5cExeW=FiadzXq3jXVP=NBTw@mail.gmail.com>
	<CANEZrP0PEcP339MKRyrHXHCCsP3BxRHT-ZfKRQ7G2Ou+15CD7A@mail.gmail.com>
	<CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com>
	<20130816140116.GB16201@petertodd.org>
	<20130816141536.GD16201@petertodd.org>
Date: Mon, 19 Aug 2013 03:09:07 +0000
Message-ID: <CAPaL=UXpitBWJOzY-TRGh4kaD2Mt6G92KTt307MfRnzygk6D3A@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
Precedence: list

-----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-----