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

Updated list of wallets/companies planning to support SegWit:

https://bitcoincore.org/en/segwit_adoption/

Latest one is my favorite SPV - Mycelium -

https://twitter.com/MyceliumCom/status/689518860727377920


... and electrum just ack'ed

To be fair I thought of a potential weakness in SegWit capacity increases vs simply raising maxBlockSize:

The Average effective capacity post segwit will be around 1.75MB, but higher for situations requiring heavy multisig.
Unless complex and heavy multisig becomes the norm, Segwit nodes will need to protect against CVE-2013-2292 as if they had a an effective capacity of 4MB when their average capacity will be 1.75MB. This is because attackers could and would use heavy multisig to exploit CVE-2013-2292.

Therefore the realistic capacity benefit is 1.75-2MB and one must protect against excessive sigops as if the maxBlockSize was raise to 4MB.

segwit testnet is live-

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012195.html



I am pleased to report that as of December 31, 2015 we have been successfully running a segregated witness testnet, called segnet, and have already implemented rudimentary wallets with support.

For source code, please look at sipa's github repo:
https://github.com/sipa/bitcoin/tree/segwit

And some example signing code at my repo:
https://github.com/CodeShark/BitcoinScriptExperiments/blob/master/src/signwitnesstx.cpp

Several wallets have already committed to supporting it including Blocktrail, Breadwallet, GreenAddress, GreenBits, mSIGNA, and NBitcoin. More wallets are expected to be added to this list soon. If you're a wallet dev and are interested in developing and testing on segnet please contact me.

We're right on schedule and are very excited about the fundamental improvements to bitcoin that segwit will enable.

The second one can answer this question, bitcoin will be dead.

I really appreciate an academic, research and facts based approach

The implementation of segwit will make some significant change on bitcoin architecture, thus require all the miners to upgrade to be fully compatible, which is unlikely to happen. As a result, network will be running on two different type of blocks where core miners will not be able to fully verify the new blocks from segwit miners (they see them as empty blocks and do no verification)

This means, the blockchain at that time is not a blockchain that contains all the proof of bitcoin transactions, at least in the eyes of a core client, the new segwit blocks are all empty, thus all the transactions in those segwit blocks are unknow to core clients

So, unless you force it as a hard fork, this kind of change will create lots of unexpected behavior from different clients, maybe a hard fork will happen right away after the first segwit block is mined


Back to the topic I'm interested I still remember an old forum member said, "every technical solution, developer aware or not, have a political consequence." Currently the disagreement is on the different political consequence that various implementations could trigger, e.g. what you want bitcoin to become?

Based on my statistics as a broker and my polls on forum, I see most of the users do not use bitcoin as a payment service (especially now in some countries there are free and instant confirmed mobile payment services available, exchanging into bitcoin and pay a fee to do transaction is just insane.) People just buy bitcoin for long term storage, or speculate the price movement on exchanges. If you follow this usage pattern, then segwit will not provide too much benefit for existing users. If you want to provide the best service for majority of users, then the focus should be on the area that they concern most, like safety or high value, and I don't think scaling solutions will provide higher safety and higher value for bitcoin, maybe opposite

There is a false claim from banks that money's value are generated from its transaction demand (to cover the fact that their money does not have any cost), but for honest money with a production cost (like gold or bitcoin), their value are not generated through its transaction demand. The fact that gold has quit transaction for decades but still rise in value clearly denied that theory. Once you cleared this misconception, you will understand that raised level of bitcoin transaction capacity will not raise its value, its value would still be decided by the mining cost and long term storage demand

I believe that we should try all the best to make bitcoin more stable and valuable. When it is highly stable and valuable, all the smart finance people will be attracted to bitcoin and solve the scaling problem using what ever method they invented, much better than a couple of devs trying to achieve the impossible scaling mission on the blockchain. I think we don't need scale bitcoin too much if bitcoin is highly stable and valuable, the people with the right competence to directly use the blockchain is almost all here

A question from investor point of view: Current bitcoin architecture has passed test of time, and increased its value for thousands of times since the invention of bitcoin. If you change it to another architecture, can you guarantee the same level of performance? If you can not, why should an investor care about your new architecture which is not time tested?

The Power to decide has always been available and a vocal minority is merely attempting to be reframe the narrative as one of control where none exists. Nodes and Miners have always had a choice and trying to pressure volunteer developers to work against some of their principles and to voluntarily code changes they believe are dangerous is not the appropriate way to go about matters.

I encourage other implementations to move forward and develop a great group of talented developers and to deploy more nodes. These contributions will help secure our ecosystem.

Back to SepSig-

Transaction signature verification is a very Interesting improvements being made possible that would be very difficult to pull off without SepSig-


https://twitter.com/aantonop/status/684760184074432512
https://twitter.com/aantonop/status/684759586390302720
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html
https://github.com/jl2012/bips/blob/segwit-checksig/bip-segwit-checksig.mediawiki




P.S... I am saddened to hear that our comrade David Chaum has decided to introduce encryption schemes with security vulnerabilities. His past contributions will be honored but his future legacy tarnished.

There are many projects running different development models but the process I mentioned is a general level principle that applies to any project as long as they are customer facing. It is not about the customer is right or wrong, it is the question of who has the power to decide

Of course I've seen occasions stupid customers who didn't even understand the consequence of their decision and cancelled a project that had invested millions of dollars (Don't we lack of these kind of VC investment in bitcoin space? 21 inc's computer for example ), but it is their money and if they don't care, why should developers bother, those who were against the investor's idea all got fired

For example, I have a view why the fee should rise: Because a high fee per block works as a mechanism to re-balance the money distribution, which is not very well in today's bitcoin ecosystem. Imagine that when bitcoin price passed millions and block reward dropped to 1 bitcoin, and miners don't bother with transaction fee since mining 1 bitcoin would bring in million dollars of income. However, that does not help to change the more and more unequal distribution of bitcoin. By imposing a higher fee per block (50 BTC for example), the future adopters would still be able to get similar share of bitcoin income from mining exactly like early adopters, thus make bitcoin more evenly distributed. When the fee is high, only the bitcoin riches can afford the fee, and their bitcoin thus get redistributed back to the miners. In fact, this design will make bitcoin different to any existing systems that money unavoidably concentrate towards a few entities. You can see that this view is not customer oriented, unless you can enforce it with power, it will not get accepted by existing coin holders since this requires them to think for the system instead of their own interest

I know there is a colloquialism that "the customer is always right" being promoted in many businesses to make the consumer feel special and empowered but in reality this is not how software is developed and behind the doors it is well understood the customer is often wrong and may be requesting features to be created in certain manners that self sabotage their ideals and true intentions. Developers should try and form consensus with the community and listen to the wants and needs of the community but also have to have a balance with technical realities and limitations. This is why there are specific developmental methodologies (none of which I am aware of match " formal R&D process of  "user feedback -> design specification -> implementation" that you suggested.) This doesn't mean you are wrong , I am merely asking fo further clarification on how protocol development is best conducted ... Is it " formal R&D process of  "user feedback -> design specification -> implementation""  the process you recommend or is there anything more to it that I am missing?

Isn't this kind of babysitting habit created such conflict in core devs? Why don't first make some poll to see what majority of the customers really want from bitcoin, and if they can not have everything, what is their priority

Miners only care about the block subsidy and low orphan rate
Investors even care less about payment function since they hold large sum for long term and use exchange to liquidate
Exchanges and payment processors are the one require large transaction capacity

Seems like an interesting link in stakeholder power dynamics ... I will check it out. I understand what you are suggesting in a very generic and abstract manner about pleasing your clients... but, I am getting specific with getting clarification on the development model because the details matter , especially when there is a high possibility that the "clients" don't have enough information to make an informed decision on what they really want and may be asking for features that are either impossible to deliver or ones they may regret getting. It is therefore important to follow a standard development process to insure that the clients get a quality product which will make them happy.... or perhaps are you proposing a new development model which is superior than normal ones?

You are dig into details here, we only talk about those model names at design level. At decision making level what matters is feedback from your customer. If you can't keep them happy, they go to another supplier and you are done

I have roughly analyzed the political power map HERE, it is the miners, exchanges and investors the biggest customer for bitcoin, and they hold veto power to a solution, similar to a large customer can write you off from their supplier list. So we should listen to their feedback before writing any design specification

I still see it -
https://github.com/bitcoin/bips/pull/265/files
https://github.com/bitcoin/bips/pull/265

Where can I read segwit BIP draft?

jl2012 has removed it at github...

You are referring to an extremely non-standard development process. Does your organization or company have internal documents that give specifications as to what process you have as a development framework such as waterfall model, v model, incremental model, RAD model Agile model, iterative model or spiral model to name a few of the more popular ones? I am frankly surprised that is the development process as it could lead to some large problems IMHO, and would like to educate myself more in your development model to see if I am missing something.

I apologize if I am coming off a bit anal retentive , but the specifics you are referring to are of great importance in development and I want to be sure I am not mis-characterizing what you are suggesting.

Each company have their own process, in the project I participated (100 to 1000+ developers) this is a common practice

Of course bitcoin is decentralized network without a centralized decision making model. But just because it is decentralized, it is more important to have a per-agreed process in change management. You can code whatever you want, people just ignore. From the amount of discussion I see on reddit and forum, the reaction for SW is even less than XT

If it was cores intent to try and sneak in SepSig with a soft-fork with an attempt to cloak a hidden agenda than why the very public pre-announcement with thousands of hours in attempts to educate the public? Why not just secretly initiate the soft-fork by discussing the details directly with wallet developers and miners?


I am unfamiliar with that R+D framework. Could you clarify or link to what formal process you are referring to? Thank You.

Exactly the reason I'm against using soft fork to sneak in changes, such kind of practice is hacking the network, not the formal R&D process of  "user feedback -> design specification -> implementation"

Most of the core developers have proven to be competent , including Hearn and Gavin by a long history of work and where this trust resides. It would be fantastic for these differences to bring new developers into the foray and become lead repository maintainers for other implementations.  


No, you missed the most salient point. Gavin asked a specific question-


and the responses reflected that his suspicions upon a quick review were well warranted.

Bitcoin needs a much higher standard of testing and competency than most open source projects because billions of dollars resides upon it. This means we need some of the best developers that have a solid history and portfolio of work behind each implementation and not some up and coming developers learning on the fly that ...


This I would have to disagree with... The stakes are extremely high with bitcoin and it is in no way a small project.

Such would seem to work towards a goal of antifragility.


Which may be the best gift that could have been given to those advocating larger blocks. XT initially sounded like a step in the right direction, but only because it was marketed as 'Core with larger maxblocksize'. It was only after the fact that it became apparent that Hearn put more in XT than was initially described.


I don't know whether or not Gavin fully knew or fully was onboard with the other changes within XT. But perhaps his goal might have been merely in forcing the conversation. In that respect, XT was likely a success. Scaling was pretty well stalled before XT -- at least from a public visibility standpoint.


I'd not heard that. Interesting.


While his comments should be addressed, it does not seem that any of them are fatal -- or even have anything to do with the intent, function, or design of the executable itself. The most damning is a lack of description of testing. The others are dismissible on their face as fully compliant with other accepted development methodologies.

eta: I would argue that each implementation's development team is perfectly within their authority to adopt any development standards that make sense for their project. 'No commented out code' does not affect the executable, and therefore is a philosophical stance.


Though comments from some indicate that this implicit trust is subject to dissipation.

There are specific reasons and benefits that SepSig provides, which merely increasing capacity with MaxBlockSize doesn't address. One large one is our ability to prune older signatures from the second merkle tree.


The article is written by a journalist , and even some developers are unaware of the odd work around softfork solution I cited. Bitcoin is a very complicated and nuanced project where we must rely on each other and no one has a firm grasp of all the moving parts.


Well that is one hypothesis... My personal opinion from following the developer discussions is the opinions are wide and varied and not monolithic like many redditors like to insinuate. There are some developers who wish to keep the blocksize the same (Luke, and Peter Todd-- but Peter recently suggested he will likely sign the scaling proposal). Many of the core developers are more consevative and while not opposed to increasing the MaxBlockSize , want to first focus on making Bitcoin more "Scalable" first and than either increase MaxBlockSize or develop some dynamic block size proposal which is market based. There appears to be some reluctance towards a "kick the can" hard fork as most developers would rather solve the problem with one hard fork rather than multiple.

One thing I and many other developers agree upon is the need for multiple implementations.... so you don't really need to be too concerned if core makes a huge mistake by being too conservative as we can fall back on another implementation. Not only do the Core developers need our support (instead of speculations and infighting) but all the other implementations are in dire need of support - Hearn walked away from XT and Gavin isn't interested in taking over.  Libbitcoin and darkwallet have stalled due to one of the lead devs dissapearing (and some speculate murdered), Bitcoin Unlimited was just reviewed quickly by gavin and it appears to be lacking - https://bitco.in/forum/threads/i-really-want-to-like-bitcoin-unlimited.684/

We really need at least 3 full and independent implementations within bitcoin with separate experienced and qualified development teams. So far we only have one competent team that miners trust , and why the community has fallen back on pleading and "voting" the core developers instead of merely trusting another implementation.