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. I agree with both these points.
I am not a fan of Gavin's current Max Blocksize proposal. It solves only half the problem and ignores the other half (or maybe 2/3 as I get to below). His reasoning is that since it is a limit the other half is unnecessary, he is flatly and demonstrably wrong about this. When more people are aware of the issue, I think he will modify his proposal again to accommodate the other half of the problem.
Adding an insensitive exponential growth resolves the "it can be as much as this" issue, but it does not protect the block chain from abuse attempting to knock out the smaller players and Southern Hemisphere nodes, so his proposal misses the "it can be as low as this" half of the limit. So I think he will modify it to have a Max Blocksize which is based on a multiple of current historical blocksize and adjusts accordingly, but is further limited by the exponential limit.
The extra 1/3 that we get for free by lookin at both sides of the problem (too high/too low) is that when he does modify his proposal again (and I think he will have to do so), it will also resolve the issue of "how long until we have to look at this issue again" as well, because when the high limit and the low limit converge, that is the indication that we will have to look at it again.
If he just goes with his current proposal, it is pretty much a computer-science failure, though it is a practical patch. It is mere engineering and not science. It measures nothing and is just yet another inflexible mechanism that takes no advantage of the power of the block chain as a tool that will persist into the future.
