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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TFNWE-0002uk-Aw for bitcoin-development@lists.sourceforge.net; Sat, 22 Sep 2012 11:05:06 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.175 as permitted sender) client-ip=74.125.82.175; envelope-from=mh.in.england@gmail.com; helo=mail-we0-f175.google.com; Received: from mail-we0-f175.google.com ([74.125.82.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TFNW9-00063b-CM for bitcoin-development@lists.sourceforge.net; Sat, 22 Sep 2012 11:05:06 +0000 Received: by weyt44 with SMTP id t44so1270630wey.34 for ; Sat, 22 Sep 2012 04:04:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.94.38 with SMTP id cz6mr2604765wib.10.1348311895108; Sat, 22 Sep 2012 04:04:55 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.216.139.134 with HTTP; Sat, 22 Sep 2012 04:04:54 -0700 (PDT) Received: by 10.216.139.134 with HTTP; Sat, 22 Sep 2012 04:04:54 -0700 (PDT) In-Reply-To: References: Date: Sat, 22 Sep 2012 13:04:54 +0200 X-Google-Sender-Auth: p5YfP-_RqOtARh9rKTgMjccEDQY Message-ID: From: Mike Hearn To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=f46d044271088deb9f04ca4853b5 X-Spam-Score: -1.0 (-) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.5 AWL AWL: From: address is in the auto white-list X-Headers-End: 1TFNW9-00063b-CM Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Atomic coin swapping? 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 Sep 2012 11:05:06 -0000 --f46d044271088deb9f04ca4853b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Perhaps I missing something obvious about the definition of coloured coins, but this appears to be very simple. Just create a transaction that transfers 300 coins and have an unsigned input connected to the coloured output. send to the owner of the coloured output, they sign it and broadcast. On Sep 22, 2012 11:10 AM, "Jorge Tim=C3=B3n" wrot= e: > I'm very interested in this. I was expecting transitive/multi-hop > transactions (Ripple) with colored coins, and I don't understand why > is not possible. > > >From https://en.bitcoin.it/wiki/Contracts > > --- > SIGHASH_ALL: This is the default. It indicates that everything about > the transaction is signed, except for the input scripts. Signing the > input scripts as well would obviously make it impossible to construct > a transaction, so they are always blanked out. Note, though, that > other properties of the input, like the connected output and sequence > numbers, are signed; it's only the scripts that are not. Intuitively, > it means "I agree to put my money in, if everyone puts their money in > and the outputs are this". > --- > > Why "Signing the input scripts as well would obviously make it > impossible to construct a transaction"? > I don't understand that part. I think a new SIGHASH_* type that > doesn't pay attention to that "obviously" is needed to achieve what we > want. > > Say we want the following transaction: > > A 1 satoshi -> B 1 satoshi -> C 100 btc -> A > > It would be necessary to sign the following: > > Inputs: from srcA, from srcB, > Outputs: 1 satoshi to destB, 1 satoshi to destC, 100 btc to destA > > "from srcC" is not really necessary. > > This same scheme can be used for n-hops. > > What am I missing? > > On 9/22/12, Jeff Garzik wrote: > > Forum URL: https://bitcointalk.org/index.php?topic=3D112007.0 > > > > gmaxwell was talking about colored coins[1] in IRC recently. They are > > potentially interesting in the context of distributed bonds[2], which > > I am currently pursuing with pybond[3]. > > > > Here is the problem I am trying to solve, does the crowd have an answer= ? > > > > 1. Alice transfers a 1-satoshi colored coin to Bob. > > 2. Bob transfers 100 BTC to Alice. May be restricted to 1 txout, if > > that eases implementation details. > > 3. Steps #1 and #2 happen as an atomic unit, all-or-none. > > 4. Alice and Bob must both approve this atomic transfer of coins, with > > appropriate signatures. > > > > Is this possible within the current bitcoin system? As far as I can > > see, the answer is "no" but maybe I'm missing something. > > > > My best guess to the answer is "possible, but requires a new SIGHASH_* > > type"? > > > > [1] https://bitcointalk.org/index.php?topic=3D106449.0 > > [2] https://bitcointalk.org/index.php?topic=3D92421.0 > > [3] https://github.com/jgarzik/pybond > > > > -- > > Jeff Garzik > > exMULTI, Inc. > > jgarzik@exmulti.com > > > > > -------------------------------------------------------------------------= ----- > > How fast is your code? > > 3 out of 4 devs don\\\'t know how their code performs in production. > > Find out how slow your code is with AppDynamics Lite. > > http://ad.doubleclick.net/clk;262219672;13503038;z? > > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > -- > Jorge Tim=C3=B3n > > > -------------------------------------------------------------------------= ----- > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --f46d044271088deb9f04ca4853b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Perhaps I missing something obvious about the definition of coloured coi= ns, but this appears to be very simple. Just create a transaction that tran= sfers 300 coins and have an unsigned input connected to the coloured output= . send to the owner of the coloured output, they sign it and broadcast.

On Sep 22, 2012 11:10 AM, "Jorge Tim=C3=B3n= " <timon.elviejo@gmail.c= om> wrote:
I'm very interested in this. I was expecting transitive/multi-hop
transactions (Ripple) with colored coins, and I don't understand why is not possible.

>From https://en.bitcoin.it/wiki/Contracts

---
SIGHASH_ALL: This is the default. It indicates that everything about
the transaction is signed, except for the input scripts. Signing the
input scripts as well would obviously make it impossible to construct
a transaction, so they are always blanked out. Note, though, that
other properties of the input, like the connected output and sequence
numbers, are signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in<= br> and the outputs are this".
---

Why "Signing the input scripts as well would obviously make it
impossible to construct a transaction"?
I don't understand that part. I think a new SIGHASH_* type that
doesn't pay attention to that "obviously" is needed to achiev= e what we
want.

Say we want the following transaction:

A 1 satoshi -> B 1 satoshi -> C 100 btc -> A

It would be necessary to sign the following:

Inputs: from srcA, from srcB,
Outputs: 1 satoshi to destB, 1 satoshi to destC, 100 btc to destA

"from srcC" is not really necessary.

This same scheme can be used for n-hops.

What am I missing?

On 9/22/12, Jeff Garzik <jgarzik@= exmulti.com> wrote:
> Forum URL: https://bitcointalk.org/index.php?topic=3D112007.0
>
> gmaxwell was talking about colored coins[1] in IRC recently. =C2=A0The= y are
> potentially interesting in the context of distributed bonds[2], which<= br> > I am currently pursuing with pybond[3].
>
> Here is the problem I am trying to solve, does the crowd have an answe= r?
>
> 1. Alice transfers a 1-satoshi colored coin to Bob.
> 2. Bob transfers 100 BTC to Alice. =C2=A0May be restricted to 1 txout,= if
> that eases implementation details.
> 3. Steps #1 and #2 happen as an atomic unit, all-or-none.
> 4. Alice and Bob must both approve this atomic transfer of coins, with=
> appropriate signatures.
>
> Is this possible within the current bitcoin system? =C2=A0As far as I = can
> see, the answer is "no" but maybe I'm missing something.=
>
> My best guess to the answer is "possible, but requires a new SIGH= ASH_*
> type"?
>
> [1] https://bitcointalk.org/index.php?topic=3D106449.0
> [2] https://bitcointalk.org/index.php?topic=3D92421.0
> [3] ht= tps://github.com/jgarzik/pybond
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti.com
>
> ----------------------------------------------------------------------= --------
> How fast is your code?
> 3 out of 4 devs don\\\'t know how their code performs in productio= n.
> Find out how slow your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219672;13503038;z?
> http://info.appdynamics.com/FreeJavaPerformanceDownloa= d.html
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-d= evelopment@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitco= in-development
>


--
Jorge Tim=C3=B3n

---------------------------------------------------------------------------= ---
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.htm= l
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--f46d044271088deb9f04ca4853b5--