More people are going to be siding with BIP101 than the BIPwaitandsee. After the last conference it is pretty obvious where we're going.

However, if a rogue node send out a block appears to be valid but with transactions with wrong signature, then if other nodes do not validate each transactions in the block, they have no way to know if those transactions are valid, if they approve those blocks and start to build block above this block then those invalid transactions can even spend satoshi's coins

Even it is a working solution, the gain in that is not even a magnitude, the risk/reward ratio is not worth it. I prefer the simplicity over complexity. I think Lightning network's settlement based design can increase the capacity for magnitudes, that is more worth the effort

Do you really understand what Pieter is suggesting? And the possible consequence in future if it is adopted?

We have observed, even simply raise the blocksize limit to 8MB which is simple enough for anyone to understand will result in huge resistance, this kind of complex solution which requires decision makers to have deep understanding of the inner workings of blocks and nodes would never get serious acceptance if any at all

1. Not a side chain, a parallel chain. For every header'ed block, there must be a corresponding SegWit block. Not a side chain.

2. SegWit chain is prunable. Future chain bloat not a problem. You haven't taken it all in yet (and neither have I)

Am I wrong to assume that the large mining pool owners aren't well versed in the rudimentary basics of bitcoin? If I can understand it, I am sure they can.

To be sure, Blockstreamers only now are coming to realize that an increase of the effective block size limit to 4 MB will have the unexpected and unwelcome consequence of increasing the effective block size limit to 4 MB.

 So Luke has already proposed to keep the 1 MB limit for the total block size, including the segregated part.

But they should not worry, since the space savings will only occur if the clients start issuing transactions in the new SW format.  Which will not happen right away, if SW is deployed by soft fork.  And even after the clients have upgraded, the use of SW will be optional.  Will there be incentives for the clients to use it?

The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating proposals were presented. I think this would be a good time to share my view of the near term arc for capacity increases in the Bitcoin system. I believe we’re in a fantastic place right now and that the community is ready to deliver on a clear forward path with a shared vision that addresses the needs of the system while upholding its values.

I think it’s important to first clearly express some of the relevant principles that I think should guide the ongoing development of the Bitcoin system.

Bitcoin is P2P electronic cash that is valuable over legacy systems because of the monetary autonomy it brings to its users through decentralization. Bitcoin seeks to address the root problem with conventional currency: all the trust that's required to make it work--

-- Not that justified trust is a bad thing, but trust makes systems brittle, opaque, and costly to operate. Trust failures result in systemic  collapses, trust curation creates inequality and monopoly lock-in, and naturally arising trust choke-points can be abused to deny access to
due process. Through the use of cryptographic proof and decentralized networks Bitcoin minimizes and replaces these trust costs.

With the available technology, there are fundamental trade-offs between scale and decentralization. If the system is too costly people will be forced to trust third parties rather than independently enforcing the system's rules. If the Bitcoin blockchain’s resource usage, relative
to the available technology, is too great, Bitcoin loses its competitive advantages compared to legacy systems because validation will be too
costly (pricing out many users), forcing trust back into the system. If capacity is too low and our methods of transacting too inefficient, access to the chain for dispute resolution will be too costly, again pushing trust back into the system.

Since Bitcoin is an electronic cash, it _isn't_ a generic database; the demand for cheap highly-replicated perpetual storage is unbounded,
and Bitcoin cannot and will not satisfy that demand for non-ecash (non-Bitcoin) usage, and there is no shame in that. Fortunately, Bitcoin
can interoperate with other systems that address other applications, and--with luck and hard work--the Bitcoin system can and will satisfy the world's demand for electronic cash.

Fortunately, a lot of great technology is in the works that make navigating the trade-offs easier.

First up: after several years in the making Bitcoin Core has recently merged libsecp256k1, which results in a huge increase in signature
validation performance. Combined with other recent work we're now getting ConnectTip performance 7x higher in 0.12 than in prior versions. This has been a long time coming, and without its anticipation and earlierwork such as headers-first I probably would have been arguing for a
block size decrease last year.  This improvement in the state of the art for widely available production Bitcoin software sets a stage for
some capacity increases while still catching up on our decentralization deficit. This shifts the bottlenecks off of CPU and more strongly onto
propagation latency and bandwidth.

Versionbits (BIP9) is approaching maturity and will allow the Bitcoin network to have multiple in-flight soft-forks. Up until now we’ve had to
completely serialize soft-fork work, and also had no real way to handle a soft-fork that was merged in core but rejected by the network. All
that is solved in BIP9, which should allow us to pick up the pace of improvements in the network. It looks like versionbits will be ready for use in the next soft-fork performed on the network.

The next thing is that, at Scaling Bitcoin Hong Kong, Pieter Wuille presented on bringing Segregated Witness to Bitcoin. What is proposed is a _soft-fork_ that increases Bitcoin's scalability and capacity by reorganizing data in blocks to handle the signatures separately, and in doing so takes them outside the scope of the current blocksize limit.

The particular proposal amounts to a 4MB blocksize increase at worst. The separation allows new security models, such as skipping downloading data you're not going to check and improved performance for lite clients (especially ones with high privacy). The proposal also includes fraud proofs which make violations of the Bitcoin system provable with a compact proof. This completes the vision of "alerts" described in the "Simplified Payment Verification" section of the Bitcoin whitepaper, and would make it possible for lite clients to enforce all the rules of the system (under a new strong assumption that they're not partitioned from someone who would generate the proofs). The design has numerous other features like making further enhancements safer and eliminating signature malleability problems. If widely used this proposal gives a 2x capacity increase (more if multisig is widely used), but most importantly it makes that additional capacity--and future capacity beyond it--safer by increasing efficiency and allowing more trade-offs (in particular, you can use much less bandwidth in exchange for a strong non-partitioning assumption).

There is a working implementation (though it doesn't yet have the fraud proofs) at https://github.com/sipa/bitcoin/commits/segwit

(Pieter's talk is at:  transcript:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/
slides:
https://prezi.com/lyghixkrguao/segregated-witness-and-deploying-it-for-bitcoin/
Video: https://www.youtube.com/watch?v=fst1IK_mrng#t=36m )

I had good success deploying an earlier (hard-fork) version of segwit in the Elements Alpha sidechain; the soft-fork segwit now proposed
is a second-generation design. And I think it's quite reasonable to get this deployed in a relatively short time frame. The segwit design
calls for a future bitcoinj compatible hardfork to further increase its efficiency--but it's not necessary to reap most of the benefits,and that
means it can happen on its own schedule and in a non-contentious manner.

Going beyond segwit, there has been some considerable activity brewing around more efficient block relay.  There is a collection of proposals,
some stemming from a p2pool-inspired informal sketch of mine and some independently invented, called "weak blocks", "thin blocks" or "soft
blocks".  These proposals build on top of efficient relay techniques (like the relay network protocol or IBLT) and move virtually all the
transmission time of a block to before the block is found, eliminating size from the orphan race calculation. We already desperately need this
at the current block sizes. These have not yet been implemented, but fortunately the path appears clear. I've seen at least one more or less
complete specification, and I expect to see things running using this in a few months. This tool will remove propagation latency from being a problem in the absence of strategic behavior by miners.  Better understanding their behavior when miners behave strategically is an open question.

Concurrently, there is a lot of activity ongoing related to “non-bandwidth” scaling mechanisms. Non-bandwidth scaling mechanisms are tools like transaction cut-through and bidirectional payment channels which increase Bitcoin’s capacity and speed using clever smart contracts
rather than increased bandwidth. Critically, these approaches strike right at the heart of the capacity vs autotomy trade-off, and may allow us to achieve very high capacity and very high decentralization. CLTV (BIP65), deployed a month ago and now active on the network, is very useful for these techniques (essential for making hold-up refunds work); CSV (BIP68/ BIP112) is in the pipeline for merge in core and making good progress (and will likely be ready ahead of segwit). Further Bitcoin protocol improvements for non-bandwidth scaling are in the works: Many of these proposals really want anti-malleability fixes (which would be provided by segwit), and there are checksig flag improvements already tendered and more being worked on, which would be much easier to deploy with segwit. I expect that within six months we could have considerably more features ready for deployment to enable these techniques. Even without them I believe we’ll be in an acceptable position with respect to capacity in the near term, but it’s important to enable them for the future.

(http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning
is a relevant talk for some of the wanted network features for Lightning, a bidirectional payment channel proposal which many parties are working on right now; other non-bandwidth improvements discussed in the past include transaction cut-through, which I consider a must-read for the basic intuition about how transaction capacity can be greater than blockchain capacity: https://bitcointalk.org/index.php?= topic=281848.0 , though there are many others.)

Further out, there are several proposals related to flex caps or incentive-aligned dynamic block size controls based on allowing miners
to produce larger blocks at some cost. These proposals help preserve the alignment of incentives between miners and general node operators, and prevent defection between the miners from undermining the fee market behavior that will eventually fund security. I think that right now capacity is high enough and the needed capacity is low enough that we don't immediately need these proposals, but they will be critically important long term. I'm planning to help out and drive towards a more concrete direction out of these proposals in the following months.

(Relevant talks include http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/a-flexible-limit-trading-subsidy-for-larger-blocks/)

Finally--at some point the capacity increases from the above may not be enough.  Delivery on relay improvements, segwit fraud proofs, dynamic block size controls, and other advances in technology will reduce the riskand therefore controversy around moderate block size increase proposals (such as 2/4/8 rescaled to respect segwit's increase). Bitcoin will be able to move forward with these increases when improvements and understanding render their risks widely acceptable relative to the risks of not deploying them. In Bitcoin Core we should keep patches ready to implement them as the need and the will arises, to keep the basic software engineering from being the limiting factor.

Our recent and current progress has well positioned the Bitcoin ecosystem to handle its current capacity needs. I think the above sets out some clear achievable milestones to continue to advance the art in Bitcoin capacity while putting us in a good position for further improvement and evolution.

TL;DR:  I propose we work immediately towards the segwit 4MB block soft-fork which increases capacity and scalability, and recent speedups
and incoming relay improvements make segwit a reasonable risk. BIP9 and segwit will also make further improvements easier and faster to deploy. We’ll continue to set the stage for non-bandwidth-increase-based scaling, while building additional tools that would make bandwidth
increases safer long term. Further work will prepare Bitcoin for further increases, which will become possible when justified, while also providing the groundwork to make them justifiable.

Thanks for your time.

It is not my fault that you seem to be unable to understand the subtlety and nuance of ethics and modern political thought.

there is no real centralized as controlled by a single man, farm right now, despite what everyone think, and in the future also, are still very decentralized, especially because there will be also the electricity limit per zone

also nodes nowadays does not count anything, and they are already very limited, only few people run a full node

Ok, that doesn't seem so bad at all. It's just a sidechain solution.

There is no hypocrisy there. I still disagree with how BIP65 was implemented. I also still disagree with RBF, since it weakens zero confirmation in favor of strengthening layer two payment channels. They did this without the appropriate time and consensus that I think should have been appropriate for such a contentious change, considering their previous position on contentious issues I also find their actions hypocritical.

I do actually agree with you though. Core can implement whatever they want to implement regardless of what the economic majority wants

I am disgusted by what is happening now with Core and RBF, to push such a contentious change without any debate, voting, time or even miner consensus. It is truly horrendous especially considering the harm that RBF can do to Bitcoin. It is also highly hypocritical especially considering their reasoning for not implementing a blocksize increase. I hope that once Core is forked out of power we will be able to reverse these changes and repair the damage that has been done here.

What Core did with the recent hard fork is also rather disgusting, they used the same version number for the blocks as BIP101, they did this on purpose in order to undermine BIP101. This represents a deliberate move by Core in order to circumvent the legitimate decision making process of proof of work.

They should have introduced BIP65 using a hard fork, since introducing it as a soft fork allows them to circumvent the processes of consensus that a hard fork would have necessitated.

The developers are our personal slaves that we can make demands from ... they are volunteers making very important contributions towards our ecosystem.

I think there is presently a fundamental disagreement within the Bitcoin community, which is related predominantly around questions of governance. I believe like many others do that consensus is an emergent property which is best reflected through proof of work which acts as a proxy for the economic majority. This is in strong contrast to the opposing view that Bitcoin should be governed top down by Core or that Bitcoin is governed by mathematics and eternal unchangeable principles. These two conceptions of Bitcoin governance are at odds with each other. It has become very clear to me especially after the conversations I had with gmaxwell on this thread that Core ascribes to the latter conception of Bitcoin governance, which I am in strong disagreement with. This has increased the need for alternative implementations especially as Core is presently attempting to fundamentally change the economic policy of Bitcoin in a way which I disagree with.

Part of this difference of perspective can be ascribed to peoples intellectual backgrounds. I can understand that for an engineer or scientist having a system governed by pure mathematics and science would be appealing. However I do not believe that is the case, Bitcoin is governed by the economic majority. People with economics background tend to understand and be more comfortable with the idea of allowing the free market to determine such things. An economist would also understand the inherent disadvantageous of central economic planning, which in effect is what Core is attempting to do now, at least in regards to their position on the blocksize related to governance. Essentially I believe that ideally the blocksize limit should not be used to determine the actual average blocksize, blocksize should ideally emerge from factors of supply and demand instead.

I can see that now , thank you. I think we hold some responsibility in breeding this vitriol and hostility as well. There were many developers that were busy coding and testing instead of playing politics. Communication problems arose due to the inefficiencies over discussing complex ideas on mailing lists and forums which were exacerbated by the stakes involved which are much higher than most open source projects.

In the future we need better communicators to bridge the ideas and work from developers as they are working at levels way above our heads and don't necessarily know how to gauge the audience or speak without jargon. We also need more conferences and get together between developers where they have a chance to build solidarity in a less stressful environment. Hopefully we can build from these mistakes and grow together.

bwahahaha