3

I had the exact same question when reading over that specification document. I'm not sure if that is a mistake in the example, but the conclusion I reached is that the colored coins are destroyed. I tested this with the Python Open assets library and the transaction that claimed less than the full possible number of assets was still a valid colored coins ...


3

You can't trust pure SPV for any Bitcoin 2.0 protocols, because of the 'metadata faking' issue that you outline. You have a few options: Accept you need to run a full node to backtrack through transactions. (Though note that this will not scale well anyway for popular assets.) Use a blockchain that has native support for assets, like Sidechain Elements or ...


2

According to the Open Assets Protocol Spec, the amounts are encoded in something called the unsigned LEB128 encoding. So for 300 the binary looks like: 100101100 You have to pad to a multiple of 7 (we have 9 bits, so this becomes 14): 00000100101100 Now split into groups of 7: 0000010 0101100 Add in a 0 bit for the very first one, and 1 for every other ...


2

Unclaimed Open Assets units are indeed destroyed, which (depending on the use case) could be a problem for you. Other protocols such as CoinSpark (ours), Counterparty and Omni Layer don't have this accidental destruction problem, because the assets always go somewhere by default, if they are not explicitly reference. In CoinSpark this default place is the ...


1

The problem is after issue_asset(), if the min_confirmation is 1, we have to mine the bitcoin block for one time. Then only after that, the asset can be seen in get_balance.


Only top voted, non community-wiki answers of a minimum length are eligible