From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VBFqE-0002Cm-OH for bitcoin-development@lists.sourceforge.net; Mon, 19 Aug 2013 03:09:14 +0000 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; Received: from mail-ee0-f52.google.com ([74.125.83.52]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VBFqD-0003Bu-P7 for bitcoin-development@lists.sourceforge.net; Mon, 19 Aug 2013 03:09:14 +0000 Received: by mail-ee0-f52.google.com with SMTP id c41so1866889eek.25 for ; Sun, 18 Aug 2013 20:09:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.15.43.140 with SMTP id x12mr45633eev.61.1376881747432; Sun, 18 Aug 2013 20:09:07 -0700 (PDT) Received: by 10.223.41.4 with HTTP; Sun, 18 Aug 2013 20:09:07 -0700 (PDT) In-Reply-To: <20130816141536.GD16201@petertodd.org> References: <20130816140116.GB16201@petertodd.org> <20130816141536.GD16201@petertodd.org> Date: Mon, 19 Aug 2013 03:09:07 +0000 Message-ID: From: John Dillon To: Peter Todd Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.4 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (john.dillon892[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (john.dillon892[at]googlemail.com) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VBFqD-0003Bu-P7 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list... X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 03:09:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, Aug 16, 2013 at 2:15 PM, Peter Todd 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-----