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; 
Date: Mon, 10 Feb 2014 14:32:47 -0500
From: Peter Todd <pete@petertodd.org>
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)
Subject: Re: [Bitcoin-development] Decentralized digital asset exchange with
 honest pricing and market depth
Precedence: list


--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 <mark@monetize.io>
Organization: Monetize.io Inc.
To: Meni Rosenfeld <meni@bitcoil.co.il>
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 <meni@bitcoil.co.il> 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--