From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WCYl6-0001oa-QG for bitcoin-development@lists.sourceforge.net; Sun, 09 Feb 2014 18:05:36 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.81 as permitted sender) client-ip=62.13.149.81; envelope-from=pete@petertodd.org; helo=outmail149081.authsmtp.net; Received: from outmail149081.authsmtp.net ([62.13.149.81]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WCYl5-00064Z-4S for bitcoin-development@lists.sourceforge.net; Sun, 09 Feb 2014 18:05:36 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s19I5Twv011513 for ; Sun, 9 Feb 2014 18:05:29 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 s19I5PUs063358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 9 Feb 2014 18:05:28 GMT Date: Sun, 9 Feb 2014 13:04:58 -0500 From: Peter Todd To: bitcoin-development@lists.sourceforge.net Message-ID: <20140209180458.GB20126@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b5gNqxB1S1yM7hjW" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: c2096bcc-91b4-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXwx1 Jh0bXVBSFQF4ABQL BhsUUBE8cANYeX5u ZEFqQHFbVVt/fUFi QwAXFGR/YAcFK2AZ U0Ndf01VcwBIfFEW aFB2UiFeMngOZyhk WlZqMmt0N2UHcmEN GltQfAobGBsHF2Eq ax0JEDMzB0QBRjc+ I1QqK1EdAE8Vekwp KlY9EV8IOB8bDAJT V15MHC8RJ14HSjE3 RRtAXEUfFjIVSCFQ ShghOBxFHl4aVidA GEst 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: 1WCYl5-00064Z-4S Subject: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth 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: Sun, 09 Feb 2014 18:05:36 -0000 --b5gNqxB1S1yM7hjW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE that allows colored coins and similar embedded consensus system assets to be securely transferred to another party in exchange for Bitcoins atomically. In summary his p2p 2-step-trade mechanism operates as follows: Alice controls a colored txout and wishes to sell it for 1BTC. Bob wishes to buy that txout. Alice signs a scriptSig using SIGHASH_SINGLE|ANYONECANPAY for a transaction with a that time. (albeit a offer floor) single input, the colored txout, and a single output with a scriptPubKey she controls and nValue=3D1 This transaction is not valid as the value out is greater than the value in. She gives this partial transaction to Bob. He can now complete the transaction by providing one or more inputs with a sum value >=3D1BTC, one output for the colored coins to be directed to, and optionally any other outputs required. (for instance for change) Bob signs his inputs with SIGHASH_ALL and broadcasts the transaction, completing the trade. What Alice has signed, the first txin scriptSig, guarantees that if the colored txout is spent she will receive 1BTC. Meanwhile what Bob has signed, all other txin scriptSigs, sign the colored input and output, guaranteeing that he will receive his coin in exchange for his money. Thus the trade is trust free and atomic. Decentralized markets and honest pricing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We can extend Mizrahi's 2-step-trade mechanism to create a decentralized marketplace. First of all, remember that traders wishing to sell their assets want to be sure that their assets offers reach the 100% of the audience who may wish to buy said assets; an attacker may try to manipulate the market to depress the price of an asset by hiding offers =66rom potential buyers. Similarly buyers want assurance that the offers they are responding to represent all offers available. Proof-of-publication(2) offers a solution. Alice can embed her incomplete transaction as data in a second, valid, transaction. She broadcasts this secondary transaction to some agreed upon blockchain, either the one the colored coin is in, or potentially a secondary system with suitable proof-of-publication security. Bidders such as Bob can now scan the blockchain for offers with an acceptable price. (the offers can make use of techniques like prefix filters to allow Bob to only scan part of the blockchain, although Bob needs to know the status of all assets of the type he is interested in anyway) There is still some potential for manipulation with very recent offers, particularly those embedded in unconfirmed transactions. However typically markets have a large number of long-standing offers, which in this case would be committed to the blockchain with one or more confirmations. Interestingly such a system can also provide honest historical pricing information: any offer that goes unfilled for one or more blocks has (in theory) been honestly published to 100% of those watching the blockchain at that time. Thus we can assume the unfufilled offers at any given block height are honest information about the market at that time historically. The overhead involved involved in Alice publishing the offer is roughly a doubling of the overall transaction fees consumed. (remember that the offer transaction is incomplete, and about half the size of the acceptance transaction) Application to other embedded consensus systems =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Any embedded consensus system can make use of the 2-step-trade mechanism so long as it is possible to create transactions where spending a single transaction output moves an asset appropriately. Unfortunately extending this to circumstances where more than one input needs to be spent, or more than out output needs to be created, is difficult. SIGHASH_SINGLE by itself results in a signature where the index of the output is signed, but the contents - scriptPubKey and nValue - of all other outputs is not signed. Meanwhile all transaction inputs are signed and changes to that set, other than modifying the nSequence value in each CTxIn, is not possible. If there was a SIGHASH mode that merely truncated vin and vout based on the index of the scriptSig we could commit to data in either, but unfortunately we can't do that. An alternative could be to create a mechanism where some embedded data signified the creation of a temporary transfer txout, where spending that txout made the underlying change desired in the consensus state atomically. 1) Alex Mizrahi, color kernel design considerations, Jan 7th 2014, Colored coins (BitcoinX) mailing list, https://groups.google.com/d/msg/bitcoinx/pON4XCIBeV4/IvzwkU8Vch0J 2) Peter Todd, [Bitcoin-development] Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation, Nov 19 2013, https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/m= sg03307.html --=20 'peter'[:-1]@petertodd.org 000000000000000075829f6169c79d7d5aaa20bfa8da6e9edb2393c4f8662ba0 --b5gNqxB1S1yM7hjW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJS98NKXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDA3NTgyOWY2MTY5Yzc5ZDdkNWFhYTIwYmZhOGRhNmU5ZWRi MjM5M2M0Zjg2NjJiYTAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsfjQf+LeiWTA9sy19coJ2Ppaz8uO6w IedA5z84t6bKxhCPREyjwUHN6JMsCcUe5/5XQiM2RTHEo0KIW7kNLBK/2oY73+MU S5Qat/6nyEq5ioyDZ6QSGRXH7SuazLuQhAugNap/56VJQOIL0/ahDkmZjggJGC4H cwfGLPdvGlFFcm9rbySoNcWqsz9aYjNWlbgMhdZl95BKozbC1VZMMPaL7uveey98 GfzraW45Qr/66XT+FWaO5Hc76K8+hUD6RAru0L8EBv0WitRLSWkJ60WiDqlAZAKE VCEI0AYUAkqRWXGooRA2wcV2GZEPB4trpoVcu+6TM7IriIiT70A04YbL9PoQPA== =VLhw -----END PGP SIGNATURE----- --b5gNqxB1S1yM7hjW--