[redspectre]

I don't understand how the stellar case and the bitcoin case differ in a network partition. You said "if Stellar fell apart and became partitioned, you would stay on DB's side."

How is that different from a network fork happening, and DB saying "We only accept tokens from ETH and not ETH classic".

At the end of the day, DB is deciding on a network partition to support, and you either support the network partition DB is supporting, or you don't do business with the DB tokens.

[mazieres]

Note that in general there is no way to name a particular branch of a blockchain fork. In cases with a protocol change coordinated well in advance, a counterparty anticipating the fork could announce that their tokens on one branch will be useless. However, if you just have two competing mining pools duking it out with the same protocol, there will be no way to name the branches ahead of time.

What's worse is that colored coins could distort the incentive structure to make it profitable to bribe miners, because the benefit to an attacker of subverting consensus could far outweigh the value of 12.5 BTC/block.

[theptip]

I'm not familiar with the "trustlines determine partition choice" feature of Stellar, but I am with trustlines in general; they are explicit app-level concepts that you define on your wallet, which in this case would say something like "I trust DB to redeem up to 1m worth of EUR credits".

If the Stellar client's behaviour in the face of a partition takes trustlines into account, that's much safer than the default behaviour in bitcoin, which I believe is "pick a partition at (pseudo)random".

It's possible to manually coax the client to pick a partition, but that requires user interaction, i.e. it's not fail-safe, it's fail-unsafe.