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 *

The difference being that the user will now be offered a more open source alternative from which to choose. The fact that more opaque, closed-source system will exist is inevitable and should suprise no one. Whether they succeed or not in this new paradigm of open source code and trustless alternatives is another question. One that the free market will decide


Hmm no, your brain dead logic is the failure. For corpSC to work well, it needs to attract as much value and liquidity as NECESSARY FOR THE SERVICE TO FULLFILL THE DEMAND OR NEED. One cannot create more demand for an application than exist.

It takes a real idiot to consider that there are a bunch of applications of features that would be more important to people than MONEY


There goes your brain dead logic in action once again. Corporate entities willing to bootstrap a closed-source, opaque sidechain on top of Bitcoin will NOT want to use SPVproof+MM. The federated server model is preferable to ensure control over the chain and security that is not dependent on miners MM.

As you would know, the federated model exists with Bitcoin as is. Therefore Blockstream could create such type of chain for corpCOIN RIGHT NOW without the need for SPVproof

That fucks up your logic quite a bit, doesn't it?

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:


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.

scipSC can be started today using
a) oracle
b) Federated Peg: oracle & scip-proof

 => "oracle & scip-proof" can be changed into
c) scip-proof when 70% of nodes adopt OP_SIDECHAINPROOFVERIFY

Yes, very interesting things bitcoin can do :-).
Did you read comments ?
 - Can proof of computation be used to create forced work that is useful?  e.g. Protein folding instead of hashing?
 - I think there does exist a possibility where the work can be replaced by running another algorithm such as Protein folding and proving through SCIP that a certain number of computational steps were executed. The other nodes then verify this proof, and accept it as work. 

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.

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

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.

I'm into improving Bitcoin, but I think we need agreement on what is wrong with it and why it should be improved, there are lots of BIS in the pipe, I just what to know what's wrong with Bitcoin that the SC proposal is supposed to fix  "improve"?

Ive been doing product development for over 20 years, and if there is one lesson I've learned the hard way it is if it isn't broken don't fix it. not that thats my position with SC's  

brg444 could squash my position in 2 words and make my case very tedious to prove, the thought of reading through more A.D.D. rhetoric is not comforting, and I'll probably crawl back into my shell, or he can carry on all A.D.D. like and I wont have to present my position again.  

Please bestow us with your wisdom of these indisputable facts or shut the hell up.

thousand/billions of sidechains, yea right. this makes no sense and is an obvious stretch of reality.

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.

My goal is not to support sidechains or Blockstream.

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're some special kind of stupid aren't you?

The basis for your argument is that sidechains enable the BTC asset to be seperated from the BTC blockchain. This, you suggest, breaks "BTC Sound Money principle".

Now would you explain to me how federated server model is not doing exactly that? What difference does it make that they use federated model other than less decentralization?

Sure, decentralization is important and that is why Blockstream propose to implement SPVproof to make the model more efficient. But what is stopping anyone, right now, to seperate the BTC asset from the BTC blockchain through the federated server model?

What are you gonna do to stop it and how does this not result exactly in your biggest concern?


Of course they are. Every possible scheme implemented on a sidechain supported by SPV proof can be replicated on a federated server model.

Decentralization is merely an adoption incentive. As you've been persistent in saying, some people will not care about lesser decentralization if they find considerable utility or speculative value in the sidechain. Furthermore, as some people were quick to show me, federated server can be considerably trustable and efficient.

Security is relative then if you accept and trust the federated server because they can be considered more secure than MM sidechains.


No, my point, which you are evidently too dense to understand, is that Blockstream will mostly not be building speculative SC's booted on top of malicious schemes. There are limitless possibilities of applications sidechains that can be built that are not speculative. This is what Blockstream will be doing.

You're acting as if any scammer off the street will be able to hire Blockstream to develop their scammy sidechains. Hopefully you don't really believe that. Blockstream will deal will large corporations that have a desire to decentralized certain infrastructure of their business so as to make them more efficient or create additional value.

What you fail to consider is that Blockstream will likely be responsible for only a minority of the sidechains that will be created


Prove it. Explain to me how they can not adapt their service to a federated model when in fact they have considered it and suggested the federated model could be good enough if properly implemented.

With a little bit of luck, this will mean that ebola is finally under control and is no longer spreading.
Around the same time that ebola started to spread a few years ago there was another outbreak that had only claimed a handful of lives (~17) and was quickly controlled

  You can have journaling with SQL I think.  But the point is not so much the POW but the key signing required to change an account balance.   With journaling you can use the journal to trace the fraud provided you notice it.  With blockchain you stop it from happening in the first place.

Ha. although I don't like a fee for paying taxes.