Quote from: cypherdoc on January 01, 2015, 09:37:20 PM

i have a suggestion, out of fairness sake. why don't we allow JR & ft, along with any other wanton altcoin/Bitcoin 2.0 dev, to insert their own highly specific op_code function into Bitcoin source code that benefits their own business model? as long as it's open source, it should be fine, right? and we shouldn't care if they are a for-profit, let alone nefarious, business; ppl can just ignore them.

There we go, thats the cypherpdoc we know

But seriously I wrote several hundred lines on this topic, so it'd be helpful if you have something specific you can point about what i've said that you dont find convincing, it'll make it easier for me to comment.

I wrote a bit about why the op_spv is not proprietary or specific to blockstream and that idea existed before blockstream the company existed. Feel free to pick it apart or disagree with something specific, here are some quotes and links from this thread:

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9988763#msg9988763

Its not our softfork - its a softfork to enable a generic extension mechanism. We have no monopoly (and wouldnt want one) on use of the op code. Our only defence is meritocracy - if we build better, more secure sidechains and people prefer to use them. We wont be getting the fees off the sidechain either because those go to miners. If we have the technical edge and people use our stuff that seems sort of fair enough to me.

(and the rest of that post follow the link).

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9991720#msg9991720

Sidechains are not a proprietary technology. Everything is FOSS, open IP. [...]

Its not our softfork - its a softfork to enable a generic extension mechanism. We have no monopoly (and wouldnt want one) on use of the op code. Our only defence is meritocracy - if we build better, more secure sidechains and people prefer to use them. We wont be getting the fees off the sidechain either because those go to miners. If we have the technical edge and people use our stuff that seems sort of fair enough to me. [...]

Sidechains are just a mechanism to extend bitcoin. The interesting thing is the extension not the chain. If a better way to do it materialises great. If some sidechain innovations are so cool and well validated from $1b resting on them for a year that it allows bitcoin core to merge them fantastic. Actually Pieter Wuille views that as the best way to view the utility of sidechains, to enable longer and live validation of things that could then go into bitcoin where that'd be difficult to impossible to gain that confidence on directly.

There can also however be one-size fits-all limits. Some extensions are mutually incompatible, or too risky though interesting (eg snark contracts, zerocash) unless a way to contain the risk in chain is found. Also you can get some new scaling possibilities by having chains with different blocksizes. Its more decentralised and safer to have a small bitcoin main block and a medium sized sidechain block, than introduce a large main bitcoin block as there is an escape route and choice. You can within limits get your cake and eat it.

and

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9994182#msg9994182

Sidechains may also be good for that - an escape valve - people who want to do crazy stuff, can go do it in a sidechain, that no one (who cares about bitcoin ethos features) would use. Vs try to coerce legally or otherwise developers into subverting bitcoin itself at its core where there's no choice left, and bitcoin risks destruction.

and

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9994308#msg9994308

For conflict freedom to occur (and I think its an interesting and useful objective) bitcoin perhaps needs to be simplified and frozen, maybe moved to a formally provable specification rather than code as definition. Soft-forks could be prevented by consensus rule if we were convinced of perfect correctness.

Hard-forks are harder to foist on people because they require a near absolute majority whereas soft-forks are a bit more miner influenceable.

If we had an extension mechanism that doesnt touch core once setup, the core becomes that bit closer to freezable & formal specifiable refactor becoming possible. If we have the possibility for live-betas we are more likely to be able to get to formal specification as definition. (Thats a hard-fork for sure).

Another aspect of conflict freedom (other than freezing and forcing change to be hard-fork) is to enable permissionless innovation - then there's no conflict, people who want to try things can go try them without lobbying for changes to bitcoin. Also good.

and

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg9998261#msg9998261

I think the bigger picture though is its premature - we have not yet released code, nor BIP draft for community discussion and picking apart and redesigning etc before there is something to merge mine. Its also useful (maybe you said it yourself also I think) for a federated peg to operate for a while in parallel with that open design discussion for people to see how it works. You can view the federated peg as a protocol adaptor - there can still be mining occuring on the sidechain with the federated peg, just the return peg is translated into a multisig for bitcoin by the federation servers.

After that if the community can settle on a op-code for extensibility everyone is happy with people including us can try to stand up a few sidechains. If no one likes them then they wont get mined. So as you can see sidechains and the op_spv really depend on community and economic majority approval, and thats a good thing.

and

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg10001181#msg10001181

I dont think one can characterise the op_spv is to the disadvantage of blockstream competitors. Its an op code, anyone can use it to make sidechains or other things.

Other things: you can also use the op_spv opcode to enhance security and efficiency for SPV clients like smartphone wallets completely separately from sidechains. And to fast catchup headers also, the compact SPV proof is work-preserving.

If for example OpenTransactions sees a use for it, or ethereum wants to switch out ethers for bitcoin (i imagine the developers are attached to their premine for now) but perhaps Mastercoin or something thats market cap is falling, seeing less use and the ICO people probably mostly dumped by now (if thats a fair characterisation, dont follow it closely) maybe they might want to migrate to a sidechain, thats all expected and good. Permisionless innovation is the point of sidechains. You could even one-way peg the remaining mastercoins into a sidechain to allow their residual tradability.

If you mean it allows bitcoin to more easily incorporate features, well most alts dont really have features, or not meaningful or useful/non-broken ones, but there are some feature coins and bitcoin 2.0ish coins that do. I dont see how extending bitcoin is unfair - they're all leeching off and copying bitcoin, which was the actual innovation - why cant bitcoin take little bits of innovation back too?

and

Quote from: adam3us link=https://bitcointalk.org/index.php?topic=68655.msg10001937#msg10001937

Another way to look at sidechains btw is that a federated peg is a multi-sig (with modest parameters eg 5 of 10 and some trustworthy security competent bitcoin interested businesses) and a SPV peg is a bigger federated peg with a 5000 of 10000 multisig with dynamic membership (ie whoever is mining the chain right now). The spv peg op_code is an opcode to understand those dynamic membership multisigs. The dynamic membership multi sigs (DMMS for short) are written about in the sidechain white paper http://www.blockstream.com/sidechains.pdf and are a different way to look at bitcoin mining, though its actually the same thing.

You can also combine DMMS sigs with regular multisigs, its just an op code so you can program with it. eg IF ( 0.5*DMMS + 0.5*multisig(5,10) ) THEN spend coin. Or IF ( hashrate > 75% AND DMMS ) OR ( hashrate <= 75% AND multisig(5,10) ) THEN spend coin can react to hashrate drops. Different people could even use different peg rules on the same chain depending on their security tradoff preferences.

I dont see that as some how evil or dangerous relating to offchain transactions (we've seen them cause system shocks mtgox etc) or federated pegs or voting pools (then you are depending on the 5 of 10 of their security etc its better but its still non-zero risk) ... its just the next evolution in that direction - more decentralised, more things enforced by the network. For example read Nick Szabo's recent blog post about fiduciary code http://unenumerated.blogspot.com/2014/12/the-dawn-of-trustworthy-computing.html what do you think he's talking about?

Adam