From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Mike Hearn Message-ID: <20130418100806.GA13908@savin> References: <453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com> <20130418090444.GA30995@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--