better theory of colored coins

[Alex Mizrahi]

I've changed some terminology, I believe it is much clearer now:

https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro

[paul snow]

Tagged and Padded based coloring

I am going to give this one more shot, especially as you begin to move further from literal Bitcoin transfers equating to literal Colored Coin transfers.

Instead of ordering inputs with outputs, I would suggest you do the following:

Colored coin definitions be implemented with a structured definition (XML? Jason?) that provides the following:

• A Name (example: Gold Coin)
• A Description (example: Each coin represents 1 ounce of Gold, or 1 share of company xyz)
• 25 signatures randomly from the odd numbers between 1 to 99, inclusively
• Other information TBD, and perhaps specific to the colored coin.

A Transaction will transfer colored coins under the following conditions:

• An output has as its last two digits a signature value as specified in its definition
• The last output transfers all the colored coin of the transaction not transferred by a previous output
• The Padding value is subtracted from the colored coin transfer amount, and is not colored
• The Transaction fee is never colored.

If an address contains multiple colored coins, then these coins can be transferred using signatures locally unique to those coins.  The odds of two coins having the same 25 random signatures is roughly 1 in 126 trillion.

Any output without a valid signature that is not the last output is a transfer of uncolored coins.

If we using a padding value (say .00010000 BTC), then that padding would not be colored coin.  The transaction fee is never colored coin.

Layout of a Colored Coin output:

      V.vvvvvvSS  

• V is any number < the number of Bitcoin to spend
• (vvvvvv - the pad)*1000000 = the number of colored coin transferred.  For example, to transfer 100 of colored coins, you would send someone .00020037  BTC, where 37 is the signature, and (.000200 - .0001)*1000000 = 100.  
• Since "change" is usually the last output in most wallets, your remaining colored balance will come back to you.

Advantages:

• SPV is all that is needed.  All you have to chase down are the inputs to transactions
• In computing a colored balance at an output, inputs that are not the last output and do not have a valid signature can be discarded immediately.  So the number of inputs you have to chase is far smaller. 
• Once you have reached the genesis transaction, you can compute back the colored coin balance at your original output.
• Literal Bitcoin balances do not get tied to your colored coin.   

Observations:

If you are going to go to a padded order based coloring, you might as well go the extra step and use tags.  They are easier to explain, easier to see, and they do disengage the Bitcoin from the Colored Coin.  They do have the slight disadvantage that you cannot use a Satoshi to represent a colored coin, but the advantages of shorting your searches, and disengaging from Bitcoin make up for that.

[Alex Mizrahi]

I don't think your scheme has significant advantages over POBC.

 

Advantages:

• SPV is all that is needed.  All you have to chase down are the inputs to transactions

It is same as with POBC.

 

• In computing a colored balance at an output, inputs that are not the last output and do not have a valid signature can be discarded immediately.  So the number of inputs you have to chase is far smaller. 

With POBC:

1. If output is colored, only colored inputs/outputs are scanned.

2. If output is uncolored, very few inputs need to be scanned. (Typically, unless somebody repeatedly transfers same amount many times, or intentionally creates transactions with look like colored.)

So your scheme has any advantage only in rare and obscure case. 

• Literal Bitcoin balances do not get tied to your colored coin.   

What matters is encoding efficiency: how many satoshi we need to use for a certain level of divisibility?

Well, your scheme is definitely inferior in this aspect.

I know schemes which provide very high (potentially, infinite) divisibility while using relatively few satoshis, but I believe extra complexity is not worth it: efficiency of POBC is good enough.

That said, if there is a desire, we can either use more efficient color kernels, or use alt-coin with more abundant satoshis (e.g. Devcoin).

 

If you are going to go to a padded order based coloring, you might as well go the extra step and use tags.

We considered using tags from the start (i.e. a year ago), and the reason we don't use them is that I see no advantages compared to order-based coloring...

Order-based coloring is unambiguous and is quite efficient. That's all we need.

Otherwise, it would be easy to extend NGCCC adding different coloring schemes.

 

 They are easier to explain, easier to see,

Um, I don't think so.

 

and they do disengage the Bitcoin from the Colored Coin.

Not really.

[paul snow]

Alex, 

I know you are rather dismissive.  That's fine, because you really like the ordered approach.  But there are problems, and, yeah, I have taken a while to really grok the whole situation.

Still, you have at least responded to my observations, so let me answer:

On Tue, Oct 8, 2013 at 12:44 PM, Alex Mizrahi <alex.m...@gmail.com> wrote:

I don't think your scheme has significant advantages over POBC.

 

Advantages:

• SPV is all that is needed.  All you have to chase down are the inputs to transactions

It is same as with POBC.

This is a big admission.  Because in the past you spent a great deal of effort to claim otherwise.

 

 

• In computing a colored balance at an output, inputs that are not the last output and do not have a valid signature can be discarded immediately.  So the number of inputs you have to chase is far smaller. 

With POBC:

1. If output is colored, only colored inputs/outputs are scanned.

How do you determine that an output is colored?  If it doesn't have a signature, with the tagged approach, the output isn't colored.  If it is tagged with one of the tags on one of your colors, then you have to look at that transactions inputs.  If none of them are tagged and none are the last output of a transaction, you are done.

What do you do?  Exactly?

 

2. If output is uncolored, very few inputs need to be scanned. (Typically, unless somebody repeatedly transfers same amount many times, or intentionally creates transactions with look like colored.)

If an output is uncolored, why do you have to scan anything?

 

So your scheme has any advantage only in rare and obscure case. 

Like someone transferring all the Bitcoin from one address to another?  Is that really so rare? 

• Literal Bitcoin balances do not get tied to your colored coin.   

What matters is encoding efficiency: how many satoshi we need to use for a certain level of divisibility?

Well, your scheme is definitely inferior in this aspect.

Not at all.  I can send any amount of uncolored away.  Haven't you read anything I have written?  Now admittedly if you are padding, you are limiting your BTC requirements quite a bit over what I am doing.  But the difference between 

 .00010100  and .00010001 is ~1 percent more for my way.  At the high end your way looks much better.  Say with 100,000 colored coins.  I would have to send  1.00010000  while you would only have to send .01010000.  But you would need to keep the 10 dollars at the address, while I would only need the 1 BTC for the transaction, then I would be free to use it as an uncolored transaction if I cared to.  Meaning I'd only be required to keep .0001 BTC in my account to hold the colored coin, while you would be required to hold .01 BTC.

If Bitcoin goes up in price another order of magnitude, we both could reduce the Pad (as the dust level would certainly be lowered).  But as the price of Bitcoin goes up, the need to separate colored coins from Bitcoins becomes more important. 

I know schemes which provide very high (potentially, infinite) divisibility while using relatively few satoshis, but I believe extra complexity is not worth it: efficiency of POBC is good enough.

That said, if there is a desire, we can either use more efficient color kernels, or use alt-coin with more abundant satoshis (e.g. Devcoin).

I think a colored coin with a separate tag value per output would be more useful than trying to order outputs, particularly when the outputs must (by definition) include both colored and uncolored coin.

 

 

If you are going to go to a padded order based coloring, you might as well go the extra step and use tags.

We considered using tags from the start (i.e. a year ago), and the reason we don't use them is that I see no advantages compared to order-based coloring...

After having conversations with many people (including Chris with Open Transactions and others), and having spent over 20 years using tagged data to solve various programming problems in complex systems, I think you are underestimating the advantages of tagged data.

 

Order-based coloring is unambiguous and is quite efficient. That's all we need.

Otherwise, it would be easy to extend NGCCC adding different coloring schemes.

 

 They are easier to explain, easier to see,

Um, I don't think so. 

 

Order based coloring is unambiguous.  I will admit (and have) that I misread your documentation months ago, which is partly my fault, and partly due to the documentation I read.  Yet the advantages of tagging are obvious too.  For example, suppose I have a transaction with inputs from 7 colored coins (A-G).  MyAddr has 3 BTC unspent  B has the unique signature 37.  The transaction to send 10 B coins to someone looks like

MyAddr ->  TheirAddr of .00011037

MyAddr ->  MyAddr    of 2.99938963

Transaction fee of .0005

What does your scheme look like?

 

and they do disengage the Bitcoin from the Colored Coin.

Not really.

Absolutely.  Suppose I have a Colored Coin address with  1.0030234 , where only the .0000200 are colored.

I can send away 1.0025234  (note the 4 is even, so not a signature) leaving the .00010000 in the account.

All my Bitcoin sans whatever minimum amount to leave as a marker are moved away to be used as I like.  I may need to use some BTC to actually spend my colored coin, but my balance remains in place.

The interesting thing to me is that I can give you examples of exactly what transactions are needed to move colored coin using tags.  Your documentation doesn't do that so much. Instead we have stuff like:

A sequence of outputs j, j+1, ..., j+n matches a sequence of inputs i, i+1, ..., i+m if a(i) = c(j) and b(i + m) = d(j + n); that is, segment which is spanned by a sequence of outputs is same as a segment which is spanned by a sequence of inputs.

I can say, if color A has a locally unique tag of 03, and B has a locally unique tag of 17, then sending 10 coins of A and 20 coins of B looks like:

MyAdr --> TheirAdr  of .00011003  (sends 10 of B to TheirAdr)

MyAdr --> TheirAdr  of .00012017  (sends 20 of A to TheirAdr)

MyAdr --> MyAdr of <balance of MyAdr less transaction fee> 

Please note that the same explanation is good for the two colors A & B, as well as for 5 colors, assuming independence over the signatures of 03 and 17.  Likewise, looking at the output of a transaction immediately eliminates Colors but those with a matching signature, when validating an input of a colored coin.

Maybe ordering is more simple, but I am not sure how.  Certainly the transaction size is smaller with a tagged approach.  By quite a bit in the multi-colored coin cases.

The only possible invalid transaction?  A transaction with zero outputs, spending everything as a transaction fee.  Not the hardest thing to avoid.

The real question is ... besides the fact that with padding you can use single Satoshis while my approach requires 100 satoshis for the transaction itself, what advantage in programming, or dependability, or ease of understanding, or independence of colored coins, or invalid transaction states, etc.  does order-based coloring afford you?

--
You received this message because you are subscribed to the Google Groups "Colored coins (BitcoinX)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinX+u...@googlegroups.com.
To post to this group, send email to bitc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Paul Snow

phone: (512) 627-8841

Fax:    (419) 831-9962 

skype: paulsnx2