Topic: Gold collapsing. Bitcoin UP. - page 592. (Read 2032266 times)

nope.  i'm just going along with BS's new way of presenting this argument.  if we shouldn't prevent the spvp op_code, why should we prevent op_codes submitted by OT or any other alt or Bitcoin 2.0?

actually, i'm quite serious.  let me rephrase the exact same concept.  we can let those guys insert an op_code of their choice which will be open source.  it will therefore be usable by anyone and not owned by them.  ppl will be free to ignore it by choice, therefore it can cause no harm.  just like your spvp.  why would you want to "prevent" them from doing that?

Do you know how many op_codes bitcoin already supports and what they do ?

https://en.bitcoin.it/wiki/Script

... we can let those guys insert an op_code ...

There we go, thats the cypherpdoc we know  

i mean, look, we have unencumbered BTC units traveling freely on an ultra secure blockchain whose value involves no counterparty and no other asset.

now, you're asking us to accept an unprecedented change to the protocol which will allow BTC units to intermingle with all sorts of assets limited only by our imaginations all while traveling on a less secure SC.  

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.

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

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.

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.

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.

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?

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?

Rusty Russell? The creator of iptables/netfilter?

Edit: a brief search confirmed we have another main linux kernel developer on board

Btw random question, I was meaning to ask with aethereum?  Would a sidechain be a better way to make the point to ethereum that their value isnt in the feature that can be forked, but in cryptocurrencies network effect.  ps I thought aethereum was awesome except that if I recall it would float from bitcoin so not by quite bitcoin denominated.  Bitcoin users had a perpetual right to claim their share of the coins right?

One of my primary concerns with sidechains is that this "other degree freedom" is used to work around the hard problems (such as the scalability hard fork) at the possible long-term detriment of the network.  Like you said, "if sidechains were ready...you can have different blockchains with different blocksizes"; I worry that simply having this option might fragment the community such that the hard-fork to increase the blocksize limit doesn't happen.  Without sufficient transactional bandwidth on the main chain, I worry that Bitcoin's SOV properties would be hurt as the "global ledger" becomes fragmented across multiple sidechains. 

I know there are some people who disagree, but I think Gavin's proposal to increase the blocksize limit inline with the historical rate of growth of internet bandwidth is a reasonable way to allow the network to scale without significantly affecting centralization. 

I'd like to see the network hard-fork to address scalability before the protocol is changed to support OP_SPV.

That's nothing negative on Blockstream, it's just different -- that's all. Anyone who thinks there is competition between us lacks an understanding of what we're building and how we plan to monetize it.

I welcome Blockstream's entry into this space and I think alt-coins are the ones most concerned about what they represent.

The reason Monetas contracted Justus to help us build the voting pools is because he is a Bitcoin purist. Justus keeps us honest. And I think that is the same role he is playing here in this thread. Bitcoin is his highest value.

And I think what Justus is saying is, that a framework needs to be developed for any changes to Bitcoin. I think he's right that it's not good enough for changes merely to be "open source, open IP." There is a potential conflict of interest, and there is an easy way to put any concerns to rest.

Justus said it best:


I really don't think that's much to ask. Do you, Adam?

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.

[kind words] And I know Justus can be blunt; Adam has been very graceful in this thread.

Nah Justus is the good guy.  He just flames a little, so what.

Yet it is true that Monetas is not asking for any forks in the Bitcoin protocol. Blockstream is. That's why these questions are being raised.

There is an easy way to put them to rest.

first off, usually they mean Bitcoin economic fundamentals.

second, they can get away with this position b/c Bitcoin is NOT broken, despite what some are trying to make us believe.

I think there's a middle ground which can grow the blocksize a bit for now if it has to.  And some technical hope that the problem can be solved so that we have decentralisation and more scale.  Sidechains have a security trade off but do give you full (and potentially more) bitcoin ethos functions - eg someone can do zerocash, or network enforced limits etc.  Other things also snarks can do magical things (full node validation and low bandwidth), sharding like Rusty Russel is exploring with pettycoin (its not an alt, its an approach to sharding bitcoin).  Federated pegs.  And Open Transactions offers some interesting protection via its trust but verify approach though maybe not quite full bitcoin features, it can offer many features and maybe some different ones also (eg blinding though that as I understand it hampers audit, and I didnt see a way to repair that either yet).

One problem we face is it seems blockchains are inherently more expensive (bandwidth, latency, convergence time) at the limit that server clusters like Voting Pools for OpenTransactions and other related ideas.  That might encourage people to not take up full bitcoin features if those systems turn out not to be able to match the features quite due to less decentralisation.

sounds good to me.  I think there is sort of assumed to be some price discovery via user preference and miner policy but as the blocks havent filled up so far we've never seen much supply shortage other than at 0 fees.

I must be missing some essential detail.  I understood that each sidechain would be just a black box from the viewpoint of the bitcoin protocol, and its designers/developers would be free to choose whether and how to peg its operations to the bitcoin chain -- without the bitcoin network having to know about it.   Is there more to the 'sidechain' concept than that?

Could a sidechain be a BTC/USD exchange providing sub-second trades with cryptographic certificates? It would not be possible to peg every such trade to the blockchain, right?

So then you are aware that Bitcoin has effectively no long-term support potential as a foundation in it's presently advertised form and are not just another clueless dupe.  Good for you!  I can understand how it's one of those 'Houston, we have a problem' things that one would wish to defer dwelling on for whatever reason or set of reasons.  Chief among them until one has pocketed what one calculates to be the maximum potential profit.

For my part, I took some profits in case the shit hit the fan in an unpleasant way, but I also retained a bunch on the hopes that something would come along to rescue the system.  Sidechains seem to me to have that potential and do so in a way that preserves the aspects of Bitcoin that I like.  Centralization under a handful of large corp/gov players could also end up making me a dime, but I'd prefer the former route for philosophical reasons.

What is this, econ 101?

Of course Bitcoin mining will always approach non-profitability - in a free market the production of all products and services always approaches non-profitability. That's what markets do.

Absent some kind of forceful outside intervention, the price of all services in an economy approaches the cost of production plus a profit margin that tends toward zero over time.

Why would you even bring this up like it's some kind of great revelation or a problem of any kind whatsoever?

It is not possible. Nobody wants to change bitcoin fundamentals.