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

[Bitcoin Billionaire]

Any concept being propagated by Mr. Andresen should be ignored, he's made his intentions very clear.

[johnyj]

Found it. https://www.youtube.com/watch?v=TgjrS-BPWDQ&feature=youtu.be&t=3h05m Mark Freidenbach (?) near the end of the morning session at day 2 of the Scaling Bitcoin conference.


eta: ^ did you sneak an edit in with the link while I was off looking for it?

So during the slide you had a pic of above, he was talking about a non-standard block that aggregated as much dust as F2Pool was able to fit in a single block. Note that those transactions that went into that block are already unrelayable under standard rules.

In summary remarks he indicated that 'blocksize is a poor indicator of the resource consumption required to process a block'.

It is indeed a special transaction,  but you can not prevent an attacker from broadcasting this kind of block

In fact coinwallet.eu's last round of attack consists exactly of this kind of dust outputs,  and in the name of coin give away so that hundreds of people tried to construct a huge transaction to claim the coins in their address. You can search for the post in this forum and this time I won't edit the link  

[bambou]

"Segwit" is "Suicide".

[Lauda]

"Segwit" is "Suicide".

I'm not sure if this is sarcasm or something? Anyhow it seems that a roadmap has been finalized for 2016:
Capacity increases FAQ
Signatures

Segwit code is planned for April.

[hdbuck]

"Segwit" is "Suicide".

I'm not sure if this is sarcasm or something? Anyhow it seems that a roadmap has been finalized for 2016:
Capacity increases FAQ
Signatures

Segwit code is planned for April.

Is it VERified?

[Lauda]

Is it VERified?

What do you mean with that? The signatures? If so, then they are.

[BitUsher]

https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-soft-fork-might-establish-a-block-size-truce-or-not-1451423607

Segregated Witness, Part 3: How a Soft Fork Might Establish a Block-Size Truce (or Not)

[jbreher]

https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-soft-fork-might-establish-a-block-size-truce-or-not-1451423607

Segregated Witness, Part 3: How a Soft Fork Might Establish a Block-Size Truce (or Not)

The author gives lip service to impartiality, and seems to be trying on this front. However, his taxonomy of advocates labeling smallblockians as "decentralists" belies his inherent bias. In order to consider smallblockians as "Decentralists", one must blinder themselves to the fact that hard limits on blocksize -- below the natural demand of the user base -- necessarily channels transactions through a relatively small number of on- and off-ramps to the blockchain. These on-ramp/off-ramp providers, being smaller in number than the number of users desiring transaction processing, are inherently a dimension of centralization. Period.

The relative merit of mining centralization vs. onramp centralization is something that can be debated. But pretending that onramp centralization is somehow not centralization is disingenuous at best.

One thing that has me scratching my head is the characterization of SegWit as not requiring a hard fork:

One of the most interesting aspects of Wuille’s Segregated Witness proposal is that it can be rolled out without breaking any of the existing consensus rules. As such, the proposal can effectively be enforced by miners only. This is called a soft fork.

Increasing the block-size limit (the “old-fashioned way”) can be done only through a hard fork. As such, there must be consensus among all of Bitcoin’s user-base that a block-size limit increase is the best way forward.

Yet my understanding of the omnibus SetWit proposal is that it includes a block size increase. How is it that SegWit can "have its cake and eat it too"?

[BitcoinNewsMagazine]

https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-soft-fork-might-establish-a-block-size-truce-or-not-1451423607

Segregated Witness, Part 3: How a Soft Fork Might Establish a Block-Size Truce (or Not)

The author gives lip service to impartiality, and seems to be trying on this front. However, his taxonomy of advocates labeling smallblockians as "decentralists" belies his inherent bias. In order to consider smallblockians as "Decentralists", one must blinder themselves to the fact that hard limits on blocksize -- below the natural demand of the user base -- necessarily channels transactions through a relatively small number of on- and off-ramps to the blockchain. These on-ramp/off-ramp providers, being smaller in number than the number of users desiring transaction processing, are inherently a dimension of centralization. Period.

The relative merit of mining centralization vs. onramp centralization is something that can be debated. But pretending that onramp centralization is somehow not centralization is disingenuous at best.

One thing that has me scratching my head is the characterization of SegWit as not requiring a hard fork:

One of the most interesting aspects of Wuille’s Segregated Witness proposal is that it can be rolled out without breaking any of the existing consensus rules. As such, the proposal can effectively be enforced by miners only. This is called a soft fork.

Increasing the block-size limit (the “old-fashioned way”) can be done only through a hard fork. As such, there must be consensus among all of Bitcoin’s user-base that a block-size limit increase is the best way forward.

Yet my understanding of the omnibus SetWit proposal is that it includes a block size increase. How is it that SegWit can "have its cake and eat it too"?

See the Capacity Increases FAQ for details. The roadmap calls for SegWit to be integrated by soft fork. SegWit could also be integrated by hard fork, and some prefer that way as a more elegant solution. Appears that the decision to use a soft fork has already been made though.

[jbreher]

See the Capacity Increases FAQ for details. The roadmap calls for SegWit to be integrated by soft fork. SegWit could also be integrated by hard fork, and some prefer that way as a more elegant solution. Appears that the decision to use a soft fork has already been made though.

My concern is the apparent contradiction.
- I am told that a maxblocksize increase requires a hard fork.
- I am told that the omnibus SegWit proposal contains an increase in the maxblocksize.
- I am told that the omnibus SegWit proposal does not require a hard fork.
Logic tells me that all three cannot be true. Which one is the lie?

[BitcoinNewsMagazine]

See the Capacity Increases FAQ for details. The roadmap calls for SegWit to be integrated by soft fork. SegWit could also be integrated by hard fork, and some prefer that way as a more elegant solution. Appears that the decision to use a soft fork has already been made though.

My concern is the apparent contradiction.
- I am told that a maxblocksize increase requires a hard fork.
- I am told that the omnibus SegWit proposal contains an increase in the maxblocksize.
- I am told that the omnibus SegWit proposal does not require a hard fork.
Logic tells me that all three cannot be true. Which one is the lie?

Segregated Witness increases the space available in current 1 MB blocks for transactions. It does this by reorganizing data to handle the transaction signatures separately. See this article for more info and a video by Pieter Wuille - hope this helps.

[BitUsher]

My concern is the apparent contradiction.
- I am told that a maxblocksize increase requires a hard fork.

This is not completely true as all hardforks can be implemented as softforks in a very convoluted method as discussed here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012153.html

One suggested term for this process is called a "Firm Fork" or the "nuclear softfork option"

This is an old idea and technically one that can be done right now if miners wanted to push it through.
This fact is a bit scary and shows you how much power miners have and how we need to decentralize hashing power.

- I am told that the omnibus SegWit proposal contains an increase in the maxblocksize.

Not exactly, the MaxBlockSize remains at 1MB with SepSig and it is the separate merkle tree handling signatures that has a higher limit. The combined limits of both trees has an effective capacity increase between 1.75-4MB

- I am told that the omnibus SegWit proposal does not require a hard fork.

Correct.

[jbreher]

See the Capacity Increases FAQ for details. The roadmap calls for SegWit to be integrated by soft fork. SegWit could also be integrated by hard fork, and some prefer that way as a more elegant solution. Appears that the decision to use a soft fork has already been made though.

My concern is the apparent contradiction.
- I am told that a maxblocksize increase requires a hard fork.
- I am told that the omnibus SegWit proposal contains an increase in the maxblocksize.
- I am told that the omnibus SegWit proposal does not require a hard fork.
Logic tells me that all three cannot be true. Which one is the lie?

Segregated Witness increases the space available in current 1 MB blocks for transactions. It does this by reorganizing data to handle the transaction signatures separately. See this article for more info and a video by Pieter Wuille - hope this helps.

Are you not also omitting the fact that the actual maxblocksize, as seen by SegWit implementation, is increased in absolute size under the omnibus SegWit proposal? Or do I have an additional misunderstanding?

Incidentally, it is the talk at Scaling Bitcoin Hong Kong by Peter Wuille from which I believe* I am getting my info.

*(My mind may have been clouded by subsequent debates - dunno.)

[BitUsher]

Both statements are incorrect. MaxBlockSize doesn't increase on the main tree with SepSig, and technically a softfork can increase MaxBlockSize if the miners really wanted to.

[jbreher]

My concern is the apparent contradiction.
- I am told that a maxblocksize increase requires a hard fork.

This is not completely true as all hardforks can be implemented as softforks in a very convoluted method as discussed here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012153.html

One suggested term for this process is called a "Firm Fork" or the "nuclear softfork option"

<<editorializing redacted>>

So the quoted news report was indeed inaccurate. Duly noted.

- I am told that the omnibus SegWit proposal contains an increase in the maxblocksize.

Not exactly, the MaxBlockSize remains at 1MB with SepSig and it is the separate merkle tree handling signatures that has a higher limit. The combined limits of both trees has an effective capacity increase between 1.75-4MB

...and every fully trustless node will require handling all 1.75-4MB, correct? Suddenly casting half (+/-) of the block content out into another differently-named construct borders upon legerdemain in this context.

- I am told that the omnibus SegWit proposal does not require a hard fork.

Correct.

So only two inaccuracies for the price of one. Cool.

I don't know how we'll ever converge to a shared vision for this grand experiment, if our quoted sources are playing fast and loose with reality. It's almost as if someone might have a vested interest in stalling the consensus process.

[BitUsher]

...and every fully trustless node will require handling all 1.75-4MB, correct? Suddenly casting half (+/-) of the block content out into another differently-named construct borders upon legerdemain in this context.

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.

I don't know how we'll ever converge to a shared vision for this grand experiment, if our quoted sources are playing fast and loose with reality. It's almost as if someone might have a vested interest in stalling the consensus process.

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.

It's almost as if someone might have a vested interest in stalling the consensus process.

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.

[jbreher]

One thing I and many other developers agree upon is the need for multiple implementations....

Such would seem to work towards a goal of antifragility.

Hearn walked away from XT

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.

and Gavin isn't interested in taking over.  

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.

Libbitcoin and darkwallet have stalled due to one of the lead devs dissapearing (and some speculate murdered),

I'd not heard that. Interesting.

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/

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.

So far we only have one competent team that miners trust

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

[BitUsher]

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

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.  

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.

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

Andrew, do you have experience leading an open source software project? Ideally Bitcoin Unlimited would be lead by somebody who has a track record in projects that produce very high quality, reliable code (on time and under budget ) (and no, I'm not volunteering....)

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

Secondly, I am creating this software with no full time developers, no paid developers, no budget, and no prior Bitcoin software experience. Its lucky that Bitcoin is a small project.

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

[johnyj]

My concern is the apparent contradiction.
- I am told that a maxblocksize increase requires a hard fork.

This is not completely true as all hardforks can be implemented as softforks in a very convoluted method as discussed here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012153.html

One suggested term for this process is called a "Firm Fork" or the "nuclear softfork option"

This is an old idea and technically one that can be done right now if miners wanted to push it through.
This fact is a bit scary and shows you how much power miners have and how we need to decentralize hashing power.

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"

[BitUsher]

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"

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?

not the formal R&D process of  "user feedback -> design specification -> implementation"

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