Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-03-02 Thread Troy Benjegerdes
I'm asking for how to DEVELOP THE CODE so I can trade between two block 
chains, and then I'm going to start trading cats and dogs and bits.

Somewhere in trying to figure out the design spec we got caught up in 
existential
concern about 'globally knowable and accurate price history', and I'm telling 
you
it doesn't matter.

I'm the customer and the developer, someone give me a clear design document to
trade between two chains and I can write it, and then we can debate 
improvements.
 

On Sat, Mar 01, 2014 at 01:33:25PM -0500, Jeff Garzik wrote:
 This is not bitcoin-philosophy, it's bitcoin-development.  Existential
 philosophy belongs on IRC or the forums.
 
 
 On Sat, Mar 1, 2014 at 1:28 PM, Mark Friedenbach m...@monetize.io wrote:
  Only if you view bitcoin as no more than a payment network.
 
  On Mar 1, 2014 10:24 AM, Jeff Garzik jgar...@bitpay.com wrote:
 
  This is wandering far off-topic for this mailing list.
 
  On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org wrote:
You can make the same argument against Bitcoin itself you know...
   
A Bitmessage-like network would be trivial to front-run via a sybil
attack. It's the fundemental problem with marketplaces - the data
they're trying to publish has to be public.
  
   I don't see the Bitcoin analogy...
   Anyway, I still don't think the seller cares, if he sells at the price
   he was asking, what would he care about front running those parallel
   networks.
   I've seen many street markets without public information and they
   work just well.
  
   The spot price for ammonia fertilizer, refined gasoline at terminals,
   and price of tea in china are not 'public information', yet these are
   some of the largest traded commodities in the world, far exceeding
   the drop in the bucket that all cryptocoin transactions make.
  
   I'd further argue that the *actual* price of corn (cash bid price at
   elevators and ethanol plants) is not public information either. There
   is a great deal of money traded in collecting and then distributing the
   'cleared price' information. Have a look at
  
   http://www.interquote.com/template.cfm?navgroup=aboutlisturlcode=12view=1
  
  
I don't think this will be a tragedy, because like we discussed on
IRC, I don't think the primary goal of markets is price discovery,
but
trade itself.
   
About historic data, the actual trades are always public, and some
kind of archivers could collect and maintain old orders for
historic
bid and asks, etc.
   
And again, how do you know that record is honest? Fact is without
proof-of-publication you just don't.
  
   Well, the trades that appeared in the chain actually occurred.
   Buying to yourself at fake prices? Be careful, the miner could just
   separate the order and fill it himself. Or anyone paying a higher fee,
   for that matter.
  
   You just made my long-term strategic argument for investing in my own
   mining hardware so I can be sure to trade reliably.
  
   Again, you haven't addressed why the seller cares more about accurate
   historic market data than just his own fees and sell.
  
You mean a reverse nLockTime that makes a transaction invalid after a
certain amount of time - that's dangerous in a reorg unfortunately as
it
can make transactions permenantly invalid.
  
   People who take money from buyers and sellers care most about 'accurate
   historic market data'. I just want to exchange my corn for e85,
   fertilizer,
   and electricity, and audit the code that runs accounting for the
   exchange.
  
   I really don't give a shit if there is 'accurate historic market data'
   as
   long as **MY** personal trade data is accurate and I got a good enough
   price,
   and I know who I'm dealing with.
  
   I know someone smarter than me and with more money, market leverage, and
   political connections **WILL** game the system and distort the market
   data
   history so they can take more money from buyers and sellers without
   actually
   doing some usefull market function.
  
   As long as use buyers and sellers can see the code, and have a good eye
   for
   knowing when someone's pushing the market around, we can just put our
   orders
   in and relieve some speculators of their money.
  
   Just get me working code for cross-chain trades, and we'll work on the
   accurate historic data problem later.
  
  
   
   Troy Benjegerdes 'da hozer'
   ho...@hozed.org
   7 elements  earth::water::air::fire::mind::spirit::soul
   grid.coop
  
 Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
  
  
  
   --
   Flow-based real-time traffic analytics software. Cisco certified tool.
   Monitor traffic, SLAs, QoS, Medianet, 

Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-03-02 Thread Jorge Timón
Again, the two best ways are here:

https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
https://bitcointalk.org/index.php?topic=321228

But this is off-topic, Peter wasn't talking about cross-chain trade.


On 3/2/14, Troy Benjegerdes ho...@hozed.org wrote:
 I'm asking for how to DEVELOP THE CODE so I can trade between two block
 chains, and then I'm going to start trading cats and dogs and bits.

 Somewhere in trying to figure out the design spec we got caught up in
 existential
 concern about 'globally knowable and accurate price history', and I'm
 telling you
 it doesn't matter.

 I'm the customer and the developer, someone give me a clear design document
 to
 trade between two chains and I can write it, and then we can debate
 improvements.


 On Sat, Mar 01, 2014 at 01:33:25PM -0500, Jeff Garzik wrote:
 This is not bitcoin-philosophy, it's bitcoin-development.  Existential
 philosophy belongs on IRC or the forums.


 On Sat, Mar 1, 2014 at 1:28 PM, Mark Friedenbach m...@monetize.io
 wrote:
  Only if you view bitcoin as no more than a payment network.
 
  On Mar 1, 2014 10:24 AM, Jeff Garzik jgar...@bitpay.com wrote:
 
  This is wandering far off-topic for this mailing list.
 
  On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org
  wrote:
You can make the same argument against Bitcoin itself you know...
   
A Bitmessage-like network would be trivial to front-run via a
sybil
attack. It's the fundemental problem with marketplaces - the data
they're trying to publish has to be public.
  
   I don't see the Bitcoin analogy...
   Anyway, I still don't think the seller cares, if he sells at the
   price
   he was asking, what would he care about front running those
   parallel
   networks.
   I've seen many street markets without public information and they
   work just well.
  
   The spot price for ammonia fertilizer, refined gasoline at
   terminals,
   and price of tea in china are not 'public information', yet these
   are
   some of the largest traded commodities in the world, far exceeding
   the drop in the bucket that all cryptocoin transactions make.
  
   I'd further argue that the *actual* price of corn (cash bid price at
   elevators and ethanol plants) is not public information either.
   There
   is a great deal of money traded in collecting and then distributing
   the
   'cleared price' information. Have a look at
  
   http://www.interquote.com/template.cfm?navgroup=aboutlisturlcode=12view=1
  
  
I don't think this will be a tragedy, because like we discussed
on
IRC, I don't think the primary goal of markets is price
discovery,
but
trade itself.
   
About historic data, the actual trades are always public, and
some
kind of archivers could collect and maintain old orders for
historic
bid and asks, etc.
   
And again, how do you know that record is honest? Fact is without
proof-of-publication you just don't.
  
   Well, the trades that appeared in the chain actually occurred.
   Buying to yourself at fake prices? Be careful, the miner could just
   separate the order and fill it himself. Or anyone paying a higher
   fee,
   for that matter.
  
   You just made my long-term strategic argument for investing in my
   own
   mining hardware so I can be sure to trade reliably.
  
   Again, you haven't addressed why the seller cares more about
   accurate
   historic market data than just his own fees and sell.
  
You mean a reverse nLockTime that makes a transaction invalid
after a
certain amount of time - that's dangerous in a reorg unfortunately
as
it
can make transactions permenantly invalid.
  
   People who take money from buyers and sellers care most about
   'accurate
   historic market data'. I just want to exchange my corn for e85,
   fertilizer,
   and electricity, and audit the code that runs accounting for the
   exchange.
  
   I really don't give a shit if there is 'accurate historic market
   data'
   as
   long as **MY** personal trade data is accurate and I got a good
   enough
   price,
   and I know who I'm dealing with.
  
   I know someone smarter than me and with more money, market leverage,
   and
   political connections **WILL** game the system and distort the
   market
   data
   history so they can take more money from buyers and sellers without
   actually
   doing some usefull market function.
  
   As long as use buyers and sellers can see the code, and have a good
   eye
   for
   knowing when someone's pushing the market around, we can just put
   our
   orders
   in and relieve some speculators of their money.
  
   Just get me working code for cross-chain trades, and we'll work on
   the
   accurate historic data problem later.
  
  
   
   Troy Benjegerdes 'da hozer'
   ho...@hozed.org
   7 elements  

Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-03-01 Thread Troy Benjegerdes
  You can make the same argument against Bitcoin itself you know...
 
  A Bitmessage-like network would be trivial to front-run via a sybil
  attack. It's the fundemental problem with marketplaces - the data
  they're trying to publish has to be public.
 
 I don't see the Bitcoin analogy...
 Anyway, I still don't think the seller cares, if he sells at the price
 he was asking, what would he care about front running those parallel
 networks.
 I've seen many street markets without public information and they
 work just well.

The spot price for ammonia fertilizer, refined gasoline at terminals, 
and price of tea in china are not 'public information', yet these are
some of the largest traded commodities in the world, far exceeding 
the drop in the bucket that all cryptocoin transactions make.

I'd further argue that the *actual* price of corn (cash bid price at
elevators and ethanol plants) is not public information either. There
is a great deal of money traded in collecting and then distributing the
'cleared price' information. Have a look at 
http://www.interquote.com/template.cfm?navgroup=aboutlisturlcode=12view=1

 
  I don't think this will be a tragedy, because like we discussed on
  IRC, I don't think the primary goal of markets is price discovery, but
  trade itself.
 
  About historic data, the actual trades are always public, and some
  kind of archivers could collect and maintain old orders for historic
  bid and asks, etc.
 
  And again, how do you know that record is honest? Fact is without
  proof-of-publication you just don't.
 
 Well, the trades that appeared in the chain actually occurred.
 Buying to yourself at fake prices? Be careful, the miner could just
 separate the order and fill it himself. Or anyone paying a higher fee,
 for that matter.

You just made my long-term strategic argument for investing in my own
mining hardware so I can be sure to trade reliably.

 Again, you haven't addressed why the seller cares more about accurate
 historic market data than just his own fees and sell.
 
  You mean a reverse nLockTime that makes a transaction invalid after a
  certain amount of time - that's dangerous in a reorg unfortunately as it
  can make transactions permenantly invalid.
 
People who take money from buyers and sellers care most about 'accurate 
historic market data'. I just want to exchange my corn for e85, fertilizer,
and electricity, and audit the code that runs accounting for the exchange.

I really don't give a shit if there is 'accurate historic market data' as
long as **MY** personal trade data is accurate and I got a good enough price,
and I know who I'm dealing with.

I know someone smarter than me and with more money, market leverage, and 
political connections **WILL** game the system and distort the market data
history so they can take more money from buyers and sellers without actually
doing some usefull market function. 

As long as use buyers and sellers can see the code, and have a good eye for
knowing when someone's pushing the market around, we can just put our orders
in and relieve some speculators of their money.

Just get me working code for cross-chain trades, and we'll work on the 
accurate historic data problem later.


Troy Benjegerdes 'da hozer'  ho...@hozed.org
7 elements  earth::water::air::fire::mind::spirit::soulgrid.coop

  Never pick a fight with someone who buys ink by the barrel,
 nor try buy a hacker who makes money by the megahash


--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-03-01 Thread Jeff Garzik
This is not bitcoin-philosophy, it's bitcoin-development.  Existential
philosophy belongs on IRC or the forums.


On Sat, Mar 1, 2014 at 1:28 PM, Mark Friedenbach m...@monetize.io wrote:
 Only if you view bitcoin as no more than a payment network.

 On Mar 1, 2014 10:24 AM, Jeff Garzik jgar...@bitpay.com wrote:

 This is wandering far off-topic for this mailing list.

 On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org wrote:
   You can make the same argument against Bitcoin itself you know...
  
   A Bitmessage-like network would be trivial to front-run via a sybil
   attack. It's the fundemental problem with marketplaces - the data
   they're trying to publish has to be public.
 
  I don't see the Bitcoin analogy...
  Anyway, I still don't think the seller cares, if he sells at the price
  he was asking, what would he care about front running those parallel
  networks.
  I've seen many street markets without public information and they
  work just well.
 
  The spot price for ammonia fertilizer, refined gasoline at terminals,
  and price of tea in china are not 'public information', yet these are
  some of the largest traded commodities in the world, far exceeding
  the drop in the bucket that all cryptocoin transactions make.
 
  I'd further argue that the *actual* price of corn (cash bid price at
  elevators and ethanol plants) is not public information either. There
  is a great deal of money traded in collecting and then distributing the
  'cleared price' information. Have a look at
 
  http://www.interquote.com/template.cfm?navgroup=aboutlisturlcode=12view=1
 
 
   I don't think this will be a tragedy, because like we discussed on
   IRC, I don't think the primary goal of markets is price discovery,
   but
   trade itself.
  
   About historic data, the actual trades are always public, and some
   kind of archivers could collect and maintain old orders for
   historic
   bid and asks, etc.
  
   And again, how do you know that record is honest? Fact is without
   proof-of-publication you just don't.
 
  Well, the trades that appeared in the chain actually occurred.
  Buying to yourself at fake prices? Be careful, the miner could just
  separate the order and fill it himself. Or anyone paying a higher fee,
  for that matter.
 
  You just made my long-term strategic argument for investing in my own
  mining hardware so I can be sure to trade reliably.
 
  Again, you haven't addressed why the seller cares more about accurate
  historic market data than just his own fees and sell.
 
   You mean a reverse nLockTime that makes a transaction invalid after a
   certain amount of time - that's dangerous in a reorg unfortunately as
   it
   can make transactions permenantly invalid.
 
  People who take money from buyers and sellers care most about 'accurate
  historic market data'. I just want to exchange my corn for e85,
  fertilizer,
  and electricity, and audit the code that runs accounting for the
  exchange.
 
  I really don't give a shit if there is 'accurate historic market data'
  as
  long as **MY** personal trade data is accurate and I got a good enough
  price,
  and I know who I'm dealing with.
 
  I know someone smarter than me and with more money, market leverage, and
  political connections **WILL** game the system and distort the market
  data
  history so they can take more money from buyers and sellers without
  actually
  doing some usefull market function.
 
  As long as use buyers and sellers can see the code, and have a good eye
  for
  knowing when someone's pushing the market around, we can just put our
  orders
  in and relieve some speculators of their money.
 
  Just get me working code for cross-chain trades, and we'll work on the
  accurate historic data problem later.
 
 
  
  Troy Benjegerdes 'da hozer'
  ho...@hozed.org
  7 elements  earth::water::air::fire::mind::spirit::soul
  grid.coop
 
Never pick a fight with someone who buys ink by the barrel,
   nor try buy a hacker who makes money by the megahash
 
 
 
  --
  Flow-based real-time traffic analytics software. Cisco certified tool.
  Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
  Customize your own dashboards, set traffic alerts and generate reports.
  Network behavioral analysis  security monitoring. All-in-one tool.
 
  http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 Jeff Garzik
 Bitcoin core developer and open source evangelist
 BitPay, Inc.  https://bitpay.com/


 --
 Flow-based real-time 

Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-03-01 Thread Mark Friedenbach
Only if you view bitcoin as no more than a payment network.
On Mar 1, 2014 10:24 AM, Jeff Garzik jgar...@bitpay.com wrote:

 This is wandering far off-topic for this mailing list.

 On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org wrote:
   You can make the same argument against Bitcoin itself you know...
  
   A Bitmessage-like network would be trivial to front-run via a sybil
   attack. It's the fundemental problem with marketplaces - the data
   they're trying to publish has to be public.
 
  I don't see the Bitcoin analogy...
  Anyway, I still don't think the seller cares, if he sells at the price
  he was asking, what would he care about front running those parallel
  networks.
  I've seen many street markets without public information and they
  work just well.
 
  The spot price for ammonia fertilizer, refined gasoline at terminals,
  and price of tea in china are not 'public information', yet these are
  some of the largest traded commodities in the world, far exceeding
  the drop in the bucket that all cryptocoin transactions make.
 
  I'd further argue that the *actual* price of corn (cash bid price at
  elevators and ethanol plants) is not public information either. There
  is a great deal of money traded in collecting and then distributing the
  'cleared price' information. Have a look at
 
 http://www.interquote.com/template.cfm?navgroup=aboutlisturlcode=12view=1
 
 
   I don't think this will be a tragedy, because like we discussed on
   IRC, I don't think the primary goal of markets is price discovery,
 but
   trade itself.
  
   About historic data, the actual trades are always public, and some
   kind of archivers could collect and maintain old orders for
 historic
   bid and asks, etc.
  
   And again, how do you know that record is honest? Fact is without
   proof-of-publication you just don't.
 
  Well, the trades that appeared in the chain actually occurred.
  Buying to yourself at fake prices? Be careful, the miner could just
  separate the order and fill it himself. Or anyone paying a higher fee,
  for that matter.
 
  You just made my long-term strategic argument for investing in my own
  mining hardware so I can be sure to trade reliably.
 
  Again, you haven't addressed why the seller cares more about accurate
  historic market data than just his own fees and sell.
 
   You mean a reverse nLockTime that makes a transaction invalid after a
   certain amount of time - that's dangerous in a reorg unfortunately as
 it
   can make transactions permenantly invalid.
 
  People who take money from buyers and sellers care most about 'accurate
  historic market data'. I just want to exchange my corn for e85,
 fertilizer,
  and electricity, and audit the code that runs accounting for the
 exchange.
 
  I really don't give a shit if there is 'accurate historic market data' as
  long as **MY** personal trade data is accurate and I got a good enough
 price,
  and I know who I'm dealing with.
 
  I know someone smarter than me and with more money, market leverage, and
  political connections **WILL** game the system and distort the market
 data
  history so they can take more money from buyers and sellers without
 actually
  doing some usefull market function.
 
  As long as use buyers and sellers can see the code, and have a good eye
 for
  knowing when someone's pushing the market around, we can just put our
 orders
  in and relieve some speculators of their money.
 
  Just get me working code for cross-chain trades, and we'll work on the
  accurate historic data problem later.
 
 
 
  Troy Benjegerdes 'da hozer'
 ho...@hozed.org
  7 elements  earth::water::air::fire::mind::spirit::soul
 grid.coop
 
Never pick a fight with someone who buys ink by the barrel,
   nor try buy a hacker who makes money by the megahash
 
 
 
 --
  Flow-based real-time traffic analytics software. Cisco certified tool.
  Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
  Customize your own dashboards, set traffic alerts and generate reports.
  Network behavioral analysis  security monitoring. All-in-one tool.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 Jeff Garzik
 Bitcoin core developer and open source evangelist
 BitPay, Inc.  https://bitpay.com/


 --
 Flow-based real-time traffic analytics software. Cisco certified tool.
 Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
 Customize your own dashboards, set traffic alerts and generate reports.
 Network 

Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-28 Thread Jorge Timón
On 2/28/14, Peter Todd p...@petertodd.org wrote:
 As usual, you don't need a hardfork.

 Anyway, one-sided trade is sufficient to get a functioning marketplace
 up and running and test out the many other issues with this stuff prior
 to forking anything.

I'm totally FOR experimenting with this as it is and I'm happy that
Alex/Killerstorm is working on regular colored coins.

 You can make the same argument against Bitcoin itself you know...

 A Bitmessage-like network would be trivial to front-run via a sybil
 attack. It's the fundemental problem with marketplaces - the data
 they're trying to publish has to be public.

I don't see the Bitcoin analogy...
Anyway, I still don't think the seller cares, if he sells at the price
he was asking, what would he care about front running those parallel
networks.
I've seen many street markets without public information and they
work just well.

 I don't think this will be a tragedy, because like we discussed on
 IRC, I don't think the primary goal of markets is price discovery, but
 trade itself.

 About historic data, the actual trades are always public, and some
 kind of archivers could collect and maintain old orders for historic
 bid and asks, etc.

 And again, how do you know that record is honest? Fact is without
 proof-of-publication you just don't.

Well, the trades that appeared in the chain actually occurred.
Buying to yourself at fake prices? Be careful, the miner could just
separate the order and fill it himself. Or anyone paying a higher fee,
for that matter.
Again, you haven't addressed why the seller cares more about accurate
historic market data than just his own fees and sell.

 You mean a reverse nLockTime that makes a transaction invalid after a
 certain amount of time - that's dangerous in a reorg unfortunately as it
 can make transactions permenantly invalid.

Yes, I'm aware this is a concern for many people and that's why I
bring it up when there's an useful use case (we have several important
uses in freimarkets).
Probably this belongs to another thread or just #wizards, but if I
remember correctly, the last discussion we had about this, I think
with you and gmaxwell, was more or less like this:

-Valid transactions could get invalid with a regorg
-Just like with any transaction if a double-spend appears, this just
means that you would need to wait for expiry transactions to be
somewhat buried to accept payments from it.
-That introduces fungibility problems.
-True, but doesn't seem a particularly difficult problem (I think we
actually drafted some potential solutions, like introducing a maturity
rule for expiry transactions) and the advantages outweigh that
potential problem IMO.

So in summary, I feel like before actually solving the problem we need
to rise more awareness on how nice and necessary nExpiryTime would be.
Anyway, sorry, I just wanted to point out another use, a deeper
discussion about this belongs to another thread.

-- 
Jorge Timón

http://freico.in/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-27 Thread Jorge Timón
First of all, sorry for the delayed answer.

On 2/10/14, Peter Todd p...@petertodd.org wrote:
 Got this:
[...]
Thank you, I knew this wasn't new for us but I doubted we had written
it anywhere.
As said in those mails, being only able to offer AAA for BTC and not
BTC for AAA nor AAA for BBB is enough of a limitation to justify a
hardfork IMO.

On 2/17/14, Troy Benjegerdes ho...@hozed.org wrote:
 Is there a simple way to do cross-chain trades that doesn't need a third
 chain to somehow facilitate things?

These are the two methods I know for cross-chain trading (no third
chain needed in any of them):

https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
https://bitcointalk.org/index.php?topic=321228

On 2/14/14, Peter Todd p...@petertodd.org wrote:
 You're assuming the seller cares about fairness - why should they? They
 offered a price for an asset and someone bought it; exactly which buyer
 willing to buy at that price was able to complete the trade is
 irrelevant to them. What they do care about is being sure that at
 whatever given price they offered 100% of the buyers willing to buy at
 that price actually see the offer in a reasonable amount of time - at
 the best price the seller will get there will be only a single buyer
 after all so you need that solid proof that said buyer was actually able
 to get the offer.

In fact, I don't think the seller will care enough about this to pay
the proof of publication fee either. Assuming sellers can either
broadcast the order on a bitmessage-like network or use your proof of
publication scheme, the later will be always be more expensive. So my
prediction is that most people will just use the simplest, fastest and
cheapest method, but I guess only time can tell.
I don't think this will be a tragedy, because like we discussed on
IRC, I don't think the primary goal of markets is price discovery, but
trade itself.

About historic data, the actual trades are always public, and some
kind of archivers could collect and maintain old orders for historic
bid and asks, etc.

As an aside, nLockTime would be nice not to always have to
double-spend the inputs of an order to cancel it.

-- 
Jorge Timón

http://freico.in/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-27 Thread Peter Todd
On Fri, Feb 28, 2014 at 12:48:33AM +0100, Jorge Timón wrote:
 First of all, sorry for the delayed answer.
 
 On 2/10/14, Peter Todd p...@petertodd.org wrote:
  Got this:
 [...]
 Thank you, I knew this wasn't new for us but I doubted we had written
 it anywhere.
 As said in those mails, being only able to offer AAA for BTC and not
 BTC for AAA nor AAA for BBB is enough of a limitation to justify a
 hardfork IMO.

As usual, you don't need a hardfork.

Anyway, one-sided trade is sufficient to get a functioning marketplace
up and running and test out the many other issues with this stuff prior
to forking anything.

 On 2/14/14, Peter Todd p...@petertodd.org wrote:
  You're assuming the seller cares about fairness - why should they? They
  offered a price for an asset and someone bought it; exactly which buyer
  willing to buy at that price was able to complete the trade is
  irrelevant to them. What they do care about is being sure that at
  whatever given price they offered 100% of the buyers willing to buy at
  that price actually see the offer in a reasonable amount of time - at
  the best price the seller will get there will be only a single buyer
  after all so you need that solid proof that said buyer was actually able
  to get the offer.
 
 In fact, I don't think the seller will care enough about this to pay
 the proof of publication fee either. Assuming sellers can either
 broadcast the order on a bitmessage-like network or use your proof of
 publication scheme, the later will be always be more expensive. So my
 prediction is that most people will just use the simplest, fastest and
 cheapest method, but I guess only time can tell.

You can make the same argument against Bitcoin itself you know...

A Bitmessage-like network would be trivial to front-run via a sybil
attack. It's the fundemental problem with marketplaces - the data
they're trying to publish has to be public.

 I don't think this will be a tragedy, because like we discussed on
 IRC, I don't think the primary goal of markets is price discovery, but
 trade itself.

 About historic data, the actual trades are always public, and some
 kind of archivers could collect and maintain old orders for historic
 bid and asks, etc.

And again, how do you know that record is honest? Fact is without
proof-of-publication you just don't.

 As an aside, nLockTime would be nice not to always have to
 double-spend the inputs of an order to cancel it.

You mean a reverse nLockTime that makes a transaction invalid after a
certain amount of time - that's dangerous in a reorg unfortunately as it
can make transactions permenantly invalid.

-- 
'peter'[:-1]@petertodd.org
b52709f0485161e764ac0198960885ccab019a978322cc6e


signature.asc
Description: Digital signature
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-16 Thread Troy Benjegerdes
On Fri, Feb 14, 2014 at 12:21:59AM -0500, Peter Todd wrote:
 On Tue, Feb 11, 2014 at 11:59:19AM -0600, Troy Benjegerdes wrote:
  Is there any code that does this? I would like to develop a multicoin-qt
  wallet that runs on two blockchains from one binary, and allows trading
  using this mechanism between the two chains.
 
 Cross-chain trading is a different thing entirely; it doesn't allow for
 the clever 2-party-trade trick. (as far as I know)

Is there a simple way to do cross-chain trades that doesn't need a third 
chain to somehow facilitate things?

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-13 Thread Peter Todd
On Wed, Feb 12, 2014 at 08:34:48AM -0800, Dan Carter wrote:
 I'm not sure how well this would work.
 
 Sure it would provide honest historical pricing, but those who wait for 
 publication confirmation may be at a disadvantage -- to get the best 
 deal possible Bob would connect to as many nodes as he could, examine 
 the stream of unconfirmed asks coming in and sign the best ones before 
 someone else does.  The network would gravitate towards an O(n^2) fully 
 connected network, because being fully connected means one is fully 
 aware of all unconfirmed asks at any moment so one can make the best 
 judgement and buy before someone else does.
 
 The seller needs a guarantee that all bidders can act on the ask 
 transaction simultaneously. Maybe the partial ask transaction could be 
 time-locked with a network propagation delay, there would be multiple 
 bidder responses and the winner is chosen by lottery (and fee priority) 
 by the bitcoin/alt-coin miner who confirms the atomic transaction in 
 their block.  That would eliminate the advantage to being fully 
 connected as it would no longer matter that one can act first, so you 
 have a more sane network.

You're assuming the seller cares about fairness - why should they? They
offered a price for an asset and someone bought it; exactly which buyer
willing to buy at that price was able to complete the trade is
irrelevant to them. What they do care about is being sure that at
whatever given price they offered 100% of the buyers willing to buy at
that price actually see the offer in a reasonable amount of time - at
the best price the seller will get there will be only a single buyer
after all so you need that solid proof that said buyer was actually able
to get the offer.

-- 
'peter'[:-1]@petertodd.org
c34e2307bf2d8e1de9db0351acfe7320a08826a5de3c146a


signature.asc
Description: Digital signature
--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-12 Thread Dan Carter
I'm not sure how well this would work.

Sure it would provide honest historical pricing, but those who wait for 
publication confirmation may be at a disadvantage -- to get the best 
deal possible Bob would connect to as many nodes as he could, examine 
the stream of unconfirmed asks coming in and sign the best ones before 
someone else does.  The network would gravitate towards an O(n^2) fully 
connected network, because being fully connected means one is fully 
aware of all unconfirmed asks at any moment so one can make the best 
judgement and buy before someone else does.

The seller needs a guarantee that all bidders can act on the ask 
transaction simultaneously. Maybe the partial ask transaction could be 
time-locked with a network propagation delay, there would be multiple 
bidder responses and the winner is chosen by lottery (and fee priority) 
by the bitcoin/alt-coin miner who confirms the atomic transaction in 
their block.  That would eliminate the advantage to being fully 
connected as it would no longer matter that one can act first, so you 
have a more sane network.

On 2014-02-09 10:04 AM, Peter Todd wrote:
 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)


--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-11 Thread Troy Benjegerdes
Is there any code that does this? I would like to develop a multicoin-qt
wallet that runs on two blockchains from one binary, and allows trading
using this mechanism between the two chains.

On Mon, Feb 10, 2014 at 02:32:47PM -0500, Peter Todd wrote:
 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:
  
  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.3080...@monetize.io
 Date: Tue, 24 Sep 2013 06:08:10 -0700
 From: Mark Friedenbach m...@monetize.io
 Organization: Monetize.io Inc.
 To: Meni Rosenfeld m...@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,
  
  The video was sent to me by Amos Meiri, I think eToro funded its production.
  
  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?
  
  In any case, I think that's out of scope for the presentation.
  
  Meni
  
  On 24/09/2013 13:10, Jorge Timón 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 m...@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,
  
  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.
  
  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?
  
  Mark
  
  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 

Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-10 Thread Peter Todd
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:
 
 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.3080...@monetize.io
Date: Tue, 24 Sep 2013 06:08:10 -0700
From: Mark Friedenbach m...@monetize.io
Organization: Monetize.io Inc.
To: Meni Rosenfeld m...@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,
 
 The video was sent to me by Amos Meiri, I think eToro funded its production.
 
 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?
 
 In any case, I think that's out of scope for the presentation.
 
 Meni
 
 On 24/09/2013 13:10, Jorge Timón 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 m...@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,
 
 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.
 
 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?
 
 Mark
 
 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



 

-- 
'peter'[:-1]@petertodd.org
76654614e7bf72ac80d47c57bca12503989f4d602538d3cd7892ca7d


signature.asc
Description: Digital signature
--
Androi apps run on BlackBerry 10
Introducing the new BlackBerry 

[Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-09 Thread Peter Todd
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=1 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 =1BTC, 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


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
from 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
===

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/msg03307.html

-- 
'peter'[:-1]@petertodd.org

Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-02-09 Thread Peter Todd
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:

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.

-- 
'peter'[:-1]@petertodd.org
0001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1


signature.asc
Description: Digital signature
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development