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

BitUsher

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.

jbreher

legendary

Activity: 3080

Merit: 1688

lose: unfind ... loose: untight

Quote from: BitcoinNewsMagazine on December 30, 2015, 06:25:33 PM

Quote from: jbreher on December 30, 2015, 06:05:17 PM

Quote from: BitcoinNewsMagazine on December 30, 2015, 04:56:21 PM

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

legendary

Activity: 994

Merit: 1035

Quote from: jbreher on December 30, 2015, 06:05:17 PM

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.

Quote from: jbreher on December 30, 2015, 06:05:17 PM

- 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

Quote from: jbreher on December 30, 2015, 06:05:17 PM

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

Correct.

BitcoinNewsMagazine

legendary

Activity: 1806

Merit: 1164

Quote from: jbreher on December 30, 2015, 06:05:17 PM

Quote from: BitcoinNewsMagazine on December 30, 2015, 04:56:21 PM

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.

jbreher

legendary

Activity: 3080

Merit: 1688

lose: unfind ... loose: untight

Quote from: BitcoinNewsMagazine on December 30, 2015, 04:56:21 PM

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

legendary

Activity: 1806

Merit: 1164

Quote from: jbreher on December 30, 2015, 03:57:13 PM

Quote from: BitUsher on December 30, 2015, 07:46:48 AM

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.

jbreher

legendary

Activity: 3080

Merit: 1688

lose: unfind ... loose: untight

Quote from: BitUsher on December 30, 2015, 07:46:48 AM

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

BitUsher

legendary

Activity: 994

Merit: 1035

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)

Lauda

legendary

Activity: 2674

Merit: 3000

Terminated.

Quote from: hdbuck on December 28, 2015, 05:28:42 PM

Is it VERified?

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

hdbuck

legendary

Activity: 1260

Merit: 1002

Quote from: Lauda on December 28, 2015, 05:02:01 PM

Quote from: bambou on December 28, 2015, 01:08:29 PM

"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

legendary

Activity: 2674

Merit: 3000

Terminated.

Quote from: bambou on December 28, 2015, 01:08:29 PM

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

bambou

sr. member

Activity: 346

Merit: 250

"Segwit" is "Suicide".

johnyj

legendary

Activity: 1988

Merit: 1012

Beyond Imagination

Quote from: jbreher on December 23, 2015, 11:31:20 PM

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

Bitcoin Billionaire

newbie

Activity: 19

Merit: 0

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

jbreher

legendary

Activity: 3080

Merit: 1688

lose: unfind ... loose: untight

Quote from: johnyj on December 23, 2015, 08:15:25 PM

Quote from: jbreher on December 23, 2015, 08:03:14 PM

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

johnyj

legendary

Activity: 1988

Merit: 1012

Beyond Imagination

Quote from: BitUsher on December 23, 2015, 07:32:13 PM

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?

BitUsher

legendary

Activity: 994

Merit: 1035

Quote from: johnyj on December 23, 2015, 08:51:59 PM

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.

johnyj

legendary

Activity: 1988

Merit: 1012

Beyond Imagination

Quote from: BitUsher on December 23, 2015, 08:42:17 PM

Quote from: johnyj on December 23, 2015, 08:19:20 PM

Quote from: marcus_of_augustus on December 23, 2015, 07:38:12 PM

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

BitUsher

legendary

Activity: 994

Merit: 1035

Quote from: johnyj on December 23, 2015, 08:19:20 PM

Quote from: marcus_of_augustus on December 23, 2015, 07:38:12 PM

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.

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