4 ms·
As far as I understand it is that it's the transactions that carry the value, not the coins. So the fact that you have an incoming transaction for a colored coi
by tinco 11y ago
As far as I understand it is that it's the transactions that carry the value, not the coins. So the fact that you have an incoming transaction for a colored coin, and not an outgoing one means you still own it. How many BTC is transferred in the transaction is irrelevant (which is why they use 1 Satoshi as an example). Finding out if a colored coin is valid means simply walking the block chain until you find an origin you consider authoritative.
- Karunamon 11y agoChecking my model here. You have a wallet for incoming transactions, checksum "abc". You recieve two transactions, one from "def" and one from "ghi". You eventually pay wallet "xyz". The blockchain for this transaction looks like this: +---1BTC (from DEF)----> +-----+ +-----+ |ABC | +---.5BTC------> |XYZ | +---2BTC (from GHI)----> +-----+ +-----+ (3BTC) How do you (as a third party, or the owner of ABC, or the owner of XYZ) differentiate which of the two transactions the .5BTC are the child of?
- fla 11y agoYou cant. What if in your example ABC already had a balance of 1BTC (totaling 4) ? It's undefined.
- tinco 11y agoYou can't. But it doesn't matter which transaction the .5BTC is a child of. You have to see colored coins as a tag, not as an actual coin. So: +-- 1BTC+C1 (from DEF) -> +-----+ +-----+ | ABC | +-- 1BTC+C1 --> + XYZ + +-- 1BTC (from GHI) -> +-----+ +-----+ The DEF->ABC transaction is tagged with C1. And the ABC->XYZ transaction is also tagged with C1. XYZ should look at ABC's history and see if he ever had an incoming transaction with C1, and then check DEF and see if he had an incoming transaction with C1, etc.. There's probably a fancy scheme to make this checking of colored coins in the blockchain easier, I'm not familiar enough with colored coins to know for sure.
- Karunamon 11y agoAh! Okay, this makes more sense - it's extra metadata.