Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WCwbg-0003TB-L0 for bitcoin-development@lists.sourceforge.net; Mon, 10 Feb 2014 19:33:28 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.80 as permitted sender) client-ip=62.13.149.80; envelope-from=pete@petertodd.org; helo=outmail149080.authsmtp.com; Received: from outmail149080.authsmtp.com ([62.13.149.80]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WCwbf-0006bU-2P for bitcoin-development@lists.sourceforge.net; Mon, 10 Feb 2014 19:33:28 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s1AJXLIH053589 for ; Mon, 10 Feb 2014 19:33:21 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 s1AJXHaR026008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 10 Feb 2014 19:33:20 GMT Date: Mon, 10 Feb 2014 14:32:47 -0500 From: Peter Todd To: bitcoin-development@lists.sourceforge.net Message-ID: <20140210193247.GC17359@savin> References: <20140209180458.GB20126@savin> <20140209204434.GA11488@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2/5bycvrmDh4d1IB" Content-Disposition: inline In-Reply-To: <20140209204434.GA11488@savin> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 32bd5f26-928a-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgV1 Jh0bXVBSFQF4ABUL BR0UUBk8cANYeX5u ZEFqQHFbVVt/fUFi QwAXFBx8DR8xCmAd VkBYf01VcwBPelFG aAIrUSUPZ3gOZHIx WlZqMmt0N2UHcmEN GltQfAobGBsHF2Eq fR1QVQYFHFEOQCQ1 ahArNFMYG14UP0Mu BBMNVFkVNQMIAwlf DUxBSCNYKFgdTi5j BBhBUFJWHS1WQS5a DRBgPR5UAl4aWi1e CVBZAwkVCihEViYA QTBRGigkFlskOwom PzwDMWkA 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: 1WCwbf-0006bU-2P Subject: Re: [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: Mon, 10 Feb 2014 19:33:28 -0000 --2/5bycvrmDh4d1IB Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 09, 2014 at 03:44:34PM -0500, Peter Todd wrote: > On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote: > > 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: >=20 > I'm told there's probably at least one if not more earlier > attributions/reinventions for the 2-step-trade protocol using > SIGHASH_SINGLE. Please reply with them if you have them so we can give > credit where credit is due. Got this: Message-ID: <52418EBA.3080602@monetize.io> Date: Tue, 24 Sep 2013 06:08:10 -0700 =46rom: Mark Friedenbach Organization: Monetize.io Inc. To: Meni Rosenfeld Subject: Re: Freimarkets and investment If assets were tagged you could do a very limited form of pre-signed offers: in: 10 btc SINGLE|ANYONECANPAY out: 1 AAA These are composable, in that you can append the inputs and outputs of multiple offers together and result in a valid transaction. However this is pretty much the limit of what is possible without adding new SIGHASH modes, and if you're going to hard-fork to add tagging, then you might as well go the whole distance with explicit hierarchical sub-transactions as we did with Freimarkets. Cheers, Mark On 9/24/13 5:44 AM, Meni Rosenfeld wrote: > Hi Jorge, >=20 > The video was sent to me by Amos Meiri, I think eToro funded its producti= on. >=20 > Maybe I don't understand SIGHASH_ANYONECANPAY very well. In the > transaction, there will be an output of 1 "my stock" to an initially > unknown address. Can I provide a signature for my input of 1 "my stock" > that will be valid even with the output details provided later? >=20 > In any case, I think that's out of scope for the presentation. >=20 > Meni >=20 > On 24/09/2013 13:10, Jorge Tim=F3n wrote: >> Yes, it's a nice presentation. >> I love the video with the chameleons that you link at the end !! >> >> As a little sugestion, I think the biggest advantage of tagging is not >> inflatable assets, it's open binding orders. Even without granular >> subtransactions as freimarket has, you could sign your input (say, >> representing 1 "My stock") and only the output you're interested in >> (say 100 bitstampUSD to myAddress) with SIGHASH_SINGLE | >> SIGHASH_ANYONECANPAY. >> >> Without tagging, you need to know where the inputs come from to check >> they're really bitstampUSD, because the network won't enforce the "100 >> bistampUSD" in your output, any uncolored coins filling the btc >> quantity you wanted to represent those 100 usd will be ok, for miners. >> >> Goog luck with the talk, I'm eager to hear it. >> >> By the way, Mark, the explanation of the blockchain image sounds a >> little bit like hashcasttle, no? well, just merged mining every new >> asset, sounds like jaromil's freecoin too. >> >> >> On 9/24/13, Meni Rosenfeld wrote: >>> Hi Mark, >>> >>> We currently have a more general mathematical framework for the concept= of >>> colored coins - a color is a combination of initial state and a kernel >>> function that maps input colors to output colors. Order-based coloring = is >>> one such kernel function, tagging is another. As long as you can point = at an >>> output and say what its color is, we call it a colored coin system. >>> >>> The blockchain image is a stand-in for "using a new block chain for each >>> asset". >>> >>> Meni >>> >>> On 24/09/2013 00:42, Mark Friedenbach wrote: > Hi Meni, >=20 > I did call Freimarkets "colored coins" in the early days, but the term > colored coin itself within the community seems to have become > identified with the specific proposal of assigning value to specific > satoshis, and running an order based coloring algorithm to determine > asset flow, e.g. Bitcoin-X. Freimarkets allows issuance of entirely > new assets and has explicit tagging of outputs, so we decided to avoid > the phrase "colored coin" so as to keep from confusing people. But as > an academic, yes you are correct. >=20 > You presentation looks great. BTW, what's the first logo for the > "Alternative token systems" slide? Or is that just a stand-in for the > block chain? >=20 > Mark >=20 > On 9/23/13 12:24 PM, Meni Rosenfeld wrote: >>>>>> Hi, >>>>>> >>>>>> As you might know I'm giving a talk about Colored Coins in >>>>>> Amsterdam. >>>>>> >>>>>> My presentation is available at >>>>>> https://bitcoil.co.il/files/Colored Coins.pptx (I'm not posting >>>>>> this link publicly until after the talk). >>>>>> >>>>>> I'll be happy for any feedback. >>>>>> >>>>>> I'm listing Freimarkets as an implementation of Colored Coins. It >>>>>> doesn't look like you're identifying with the term, but it does fit >>>>>> the definition (and though it does obviously do much more than >>>>>> just implement colored coins.) >>>>>> >>>>>> Thanks, Meni >>>> >>> >> >=20 --=20 'peter'[:-1]@petertodd.org 0000000076654614e7bf72ac80d47c57bca12503989f4d602538d3cd7892ca7d --2/5bycvrmDh4d1IB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJS+SlfXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwNzY2NTQ2MTRlN2JmNzJhYzgwZDQ3YzU3YmNhMTI1MDM5ODlmNGQ2MDI1 MzhkM2NkNzg5MmNhN2QvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsYiQf7B2/Mc5wKDj6Yy/SEHo1DWmLF c316WtZx8oIVs2gUGP5Iu0qBnSNAU/ivNzhFGVan04NB0iN23jNNGiN/jNFoo1as gTPqrAcmawxzShK1vjUKP3Ow+dG0pDUxJeHqmLO4M8eh11czFLAVQsqGndkK27xN U0BUXFwiZU8DaQgHmXuAkNjgP8mPpI1lfmdNQqkLkUxfvnjibKeYDXTCj4gDgxph BHS/46TKhzk2/88qBVh4qtIuUvvDD44IVLgJj4shsuqFwJNVyMnic6egSXAu5CoB 6awv7Et6GC5epbOqkfns13BEi+bpmAXGOyrmdya7s6mfcOBaQvBayHKEEFjgMA== =wd4p -----END PGP SIGNATURE----- --2/5bycvrmDh4d1IB--