From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WRHZl-0006hF-5s for bitcoin-development@lists.sourceforge.net; Sat, 22 Mar 2014 08:46:45 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.100 as permitted sender) client-ip=62.13.148.100; envelope-from=pete@petertodd.org; helo=outmail148100.authsmtp.co.uk; Received: from outmail148100.authsmtp.co.uk ([62.13.148.100]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WRHZj-00064U-Mr for bitcoin-development@lists.sourceforge.net; Sat, 22 Mar 2014 08:46:45 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2M8kbuo005581 for ; Sat, 22 Mar 2014 08:46:37 GMT 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 s2M8kYl1027429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 22 Mar 2014 08:46:36 GMT Date: Sat, 22 Mar 2014 04:47:02 -0400 From: Peter Todd To: bitcoin-development@lists.sourceforge.net Message-ID: <20140322084702.GA13436@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 7a735fa9-b19e-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQd1 LRkLXVBSFQF4ARQL AhgUUR88cANYeX5u ZEFqQHFbVVt/fUFi QwAXFxAOPg48aWAd V0Rafk1VcQRLflFC O1d8USVcaHhVZ3M1 WlZqMmt0N2UHcmEN GltQfAobGBsHF2Eq ZxkEETEuG0JNQiQ1 IgZuI1IbBFoQNUN6 PkEoUl8WLhsWG0VQ GFsFDSpTKlUNSiZj BgRcRkMYCyBGCTxN GQElJwQqSiJTU2JU A1ZPTxxKEDtIViVJ TjkaSCA1CFEiKgcg I2ERPAxZ X-Authentic-SMTP: 61633532353630.1023: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: 1WRHZj-00064U-Mr Subject: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee 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: Sat, 22 Mar 2014 08:46:45 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable There's been a lot of recent hoopla over proof-of-publication, with the OP_RETURN length getting reduced to a rather useless 40 bytes at the last minute prior to the 0.9 release. Secondly I noticed a overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken into account, making it possible to broadcast unminable transactions and bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG outputs given that the sigops limit and the way they use up a fixed 20 sigops per op makes them hard to do fee calculations for. They also make it easy to bloat the UTXO set, potentially a bad thing. This would of course require things using them to change. Currently that's just Counterparty, so I gave them the heads up in my email. To make a long story short, it was soon suggested that Bitcoin Core be forked - the software, not the protocol - and miners encouraged to support it. This isn't actually as trivial as it sounds, as you need to add some anti-DoS stuff to deal with the fact that the hashing power mining the transations you are relaying may be quite small. The second issue is you need to add preferential peering, so the nodes in the network with a broader idea of what is a "allowed" transaction can find each other. (likely with a new service flag) It'd be a good time to implement replace-by-fee, partly for its anti-DoS properties. Which leaves us with a practical question: How do you gracefully handle a switchover? First of all I suggest that proof-of-publication applications adopt format flexibility, similar to how Mastercoin can encode its data in pay-to-pubkeyhash, bare multisig, or op_return outputs. Given the possibility of bare multisig going away, I'd suggest that P2SH multisig scriptSig encoding be added as well. Note that a really good implementation of all this is actually format agnostic, and will let PUSHDATA's used for encoding data be specified arbitrarily. I wrote up some code to do so awhile back as an experiment. It used the LSB's of the nValue field in the txouts to specify what was and wasn't data, along with some stenographic encryption of data and nValue. I'd be happy to dig that up if anyone is interested. All these methods have some overhead compared to just using OP_RETURN and thus cost more. So I suggest you have your software simultaneously double-spend the inputs to any proof-of-publication transaction with a second transaction that just makes use of efficient OP_RETURN. That second one can go to more enlightened miners. Only one or the other will get mined of course and the cost to publish data will be proportional to the relative % of hashing power in the two camps. Finally I'll be writing something more detailed soon about why proof-of-publication is essential and miners would be smart to support it. But the tl;dr: of it is if you need proof-of-publication for what your system does you're much more secure if you're embedded within Bitcoin rather than alongside of it. There's a lot of very bad advise getting thrown around lately for things like Mastercoin, Counterparty, and for that matter, Colored Coins, to use a separate PoW blockchain or a merge-mined one. The fact is if you go with pure PoW, you risk getting attacked while your still growing, and if you go for merge-mined PoW, the attacker can do so for free. We've got a real-world example of the former with Twister, among many others, usually resulting in a switch to a centralized checkpointing scheme. For the latter we have Coiledcoin, an alt that made the mistake of using SHA256 merge-mining and got killed off early at birth with a zero-cost 51% attack. There is of course a censorship risk to going the embedded route, but at least we know that for the forseeable future doing so will require explicit blacklists, something most people here are against. To MSC, XCP and others: Now I'm not going to say you shouldn't take advice from people who call your finance 2.0 systems scams, or maybe if they're nice, indistinguishable from a scam. But when you do, you should think for yourself before just trusting that some authority figure has your best interests in mind. 1) Yes, this was responsibly disclosed to the security mailing list. It was revealed to the public a few hours later on the -dev IRC channel without a fix. --=20 'peter'[:-1]@petertodd.org 00000000000000009065ab15f4a036e9ec13d2e788e0ede69472e0ec396b097f --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTLU3/XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDA4MTJjNzU2ZGJhNmJkYmYyODQwMTU0NjNhNzYzMGFiNWU0 ODA1NmQ0MmFlZTAyNjkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuO3AgAnM7TALoodJuOPh4x1Xm8hYYS fjak1he1YQTahPnxJEO/Pt2ol0kr6nP6qFsDi2Ty+tQg+C7vj7HMvgj7nkOC/oas +3eCCrFi/bXGbiPs6o+8nFXWJpCqj8WUc//PjsH/zRYkp2OGHP1/DStjHCqFnVO8 lozIC18bNgspGLkBFoPEYmqPrQ+GwCF7mK+JsjA9KBJcuwTySX/RtEyxE1YXVcGb 5H0nftMznw74UxZiy7+B5HGWmrbmBLpgmn05W3fzG1QU45LLEMLeq8p9TJ39qZYv BKyirOrxHzyrHrXNnZgfgQibrc+0CQR4euVyCvStXLbuiCNdbkq4fuL+W1WREA== =dONs -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi--