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

[BitUsher]

https://www.youtube.com/watch?v=NOYNZB5BCHM

Peter Wuille: Segregated witness and its impact on scalability at SF Meetup with more time for questions and clarifications.

I would love to listen to this since the latest lecture was very limited in time as there was a bunch of other speakers in queue, but I just can't stand having to hear a voice from only one of my headphones...

Is there a way to make the sound mono? It's not that hard to do it before you upload it, so much for tech geniuses that fail to duplicate the left audio channel into the right one before uploading

First world problems. Just sayin'.

You could always just short the left hot to the right hot. An adapter could be soldered up in five minutes tops, and that would include the time spent rooting around for the soldering iron. Or go ghetto and slice into the leads, twisting the wires together.

^(partially) in jest.

....or wait till he gets home and listen with speakers instead of headphones at work. I bit tedious we have to point out the obvious

[1714173110]

1714173110

[1714173110]

1714173110

[franky1]

https://www.youtube.com/watch?v=NOYNZB5BCHM

Peter Wuille: Segregated witness and its impact on scalability at SF Meetup with more time for questions and clarifications.

I would love to listen to this since the latest lecture was very limited in time as there was a bunch of other speakers in queue, but I just can't stand having to hear a voice from only one of my headphones...

Is there a way to make the sound mono? It's not that hard to do it before you upload it, so much for tech geniuses that fail to duplicate the left audio channel into the right one before uploading

First world problems. Just sayin'.

You could always just short the left hot to the right hot. An adapter could be soldered up in five minutes tops, and that would include the time spent rooting around for the soldering iron. Or go ghetto and slice into the leads, twisting the wires together.

^(partially) in jest.

....or wait till he gets home and listen with speakers instead of headphones at work. I bit tedious we have to point out the obvious

or even a simpler hack..
you know when you put an audio jack into the socket. you feel it click twice.. pull it out slightly so you feel only one click..you should now get mono in both headphones

[BitUsher]

or even a simpler hack..
you know when you put an audio jack into the socket. you feel it click twice.. pull it out slightly so you feel only one click..you should now get mono in both headphones

Ahh genius ...

Garziks concerns with segwit---

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

1. Summary

Segregated Witness (SegWitness, SW) is being presented in the context of
Scaling Bitcoin.  It has useful attributes, notably addressing a major
malleability vector, but is not a short term scaling solution.


2. Definitions

Import Fee Event, ECE, TFM, FFM from previous email.

Older clients - Any software not upgraded to SW

Newer clients - Upgraded, SW aware software


Block size - refers to the core block economic resource limited by
MAX_BLOCK_SIZE.  Witness data (or extension block data) is excluded.
Requires a hard fork to change.

Core block - Current bitcoin block, with upper bound MAX_BLOCK_SIZE.  Not
changed by SW.


Extended transaction - Newer, upgraded version of transaction data format.

Extended block - Newer, upgraded version of block data format.


EBS - Extended block size.  Block size seen by newer clients.


3. Context of analysis

One proposal presents SW *in lieu of* a hard fork block size increase.
This email focuses directly on that.

Useful features outside block size context, such as anti-malleability or
fraud proof features, are not covered in depth.


4.1.  Observations on data structure formats and views

SW creates two *views* of each transaction and block.  SW has blocks and
extended blocks.  Similarly, there exists transactions and extended
transactions.

This view is rendered to clients depending on compatibility level.  Newer
clients see extended blocks and extended transactions.  Older clients see
blocks (limit 1M), and do not see extended blocks.  Older clients see
upgraded transactions as unsigned, anyone-can-pay transactions.

Each extended transaction exists in two states, one unsigned and one
signed, each of which passes validation as a valid bitcoin transaction.


4.2.  Observations on behavior of older transaction creation

Transactions created by older clients will not use the extended transaction
format.  All data is stored the standard 1M block as today.


4.3.  Observations on new block economic model

SW complicates block economics by creating two separate, supply limited
resources.

The core block economic resource is heavily contended.  Older clients use
core blocks exclusively.  Newer clients use core blocks more
conservatively, storing as much data as possible in extended blocks.

The extended block economic resource is less heavily contended, though that
of course grows over time as clients upgrade.

Because core blocks are more heavily contended, it is presumed that older
clients will pay a higher fee than newer clients (subject to elasticity
etc.).


5.1.  Problem:  Pace of roll-out will be slow - Whole Ecosystem must be
considered.

The current apparent proposal is to roll out Segregated Witness as a soft
fork, and keep block size at 1M.

The roll-out pace cannot simply be judged by soft fork speed - which is
months at best.  Analysis must the layers above:  Updating bitcoin-core
(JS) and bitcoinj (Java), and then the timelines to roll out those updates
to apps, and then the timeline to update those apps to create extended
transactions.

Overall, wallet software and programmer libraries must be upgraded to make
use of this new format, adding many more months (12+ in some stacks) to the
roll out timeline.  In the meantime, clients continue to contend entirely
for core block space.


5.2.  Problem:   Hard fork to bigger block size Just Works(tm) with most
software, unlike SW.

A simple hard fork such as BIP 102 is automatically compatible with the
vast range of today's ecosystem software.

SW requires merchants to upgrade almost immediately, requires wallet and
other peripheral software upgrades to make use of.  Other updates are
opt-in and occur more slowly.  BIP 70 processors need some updates.

The number of LOC that must change for BIP 102 is very small, and the
problem domain well known, versus SW.


5.3.  Problem:   Due to pace, Fee Event not forestalled.

Even presuming SW is merged into Bitcoin Core tomorrow, this does not
address the risk of a Fee Event and associated Economic Change in the
coming months.


5.4.  Problem:   More complex economic policy, new game theory, new bidding
structure risks.

Splitting blocks into two pieces, each with separate and distinct behaviors
and resource values, creates *two fee markets.*

Having two pricing strata within each block has certainly feasible - that
is the current mining policy of (1) fee/KB followed by (2) priority/age.

Valuable or not - e.g. incentivizing older clients to upgrade - the fact
remains that SW creates a more-complex bidding structure by creating a
second economic resource.

*This is clearly a change to a new economic policy* with standard risks
associated with that.  Will that induce an Economic Change Event (see def
last email)?  *Unlikely*, due to slow rollout pace.


5.5.  Problem:  Current SW mining algorithm needs improvement

Current SW block template maker does a reasonable job, but makes some naive
assumptions about the fee market across an entire extended block.  This is
a mismatch with the economic reality (just described).

5.6.   Problem:  New, under-analyzed attack surfaces

Less significant and fundamental but still worth noting.

This is not a fundamental SW problem, but simply standard complexity risk
factors:  splitting the signatures away from transactions, and creating a
new apparently-unsigned version of the transaction opens the possibility of
some network attacks which cause some clients to degrade down from extended
block to core block mode temporarily.

There is a chance of a failure mode that fools older clients into thinking
fraudulent data is valid (judgement: unlikely vis hashpower but not
impossible)

6. Conclusions and recommendations

It seems unlikely that SW provides scaling in the short term, and SW
introduces new economics complexities.

A "short term bump" hard fork block size increase addresses economic and
ecosystem risks that SW does not.

Bump + SW should proceed in parallel, independent tracks, as orthogonal
issues.


7. Appendix - Other SW comments

Hard forks provide much stronger validation, and ensure the network
operates at a fully trustless level.

SW hard fork is preferred, versus soft fork.  Soft forking SW places a huge
amount of trust on miners to validate transaction signatures, versus the
rest of the network, as the network slowly upgrades to newer clients.

An SW hard fork could also add several zero-filled placeholders in a merkle
tree for future use.

[BitUsher]

A summary of the scalability consensus status-

Peter Todd appears to be one of the developers which is fine with staying with 1 MB blocks.

https://www.reddit.com/r/Bitcoin/comments/3x34wt/in_a_66b_economy_it_is_criminal_to_let_the/cy15xbn

While some core developers-(sipa) appear to want to simply maintain or follow the will of the community without forcing anything through, and miners want leadership and a clear path they can rally behind.

In one sense I can empathize with Pieter as he doesn't want to give developers too much power or set any precedents that reflect they should be responsible for economic changes, in another sense I can understand with Gavin/Hearns/and their supporters frustration when no "benevolent dictator" is leading the course and driving a decision through. The miners are naturally humble enough from indication at the scalability conference to want some leadership and direction from the developers as well so are waiting on guidance.

There needs to be some manner to efficiently determine " extreme widespread acceptance" as the miner vote only encompasses one segment of our ecosystem. Or perhaps if one of the proposed BIPs that is introduced has a better set of tradeoffs than everyone will just rally behind it without too much disagreement like segwit.

There also appears to be a disagreement between developers between how quickly a soft fork vs a hard fork can be deployed. Matt Corallo suggests that it will take 1.5-2.5 years while garzik suggests it can roll out quicker than the segwit soft fork.

Either way, there may be a need to for trustless off the chain solutions using CLTV in the event of potentially negative effects from a Fee market event.

[BitUsher]

https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-clever-hack-could-significantly-increase-bitcoin-s-potential-1450553618
Good explanation of segwit

[johnyj]

In fact, the possibility of carrying out such a soft fork to change bitcoin's architecture without being rejected by old nodes revealed a fundamental security problem for bitcoin that needs to be addressed: You can even increase the total amount of coins in a similar way, because the old nodes can not see new coins, only new nodes can see

Soft Fork to Increase the 21M Limit?

Of course the money supply limit is prohibited from being changed, but there could be other changes which users do not fully understand its dangerous potential today. Now I understand why Satoshi said it will either worth nothing or a lot, there are just so many uncertainties on the road ahead which can wipe out this ecosystem altogether overnight

But this is bad, bitcoin is trust-less since all the trust is placed on this network and mathematics. I think at least we should make a system that is trust-backward-compatible, e.g. any aspects that affects trust should continuously strengthen the trust, not weaken it

For example, the changes I think are trust-backward-compatible: Any change that increase the security of the system; Any change that increase the mining decentralization (encourage more and more private miners, p2pool for example); Any change that increase the communication and understanding of different actors in the ecosystem

[bambou]

Seems the forkers just can't get enough of their governance illiteracy, rolling out the heavy artillery after the XT debacle, soft or hard forking for every little feature that make their business plan irrelevant.

Such time and energy spent in lame attempts at highjacking bitcoin from within the inside. Banksters and corporatists trying to preserve their privilege. Almost makes you sorry for them. But not.

[AtheistAKASaneBrain]

https://www.youtube.com/watch?v=NOYNZB5BCHM

Peter Wuille: Segregated witness and its impact on scalability at SF Meetup with more time for questions and clarifications.

I would love to listen to this since the latest lecture was very limited in time as there was a bunch of other speakers in queue, but I just can't stand having to hear a voice from only one of my headphones...

Is there a way to make the sound mono? It's not that hard to do it before you upload it, so much for tech geniuses that fail to duplicate the left audio channel into the right one before uploading

First world problems. Just sayin'.

You could always just short the left hot to the right hot. An adapter could be soldered up in five minutes tops, and that would include the time spent rooting around for the soldering iron. Or go ghetto and slice into the leads, twisting the wires together.

^(partially) in jest.

That's pretty crazy to be honest. How I solved it: Get a Firefox plugin that allows you to download videos, open it up in a video editor and make the audio track mono (there are free editors that can do this). Render it and voila, you have your headphone ready video.

[johnyj]

imagine you have a pair of pants(fullnode) and in the pockets(chain) you carry receipts for all your spending..
your girlfriend(segwit) loves wearing skinny jeans hates filling her pockets up.. she now wants you to keep the transaction part of the receipt in your left pocket and the part with the shops logo of the receipt in your right pocket.. the pants still weight the same as the total paper equals the same amount but she wants you to only think about the left pocket. and although you pretend the right pocket doesnt exist, you know its still weighing you down..

I like this analogy, it is a good representation of SW: Because currently there is a limitation on size of your left pocket on this pants (1MB), and it is not easy to change the size of this pocket (Difficult to reach consensus, the pants might be too heavy etc... ), so the solution is to cut the receipts in half and put the other half in another newly made pocket (SW data)

I'm still evaluating the security consequence of the new architecture on full nodes under SW. Is there a 100% sure way to prove a specific set of SW data belongs to a specific block? I think nodes still needs to go through every transaction to verify both the block and SW

This is also a "kick the can down the road" approach, provide one time increase of block capacity, while made large change to bitcoin's architecture, so the question is: Is it really worth the effort comparing with simply raise the block size to 2MB?

[jbreher]

I'm still evaluating the security consequence of the new architecture on full nodes ...

I'm still evaluating what type of user will want to run a medium-weight client - which seems to have none of the security of a full node, while still requiring about half the storage and bandwidth thereof. Is there really space in the market in between a full node and an SPV client? Maybe if the demands were 10%. But at half, I kinda doubt it. Who is that user?

[marcus_of_augustus]

I'm still evaluating the security consequence of the new architecture on full nodes ...

I'm still evaluating what type of user will want to run a medium-weight client - which seems to have none of the security of a full node, while still requiring about half the storage and bandwidth thereof. Is there really space in the market in between a full node and an SPV client? Maybe if the demands were 10%. But at half, I kinda doubt it. Who is that user?

With SW the fraud proofs required to bring SPV security up to 'almost as good as' fullnodes will finally be available. Look for 'Alerts' in the Nakamoto white paper.

[jbreher]

I'm still evaluating the security consequence of the new architecture on full nodes ...

I'm still evaluating what type of user will want to run a medium-weight client - which seems to have none of the security of a full node, while still requiring about half the storage and bandwidth thereof. Is there really space in the market in between a full node and an SPV client? Maybe if the demands were 10%. But at half, I kinda doubt it. Who is that user?

With SW the fraud proofs required to bring SPV security up to 'almost as good as' fullnodes will finally be available. Look for 'Alerts' in the Nakamoto white paper.

Trusting others to provide 'proof of fraud' is still trusting others.

[BitUsher]

Trusting others to provide 'proof of fraud' is still trusting others.

You are correct , we should have a healthy amount of full nodes distributed across the world that SPV clients with Fraud proofs can depend upon. Hopefully, we can work together to reverse node centralization and create incentives beyond "security" that increase full node count.

Any thoughts or ideas to incentivize full nodes besides - https://bitnodes.21.co/nodes/incentive/ which only gives nodes a very small chance weekly to win 10 USD? This is nice but clearly not enough. ~1/100 chance of winning 10 usd in a year.

[RoadTrain]

Trusting others to provide 'proof of fraud' is still trusting others.

Still that's a lot better than current headers-only SPV design and gives more freedom designing lite wallets.

[jbreher]

Trusting others to provide 'proof of fraud' is still trusting others.

Still that's a lot better than current headers-only SPV design

I guess I'm missing it. Seems to me that needing to trust others is needing to trust others. How is this an improvement?

[BitUsher]

I guess I'm missing it. Seems to me that needing to trust others is needing to trust others. How is this an improvement?

SPV nodes with Fraud proofs raise the standard and allow for fraud alerts and limited auditing with SPV lite nodes that currently don't have these capabilities. As long as having these fraud proofs doesn't incentivize us to drop full nodes than security will be improved within the ecosystem. The SPV client isn't directly dependent upon one full node but can audit many full nodes with a fraud proof.

Further reading in different proposals -
https://www.reddit.com/r/bitcoin_devlist/duplicates/3vzm35/why_sharding_the_blockchain_is_difficult_peter/
https://gist.github.com/justusranvier/451616fa4697b5f25f60

Your point is still valid in our need to have more full nodes as well.

[jbreher]

SPV nodes with Fraud proofs raise the standard and allow for fraud alerts and limited auditing with SPV lite nodes that currently don't have these capabilities.

OK. I'm just not seeing what type of user would switch from an SPV client to a SegWit 'medium-weight' client. Especially when the SegWit 'medium-weight' client makes not only on the same order of magnitude, but around half as much, demands on their system as does a full node.

Your point is still valid in our need to have more full nodes as well.

Nothing in SegWit seems to address this.

[BitUsher]

OK. I'm just not seeing what type of user would switch from an SPV client to a SegWit 'medium-weight' client. Especially when the SegWit 'medium-weight' client makes not only on the same order of magnitude, but around half as much, demands on their system as does a full node.

Within separated signatures (I'm going to start calling the upgrade SepSig, as segwit is misleading and a horrible name*) there is an incentive structure to lower tx fees and encourage adoption with a discount . This might not even be necessary as most users simply accept and download the update which will upgrade them automatically to "medium weight" SPV client.

Nothing in SegWit seems to address this.

Agreed, that is out of separated signatures scope. We need other solutions to address this problem as bitnodes lottery clearly isn't enough and centralization will get worse when SepSig allows for the blocksize capacity to increase from 1.8-4x in capacity. I have been thinking long and hard about various solutions and am testing things now. My guess is various "off the chain" solutions to encourage full nodes might be good enough.


* "segregated" has negative connotations and "witness" usually refers to probabilistic proof in which signatures aren't.

Edit- Developers rallying behind SepSig and Gregory Maxwell's scaling roadmap:
https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

BTCC skeptical but appears to give 3 months or room to see rollout before hard forking
https://twitter.com/Excellion/status/679066301168418816

[BitUsher]

http://blog.oleganza.com/post/135710722553/how-segregated-witness-is-not-the-same-as-bumping


How segregated witness is not the same as bumping block size limit

[hdbuck]

Trusting others to provide 'proof of fraud' is still trusting others.

Still that's a lot better than current headers-only SPV design

I guess I'm missing it. Seems to me that needing to trust others is needing to trust others. How is this an improvement?

the irony: "trust others" to provide "proof of fraud"





bitcoin is trust.