diff options
| author | Peter Todd <pete@petertodd.org> | 2013-04-18 06:08:06 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-04-18 10:08:21 +0000 |
| commit | 1a46f22d5e214f228b6de642b6b9131abacf0796 (patch) | |
| tree | 6f6bdb5184419604e7c1498cf2c583b608bd17db /bb/d0af37435ead0c70f30a1ee4160d45aaa47ccd | |
| parent | 5d65f5bd70f1e9dea610118da740ee839a802489 (diff) | |
| download | pi-bitcoindev-1a46f22d5e214f228b6de642b6b9131abacf0796.tar.gz pi-bitcoindev-1a46f22d5e214f228b6de642b6b9131abacf0796.zip | |
Re: [Bitcoin-development] Anti DoS for tx replacement
Diffstat (limited to 'bb/d0af37435ead0c70f30a1ee4160d45aaa47ccd')
| -rw-r--r-- | bb/d0af37435ead0c70f30a1ee4160d45aaa47ccd | 191 |
1 files changed, 191 insertions, 0 deletions
diff --git a/bb/d0af37435ead0c70f30a1ee4160d45aaa47ccd b/bb/d0af37435ead0c70f30a1ee4160d45aaa47ccd new file mode 100644 index 000000000..7d3ce43dd --- /dev/null +++ b/bb/d0af37435ead0c70f30a1ee4160d45aaa47ccd @@ -0,0 +1,191 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pete@petertodd.org>) id 1USllN-000371-PW + for bitcoin-development@lists.sourceforge.net; + Thu, 18 Apr 2013 10:08:21 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org + designates 62.13.148.154 as permitted sender) + client-ip=62.13.148.154; envelope-from=pete@petertodd.org; + helo=outmail148154.authsmtp.co.uk; +Received: from outmail148154.authsmtp.co.uk ([62.13.148.154]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1USllM-0003bC-3i for bitcoin-development@lists.sourceforge.net; + Thu, 18 Apr 2013 10:08:21 +0000 +Received: from mail-c226.authsmtp.com (mail-c226.authsmtp.com [62.13.128.226]) + by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id + r3IA8DoN020363; Thu, 18 Apr 2013 11:08:13 +0100 (BST) +Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) + (authenticated bits=128) + by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r3IA86Dk081280 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); + Thu, 18 Apr 2013 11:08:09 +0100 (BST) +Date: Thu, 18 Apr 2013 06:08:06 -0400 +From: Peter Todd <pete@petertodd.org> +To: Mike Hearn <mike@plan99.net> +Message-ID: <20130418100806.GA13908@savin> +References: <CANEZrP1yKeQMayFHsEUWtA3=q+v5rPAutjzEFVVHopPGNZ4jGQ@mail.gmail.com> + <453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com> + <CANEZrP0z6W0ZDsytQ7Rcqb5L6rswn1wv8cbR7c383Dmpzu+gyg@mail.gmail.com> + <CAPaL=UVJd3mdd0bs6Oo9vFHnv_6RbFowjmp0tD-ZbOzZxJEJ3g@mail.gmail.com> + <CANEZrP3ocAJNoQ3xJqRTL8Gz3_T8xsCPPAvSfEOYpPo76wgbig@mail.gmail.com> + <20130418090444.GA30995@savin> + <CANEZrP0AYaWnVhrAbMXP0BGhb=CZMg_-PYVzwKbcCoRKC9V2rw@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha1; + protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" +Content-Disposition: inline +In-Reply-To: <CANEZrP0AYaWnVhrAbMXP0BGhb=CZMg_-PYVzwKbcCoRKC9V2rw@mail.gmail.com> +User-Agent: Mutt/1.5.21 (2010-09-15) +X-Server-Quench: df7ce56e-a80f-11e2-98a9-0025907ec6c5 +X-AuthReport-Spam: If SPAM / abuse - report it at: + http://www.authsmtp.com/abuse +X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR + aQdMdwoUGUUGAgsB AmUbWlVeUFV7WGM7 bAxPbAVDY01GQQRq + WVdMSlVNFUsqAmVw DhhqCRl6dgdOeDBy YEZmXj4PCkMpIEN7 + F1MFHW1QeGZhPWIC WUgJfh5UcAFPdx9C PwN5B3ZDAzANdhES + HhM4ODE3eDlSNilR RRkIIFQOdA4iGCI9 DzwFJn0hGldNWzV7 + NRE+LlcXEUMcNFla +X-Authentic-SMTP: 61633532353630.1020:706 +X-AuthFastPath: 0 (Was 255) +X-AuthSMTP-Origin: 76.10.178.109/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: 1USllM-0003bC-3i +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Anti DoS for tx replacement +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: Thu, 18 Apr 2013 10:08:21 -0000 + + +--OXfL5xGRrasGEqWY +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Thu, Apr 18, 2013 at 11:28:48AM +0200, Mike Hearn wrote: +> Let's include bandwidth. Say the contract (multi-sig input + the outputs) +> is about 700 bytes. 43,200 transactions is then about 29 megabytes of dat= +a. +> On a fairly normal 10mbit connection that would take about 23 seconds to +> transfer. Of course the real number is a bit higher because of latency +> introduced by the inv/tx round-tripping. So the time window of the attack +> is dominated by bandwidth but it's still quite small compared to the block +> solving window. + +Mike, for the love of god, it's not acceptable to require Bitcoin +validating and mining nodes to buy unlimited bandwidth. The attacker +just has to spend more outgoing bandwidth than some fraction of the +network hashing power has incoming bandwidth (individually speaking) for +convergence to fail. + +But anyway, as I said in my follow up email, with correct prioritization +it's probably a tractable problem. + +> It's *easily* DoSable, not trivially. +> > +>=20 +> What I meant is - find some open DNS resolvers, start firing packets at +> testnet nodes, done. You don't have to do protocol level attacks to just +> render nodes useless. + +Testnet has 40 nodes online right now that can be seen by my seeder. To +shut down all those nodes with a standard DoS attack would take at least +40 times more bandwidth than required by a tx-replacement DoS attack. + +> Having a single multi-sig input means you can't do that because both +> parties co-operate to update the single input, but schemes that use +> multiple inputs do seem posible. + +You can always add dummy inputs. + +> > How exactly do you envision replacement working with non-final =3D=3D +> > non-standard anyway? +> > +>=20 +> As I said at the bottom of my second mail, it means making non-final +> transactions relayable again, but only to nodes that advertise a high +> enough version number. Those nodes are expected to do something intellige= +nt +> with them, like just not put them in the wallet (unless the user has opted +> in and ticked the "i know what i'm doing" box, perhaps). + +Well, all that making them relayable enables is letting all parties to a +transaction be offline when the nLockTime expires, so I'm not really +sure it's worth doing, at least immediately. Weakening the non-final =3D=3D +non-standard test to give a window of, say, 3 blocks, would be fine I +think. + +> Well, it depends on your use case - you need to cast the (fixed) algorithm +> into a network protocol, manage the interactions between the parties, +> monitor the network for malicious broadcasts so you can replace them, fix +> the code so the wallets don't accept non-final transactions except when +> taking part in your contract, etc. If you do it all with Bitcoin-Qt it's +> easier but then your app can't easily run in places that can't afford a f= +ew +> hundred megs of ram (like wifi hotspots). The devil is in the details. + +The whole point of tx-replacement by fee is that the algorithm doesn't +need to be fixed. It makes it very clear that unconfirmed transactions +aren't trustworthy, and levels the playing field between you and people +posessing lots of hashing power. Nodes can independently choose their +replacement policy and the system still works. It also makes adjusting +fees after the fact easy, again, functionality that we really need right +now. + +John's adjusting micropayments proposal would work best in conjuction +with some reputation stuff, like buying a fidelity bond promising you +will play nice with tx replacement. Implementing such bonds is a bit +subtle, because random chance can cause an earlier tx to be mined rather +than a latter, but you can, for instance, rebut accusations of fraud in +that case by simply creating an additional tx that pays the full amount +if a partial tx accidentally gets mined. Come to think of it, such a +system could be useful for inter-bank settlement, providing a security +guarantee somewhere between a standard transaction and a fully off-chain +transaction, at the cost of a single transaction fee. + +More importantly, it's not subject to sudden "oh shit, slush's pool got +hacked and is doing double spends!" disasters. People should not be +trusting multiple mining pools run by individuals as hobbies on insecure +VPS services with the security of their payments, and zero-conf +transactions do exactly that. Not to mention the ~25% of hashing power +controlled by parties of unknown origin. + +--=20 +'peter'[:-1]@petertodd.org + +--OXfL5xGRrasGEqWY +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: Digital signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.11 (GNU/Linux) + +iQEcBAEBAgAGBQJRb8YFAAoJEH+rEUJn5PoEVXIH/1LeeTaDaiF//lduQchcsoul +H32CZkQ7eHzeHOrOhuhJXM2x6K3rOvtsK8To4Q157d93qskXAqmNeOI5ZwGHSNi4 +loRePp7+teny6y2lo0YwlPQEj7GEbGyKVqrziokkeuTeOnJU/X6VnD1/HH0sXSA6 +qihlHdbPvbPxLEMm+Nyo3tWyi8MBvz2v2fo1At3ZtT9UfuGQokYipnKhvxSQD0vF +UgWcGNLkLBjRdwWOmk5vP167FwpOTI3OydhxdnS083fesFiPxSTSgy4aet1Aw/MX +uqAooTQPmznM7uS0zlbRZ9PZocAapgfpx9Qsl7Vb8nLFk2taPhpAVDZnkIIIry0= +=rz4o +-----END PGP SIGNATURE----- + +--OXfL5xGRrasGEqWY-- + + |