public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] Atomic coin swapping?
@ 2012-09-22  7:28 Jeff Garzik
  2012-09-22  9:10 ` Jorge Timón
  0 siblings, 1 reply; 6+ messages in thread
From: Jeff Garzik @ 2012-09-22  7:28 UTC (permalink / raw)
  To: Bitcoin Development

Forum URL: https://bitcointalk.org/index.php?topic=112007.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=106449.0
[2] https://bitcointalk.org/index.php?topic=92421.0
[3] https://github.com/jgarzik/pybond

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] Atomic coin swapping?
  2012-09-22  7:28 [Bitcoin-development] Atomic coin swapping? Jeff Garzik
@ 2012-09-22  9:10 ` Jorge Timón
  2012-09-22 11:04   ` Mike Hearn
                     ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Jorge Timón @ 2012-09-22  9:10 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: Bitcoin Development

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 <jgarzik@exmulti.com> wrote:
> Forum URL: https://bitcointalk.org/index.php?topic=112007.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=106449.0
> [2] https://bitcointalk.org/index.php?topic=92421.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ón



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] Atomic coin swapping?
  2012-09-22  9:10 ` Jorge Timón
@ 2012-09-22 11:04   ` Mike Hearn
  2012-09-22 17:05   ` Mike Hearn
  2012-09-22 17:09   ` Jeff Garzik
  2 siblings, 0 replies; 6+ messages in thread
From: Mike Hearn @ 2012-09-22 11:04 UTC (permalink / raw)
  To: Jorge Timón; +Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 4172 bytes --]

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ón" <timon.elviejo@gmail.com> 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
> 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 <jgarzik@exmulti.com> wrote:
> > Forum URL: https://bitcointalk.org/index.php?topic=112007.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=106449.0
> > [2] https://bitcointalk.org/index.php?topic=92421.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ón
>
>
> ------------------------------------------------------------------------------
> 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
>

[-- Attachment #2: Type: text/html, Size: 5947 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] Atomic coin swapping?
  2012-09-22  9:10 ` Jorge Timón
  2012-09-22 11:04   ` Mike Hearn
@ 2012-09-22 17:05   ` Mike Hearn
  2012-09-22 17:09   ` Jeff Garzik
  2 siblings, 0 replies; 6+ messages in thread
From: Mike Hearn @ 2012-09-22 17:05 UTC (permalink / raw)
  To: Jorge Timón; +Cc: Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

>
> Why "Signing the input scripts as well would obviously make it
> impossible to construct a transaction"?


As it states in the source code, signatures cannot sign themselves.  If
scriptSigs were included in the data that is being signed, the act of
inserting the newly calculated signature for one input would break the
signatures for all the others.

[-- Attachment #2: Type: text/html, Size: 537 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] Atomic coin swapping?
  2012-09-22  9:10 ` Jorge Timón
  2012-09-22 11:04   ` Mike Hearn
  2012-09-22 17:05   ` Mike Hearn
@ 2012-09-22 17:09   ` Jeff Garzik
  2012-09-22 18:24     ` Jorge Timón
  2 siblings, 1 reply; 6+ messages in thread
From: Jeff Garzik @ 2012-09-22 17:09 UTC (permalink / raw)
  To: Jorge Timón; +Cc: Bitcoin Development

On Sat, Sep 22, 2012 at 5:10 AM, Jorge Timón <timon.elviejo@gmail.com> 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

Yes, SIGHASH_ALL was the crucial piece I was missing.

I have updated the post to add a concrete example with as much detail
as necessary for programmers to recreate.  Review requested:
https://bitcointalk.org/index.php?topic=112007.msg1212356#msg1212356

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Bitcoin-development] Atomic coin swapping?
  2012-09-22 17:09   ` Jeff Garzik
@ 2012-09-22 18:24     ` Jorge Timón
  0 siblings, 0 replies; 6+ messages in thread
From: Jorge Timón @ 2012-09-22 18:24 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: Bitcoin Development

On 9/22/12, Mike Hearn <mike@plan99.net> wrote:
>>
>> Why "Signing the input scripts as well would obviously make it
>> impossible to construct a transaction"?
>
>
> As it states in the source code, signatures cannot sign themselves.  If
> scriptSigs were included in the data that is being signed, the act of
> inserting the newly calculated signature for one input would break the
> signatures for all the others.

I see. By "input scripts" I thought you meant scriptPubKey rather than
scriptSigs. We only need to sign scriptPubKey. Right, Jeff?

> Yes, SIGHASH_ALL was the crucial piece I was missing.

Great, there's no need for an additional SIGHASH.
I guess you're implementing the simple case you describe first.
Do you plan to implement the more general case with n participants
instead of only 2 (a Ripple transaction)?
That would be awesome.

-- 
Jorge Timón



On 9/22/12, Jeff Garzik <jgarzik@exmulti.com> wrote:
> On Sat, Sep 22, 2012 at 5:10 AM, Jorge Timón <timon.elviejo@gmail.com>
> 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
>
> Yes, SIGHASH_ALL was the crucial piece I was missing.
>
> I have updated the post to add a concrete example with as much detail
> as necessary for programmers to recreate.  Review requested:
> https://bitcointalk.org/index.php?topic=112007.msg1212356#msg1212356
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti.com
>


-- 
Jorge Timón



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-09-22 18:24 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-22  7:28 [Bitcoin-development] Atomic coin swapping? Jeff Garzik
2012-09-22  9:10 ` Jorge Timón
2012-09-22 11:04   ` Mike Hearn
2012-09-22 17:05   ` Mike Hearn
2012-09-22 17:09   ` Jeff Garzik
2012-09-22 18:24     ` Jorge Timón

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox