From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VAKas-0004tm-Ao for bitcoin-development@lists.sourceforge.net; Fri, 16 Aug 2013 14:01:34 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.56 as permitted sender) client-ip=62.13.149.56; envelope-from=pete@petertodd.org; helo=outmail149056.authsmtp.com; Received: from outmail149056.authsmtp.com ([62.13.149.56]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VAKaq-0007KS-J6 for bitcoin-development@lists.sourceforge.net; Fri, 16 Aug 2013 14:01:34 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r7GE1PxT091707; Fri, 16 Aug 2013 15:01:25 +0100 (BST) Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r7GE1H2f072135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 16 Aug 2013 15:01:19 +0100 (BST) Date: Fri, 16 Aug 2013 10:01:16 -0400 From: Peter Todd To: Mike Hearn Message-ID: <20130816140116.GB16201@petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PmA2V3Z32TCmWXqI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 53b799b2-067c-11e3-b5c5-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwQUGUATAgsB AmUbWlFeUFx7W2M7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQxt2 cx9mUE9ycAdHe3s+ Z0RlXXIVWUcock90 EExJFWsBNnphaTUc TRJdJAZJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMTci RhZNBn03GlYZAn11 flQaDXI7VEIQKVl0 dx1J X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1VAKaq-0007KS-J6 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: Fri, 16 Aug 2013 14:01:34 -0000 --PmA2V3Z32TCmWXqI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 16, 2013 at 02:24:04PM +0200, Mike Hearn wrote: > The only other thing I'd like to see there is the start of a new anti-DoS > framework. I think once the outline is in place other people will be able > to fill it in appropriately. But the current framework has to be left > behind. Part of anti-DoS should include making it easier for people to contribute back to the network. Lowest hanging fruit: 1) SPV nodes with spare bandwidth should relay whole blocks to reduce the load on full-nodes. The SPV security model is based on hashing power anyway, so there is no major harm in doing so - if you have the resources to fake blocks, you probably have the resources to sybil the network anyway. 2) It's probably reasonable for SPV peers with bandwidth to be willing to do bloom filtering on the behalf of peers that don't have spare bandwidth. Hence they would set NODE_BLOOM, but not NODE_NETWORK. (or more likely some more nuanced flags) Again this has to apply to full blocks only unless we come up with some PoW scheme or similar to discourage DoS attacks via invalid transactions. (maintaining partial UTXO sets is another possibility, although a complex one) Both examples work best with payment protocols where the recipient is responsible for getting the transaction broadcast. Similarly you can by default not connect to full-node peers, and then connect to them on demand when you have a transaction to send. 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. Deanonymization is another attack that can be done at the same time of course. In any case, the more peers on the network that can relay data the better. 3) Make it easier to run a full node. IMO partial mode is the way to go here. Note that from a legal perspective we really want to make sure that running full nodes (and mining p2pool or solo) continue to be something ordinary users do. We do not want to give the impression to regulators that running a full node is in any way unusual or rare, and thus something that might be practical or desirable to regulate. Users should be given clear options about how much disk space and bandwidth to donate to the health of the network, and within those limits nodes should always try to make progress towards being full nodes, and in the meantime being increasingly productive partial nodes. Even with pure SPV nodes if they are relaying block data and ideally transactions they make it much more difficult for regulations to be made that, say, require full node operators to apply blacklists to transactions in the mempool or in blocks. 4) This is really a side effect, and not directly DoS-related, but unfortunately we're going to have to create some kind of proof-of-UTXO-possession that miners include in the blocks they mine. With partial mode it's just too easy and tempting for people to mine blocks with fee paying transactions in them without actually having the full UTXO set; such nodes can't tell if a block is invalid due to a fake txin, and thus will happily extend a invalid chain. This possession proof can probably be make part of a UTXO commitment. > If I had to choose one thing to evict to make time for that, it'd be the > whitepapers. At the moment we still have plenty of headroom in block size= s, > even post April. It can probably be safely delayed for a while. Lots of off-chain tx solutions are popping up which will help push back the issue's relevance as well. Also your micropayment channels possibly. --=20 'peter'[:-1]@petertodd.org 000000000000000b9656276a0fdab028ca759c3fd7f951fb20196c264b5cd1ce --PmA2V3Z32TCmWXqI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlIOMKwACgkQpEFN739thoxusACdHlQifBh2/AOWq7oMbeLgB/pO AhUAn2W5vIQj384QPwn6tihCCPId4gqO =1OOu -----END PGP SIGNATURE----- --PmA2V3Z32TCmWXqI--