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

[Carlton Banks]

All in all, seems to be even less than a x2 capacity increase:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html

Lol you clearly still cant read with any proficiency.

For how many month will it be 'the solution' in 2016, the year of the Great Halvening? April or even May?

You're thinking of proposals that people dislike, not proposals that have received a warm welcome. Pieter Wuille is highly respected, mainly because of his amazing computer science work so far. This sounds to be more of the same, and all you can do is lie and hate? I feel genuinely sorry for you Zara, it can't be much fun, for you or your friends, being such a bitter person.

[hunnaryb]

I don't understand any of this, maybe there can be something written for the less technical among us?

[Lauda]

You're thinking of proposals that people dislike, not proposals that have received a warm welcome. Pieter Wuille is highly respected, mainly because of his amazing computer science work so far. This sounds to be more of the same, and all you can do is lie and hate? I feel genuinely sorry for you Zara, it can't be much fun, for you or your friends, being such a bitter person.

Just ignore anyone who ignores this:

fixing malleability, improving upgradability; improving scaleability, and increasing capacity.

This is very important (the first 3). This proposal received a warm welcome on the conference.

I don't understand any of this, maybe there can be something written for the less technical among us?

There already was an airplane analogy. Re-read the whole thread.

I've updated the thread title a bit.

[BitUsher]

All in all, seems to be even less than a x2 capacity increase:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html

For how many month will it be 'the solution' in 2016, the year of the Great Halvening? April or even May?

It was never presented or intended to be "the solution" and merely a small peice of a puzzle in a comprehensive and holistic approach to addressing Scalability and capacity.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

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.

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.

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

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

[Zarathustra]

All in all, seems to be even less than a x2 capacity increase:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html

Lol you clearly still cant read with any proficiency.

For how many month will it be 'the solution' in 2016, the year of the Great Halvening? April or even May?

You're thinking of proposals that people dislike, not proposals that have received a warm welcome. Pieter Wuille is highly respected, mainly because of his amazing computer science work so far. This sounds to be more of the same, and all you can do is lie and hate? I feel genuinely sorry for you Zara, it can't be much fun, for you or your friends, being such a bitter person.

Your stupid projections. Are you crazy? We welcome a 1,8x increase. But I say it will not be the solution. That's even not enough to survive until the halving date.

[Zarathustra]

All in all, seems to be even less than a x2 capacity increase:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html

For how many month will it be 'the solution' in 2016, the year of the Great Halvening? April or even May?

It was never presented or intended to be "the solution" and merely a small peice of a puzzle in a comprehensive and holistic approach to addressing Scalability and capacity.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

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

Is this a joke? What is long term? 1 month before the halving date oder 1 month after?

[BitUsher]

projections. Are you crazy? We welcome a 1,8x increase. But I say it will not be the solution. That's even not enough to survive until the halving date.

No developer is suggesting it is "the solution". The fact that you cannot see that after we keep clarifying and providing contrary evidence suggests you are acting irrationally.

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

Is this a joke? What is long term? 1 month before the halving date oder 1 month after?

Serious people do not pretend to know the how quickly we will need to scale the capacity needs in the future.

This is why a very responsible approach is outlined here-

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.

If we make sloppy and dumb capacity upgrades in fear and haste we don't have the right incentives to make the right tradeoffs and develop optimal solutions which benefit all. There is no harm in having tested backup plans if the need arises and demand increases more than expected.

The paypal and Visa network have outages all the time and the ecosystem doesn't simply crumble in chaos. with bitcoin the worst fear is some transactions being delayed from confirmation while payment processors rely on 0 conf verification more heavily while an agreed upon and tested hardfork gets deployed. This is far less of an issue than the Visa payment network/paypal being down.   

[Carlton Banks]

We welcome a 1,8x increase. But I say it will not be the solution. That's even not enough to survive until the halving date.

If this is your impression of being welcoming, then I'd certainly avoid any event where you were greeting the guests.

And more doomsday deadline scaremongering, after last time? Come on now.

[Zarathustra]

If we make sloppy and dumb capacity upgrades in fear and haste we don't have the right incentives to make the right tradeoffs and develop optimal solutions which benefit all. There is no harm in having tested backup plans if the need arises and demand increases more than expected.

Some say that a 'monster softfork' would be a dumber 'immediate' short term last minute solution than a simple increase of the block size, when everyone can see that the capacity is at the limit right now and the halving event is just 7 month away.

[BitUsher]

We welcome a 1,8x increase. But I say it will not be the solution. That's even not enough to survive until the halving date.

If this is your impression of being welcoming, then I'd certainly avoid any event where you were greeting the guests.

And more doomsday deadline scaremongering, after last time? Come on now.

 It is almost as if he believes that the only thing holding bitcoin back is capacity...and as soon as we build the 100k seat stadium it will be filled. Even if these optimistic delusions are correct it would be disastrous for the bitcoin ecosystem to have that rapid of growth in such short order.

I am so glad there are enough rational and calm developers contributing and who are aware of the nuances and trade offs in decentralization and security.

Some say that a 'monster softfork' would be a dumber 'immediate' short term last minute solution than a simple increase of the block size, when everyone can see that the capacity is at the limit right now and the halving event is just 7 month away.

Define simple. Bitpays BiP 101 patch actually has more lines of code than the SW softfork.

[Zarathustra]

You're thinking of proposals that people dislike, not proposals that have received a warm welcome. Pieter Wuille is highly respected, mainly because of his amazing computer science work so far. This sounds to be more of the same, and all you can do is lie and hate? I feel genuinely sorry for you Zara, it can't be much fun, for you or your friends, being such a bitter person.

Just ignore anyone who ignores this:

Ah, the ignoring user changed the title of his thread.

[Zarathustra]

We welcome a 1,8x increase. But I say it will not be the solution. That's even not enough to survive until the halving date.

If this is your impression of being welcoming, then I'd certainly avoid any event where you were greeting the guests.

And more doomsday deadline scaremongering, after last time? Come on now.

 It is almost as if he believes that the only thing holding bitcoin back is capacity...and as soon as we build the 100k seat stadium it will be filled.

More projections out of thin air. Crazy.

[BitUsher]

ETA update-

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011875.html

"- Segwit BIP is being written, but has not yet been published.

  - Gregory linked to an implementation but as he mentions it is not completely
    finished yet. ETA for a Segwit testnet* is later this month, then you can test as well.

Wladimir"


I assume Wladimir is refering to rolling segwit into the main bitcoin testnet instead of being tested merely in elements sidechain testnet .

[johnyj]

Pieter Wuille is highly respected because he is one of the devs that made the right conservative approach during the 2013 fork. Still, his proposal can not be taken without careful review

We know that every large player here in bitcoin community never listen to anyone else but only themselves, so unless a proposal can be understand by them it will just be ignored. People ignore Gavin's solution just because they don't understand the potential risk for his radical change in block size limit. Similarly, if Pieter's solution is so complex (much more complex than Gavins) that it is not understandable for majority of the large players, it will just be ignored. You can never convince the large mining pools with those slides

[BitUsher]

Pieter Wuille is highly respected because he is one of the devs that made the right conservative approach during the 2013 fork. Still, his proposal can not be taken without careful review

We know that every large player here in bitcoin community never listen to anyone else but only themselves, so unless a proposal can be understand by them it will just be ignored. People ignore Gavin's solution just because they don't understand the potential risk for his radical change in block size limit. Similarly, if Pieter's solution is so complex (much more complex than Gavins) that it is not understandable for majority of the large players, it will just be ignored. You can never convince the large mining pools with those slides

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.

[brg444]

Pieter Wuille is highly respected because he is one of the devs that made the right conservative approach during the 2013 fork. Still, his proposal can not be taken without careful review

We know that every large player here in bitcoin community never listen to anyone else but only themselves, so unless a proposal can be understand by them it will just be ignored. People ignore Gavin's solution just because they don't understand the potential risk for his radical change in block size limit. Similarly, if Pieter's solution is so complex (much more complex than Gavins) that it is not understandable for majority of the large players, it will just be ignored. You can never convince the large mining pools with those slides

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.

It's mostly a lack of communication and language barrier. (with regards to chinese mining pool)

[johnyj]

Back to the basic: How can you validate a transaction without the signature? You can not, otherwise a node will be able to spend anyone's coin and bitcoin will immediately worth nothing overnight

It seems that after the validation and the transaction is finalized in the block, if node can verify the validity of the block, then it requires no detailed transaction data, since everything in that block is regarded as valid

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

Therefore bitcoin is designed so that any nodes are able to independently verify every transaction, so that it is secure on every node. And that will include lots of data in each block

In order to come over this limitation, Pieter suggested to redesign bitcoin, where the hashes of all the signature goes into the coinbase. But still, without the original transaction data together with signature, you have no way to prove that the hashes are correct, you would still need all those data to prove the validity of each hash. However, those data would be in another chain, then it will reduce the data on main chain, but put the data into a side chain. And in future, that side chain will have all the capacity problem that bitcoin chain have today, even more difficult to deal with

[Carlton Banks]

In order to come over this limitation, Pieter suggested to redesign bitcoin, where the hashes of all the signature goes into the coinbase. But still, without the original transaction data together with signature, you have no way to prove that the hashes are correct, you would still need all those data to prove the validity of each hash. However, those data would be in another chain, then it will reduce the data on main chain, but put the data into a side chain. And in future, that side chain will have all the capacity problem that bitcoin chain have today, even more difficult to deal with

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)

[brg444]

In order to come over this limitation, Pieter suggested to redesign bitcoin, where the hashes of all the signature goes into the coinbase. But still, without the original transaction data together with signature, you have no way to prove that the hashes are correct, you would still need all those data to prove the validity of each hash. However, those data would be in another chain, then it will reduce the data on main chain, but put the data into a side chain. And in future, that side chain will have all the capacity problem that bitcoin chain have today, even more difficult to deal with

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)

To be exact it's more like a parallel merkle tree than a chain if I understand it correctly.

[johnyj]

Pieter Wuille is highly respected because he is one of the devs that made the right conservative approach during the 2013 fork. Still, his proposal can not be taken without careful review

We know that every large player here in bitcoin community never listen to anyone else but only themselves, so unless a proposal can be understand by them it will just be ignored. People ignore Gavin's solution just because they don't understand the potential risk for his radical change in block size limit. Similarly, if Pieter's solution is so complex (much more complex than Gavins) that it is not understandable for majority of the large players, it will just be ignored. You can never convince the large mining pools with those slides

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.

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