Quote from: tim2020 on November 15, 2014, 09:17:53 PM

Quote from: Peter R on November 15, 2014, 09:12:17 PM

Quote from: brg444 on November 15, 2014, 07:58:49 PM

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).

I think it is clearly a new feature (not that that's necessarily a bad thing--one could argue that Pay2ScriptHash was a new feature too). The fact that federated sidechains are already possible in no way means that adding OP_SIDECHAINPROOFVERIFY is an "upgrade." The federated servers sit on top of the bitcoin protocol, whereas the SPV-proof-based sidechains would be integrated within the protocol. If you argue that SPV-sidechains would be an "upgrade," would you not also argue that native support for colored coins or Counterparty features would also be an "upgrade"? Like federated sidechains, these features are already possible on platforms that sit on top of bitcoin too.

brg444: Do you support a hard-fork to increase the max block size limit?

Thank Peter, I've got a much better understanding of the politics involved. This solidifies my understanding of the argument that it's * not * an insignificant change.

* edit *

Correct it is a freaking huge change of monumental proportions.
Its a high-risk high-reward gambit that expands the potential in all sorts of currently unforeseen ways..
It really can't be implemented without the change,
Well... some special cases things can be done, (with the federation/oracles) but the vast capabilities of validating arbitrary code on (and with) the Bitcoin block chain is what takes the fork.