diff options
| author | Peter Todd <pete@petertodd.org> | 2013-08-16 10:01:16 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-08-16 14:01:34 +0000 |
| commit | e493acd1c882043bbf7fd5a82095565ccdbf6cbd (patch) | |
| tree | ae2f4db0fee88248e668fcc563cb01624d3d12bc | |
| parent | 3d336b28556e5a21f8447144effe6fa289a414b9 (diff) | |
| download | pi-bitcoindev-e493acd1c882043bbf7fd5a82095565ccdbf6cbd.tar.gz pi-bitcoindev-e493acd1c882043bbf7fd5a82095565ccdbf6cbd.zip | |
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
| -rw-r--r-- | 30/60453f93c126523524c9c234c11e179ab1cad9 | 178 |
1 files changed, 178 insertions, 0 deletions
diff --git a/30/60453f93c126523524c9c234c11e179ab1cad9 b/30/60453f93c126523524c9c234c11e179ab1cad9 new file mode 100644 index 000000000..f2b140754 --- /dev/null +++ b/30/60453f93c126523524c9c234c11e179ab1cad9 @@ -0,0 +1,178 @@ +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 <pete@petertodd.org>) 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 <pete@petertodd.org> +To: Mike Hearn <mike@plan99.net> +Message-ID: <20130816140116.GB16201@petertodd.org> +References: <CABsx9T32q8mKgtmsaZgh7nuhHY5cExeW=FiadzXq3jXVP=NBTw@mail.gmail.com> + <CANEZrP0PEcP339MKRyrHXHCCsP3BxRHT-ZfKRQ7G2Ou+15CD7A@mail.gmail.com> + <CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha1; + protocol="application/pgp-signature"; boundary="PmA2V3Z32TCmWXqI" +Content-Disposition: inline +In-Reply-To: <CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com> +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 <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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-- + + |