They do it with crypto tricks, so if there are loopholes in the crypt used I guess it could be vulnerable but the basic idea seems to be if they sign for your coins the data that puts into that blockchain suffices to let you compute what you need to use on the other blockchain.
So presumably as long as you get the math right, including making sure they really do give you the data they are supposed to at each step, it should be about as secure as the blockchain the coins are on.
-MarkM-
Topic: colored bitcoin tech discussion - page 4. (Read 13197 times)
If trading on two existing chains is not what you want, then what is it you do want?
It IS what I want. It seemed to me the linked page showed how two existing chains can perform transfers of their own coins on their own chain in such a way that either the transactions on both existing chains happen or neither of the transactions on either of the existing chains happens.
Having all coins on the same chain, both colored and not-colored, will of course enable the trading. The part I failed to understand is how it could make the cross-chain conversion transaction as part of the atomic transaction. Maybe trying to apply database distributed transaction theory is a mistake here. It won't be applicable if all trading parties agree to use same modified client and thus to follow a super-protocol. I still suspect there will be loophole that can be exploited between the transaction on the native chain and the one on the color chain. Just a gut feeling, I can be wrong.
I think I do not understand what you want, or possibly it might be more accurate to say I do not understand why.
It seemed to me the linked page showed how two existing chains can perform transfers of their own coins on their own chain in such a way that either the transactions on both existing chains happen or neither of the transactions on either of the existing chains happens.
So for example if you want to sell me some litecoins for some bitcoins we can set up transactions that will prevent you from getting my bitcoins without me getting your litecoins, and/or we can set up transactions that will prevent me from getting your litecoins without you getting my bitcoins.
If trading on two existing chains is not what you want, then what is it you do want?
-MarkM-
It seemed to me the linked page showed how two existing chains can perform transfers of their own coins on their own chain in such a way that either the transactions on both existing chains happen or neither of the transactions on either of the existing chains happens.
So for example if you want to sell me some litecoins for some bitcoins we can set up transactions that will prevent you from getting my bitcoins without me getting your litecoins, and/or we can set up transactions that will prevent me from getting your litecoins without you getting my bitcoins.
If trading on two existing chains is not what you want, then what is it you do want?
-MarkM-
There are simply transactions that can only be completed using infomation that also allows the other chain transaction to complete.
I know exactly what is being discussed. Sorry, it's not my problem if you failed to understand what I was saying. This is not the solution I was looking for to solve automated transactions among existing alt-chains. Those chains can't and won't delegate their transaction handling to whatever the modified btc chain you come up with.
DId you actually read the linked information?
Or did you simply fail to understand it?
There is no representation of one type of coin on the other's chain.
There are simply transactions that can only be completed using infomation that also allows the other chain transaction to complete.
Maybe you need to study it more until you understand what it is saying?
-MarkM-
Or did you simply fail to understand it?
There is no representation of one type of coin on the other's chain.
There are simply transactions that can only be completed using infomation that also allows the other chain transaction to complete.
Maybe you need to study it more until you understand what it is saying?
-MarkM-
No, it doesn't help in this case. There is a contract to do trade across blockchains: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
One good thing about colored coins is that they allow us to represent different currencies within one blockchain, thus eliminating the need of trading across blockchains.
Ok. Thanks. One good thing about colored coins is that they allow us to represent different currencies within one blockchain, thus eliminating the need of trading across blockchains.
I think most people agree that BTC or LTC chain will be here for a long time. The way I see it, BTC chain is a database, LTC is another database. They each performs CRUD transactions independently.
As long as they do not agree to be bound by a common transaction API, attempts of making trade across them will be futile.
You can represent other currency whatever way you like, but this kind of representation will always be secondary when comparing to the native protocols.
What is distributed transaction?
Transactions happened at more than places, i.e. each LTC->BTC trade requires two transactions, one on LTC chain and one on BTC chain. It's one atomic transaction, no partial commit. I was under the impression, this colored chain scheme can be used for this purpose.
No, it doesn't help in this case. There is a contract to do trade across blockchains: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
One good thing about colored coins is that they allow us to represent different currencies within one blockchain, thus eliminating the need of trading across blockchains.
What is distributed transaction?
Transactions happened at more than places, i.e. each LTC->BTC trade requires two transactions, one on LTC chain and one on BTC chain. It's one atomic transaction, no partial commit. I was under the impression, this colored chain scheme can be used for this purpose.
What is distributed transaction?
does this have anything to do with distributed transaction?
Are you talking about valid ECDSA keys, or random garbage stored as a guaranteed-to-fail pubkey?
Valid ECDSA keys. Issuer will create a keypair and will reveal both public and private key to people who need to work with that color. So it would be 100% legit 2-of-2 multisig transaction.
I also considered using random garbage and 1-of-2 multisig, but that's kinda ugly...
But a bigger point is simply... please please please do not encode data inside pubkeys. Use OP_DROP or another visible solution. In-pubkey makes it really difficult to detect and manage, for those of us trying to help the blockchain software 
Err, it isn't "data inside pubkey", it is pubkey itself. I.e. if serialized pubkey matches pubkey associated with a certain color then this TXO might be of that color. I really do not understand what's difficult about comparing two pieces of binary data. You can use something as dumb as grep to detect potentially colored TXOs.
Are you talking about valid ECDSA keys, or random garbage stored as a guaranteed-to-fail pubkey?
But a bigger point is simply... please please please do not encode data inside pubkeys. Use OP_DROP or another visible solution. In-pubkey makes it really difficult to detect and manage, for those of us trying to help the blockchain software
Err, it isn't "data inside pubkey", it is pubkey itself. I.e. if serialized pubkey matches pubkey associated with a certain color then this TXO might be of that color. I really do not understand what's difficult about comparing two pieces of binary data. You can use something as dumb as grep to detect potentially colored TXOs.
You add one (1) merged mining merkle root to the block, covering all merge-mined currencies. Each currency is an entry in the merkle tree.
That can then scale to a billion private currencies, without bloating the block.
That can then scale to a billion private currencies, without bloating the block.
If this data is not included into main Bitcoin blockchain it doesn't mean that it doesn't exist. Miners who are participating in merged mining would have to process and send this data. So maintaining a separate currency via a separate chain ultimately costs you some resources.
Quote
Merged mining is obviously far more scalable than any solution that requires blockchain bloat, however minimal.
Do you mean "does not bother people who care only about Bitcoins" by "scalable" here?
Quote
The downside is that you cannot have atomic transfers between a smartcoin holder, and a payment holder.
There is a contract for cross-blockchain trade. It's rather complex, though.
It could be useful to do this with a blockchain which is merged-mine-able but does not mint new coins.
That would throw out the entire confounding pricing/cost factor caused by miners minting coins, so we can look directly at how much it costs to have miners merged-mine a chain.
There are already several chains in which miners do not mint coins.
Each is individually looking at having to pay whatever "the going rate" turns out to be for having a chain merged-mined.
Maybe all such chains can gang up, between them paying to have one multicoloured chain merged-mined.
Maybe also everyone who is interested in colouring coins could provide an estimate / ballpark of how much buying-power their colour expects / plans / intends / will commit to spending on securing a chain.
-MarkM-
That would throw out the entire confounding pricing/cost factor caused by miners minting coins, so we can look directly at how much it costs to have miners merged-mine a chain.
There are already several chains in which miners do not mint coins.
Each is individually looking at having to pay whatever "the going rate" turns out to be for having a chain merged-mined.
Maybe all such chains can gang up, between them paying to have one multicoloured chain merged-mined.
Maybe also everyone who is interested in colouring coins could provide an estimate / ballpark of how much buying-power their colour expects / plans / intends / will commit to spending on securing a chain.
-MarkM-
No, that is the opposite of elegant: it adds blockchain bloat that is difficult to recognize or avoid or prune.
It is elegant in solving a problem with accidents. It isn't efficient, yes. But OP_DROP adds some bloat too.
Any added data, OP_DROP or fake-pubkey or whatever, typically requires two parties to agree to maintain the format of the in-chain metadata.
But a bigger point is simply... please please please do not encode data inside pubkeys. Use OP_DROP or another visible solution. In-pubkey makes it really difficult to detect and manage, for those of us trying to help the blockchain software
Imagine you want to have a million private currencies... So you need to add a million of hashes to each block... This simply won't work.
Incorrect. You misunderstand how merged mining already works.
You add one (1) merged mining merkle root to the block, covering all merge-mined currencies. Each currency is an entry in the merkle tree.
That can then scale to a billion private currencies, without bloating the block.
Merged mining is obviously far more scalable than any solution that requires blockchain bloat, however minimal.
The downside is that you cannot have atomic transfers between a smartcoin holder, and a payment holder.
I think this is awesome and applaud the effort. I am very excited at the prospect of satoshi's colored to denote USD-denominated debt in particular.
When colored coins come up I always hear the example of shares / stock. But when it comes to securities, determining ownership and decentralizing the exchange is simply not an interesting problem, compared to the bigger problem of ensuring that the issuing company is trustworthy (which is more of a social problem rather than a technological one).
Do you trust GLBSE? I heard the SEC is investigating. Do you trust MPOE? I heard the operator is a pedophile/pornographer. Do you trust Mt. Gox not to keep accurate records of account balances and not freeze your funds? Wouldn't it be better if you could trade your MtGox USD in the blockchain?
Doing away with one level of trust is a major contribution.
Let's say I'm an owner of a company XYZ and I want to sell its shares. I can sell those shares on GLBSE, then ownership of company is represented by some records in GLBSE's database. In this case I declare that whatever information GLBSE stores is legit.
When colored coins come up I always hear the example of shares / stock. But when it comes to securities, determining ownership and decentralizing the exchange is simply not an interesting problem, compared to the bigger problem of ensuring that the issuing company is trustworthy (which is more of a social problem rather than a technological one).
Do you trust GLBSE? I heard the SEC is investigating. Do you trust MPOE? I heard the operator is a pedophile/pornographer. Do you trust Mt. Gox not to keep accurate records of account balances and not freeze your funds? Wouldn't it be better if you could trade your MtGox USD in the blockchain?
Doing away with one level of trust is a major contribution.
No, that is the opposite of elegant: it adds blockchain bloat that is difficult to recognize or avoid or prune.
It is elegant in solving a problem with accidents. It isn't efficient, yes. But OP_DROP adds some bloat too.
As for merged mining, you have to add hash of alt-chain into bitcoin block chain, right? Even if there are no transactions.
Imagine you want to have a million private currencies... So you need to add a million of hashes to each block... This simply won't work.
OTOH a million of colors is not a problem as long as there are no transactions.
You're forgetting that colored coins can exist on merged mined alt-chains. If transaction number becomes an issue, txn fees would force people to move to cheaper alt-chains, thus de-cluttering Bitcoin blockchain.
So ultimately it will only improve resource utilization efficiency as market will prefer most efficient solution.
A viable alternative to order-based coloring is embedding meta-info into a scriptPubKey.
The most straightforward way to do this is OP_DROP message, but there is a rather elegant approach which uses already standard multisig transactions:
The most straightforward way to do this is OP_DROP message, but there is a rather elegant approach which uses already standard multisig transactions:
No, that is the opposite of elegant: it adds blockchain bloat that is difficult to recognize or avoid or prune.
Jump to: