Re: [Bitcoin-development] Feedback request: colored coins protocol
I have updated the spechttps://github.com/Flavien/colored-coins-protocol/blob/master/specification.mediawiki . This is an interesting approach, but OP_RETURN size limitations can be a significant problem for some kinds of applications. This is correct, the number of colored outputs you can have per transaction is limited by OP_RETURN's 40 bytes. We use a compact format (LEB128http://en.wikipedia.org/wiki/LEB128) for the asset quantity of each output to mitigate that. Assuming you're transferring small amounts of colored coins, you could have up to about 30 colored ouputs. It should work for a decentralized exchange (you only really need 2 or 3 colored outputs). Applications like sending dividends in colored coins however may require splitting into several smaller transactions, but I believe that's an acceptable limitation. On Thu, Apr 10, 2014 at 6:24 PM, Alex Mizrahi alex.mizr...@gmail.comwrote: At this point, I don't think what you are doing is even colored coins anymore. You might want to look into Counterparty or Mastercoin. Nope, it's still colored coins. The difference between colored coin model and Mastercoin model is that colored coins are linked to transaction outputs, while Mastercoin has a notion of address balances. The implications of this is that in colored coin model explicit dependencies allow us to rely on SPV. (Assuming that one can fetch the dependency graph to link txout in question to genesis.) While it is not the case with Mastercoin. While it's pretty far from the original colored coins model, what Flavien have described is identical to it in majority of aspects. This is an interesting approach, but OP_RETURN size limitations can be a significant problem for some kinds of applications. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
Thanks for the valuable feedback. I see there is a strong concern with requiring a large BTC capital for issuing coloring coins, so I am now in the process of modifying the specification to address that. I will post an update when this is finished. By the way, padding doesn't solve the issue entirely (issuing 10 billion shares sill takes you 100 BTC, even with padding and 1 satoshi = 1 share), so I am going for the solution where the asset quantity of every output is explicitly encoded in the OP_RETURN output. That way, whether you are issuing 1 share or 100 trillions, you never need to pay more than 540 satoshis. On Mon, Apr 7, 2014 at 8:58 PM, Alex Mizrahi alex.mizr...@gmail.com wrote: This is beyond ridiculous... Color kernel which works with padding is still quite simple. I think we have extra 10-50 lines of code to handle padding in coloredcoinlib. Essentially we have a couple of lines like this : value_wop = tx.outputs[oi].value - padding (value_wop means value without padding). And then we have like 10 lines of code which selects padding for a transaction. That's not a lot of extra complexity. And it solves the problem once and for all. What you propose instead: a different colored coin representing 10 shares, and another one representing 100 shares (like the different denominations of dollar bills) is much more complex, and it won't work: Suppose you have $100 coin, as a single coin. How do you send $54.23? That's simply impossible. So you'd rather push complexity to higher levels (and create inconvenience for end users, as you admitted yourself) than add 10-50 lines of code to color kernel? I just do not understand this. But I'm not going to argue. I already wrote everything which I could write on this topic. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
At this point, I don't think what you are doing is even colored coins anymore. You might want to look into Counterparty or Mastercoin. Nope, it's still colored coins. The difference between colored coin model and Mastercoin model is that colored coins are linked to transaction outputs, while Mastercoin has a notion of address balances. The implications of this is that in colored coin model explicit dependencies allow us to rely on SPV. (Assuming that one can fetch the dependency graph to link txout in question to genesis.) While it is not the case with Mastercoin. While it's pretty far from the original colored coins model, what Flavien have described is identical to it in majority of aspects. This is an interesting approach, but OP_RETURN size limitations can be a significant problem for some kinds of applications. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
Thanks for the feedback Mark. (1) there is absolutely no reason to include asset tagging information if it is not validated Sure, there is a good reason to include it in the blockchain: so that clients don't need external information to recognize colored coins. Also, I'm not sure what you mean by not validated, in that proposal, the tagged transaction is the authoritative source of information. that just bloats the block chain 9 bytes is much less than what Mastercoin and counterparty are doing (certainly under the 40 bytes allowed). Have you seen the padded order-based coloring scheme worked out here? Yes I have seen it and find the padding quite clumsy and unintuitive. A more general solution is the one I described in my original post, where the color value is entirely separate from the satoshi value, and encoded separately: if you have to have an additional padding value to calculate color_value = satoshi_value - padding, you might as well have color_value directly, independently from satoshi_value. But I don't even think it is necessary: (2) And needing a capital of 54 btc for a million shares is totally unacceptable. An easy workaround is to have various scales, the same way you have $1 bills, $5 bills an $10 bills. I don't see that as a big problem. That way the protocol is more lightweight and simple. Also those 54 BTC (actually 5.4 BTC if the dust is now 540 satoshis) become part of the capital of the company, and can always be recovered by uncoloring the shares. It's an investment, not an expense, so I think it is acceptable. Best, Flavien On Mon, Apr 7, 2014 at 12:23 AM, Mark Friedenbach m...@monetize.io wrote: On 04/06/2014 01:59 PM, Flavien Charlon wrote: Do you think this is the right approach? No, I'm afraid it has significant flaws. The two chief flaws are (1) there is absolutely no reason to include asset tagging information if it is not validated - that just bloats the block chain, and (2) you shouldn't be using fixed increments for share sizes either. It's not future-proof as the minimum output size changes based on the minimum fee (currently 540 satoshis, not 5,400, and it will float in the near future). And needing a capital of 54 btc for a million shares is totally unacceptable. Flavien, I know that I've seen you on the Bitcoin-X mailing list, where these issues have been mostly worked out: https://groups.google.com/forum/#!forum/bitcoinx Have you seen the padded order-based coloring scheme worked out here? https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro Kind regards, Mark Friedenbach -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
On 4/7/14, Flavien Charlon flavien.char...@coinprism.com wrote: Also those 54 BTC (actually 5.4 BTC if the dust is now 540 satoshis) become part of the capital of the company, and can always be recovered by uncoloring the shares. It's an investment, not an expense, so I think it is acceptable. This doesn't make much sense to me. If you print shares on gold plates instead of paper, is that gold part of the capital of the company? I don't think so. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
Jorge, they'd have to be. Otherwise, assuming the price of the share goes low enough, you could buy a share of the company, melt the gold plate, and sell it for a profit. If the gold is part of the capital of the company, the cheapest a share can be is the price of the gold on which the stock certificate is printed. This is why I think the importance of padding with colored coins is overblown. On Mon, Apr 7, 2014 at 1:12 PM, Jorge Timón jti...@monetize.io wrote: On 4/7/14, Flavien Charlon flavien.char...@coinprism.com wrote: Also those 54 BTC (actually 5.4 BTC if the dust is now 540 satoshis) become part of the capital of the company, and can always be recovered by uncoloring the shares. It's an investment, not an expense, so I think it is acceptable. This doesn't make much sense to me. If you print shares on gold plates instead of paper, is that gold part of the capital of the company? I don't think so. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
Flavien, capital is wealth or resources available for the stated purpose of the company. These bitcoins represent nothing more than a speculative floor owned by the investors, not the company. On 04/07/2014 07:00 AM, Flavien Charlon wrote: Jorge, they'd have to be. Otherwise, assuming the price of the share goes low enough, you could buy a share of the company, melt the gold plate, and sell it for a profit. If the gold is part of the capital of the company, the cheapest a share can be is the price of the gold on which the stock certificate is printed. This is why I think the importance of padding with colored coins is overblown. On Mon, Apr 7, 2014 at 1:12 PM, Jorge Timón jti...@monetize.io mailto:jti...@monetize.io wrote: On 4/7/14, Flavien Charlon flavien.char...@coinprism.com mailto:flavien.char...@coinprism.com wrote: Also those 54 BTC (actually 5.4 BTC if the dust is now 540 satoshis) become part of the capital of the company, and can always be recovered by uncoloring the shares. It's an investment, not an expense, so I think it is acceptable. This doesn't make much sense to me. If you print shares on gold plates instead of paper, is that gold part of the capital of the company? I don't think so. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
On 4/7/14, Flavien Charlon flavien.char...@coinprism.com wrote: Ok, I guess I'm not using the proper terminology. It would be listed on the Asset section of the company's balance sheet, is what I meant. No, it's an asset for the owner of the share, not the company, just like the gold plates are not assets for the company when someone else holds them. What you're doing is getting less capital for the company due to the money that is going to pay the gold costs. Are you rising capital or selling gold? It doesn't make sense to do both at once. You need money, why would you spend money on gold before asking for other people's money to build your company? Investors will appreciate the convenience of being able to buy shares of your company and gold separately (or not buy gold at all). It may even be more clear for other use cases different than stocks. Does an IOU written in a gold plate make sense to you? -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
An IOU written in a gold plate sure makes no sense. I see what you are saying, the inconvenience comes from the fact that the buyer has to buy some amount of BTC at the same time as he buys a share. That's why I was making the point that you could have a colored coin representing a single share, a different colored coin representing 10 shares, and another one representing 100 shares (like the different denominations of dollar bills). Assuming you have a proper application layer/UI that can hide this from the user, the need for padding is greatly reduced. My opinion is that the protocol should do the minimum required and remain as simple as possible. If a proper UI can work around this, then it might not be worth complicating the protocol for this. Also, the dust rule may disappear all together one day (it's already been slashed heavily to 540 satoshis), at which point we'll be left with a useless padding parameter. It's easier to add something when you need it than to remove it. But I am posting here to see how people feel about this, and I see you are on the opinion that satoshi_value and color_value should have a degree of freedom between each other. Thanks for the feedback. On Mon, Apr 7, 2014 at 7:23 PM, Jorge Timón jti...@monetize.io wrote: On 4/7/14, Flavien Charlon flavien.char...@coinprism.com wrote: Ok, I guess I'm not using the proper terminology. It would be listed on the Asset section of the company's balance sheet, is what I meant. No, it's an asset for the owner of the share, not the company, just like the gold plates are not assets for the company when someone else holds them. What you're doing is getting less capital for the company due to the money that is going to pay the gold costs. Are you rising capital or selling gold? It doesn't make sense to do both at once. You need money, why would you spend money on gold before asking for other people's money to build your company? Investors will appreciate the convenience of being able to buy shares of your company and gold separately (or not buy gold at all). It may even be more clear for other use cases different than stocks. Does an IOU written in a gold plate make sense to you? -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
