Segregated witness - The solution to Scalability (short term)?

[johnyj]

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

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

[BitUsher]

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

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

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.

[pianist]

Where can I read segwit BIP draft?

jl2012 has removed it at github...

[BitUsher]

Where can I read segwit BIP draft?

jl2012 has removed it at github...

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

[johnyj]

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

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

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.

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

[BitUsher]

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

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?

[johnyj]

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.

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

[BitUsher]

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

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?

[johnyj]

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

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?

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

[BitUsher]

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

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.

[johnyj]

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

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.

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?

[hdbuck]

It is not about the customer is right or wrong, it is the question of who has the power to decide

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

[BitUsher]

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.

[BitUsher]

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.

[BitUsher]

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