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

[Carlton Banks]

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

The objection to BIP101 was on the basis of it's efficacy, not it's simplicity.

If you're looking for a simple system, a trustless cryptographic consensus network is possibly the wrong place to look.

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

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

Not only these. I guess chinese mining farms  are mostly driven by large capitals which using the mining infrastructure to move capital out of china due to capital control in China. These investors can hire hundreds of developers in a large project, so they might not be too interested in what devs are saying. For large capitals, the only thing they care about is risk, anything increase the risk will not be considered

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

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

So far from what I've gathered there's clear understanding of what Pieter is doing within the dev community.

It is not as complex as you make it seem but certainly more complex than a simple change in constant. Yet the upsides are clear and significant.

Maybe Greg could pop up in this thread and clear things up a bit.

[johnyj]

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

The objection to BIP101 was on the basis of it's efficacy, not it's simplicity.

If you're looking for a simple system, a trustless cryptographic consensus network is possibly the wrong place to look.

Raised level of complexity will bring much more trouble later in robustness and sustainability. That's why those complex network design in early ages of internet eventually died over time

[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

So far from what I've gathered there's clear understanding of what Pieter is doing within the dev community.

It is not as complex as you make it seem but certainly more complex than a simple change in constant. Yet the upsides are clear and significant.

Maybe Greg could pop up in this thread and clear things up a bit.

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

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

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

So far from what I've gathered there's clear understanding of what Pieter is doing within the dev community.

It is not as complex as you make it seem but certainly more complex than a simple change in constant. Yet the upsides are clear and significant.

Maybe Greg could pop up in this thread and clear things up a bit.

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

A full-scale deployment of Lightning would require segregated witness to be implemented.

I insist that you are exagerrating the complexity of the proposal. It may not be simple for laymen but clearly it is generally well understood by the developer community from the logs of bitcoin-wizards I've looked at. This is also something that's already been tested to an extent under the Sidechains Elements platform.

By all accounts the security model is exactly the same and while the direct transaction gains are not in the order of magnitude improvement, they are significant. Moreover it enables a new type of semi-verifying SPV using fraud proofs, an important progress.

[brg444]

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

That cannot happen.

If the right signatures are not included along with the transactions data inside the blocks fully verifying nodes will reject them.

[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

So far from what I've gathered there's clear understanding of what Pieter is doing within the dev community.

It is not as complex as you make it seem but certainly more complex than a simple change in constant. Yet the upsides are clear and significant.

Maybe Greg could pop up in this thread and clear things up a bit.

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

A full-scale deployment of Lightning would require segregated witness to be implemented.

I insist that you are exagerrating the complexity of the proposal. It may not be simple for laymen but clearly it is generally well understood by the developer community from the logs of bitcoin-wizards I've looked at. This is also something that's already been tested to an extent under the Sidechains Elements platform.

By all accounts the security model is exactly the same and while the direct transaction gains are not in the order of magnitude improvement, they are significant. Moreover it enables a new type of semi-verifying SPV using fraud proofs, an important progress.

The biggest drawback of complexity is it increases the risk of centralization: If only a few guys knows how it works, then if these guys are compromised then the whole system is down. Currently bitcoin is understandable by thousands of developers, but if you go two chain implementation it will take decades to reach that level of understanding, at mean time simple solutions will gain more and more supporters

[johnyj]

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

That cannot happen.

If the right signatures are not included along with the transactions data inside the blocks fully verifying nodes will reject them.

Ok, so the fully verifying nodes are not going to benefit from the new design, then how does this design improve the communication speed between fully verifying nodes (which is the bottleneck of the current design) ?

[brg444]

The biggest drawback of complexity is it increases the risk of centralization: If only a few guys knows how it works, then if these guys are compromised then the whole system is down. Currently bitcoin is understandable by thousands of developers, but if you go two chain implementation it will take decades to reach that level of understanding, at mean time simple solutions will gain more and more supporters

Look, you need to step back and realize that you clearly don't understand the proposal. Granted that may be because it wasn't communicated well enough yet seeing as all details haven't been hashed out.

I understand your precautionary approach but may I suggest you wait until the full BIP proposal is out?

[Carlton Banks]

The biggest drawback of complexity is it increases the risk of centralization: If only a few guys knows how it works, then if these guys are compromised then the whole system is down. Currently bitcoin is understandable by thousands of developers, but if you go two chain implementation it will take decades to reach that level of understanding, at mean time simple solutions will gain more and more supporters

jonnyj, your avatar text has always read "Beyond Imagination". May I submit that you have gone too far. Come back!

[johnyj]

The biggest drawback of complexity is it increases the risk of centralization: If only a few guys knows how it works, then if these guys are compromised then the whole system is down. Currently bitcoin is understandable by thousands of developers, but if you go two chain implementation it will take decades to reach that level of understanding, at mean time simple solutions will gain more and more supporters

Look, you need to step back and realize that you clearly don't understand the proposal. Granted that may be because it wasn't communicated well enough yet seeing as all details haven't been hashed out.

I understand your precautionary approach but may I suggest you wait until the full BIP proposal is out?

Yes, need some more material, especially some examples showing how a transaction is verified in the new design

[johnyj]

The biggest drawback of complexity is it increases the risk of centralization: If only a few guys knows how it works, then if these guys are compromised then the whole system is down. Currently bitcoin is understandable by thousands of developers, but if you go two chain implementation it will take decades to reach that level of understanding, at mean time simple solutions will gain more and more supporters

jonnyj, your avatar text has always read "Beyond Imagination". May I submit that you have gone too far. Come back!

Thanks, but that's Pieter's imagination to re-design bitocin:

"What if we could redesign Bitcoin from scratch? What if you're designing an altcoin, there's really no reason why you would want to do this in Bitcoin. This is actually something we did in sidechain alpha."

[brg444]

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

That cannot happen.

If the right signatures are not included along with the transactions data inside the blocks fully verifying nodes will reject them.

Ok, so the fully verifying nodes are not going to benefit from the new design, then how does this design improve the communication speed between fully verifying nodes (which is the bottleneck of the current design) ?

It doesn't.

It was clearly implied that data propagation and bandwidth is not directly addressed by this proposal.

Have you read Greg's scalability "roadmap"? There are other solutions on the drawing boards in that regard:

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.

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

[brg444]

The biggest drawback of complexity is it increases the risk of centralization: If only a few guys knows how it works, then if these guys are compromised then the whole system is down. Currently bitcoin is understandable by thousands of developers, but if you go two chain implementation it will take decades to reach that level of understanding, at mean time simple solutions will gain more and more supporters

jonnyj, your avatar text has always read "Beyond Imagination". May I submit that you have gone too far. Come back!

Thanks, but that's Pieter's imagination to re-design bitocin:

"What if we could redesign Bitcoin from scratch? What if you're designing an altcoin, there's really no reason why you would want to do this in Bitcoin. This is actually something we did in sidechain alpha."

So far, I was talking hypothetically about the scheme presented so far, because the deployment would not be easy. All transaction data structures would have to be changed, which is a huge deployment friction. (...) This seemed like a hard problem. I personally dismissed this as a solution for a long time as something non-viable, until Luke-Jr discovered that it's possible to do this as a soft-fork.

[johnyj]

The biggest drawback of complexity is it increases the risk of centralization: If only a few guys knows how it works, then if these guys are compromised then the whole system is down. Currently bitcoin is understandable by thousands of developers, but if you go two chain implementation it will take decades to reach that level of understanding, at mean time simple solutions will gain more and more supporters

jonnyj, your avatar text has always read "Beyond Imagination". May I submit that you have gone too far. Come back!

Thanks, but that's Pieter's imagination to re-design bitocin:

"What if we could redesign Bitcoin from scratch? What if you're designing an altcoin, there's really no reason why you would want to do this in Bitcoin. This is actually something we did in sidechain alpha."

So far, I was talking hypothetically about the scheme presented so far, because the deployment would not be easy. All transaction data structures would have to be changed, which is a huge deployment friction. (...) This seemed like a hard problem. I personally dismissed this as a solution for a long time as something non-viable, until Luke-Jr discovered that it's possible to do this as a soft-fork.

Yes, soft fork is a much better way to bring in a change, get it thoroughly tested and maybe becomes a hard fork when majority of users have tested it. It also takes time to test. Bitcoin has been tested in live traffic for almost 7 years to reach today's maturity, any large change would also need such kind of test by time

[RealMalatesta]

The biggest drawback of complexity is it increases the risk of centralization: If only a few guys knows how it works, then if these guys are compromised then the whole system is down. Currently bitcoin is understandable by thousands of developers, but if you go two chain implementation it will take decades to reach that level of understanding, at mean time simple solutions will gain more and more supporters

Do you mean that a trustless system which depends on users trust in the "brainpool"... isn't really a trustless system anymore? But isn't this already the case?

[BitUsher]

Ok, so the fully verifying nodes are not going to benefit from the new design, then how does this design improve the communication speed between fully verifying nodes (which is the bottleneck of the current design) ?

Besides all the benefits already described, one benefit with SW 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)

[johnyj]

The biggest drawback of complexity is it increases the risk of centralization: If only a few guys knows how it works, then if these guys are compromised then the whole system is down. Currently bitcoin is understandable by thousands of developers, but if you go two chain implementation it will take decades to reach that level of understanding, at mean time simple solutions will gain more and more supporters

Do you mean that a trustless system which depends on users trust in the "brainpool"... isn't really a trustless system anymore? But isn't this already the case?

Let me borrow Peter Todd's famous word: If it is already so then why make it worse 

[jbreher]

My worry here is that we seem to have a large cadre of proponents of this new feature that are not able to articulate answers to reasonable questions. I see a lot of demurring of the nature of "perhaps the devs can come by and explain it better". It makes be think that perhaps these proponents likewise don't understand the details of what is being proposed deeply enough to understand the implications upon the questions being asked.