Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
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
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
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
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
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
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
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
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
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
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
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
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
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
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
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
