What happens with the data validated via Blockstack when some day Bitcoin won’t be secure anymore?
Lots of good questions. [quote=“vsund, post:1, topic:677”]
Do they get migrated to another (better) chain?
[/quote]
Yes. We’ve already done one migration from Namecoin to Bitcoin. Blockstack Core has functionality to support this - the import commands.
@jude is probably better positioned to answer the other questions!
We use the underlying blockchain for recording transactions/data, i.e., Blockstack operations like a preorder, register, or transfer are announced/stored in the underlying blockchain (currently Bitcoin).
There are a couple of properties we require from the underlying blockchain:
a) Ordering of operations: the underlying blockchain should be able to give a total ordering of operations, i.e., I should be able to sort all Blockstack operations/transactions in order. That’s the only thing we really rely on, and all blockchains provide this property.
b) Data durability: We require/assume that the blockchain data stays available and doesn’t just disappear, i.e., transactions that have committed will survive permanently. This property is implicit in the design of most blockchains.
c) Tamper resistance: We require/assume that it’s very hard to change blockchain history and if someone can attack the blockchain and change history, everyone will notice and it’s a fail-stop condition. Proof-of-work blockchains satisfy this requirement by providing a high proof-of-work bar for tampering with blockchain history.
If the underlying blockchain fails for some reason, we can migrate to another blockchain. Just like we migrated from Namecoin earlier.
Yes, Blockstack can migrate to another blockchain. Our rule-of-thumb is to operate on the most secure blockchain available in any given year. Migrating blockchains is a big decision/change and we don’t expect to do it often. It’s a consensus-breaking change i.e., some people might remain on the old blockchain and there will be two forks after the migration. Most apps and users will converge to a single fork eventually because people/apps on different forks are in different universes. I can post more details about forks later on.
For Bitcoin, you are really just trusting the proof-of-work. It’s really really hard for someone to come up with a longer Bitcoin blockchain that is different from the current one. Also, we ignore the last 6 blocks of the Bitcoin blockchain. So any reorgs/forks/changes that are less than 6 blocks deep don’t impact us. The probability of reorgs after 6 blocks is extremely small and that’s why it’s a common practice to wait for 6 confirmations before considering your Bitcoin transfer committed.
The developers and the community can decide to migrate. The way a migration works is that you pick a “migration block” on the current blockchain (this can be block in recent history) and transfer all state/transactions until that block to the new blockchain.
The keypairs are indepedent of the blockchain and depend on the cryptographic algorithm used to generate the keypairs. For example, when we migrated from Namecoin to Bitcoin we transferred names to bitcoin addresses that were owned by the same keypairs with which users owned their names on Namecoin. A bitcoin/namecoin/cryptocurrency-address is just a way to display a public key. You can own cryptocurrency addresses on multiple blockchains with the same keypair.
First of all, a huge thanks for that detailed answer!
One thing remains: When I wrote “getting insecure” I had in mind that the crypto part of Bitcoin get’s insecure (for example their hashing algorithm, iirc there’s only one algorithm hard-coded?).
So when somebody finds a flaw in that algorithm, you can’t tell anymore whether everything from the old blockchain is really trustful or not. How do you decide this situation? Is the “migration block” then just somewhat back in history?
Is it possible to use two blockchains at a time to circumvent such things?
So this is the case that secp256k1 breaks (say because of quantum computers) or some other breakthrough.
In that case, all hell breaks loose. The $15 Billion bitcoin market cap is now up for grabs by the attacker. And yes, we’d need to migrate to some other cryptographic algorithm at that time. And yes, we can freeze the blockchain state at a given block and ignore any transactions after some block (because we no longer know if users are making transactions or the attacker is). We’d need to start planning for these catastrophic events and start “future proofing” the protocol. It’d be very hard to just react to a catastrophic event like this without any preparation.
This attack vector is definitely a bigger thing than some other problem with the underlying blockchain e.g., some state actor wants to be malicious and brings an enormous amount of hashing power online and then stop packing any transactions in blocks they mine. Such an attack would effectively reduce the bandwidth of the blockchain by a lot (possibly to near-zero).
So I assume that if it’s not sure how long the blockchain is already vulnerable to attacks, the devs & community has to decide from what point of history data isn’t trustful anymore?
I guess the wonderful technique of preorders breaks at this point?
(Although I think that’s less a concern in such a situation 
)