Pages:
Author

Topic: Segregated witness - The solution to Scalability (short term)? - page 2. (Read 23163 times)

legendary
Activity: 3038
Merit: 1660
lose: unfind ... loose: untight
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"

<>

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.
legendary
Activity: 994
Merit: 1035
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.
legendary
Activity: 3038
Merit: 1660
lose: unfind ... loose: untight
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.)
legendary
Activity: 994
Merit: 1035
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.

legendary
Activity: 1806
Merit: 1164
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.
legendary
Activity: 3038
Merit: 1660
lose: unfind ... loose: untight
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?
legendary
Activity: 1806
Merit: 1164
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:

Quote
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.
legendary
Activity: 3038
Merit: 1660
lose: unfind ... loose: untight
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:

Quote
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"?
legendary
Activity: 994
Merit: 1035
legendary
Activity: 2674
Merit: 2965
Terminated.
legendary
Activity: 1260
Merit: 1002
"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?
legendary
Activity: 2674
Merit: 2965
Terminated.
"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.
sr. member
Activity: 346
Merit: 250
"Segwit" is "Suicide".

legendary
Activity: 1988
Merit: 1012
Beyond Imagination


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  Wink
newbie
Activity: 19
Merit: 0
Any concept being propagated by Mr. Andresen should be ignored, he's made his intentions very clear.
legendary
Activity: 3038
Merit: 1660
lose: unfind ... loose: untight

To be clear, is this re-serialization totaling 1.25 GB something that the _current_ Bitcoin Core does when faced with this aberrant block, or are we comparing apples to oranges?

Got a link to the presentation?

F2Pool did this on their node, the video is from the September scaling bitcoin conference,

 https://www.youtube.com/watch?v=TgjrS-BPWDQ

https://scalingbitcoin.org/montreal2015/presentations/Day2/11-Friedenbach-scaling-bitcoin.pdf

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'.
legendary
Activity: 1988
Merit: 1012
Beyond Imagination

Satoshi did build a lot of extensibility and op codes within the original design so bitcoin could grow, evolve, and use layers like the lightning network. While I do respect Satoshi we shouldn't worship him and treat everything he has done as sacrosanct as he has made many mistakes. What is more important is us respecting the investment contract we have all agreed to over the years about respecting the core fundamentals that makes bitcoin unique. Satoshi can always sign a PGP key and jump and and make a comment if he has some serious concerns as well.  


It is not worship, more like respect the intellectual property of the original designer

What makes bitcoin valuable? The idea tested by time. You could have more refined design than bitcoin like Ethereum, but without the test of time, any code is just a piece of open source software which worth almost nothing. Overtime, many people little by little build up the trust and value of bitcoin, obviously its architecture is part of this value

Imagine that if you redesign an altcoin with SW architecture, would it get any value? Almost none of course. However, if you put this design as a soft fork of bitcoin, trying to slowly seek its way into the bitcoin ecosystem and become part of it. This kind of action is very alike virus or trojan, highly malicious. If your design is really genius and excellent, you should ask for major approval and implement it as a hard fork. Being a soft fork just feels shady

If anything that scales bitcoin can be accepted, I'm sure we will have Cisco/Ericsson/VISA bitcoin architecture that can scale much better than SW, anyway their engineers are dealing with traffic of millions of nodes, bitcoin level of petty traffic would make them laugh, their engineering team will totally replace bitcoin core devs, right?
legendary
Activity: 994
Merit: 1035
It is easy to predict from each individual user point of view: If I'm currently doing one transaction per day and it cost 0.0001 btc for fee, if the transaction capacity gets full, I will combine 2 transactions and do one transaction every 2 days and pay 0.0002 btc for fee

If everyone is doing this, then the number of transactions will be cut by half, all the blocks become half-empty

I am more concerned with the automated scripts that verify payments , full mempools crashing nodes, and new adopters being confused when they don't receive a confirmation. Users like us who pay attention to specifics and know workarounds like paying a higher fee or combining txs may become the minority in a "fee market event"

All I'm suggesting is that there are many valid viewpoints and we should prepare for these concerns with tested backup plans. Hopefully a massive swell in adoption can also be directed to use off the chain solutions like coinbase/circle as well to temporarily buffer any negative impact a fee market event creates.

There isn't a single solution that will allow us to grow but many combined solutions that must be implemented. Bitcoin is fragile and cannot scale well right now until we make many changes.
legendary
Activity: 1988
Merit: 1012
Beyond Imagination
Bitcoin itself is a huge "Economic Change Event" in the wider context of the existing monetary systems (i think this is where Jeff probably got the idea from) ... fees coming online for bitcoin TX is a storm in a teacup by comparison.

During July and September coinwallet.eu attack, all the blocks were full for at least a week, but you just need to raise the fee to 0.0005 btc to get a confirmation in 10 minutes, how is that a storm in a teacup?

Concerns of a Fee Market Event may be valid. The coinwallet.eu attack would only briefly fill blocks during a few moment here and there and never created sustained filled blocks for a long period of time. We have no idea what will happen if a there is sustained Fee event --

This is why Garzik defines such fee event as

FE - "Fee Event", the condition where main chain MSG_BLOCK is 95+% to hard
limit for 7 or more days in row, "blocks generally full"

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

Bitcoin has never seen this before and we don't know what will happen.


It is easy to predict from each individual user point of view: If I'm currently doing one transaction per day and it cost 0.0001 btc for fee, if the transaction capacity gets full, I will combine 2 transactions and do one transaction every 2 days and pay 0.0002 btc for fee

If everyone is doing this, then the number of transactions will be cut by half, all the blocks become half-empty

In old times, when banks are closed during weekends, people will do their withdraw early and they withdraw much more to deal with the transaction capacity stop, and they won't give up using banks




legendary
Activity: 994
Merit: 1035
Bitcoin itself is a huge "Economic Change Event" in the wider context of the existing monetary systems (i think this is where Jeff probably got the idea from) ... fees coming online for bitcoin TX is a storm in a teacup by comparison.

During July and September coinwallet.eu attack, all the blocks were full for at least a week, but you just need to raise the fee to 0.0005 btc to get a confirmation in 10 minutes, how is that a storm in a teacup?

Concerns of a Fee Market Event may be valid. The coinwallet.eu attack would only briefly fill blocks during a few moment here and there and never created sustained filled blocks for a long period of time. https://www.quandl.com/data/BCHAIN/AVBLS

We have no idea what will happen if a there is sustained Fee event --

This is why Garzik defines such fee event as

FE - "Fee Event", the condition where main chain MSG_BLOCK is 95+% to hard
limit for 7 or more days in row, "blocks generally full"

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

Bitcoin has never seen this before and we don't know what will happen.


Pages:
Jump to: