coloredcoinlib: implement bitfield-tagged color kernel demo1

[killerstorm]

BFTColorDefinition inherits from ColorDefinition

For the first version we need only run_kernel, but no compose_tx_spec functions.

The idea:

nSequence of an transaction input (unused 32-bit integer) is used a a bit field which shows where colored coins from this input go.

For the demo1 version, we will only consider cases where nSequence has only 1 bit set.

So algorithm is this:

1. start with all outputs having null colorvalue
2. go through all inputs
3. if input has non-null colorvalue, check its nSequence
4. if nSequence has exactly one bit set (i-th bit), add colorvalue of this input to colorvalue of i-th output
5. return output colorvalues

Note that CTransaction from coloredcoinlib/blockchain.py doesn't give you an access to nSequence, but tx.raw gives you access to CTransaction from bitcoin/core.py, which has all the data.

In demo2 we will cover the case where more than one bit is set...

[yesminister]

Looked at it, understand the task. Starting to work on it now. Holding task for another 24 hours.

[maraoz]

working on this now

[maraoz]

first attempt: maraoz@bdb8e7c

[killerstorm]

The second version:

1. Go through all inputs which have non-null colorvalue:
2. nSequence is converted to a set of output indices, which we call 'output group'
3. add colorvalue of input to colorvalue of this 'output group'

Possible exceptional situations:

1. nSequence is 0
2. nSequence has output indices exceeding number of outputs of this transactions
3. there are intersecting 'output groups' (i.e output belongs to more than one group)

If exceptional situation is detected, we return a list of null colorvalues. (Note that we inspect only nSequence field only for inputs which have non-null colorvalue, other inputs are ignored.)

At this step we have total colorvalue for each output group.

1. For each output group:
2. sum satoshi-values of outputs in it (let's call it ssvalue)
3. find n such that 2^n*ssvalue = total colorvalue (loop over all |n|<32, positive and negative)
4. if n exists, each output of this group is assigned colorvalue svalue*2^n, where svalue is its satoshi-value
5. if n doesn't exist, we treat is as an exceptional sitation and return a list of None values.

[maraoz]

Great! I'll look into this

[maraoz]

Alex, some questions:

• if any colored input has nSequence==0 we should return all null color values? what if we have two colored inputs, one which transfers color sucessfully and the other that has nSequence==0. Shouldn't we ignore the 0 one and respect the other color transfer?
• I don't understand the reasoning behind finding n such that 2^n*ssvalue = total colorvalue, but I can make an algorithm that does that. I'd like to understand though. Thanks!

[killerstorm]

if any colored input has nSequence==0 we should return all null color values? what if we have two colored inputs, one which transfers color sucessfully and the other that has nSequence==0. Shouldn't we ignore the 0 one and respect the other color transfer?

I believe it should be all-or-nothing: if validation fails, no coins are transferred. I believe it is more consistent and it is easier to recover if failure is consistent.

Say, if you were transferring ownership of shares, malformed transaction would mean that transfer failed. That is, legally you still own shares, but you can no longer transfer them using coins you have. Issuer might offer to fix this problem by sending replacement shares, for example.

Partial transfer only makes things worse.

I don't understand the reasoning behind finding n such that 2^n*ssvalue = total colorvalue, but I can make an algorithm that does that. I'd like to understand though.

OBC and POBC require fixed svalue/colorvalue ratio (e.g. one satoshi per atom of colored coin). This means that higher precision requires more satoshi to be used, and so it is more expensive. Additionally, POBC requires fixed-size padding, which might become expensive at some point.

But it is possible to make it adjustable: people might want to adjust it depending on price of Bitcoin, dust limit and precision they'd like to achieve.

We want factor to be of form 2^n to avoid problems with infinite precision arithmetic.

So, basically, in case with OBC we need 10000 satoshi per unit (due to dust limit), and it remains that way forever

But in case with bitfield-tagging it can be chosen for each transaction. E.g. currently one unit might be represented with 2^13=8192 satoshi. (n=13). If min fee is slashed in half, one can choose 2^12=4096 satoshi per unit and so on.

[maraoz]

ACK. Starting with this.