[POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) - page 9.

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: Carlton Banks on March 14, 2017, 03:40:32 AM

Let's see what happens when some form of UASF gains popularity with people that don't have all day long to sit around shit talking about this

The problem with that is, as Todd mentioned, that there is no safe & ready implementation in addition to the uncertainity of the safety of the idea itself. The concept is interesting though.

Quote from: Carlton Banks on March 14, 2017, 03:40:32 AM

You can all fuck off with your "2MB" compromise, which has taken less than 12 pages to warp itself into 12MB Roll Eyes

A potential maximum of 12 MB weighted in 5 years is much different from 12 MB right now. Even then, the weight ratio should be adjusted to lower the total maximum.

Quote

Lauda in particular, you should know better than this by now, which makes me question your intentions towards the whole issue to begin with

Stop attacking my character. I was always pro :Segwit -> proper HF. I've been saying this for a long time. The primary problem for me is the lack of a proper proposal (e.g. Luke-jr's is bad, emergent consensus is a disaster).

Carlton Banks

legendary

Activity: 3430

Merit: 3074

Quote from: mezzomix on March 14, 2017, 03:42:40 AM

I'm fine with segwit + 2MB.

Which is not what's being proposed

mezzomix

legendary

Activity: 2618

Merit: 1253

I'm fine with segwit + 2MB. I do not support transferring more control to miners by giving them a voting mechanism to decide about the future rules. Some of them currently show us their malicious behavior. We should not reward this by giving them more control.

Carlton Banks

legendary

Activity: 3430

Merit: 3074

Quote from: Searing on March 13, 2017, 07:41:30 PM

What I'm thinking is there will never be consensus.

Let's see what happens when some form of UASF gains popularity with people that don't have all day long to sit around shit talking about this

You can all fuck off with your "2MB" compromise, which has taken less than 12 pages to warp itself into 12MB Roll Eyes

Lauda in particular, you should know better than this by now, which makes me question your intentions towards the whole issue to begin with

I hope you all have sufficient understanding of what "fuck off" means

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: franky1 on March 13, 2017, 09:35:05 PM

EG SEGWIT
fill a baseblock with 1mb of native garbage and the other 3mb of weight are MEANINGLESS (100%native bloat=0% weight occupied)
you seem to forget that the weight is dependant on the base and what can get into the base to then utilise the weight.
segwit just doesnt give real capacity growth unless a few issues are sorted. which it cannot sort because it doesnt stop native attacks.

all it does is disarm segwit volunteers. but those segwit volunteers are still at the mercy of the 1mb base block and native key spammers.

I've already told you that you can easily prioritize Segwit transactions over native ones as a miner.

Quote from: franky1 on March 13, 2017, 09:35:05 PM

vs BU, classic, xt (and other real-block growth proposals)
2mb baseblock means it requires twice as much effort..

No. If the sigops limit remains the same, e.g. 20k, it doesn't matter even if the block size is something absurdly large. You just need to hit the sigops threshold.

franky1

legendary

Activity: 4270

Merit: 4534

Quote from: Lauda on March 13, 2017, 08:15:28 PM

Quote from: franky1 on March 13, 2017, 08:04:01 PM

this 'effective potential' can be inhibited(prevented) by atleast 5 attack vectors that can stop segwit ever getting any effective increase in tx counts

The SAME can be done with BTU. Roll Eyes

nope not the same.
segwit is still limited and dependant on the 1mb base block.
(by this i mean if no segwit key tx's get into the 1mb base.. the 3mb is empty)
Vs
BU,xt,classic, and and other dynamic proposals, grow beyond the 1mb base. meaning its not limited to 1mb thus requires more effort to spam.

EG SEGWIT
fill a baseblock with 1mb of native garbage and the other 3mb of weight are MEANINGLESS (100%native bloat=0% weight occupied)
you seem to forget that the weight is dependant on the base and what can get into the base to then utilise the weight.
segwit just doesnt give real capacity growth unless a few issues are sorted. which it cannot sort because it doesnt stop native attacks.

all it does is disarm segwit volunteers. but those segwit volunteers are still at the mercy of the 1mb base block and native key spammers.
its not like a berlin wall wher ALL segwit data sits in the 3mbweight. and all native sit in the base
segwit need to get into the base to then spread their legs into the weight.

vs BU, classic, xt (and other real-block growth proposals)
2mb baseblock means it requires twice as much effort..

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: Swimmer63 on March 13, 2017, 08:13:18 PM

Quote from: Lauda on March 13, 2017, 07:47:44 PM

Quote from: Searing on March 13, 2017, 07:41:30 PM

Seems like bitcoin core's strategy. Apathy rules. 1mb block is just dandy.

Bitcoin Core has already offered a solution with bigger block, i.e. Segwit. Apparently the market does not want a block size increase or pool owners (e.g. Jihan) are being severely lobbied into doing the opposite.

Stupid comments like this don't help with a compromise.

Apparently someone lacks a brain, and it ain't neither Searing nor I. Segwit is the compromise.

Quote from: franky1 on March 13, 2017, 08:04:01 PM

its not a native block increase!
its only a growth if people use segwit keys and only reaches potential amounts dependant on how much segwit key adoption there is.

-snip-

Take away your nonsense somewhere else. Segwit -> Big blocks. Writing long posts won't change that in any way or form.

Quote from: franky1 on March 13, 2017, 08:04:01 PM

this 'effective potential' can be inhibited(prevented) by atleast 5 attack vectors that can stop segwit ever getting any effective increase in tx counts

The SAME can be done with BTU. Roll Eyes

Swimmer63

legendary

Activity: 1593

Merit: 1004

Quote from: Lauda on March 13, 2017, 07:47:44 PM

Quote from: Searing on March 13, 2017, 07:41:30 PM

Seems like bitcoin core's strategy. Apathy rules. 1mb block is just dandy.

Bitcoin Core has already offered a solution with bigger block, i.e. Segwit. Apparently the market does not want a block size increase or pool owners (e.g. Jihan) are being severely lobbied into doing the opposite.

Stupid comments like this don't help with a compromise.

franky1

legendary

Activity: 4270

Merit: 4534

Quote from: Lauda on March 13, 2017, 07:47:44 PM

Quote from: Searing on March 13, 2017, 07:41:30 PM

Seems like bitcoin core's strategy. Apathy rules. 1mb block is just dandy.

Bitcoin Core has already offered a solution with bigger block, i.e. Segwit. Apparently the market does not want a block size increase or pool owners (e.g. Jihan) are being severely lobbied into doing the opposite.

its not a native block increase!
its only a growth if people use segwit keys and only reaches potential amounts dependant on how much segwit key adoption there is.

stop thinking just segwit activation causes native tx's to have 2mb..

you know this. you have admitted such in different posts/topics. so dont exaggerate it into a native base block increase, when its not.

again its only a 'effective size if X,Y,Z is achieved AFTER activation..
no promises no guarantee's.

this 'effective potential' can be inhibited(prevented) by atleast 5 attack vectors that can stop segwit ever getting any effective increase in tx counts

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: Searing on March 13, 2017, 07:41:30 PM

Seems like bitcoin core's strategy. Apathy rules. 1mb block is just dandy.

Bitcoin Core has already offered a solution with bigger block, i.e. Segwit. Apparently the market does not want a block size increase or pool owners (e.g. Jihan) are being severely lobbied into doing the opposite.

Searing

copper member

Activity: 2898

Merit: 1464

Clueless!

What I'm thinking is there will never be consensus. Anything offered will get say no more
Then 30% adoption due to fud. Thus bitcoin core is happy. They think of btc as a store of value
(Gold).

Thus stuck.

Other Alt coins will fill the consumer use niche imho.

Seems like bitcoin core's strategy. Apathy rules. 1mb block is just dandy.

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: hv_ on March 13, 2017, 04:34:01 PM

What makes this proposel different from BU if the max block size is defined in specific 'quant' sized jumps nodes / miners could vote for ? Such a quant could have the size of 0.2MB and would be added ( or removed ) if the voting reaches some 75% agreement.

The (auto) voting could be done in same manner as the difficulty is adjusted over a block number period.

This proposal wouldn't have the following issues:

Quote

BU has no miner threshold for activation
BU has no grace period to allow nodes to upgrade
BU has no checkpoint (AKA wipe-out protection), therefore users could lose funds
BU has no replay attack prevention

https://www.reddit.com/r/Bitcoin/comments/5z6d56/a_summary_of_bitcoin_unlimiteds_critical_problems/

hv_

legendary

Activity: 2520

Merit: 1055

Clean Code and Scale

Quote from: d5000 on March 13, 2017, 04:09:09 PM

Quote from: Lauda on March 12, 2017, 04:11:16 PM

The next questions are:
1) What exactly decides whether it goes up 10% or down?
2) Why that specific period? I think that once per retarget is too frequent; maybe once per month is better. Someone else may have more input on that.

D'accord to your second proposal, 2016 blocks may be a too small period.

Yes, there should be more input from advanced users. If this discussion here gets stalled, a new thread about the modified proposal in the Development/Technical Discussion section would be the way to go, I think - then I would also contact the autors (Garzik, Upal, DooMAD).

What makes this proposel different from BU if the max block size is defined in specific 'quant' sized jumps nodes / miners could vote for ? Such a quant could have the size of 0.2MB and would be added ( or removed ) if the voting reaches some 75% agreement.

The (auto) voting could be done in same manner as the difficulty is adjusted over a block number period.

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Quote from: Lauda on March 12, 2017, 04:11:16 PM

The next questions are:
1) What exactly decides whether it goes up 10% or down?
2) Why that specific period? I think that once per retarget is too frequent; maybe once per month is better. Someone else may have more input on that.

D'accord to your second proposal, 2016 blocks may be a too small period.

Yes, there should be more input from advanced users. If this discussion here gets stalled, a new thread about the modified proposal in the Development/Technical Discussion section would be the way to go, I think - then I would also contact the autors (Garzik, Upal, DooMAD).

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: d5000 on March 12, 2017, 04:03:16 PM

Oh, you were too fast to answer, I just had edited the post to clarify a bit Wink

Yeah, sometimes I can be quite fast.

Quote from: d5000 on March 12, 2017, 04:03:16 PM

I meant that for the first year (or for the first 6 months, if miners insist on it) the proposed voting mechanism would be "on ice" to be able to react to attacks, only Segwit with no modifications of the "base" size.

Okay so for the first year we only use Segwit and the size it brings on its own.

Quote from: d5000 on March 12, 2017, 04:03:16 PM

So the last proposal with correct terminology (I hope so Wink

) should be:

1) first year: only Segwit with the 1 MB base variable and 4 MB weight.
2) years 2-3: Voting mechanism for miners (10%+ or - per difficulty period) is enabled; upper bound base size is 2 MB
3) years 4-5: upper bound base size changes to 3 MB; maybe reduction of base-to-weight ratio, like you proposed.

This looks much better now. The next questions are:
1) What exactly decides whether it goes up 10% or down?
2) Why that specific period? I think that once per retarget is too frequent; maybe once per month is better. Someone else may have more input on that.

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Oh, you were too fast to answer, I just had edited the post to clarify a bit Wink

I meant that for the first year (or for the first 6 months, if miners insist on it) the proposed voting mechanism would be "on ice" to be able to react to attacks, only Segwit with no modifications of the "base" size. I think for one year these 2-4 MB should be enough.

So the last proposal with correct terminology (I hope so Wink

) should be:

1) first year: only Segwit with the 1 MB base variable and 4 MB weight.
2) years 2-3: Voting mechanism for miners (10%+ or - per difficulty period) is enabled; upper bound base size is 2 MB
3) years 4-5: upper bound base size changes to 3 MB; maybe reduction of base-to-weight ratio, like you proposed.

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: d5000 on March 12, 2017, 03:44:40 PM

Yes I took this into account, the ~3 MB estimation is based on estimations (like these from Core) that with the current transaction pattern the maximum block capacity is calculated to be 1,7-2,2 MB with Segwit. I first went for 2 MB, but as this already in extreme cases can mean 8 MB blocks (which aren't aceptable for many at this moment), I reduced it to 1,5 MB.

You're mistaken or aren't properly explaining yourself. Segwit as is, has 1 MB base, which can result with ~2.1 MB worth of transactions (with 100% Segwit TXs). However, this also has a potential maximum of creating 4 MB blocks (heavy multisignature usage). In your proposal, a 1.5 MB base has potential to fit ~3MB worth of transactions and a maximum of 6 MB blocks (heavy multisignature usage).

Quote from: d5000 on March 12, 2017, 03:44:40 PM

But for me, we can also modify the scale by:
1) first year, only Segwit + 1 MB upper bound (no modifications)

1 MB upper bound of what? The base size? It is best to elaborate as follows:
a) 1 MB base size variable.
b) 2 MB upper bound base size.
c) Weight variable from 4 MB to 8 MB depending on the above.

I think the base-to-weight ratio should possibly be reduced if the base were to grow. 8 MB potential would be too much.

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Quote from: Lauda on March 12, 2017, 01:55:50 PM

Quote from: d5000 on March 12, 2017, 11:51:04 AM

1) Segwit as first measure;
2) adopt DooMAD/Garzik/Upal proposal (10%+ or 10%- voting when conditions are met), modified by adding a "upper limit"
3) for the first year, a 1,5 MB upper base limit (equivalent to ~3 MB maximal "block unit" size, for now)
4) for years 2-5, a 3 MB upper base limit (equivalent to 6-12 MB [worst case] maximal "block unit" size)

It doesn't look like you entirely understand how the block size works after Segwit. It changes the block size into two parameters, base size and weight (currently 1:4).

Yes I took this into account, the ~3 MB estimation is based on estimations (like these from Core) that with the current transaction pattern the maximum block capacity is calculated to be 1,7-2,2 MB with Segwit. I first went for 2 MB, but as this already in extreme cases can mean 8 MB blocks (which aren't aceptable for many at this moment), I reduced it to 1,5 MB.

But for me, we can also modify the scale by:
1) first year, only Segwit + 1 MB max block size (no modifications)
2) years 2-3, Segwit + 2 MB upper bound (here the voting mechanism would start)
3) years 4-5, Segwit + 3 MB upper bound (absolute worst case with heavy multisig use would mean 12 MB blocks, but mostly about 6-10 MB)

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: Carlton Banks on March 12, 2017, 03:42:36 PM

You've changed your tune

Explain how Segwit makes "everything" worse

Without the additional steps, it requires a lower number of TXs to cause the 'issue' that you've specified in your own thread.

Carlton Banks

legendary

Activity: 3430

Merit: 3074

You've changed your tune

Explain how Segwit makes "everything" worse

Topic: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) - page 9. (Read 14376 times)