If you have big enough user base then even 100% hash power attack cannot spend this BTC b/c it is not valid transaction.
1. you can ignore OP_SIDECHAINPROOFVERIFY
2. if some miner will add transaction what will spent BTC from address using OP_SIDECHAINPROOFVERIFY into block without valid "SideChain proof" then this block will be ignored b/c it will contain invalid tx.
1. you can ignore OP_SIDECHAINPROOFVERIFY
2. if some miner will add transaction what will spent BTC from address using OP_SIDECHAINPROOFVERIFY into block without valid "SideChain proof" then this block will be ignored b/c it will contain invalid tx.
You are correct. In order for the SPV locking/unlocking mechanism to be secure, strong support for sidechains across the bitcoin community is required.
I brought up the fact that implementing SPV proofs in bitcoin still requires broad support because there's been confusion caused by the word "soft" in "soft fork." For some reason many people seem to think that soft-forking changes can "just be done" and that because the fork is "soft" it's like a little furry and unthreatening bunny. I think this is disingenuous, as soft-forks still require broad support and a lot of bad stuff could be implemented with them (e.g., blacklisting).
At the risk of taking maaku's comment out of context:
Quote from: Mark Friedenbach (23 October 2014 Reddit "Sidechain" AMA)
It is possible for multiple sidechains to exist, each with larger block sizes and/or shorter block times, and only the transfers between these high-speed payment networks need to hit the bitcoin blockchain. This would allow bitcoin the currency to scale as required without requiring significant block size increases.
While this is true, it seems to imply that achieving scalability via sidechains is superior (easier and safer) than some version of Gavin's scalability proposal. One of my concerns with the sidechain proposal is that it might seem like an "alternative" to moving forward with the max-block-size hard fork. I think we should be looking at both proposals as orthogonal (and we should move forward with a hard fork to address scalability, regardless).
I would also argue that adding OP_SIDECHAINPROOFVERIFY poses a larger existential risk to bitcoin than a hard-fork to increase the max block size. The reason I think this is that OP_SIDECHAINPROOFVERIFY fundamentally changes bitcoin, whereas increasing the max block size has always been on our road map. Will support for SPV sidechains set a precedent that adding "features" to bitcoin is OK if it can be done with a soft fork? Remember, "features" like blacklisting and other nasty stuff can be implemented as a soft fork too.
I'm trying to make two points: (1) soft forks pose no less an existential threat to bitcoin than hard forks (although they pose less technical risk), and (2) soft forks still require consensus, it's just that that consensus is probably easier to obtain since it only requires support from the majority of network hash power.
I'll conclude by saying that I think sidechains are exciting, I hope to see federated sidechains become a thing, and I'm "undecided" on SPV sidechains that require a change to bitcoin (let's see what happens with federated sidechains first
). I support moving forward with a hard fork to address scalability now. But there is possible to create more scenarios. For example "federated sidechains" can be constructed as { ECDSA signature AND OP_SIDECHAINPROOFVERIFY }
Now I can create transaction what is spending this output {ECDSA and SIDECHAINPROOFVERIFY}
a) ECDSA signature is VALID but SIDECHAINPROOFVERIFY is invalid => if miner will add this transaction into block then he will not get reward b/c it is not valid block b/c it contains invalid transaction. (I'll only test network by offering big fee ... move my BTC to my new address ) => I think you know what consequences it will bring.