Topic: Segregated witness - The solution to Scalability (short term)? - page 12. (Read 23195 times)

removing the cryptography in cryptocurrency would seem a downside to me.

No, it is not. Even Pieter said that it was not possible anymore IIRC. If they could redesign it from scratch they would approach it differently than they're going to now. This added complexity is only going to play a downside role on other developers, but that's pretty much it. Users should not feel the difference (aside from the benefits).

Aside from added complexity, there are no downsides (yet).

Oh ok. Now I get it. So they are going to take away the signatures, which in turn will lower the amount taken in a block, and then they are going to make the block-size bigger. That makes a lot sense. What are the downsides of doing this?

Could you please re-tell this topic in words that ordinary people, like me, will be able to understand? So there is something about malleability, stopping fraud and increasing the block-size, that is all I got from that.

No we wont, there is no solutions to be found to a non problem.

Seriously you should take a deep breath instead of cheerleading all the BIPs ph0rking initiatives.

Sick of the highjack BS. Let it be people, or make your own "blockchain"!

Bitcoin is, and has features, not bugs.

Also just to add, I think that we will need all of these solutions when the real mass adoption hits! So in my opinion it is very good to see that many solutions are being proposed, hard forks, LN, as well as this segregated witness proposal which is really just a smart move to buy us more time.

Remember guys, we will need them all, simple as that!

The large miners own only a fraction of the hardware. Changing the pool credentials is easy for the hardware owner. 

If the hardware owners leave the mining scene they have to sell their machines to recover (parts of) their investment.

what if all the miners agree to leave the bitcoin mining scene, does we can save it by simply holding our coins? i don't think so

i could agree that also merchants matter, but i can't see how a simple holder waiting for dumping his stash could matter here

They are totally different, SW is a redesign of bitcoin, while BIP 65 is a planned patch toward lightning network which is easy to understand since it is very similar to a clearing based solution. Lightning network make things more simple (combining thousands of transactions into one) while SW make things more complex (split one transaction into two chains)

This will be very true if you add Btc guild's owner and dial back time to 2013, where they successfully prevented an accident fork by commanding more than 60% of the hash power and forced the chain go back to their desired direction

And today? Btc guild does not even exist, large mining pools from China have dominated hash power distribution, and even inside the core devs there are large disagreement

The core devs are losing dominance because bitcoin is open source. Suppose that a group of large mining pools are not satisfied with the solution proposed by core devs, they could easily deploy their own R&D people and make a version that they prefer, and because they have dominant hashing power, when they roll out the change, their fork will be the strongest chain immediately. Of course they could not persuade others to join them, and they risk being abandoned by the other pools and exchanges, but having so much hash power definitely can affect lots of things

This was not the case during early days of bitcoin when mining pools were just a couple of hobbyists, they didn't have resources to implement such large code change, they only listen to core devs (I still remember the deepbit pool refused to upgrade to any latest version and stayed at 0.3 for a very long time That could be the earliest case of mining pool not following core devs)

Fortunately, chinese mining pools are not very interested in codes, so core devs still hold a lot of saying power, but when there is a disagreement inside core devs, we have already seen on BIP101, miners have veto right

Let me quote Bitmain’s Pan Zhibiao's word here:
“There are many technical solutions. Every solution has pros and cons. The miners are put on a pedestal to be a jury. Right now there is no lawyer on both side. We need a lawyer, we need more discussion, more evidence. ”

I happened recall the movie "Divergent", there are 5 factions, each doing its own job, maintaining a balanced society, hopefully we can reach that status of balance here

That's absolutely backwards.

The best contribution to Bitcoin is every owner's respective economic share.

Yes, that absolutely implies that large holders are de facto more powerful than those with less coins.

No, your "activity" has nothing to do with this.

TLDR: The investors run Bitcoin http://nakamotoinstitute.org/mempool/who-controls-bitcoin/

salt..



http://qntra.net/2015/12/after-xt-failure-gavin-andresen-supports-jim-crow-for-signatures-on-the-blockchain/


and pepper... http://trilema.com/2015/theres-a-one-bitcoin-reward-for-the-death-of-pieter-wuille-details-below/

The power dynamics is a stratification of users/nodes/developers/miners/merchants and exchanges; each exists with differing capabilities to exert influence on each other.

Many Miners have the most power as they are in at least 3 of those categories and sometimes 4. A user that doesn't host a full node is only in one of those categories therefore is more limited in their vote/abilities.

Meritocracy is really an critical aspect within bitcoin. It isn't just Proof or work with regards to hashing but proving ones work with developed and tested code, proving ones work with a hosted node, proving ones working with the most hashing power, proving ones work by client base or political power, ect...

If you only own bitcoin than your vote is counted far less than if you actively contribute to the ecosystem.

No.

We do. (assuming you hold any bitcoins)

Miners have most of the power. They can immediately protest and scare the developers into changing their proposal or adopting another. They also are the ones that have to ultimately accept the code so whatever the developers implement can be ignored or rejected.
The only power the developers have over the miners ultimately is the fact that they can walk away as volunteers and refuse to contribute if the miners don't accept their updates. This isn't of much consequence because other (likely less talented ) developers would fill the void. The miners, node operators, merchants and exchanges will likely accept the soft fork because they agree with it and trust the judgment of the developers. 

Here is the code -

https://github.com/sipa/bitcoin/commits/segwit

Transcript -
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/

Wuille does discuss 4x(sipa should have stressed up to 4x), but it is more complicated than that as the 4MiB limit increase is only on the whitness merkle tree(parallel chain) with a 1 MiB still on the main chain, thus only heavy multisig will use all 4 MiB.

Here is some quick math to show you an example-

That's not what I derived from Wuille's talk.


http://imgur.com/HdnFO7x

I may have missed it when he said something more clearly about the actual new block size limit. Shall we look at the code to check?


http://imgur.com/am6m5PT

Oh. Dear.


http://imgur.com/BEXIhpH

What to do?

As far as capacity is concerned it doesn't even increase it to 4 MiB , but allows heavy multisig to extend that limit up to 4. It is better to assume that it equivalent to a 1.8-2.5MiB limit increase.

The one direct scalability benefit of segwit that isn't found with simply raising the block limit is full nodes could also skip transferring old signatures which is an unnecessary task.(Existing full nodes already do not validate signatures in the far past but still have the burden of transferring them)

All the other segwit benefits are only indirectly related to capacity increases.  

Segwit isn't being promoted as the solution to capacity problems by developers. It is a elegant change that solves many problems and only slightly increases capacity. The core developers are being very conservative and want to resolve all other optimizations like Segwit and the relay network before drastically increasing the limit.

Gavin does have a fair point to getting these capacity increases completed immediately because it will take a a long time to deploy them and complete the hard fork. I would like for the core devs, miners, and wallet developers to have the code ready and tested and a plan in place to increase the blocksize as an emergency measure if the fee market produces unfavorable results and there is a huge backlog.