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