Flavien Charlon [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-11 📝 Original message:I have updated the ...
📅 Original date posted:2014-04-11
📝 Original message:I have updated the
spec<https://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
(LEB128<http://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.mizrahi at gmail.com>wrote:
>
>
>> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140411/e5f3036b/attachment.html>;
📝 Original message:I have updated the
spec<https://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
(LEB128<http://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.mizrahi at gmail.com>wrote:
>
>
>> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140411/e5f3036b/attachment.html>;