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. That is a very reasonable position. Thanks for your input.
One argument I would like to make is I don't consider SPV to be a "feature" like blacklisting but moreso an "upgrade" on a scheme that is already possible within the existing Bitcoin protocol (federated peg can be implemented right now as you have pointed out).
This gives us the chance to tinker with the tech before making a decision on whether or not the "improved capabilities" of the SPVproof should be implemented.
Moreover SPVproof is a very "neutral" update whereas blacklisting (and other "nasty stuff") is inherently a very biased position that hurts the fungibility property of Bitcoin at its core.