Post
Topic
Board Speculation
Re: Gold collapsing. Bitcoin UP.
by
NewLiberty
on 15/11/2014, 03:59:57 UTC
On that we agree.  It would be nice to see some controlled experimentation first....


Cypher, it's great that you care so much about Bitcoin, but the facts are that there is nothing you can do to stop SPV proofs.  If the code were available today, any miner who wanted could start processing them and every other miner would still find their blocks valid.  If this upsets you, your only recourse is to create an altcoin that is designed to be immutable.  Satoshi designed Bitcoin to be able to adapt to the changing needs of the community.

Although it's true that any miner can choose to support SPV proofs (OP_SIDECHAINPROOFVERIFY), my current understanding is that the "locked coins" will only be secure if the majority of the hashpower also supports OP_SIDECHAINPROOFVERIFY.

Remember, only the soft-forked nodes can discern a valid proof from an invalid proof--the older nodes accept all proofs as valid (that's why it's a soft fork as opposed to a hard fork).  My interpretation of this is that the "locked coins" are only "locked" according to the new protocol rules--according to the old rules the coins are free for the taking (i.e., old nodes accept all "proofs" as valid).  What this means is that unless the majority of the hashpower supports the change, SPV proofs are useless because they won't be enforced by the longest proof-of-work chain.

As an example, imagine that a miner who doesn't support sidechains (and running the pre-SPV-proof code) publishes a block where "locked coins" are unlocked without a valid proof.  All the other pre-sidechain nodes will interpret this block as valid and will begin mining on top of it (let's call this Chain A).  The nodes that support OP_SIDECHAINPROOFVERIFY, however, will interpret this block as invalid and will continue mining on top of the previous block (let's call this Chain B).  So we get a forked blockchain…

Now, if >50% of the hashpower supports SPV proofs, then eventually Chain B will become the longest proof-of-work chain.  When this event occurs, the miners and nodes running the pre-sidechain code will abandon Chain A in favour of Chain B.  Chain A will get orphaned and Chain B (where the sidechain coins are still locked) will become the main chain.  

However, if <50% of the hashpower supports SPV proofs, then Chain B will grow at a slower rate than Chain A, and the two chains will remain forked.  


TL/DR: I think network support for SPV proofs is still a political decision.  It's just that instead of requiring support from a super majority of the community, it requires support from a simple majority of the hashpower (which is perhaps easier to obtain).    

You are right, but SPV proofs can be combined using multi-signatures and oracles. => SPV proof and/or oracle/authority signature are valid transactions too.

Sure they CAN be combined with multi-sig and oracles.  But if this is not ALWAYS done (and it appears that it is likely to in fact be rare) then each SPV proof that does not so combine them, increases the incentive for a 51% attack (with miners not running OP_SIDECHAINPROOFVERIFY support, due to the ability to unlock SPV locked coins, and perhaps make some use of them).

As Charlie Munger, Warren Buffett's long-time business partner said: “Show me the incentive and I will show you the outcome”.

This incentive remains a bit troubling.  There should be a way to defeat it other than requiring multi-sig and oracle/authorities for every SPV transaction.
The troubling part is that it would be insidious.  The incentive would build gradually as the sum of all SPV'd coins' UXTOs would grow over time.

I wasn't particularly pleased with Luke's idea of a test plan on their AMA:

Quote
RaptorXP40 - 23-Oct-2014 17:56
Do you have a plan for testing side-chains before the new script operators are implemented in Bitcoin (OP_SIDECHAINPROOFVERIFY and the other ones)?
luke-jr60 - 23-Oct-2014 18:00
Yes, that's what the federated peg in Appendix A is for. We can use that to make a sidechain without any changes to Bitcoin today, and implement the pegging opcodes there. When everyone is satisfied the pegging code is complete and stable, we just migrate the main chain over.