colored bitcoin tech discussion

[killerstorm]

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).

I believe there is a demand for a secure trading platform which doesn't try to be an investment bank.

You probably know that Goat was delisted from GLBSE. Maybe he shouldn't have been there in the first place, but now this delisting creates problem for Goat and for people who bought something from him.

Or imagine a situation where GLBSE will suffer from catastrophic data failure, it it will be hacked. Do people have a backup plan?

Suppose they even have a list of owners (this features is offered by MPex), can they continue trading after being delisted or after some problem with exchange?

With a trading platform based on colored coins ownership data is encoded in a blockchain, it cannot be lost, it cannot be hacked in realistic scenarios. You cannot be delisted. You will be able to trade no matter what.

Maybe this problem is not interesting to you because you haven't considered catastrophic failure scenarios yet.

But things like that happened to currency exchanges and wallet services, why do you think stock exchange would be immune?

Anyway, I'm a programmer, not a lawyer. I cannot help you with non-trustworthy exchanges, but I can help to develop a secure trading platform.

By the way, it might help with trustworthiness checks indirectly: since smartcoin based trading platform won't do any checks at all, this would create a market for trustworthiness checks.

GLBSE wants to be everything at once, they offer some verification, sort of, but it is really half-assed, and its bundled with their trading platform. So people have no choice but to use it, and they don't think that 3rd party rating agency is needed.

But when trading platform is open to anybody, amount of bullshit assets will be so high that companies will have no option but to go to 3rd party rating agency. As many such agencies can co-exist, there will be a market, and so they'll compete to provide best services. I.e. you'll be able to check rating agency's track record.

The best way to solve social problem is to provide economic incentive, I think.

[1714773122]

1714773122

[1714773122]

1714773122

[1714773122]

1714773122

[Jutarul]

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:

No, that is the opposite of elegant:  it adds blockchain bloat that is difficult to recognize or avoid or prune.

Can you be more specific on why you think a "color tag" in form of a published color public/private key pair and the use of it as a trace poses a problem in recognition and pruning? I fail to see the problem. (Apart of the "bloating" effect, but that's a small price to pay for an additional functionality, and the maximum required space is just an additional key verification...

[killerstorm]

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.

[cunicula]

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.

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.

[jgarzik]

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.

[jgarzik]

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

[markm]

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-

[killerstorm]

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.

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.

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?

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.

[killerstorm]

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.

[jgarzik]

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?

[killerstorm]

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...

[bitcool]

does this have anything to do with distributed transaction?

[killerstorm]

What is distributed transaction?

[bitcool]

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.

[killerstorm]

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.

[bitcool]

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.

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.

[markm]

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-

[bitcool]

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.

 

[markm]

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-

[bitcool]

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.