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

[Carlton Banks]

To summarize the last discussions: Would that be an acceptable base for a "real" BIP?

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)

all that coded into a single BIP/pull request, to make it attractive for "big blocker" miners to accept it.

(I hope the terminology is OK)

Nope. Entirely unacceptable, all of that will be abused in seven ways from Sunday

[1713437005]

1713437005

[1713437005]

1713437005

[1713437005]

1713437005

[franky1]

To summarize the last discussions: Would that be an acceptable base for a "real" BIP?

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)

all that coded into a single BIP/pull request, to make it attractive for "big blocker" miners to accept it.

(I hope the terminology is OK)

3 and 4.. = spoon feeding numbers by devs hard writing the limits and needing users to download new versions (if a dev team even rlease the limit).
if the last 2 years are anything to go by.. forget it.. 2 years SO FAR to debate just getting a 2mb REAL limit even when all devs admit 4-8 is safe so the 2015 2mb compromise was actually ok all along....
we cant keep having these "please dev release a version that has X" debates
and we cant even have users set limit and release to public in their own repo due to "its just a clone of core but not peer reviewed REKT it"

instead
each node could have a speedtest mechanism. it start-point is when it sees a new height block. its end-point is after it has validated and relayed it out.
then over a scale of 2016 blocks it combines the times to get a total score.(recalculated every 2016 blocks) that way it can flag its capability.
thn we can see what is capable

that way the network can know safe capable growth amounts without spoon feeding and 2 year debates.

then below the network limit (capability) upper level:
preference lower level:
also at GUI (options tab) and rpc-console(debug) level.. or even a downloadable .ini file patch USERS can change the settings themselves without needing to recompile each time their independant client. or having to wait for devs to spoonfeed it.
which is adjustable by consensus.

[AngryDwarf]

In my opinion segwit should be a hard fork. It's not safe or desirable as a soft fork.
A dynamic base block solution is required that doesn't use arbitrary growth settings or further future block size hard fork debates.
Miners aren't going to create gigantic blocks by midnight, it would be orphaned by the speed of their competitors.
Technology limitations will ultimately decide blocksize growth. Miners are not going to spend 10mins creating a block.
Let a natural market fee market develop between on-chain transactions and off-chain service providers.
The two need implementing at the same time in the same hard fork, or conflict of interest issues could re-occur.

[Lauda]

So what is the definition of weight, and how does this relate to data storage requirements?

You should research Segwit yourself. I don't plan on rewriting what is already written in a lot of articles. Use Google.

but are you thinking that a quadratic sigop attack is just about limiting sigops to not cause validation delays when a solved block is relayed.

No.

EG if a block in v.14 only allowed 80ksigops for the block and 16k sigops per tx... it only takes 5 tx to fill a block. and not let anything else in.

It is 80k sigops ONCE Segwit is activated. It is scaled with the 4 MB weight, so it comes down to the same thing as before Segwit.

thus a native key user can with just 5 tx stop other tx's getting in. and thus all segwit promises cant be met.

It is quite likely that transactions with such a high amount of sigops would be above 100kb; therefore, they'd not be relayed nor mined by any miner using Bitcoin Core (a non standard TX).

so effectively.. what does segwit actually offer that is a real feature that has real 100% guarantee promise

Miners can prioritize Segwit transactions (e.g. 20% vs. 80%). Simple solution.

https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179#.mt4mf9jjh

That's not what I was looking for. I wanted to know how you managed to extrapolate the conclusion that "most Segwit supporters" don't dispute that.

https://rusty.ozlabs.org/?p=522

This is inadequate data. I'd like to see worst case numbers for every block size (e.g. 1 MB, 2 MB, ... 8 MB). This could be nicely represented in a table.

2MB is an action that would "compromise" decentralization and therefore security. and it would be occurring as a result of political pressure rather than technical necessity.

Without adequate consensus (this being a economic super majority and 95% of the network), it does harm every part of the ecosystem.

[jbreher]

That isn't disputed by most SegWit supporters.

Source?

I think you are on the verge of understanding that issue.

I don't see why it is an issue. I see it as a non-issue, just as you see quadratic validation as a non issue.

I said The SegWit Omnibus Changeset destroys fungibility. I did not say it was an issue. You initially denied the fact that it does ... now you are backtracking to 'not an issue'. Perhaps you should actually think about your claims before you make them.

OK... sure. I'm quite certain you are unable to poke a hole in my scenario there. Why don't you try? Or even ... why don't you ping Harding with what I posted, and have him see if he can poke holes in it?

I just quickly went through it and saw your conclusion.

IOW, you are happy to wallow in your ignorance. ::sigh:: Oh well - it certainly would not be a first.

I'm not going to be a messenger between you and someone with clearly superior understanding. Find a way to contact him yourself.

I don't need to contact him. You are the one that appealed to his supposed authority. Which, if accurately relayed by you in both directions (which may or may not have been the case) displays an incomplete analysis if the scenario.

[franky1]

knowing that ultimately (due to not preventing native key use) segwits only real promise is a fee discount(for the segwit key volunteers)
causes fungibility issues between which tx types cause preference or not(sigop,malle armed+ expensive or disarmed +cheap)

where people will have preference over which type of funds they receive/they prefer to deal with, based on which keys are used.
eg native(starting 1) becomes nasty and segwit(starting 3) becomes 'good money' people will not want to risk funds coming from a 1address

where not only uses start having thier preference but pools do too. where by if you know ur dealing with funds coming from native key may end up taking longer to confirm, or rejected to never confirm if pools start ignoring native keys. etc

aswell as the things jbreher  mentioned

[Lauda]

To summarize the last discussions: Would that be an acceptable base for a "real" BIP?

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). If you use base size of 2 MB, you can get up to 4 MB worth of Segwit TXs or a maximum of 8 MB(!) in case of extreme multisignature usage. Your 'proposal' needs to be rewritten. A 'upper base limit of 1.5 MB' is actually equivalent to a maximum of 6 MB and not 3 MB.

Nope. Entirely unacceptable, all of that will be abused in seven ways from Sunday

I don't see how it could possibly be abused (size wise) if you add a maximum yearly growth. The consensus rules would dictate that it can't be increased more than that.

You initially denied the fact that it does ... now you are backtracking to 'not an issue'. Perhaps you should actually think about your claims before you make them.

I'm not backtracking on anything. This just shows open-mindedness, unlike what can be said for you and your kind. Money rules I guess.

IOW, you are happy to wallow in your ignorance. ::sigh:: Oh well - it certainly would not be a first.

Parallel validation is so useless that it isn't worth reading through its BIP. It's not about ignorance, it's about time efficiency.

I don't need to contact him. You are the one that appealed to his supposed authority.

I barely know who the person is. Stop using logical fallacies when you are clearly not adequately educated to properly do so.

[Carlton Banks]

Nope. Entirely unacceptable, all of that will be abused in seven ways from Sunday

I don't see how it could possibly be abused (size wise) if you add a maximum yearly growth. The consensus rules would dictate that it can't be increased more than that.

It can be seriously abused at Step 1 Lauda, the yearly maximums are a part of the steps subsequent to Step 1

[Lauda]

It can be seriously abused at Step 1 Lauda, the yearly maximums are a part of the steps subsequent to Step 1

Care to elaborate further on that with an example? I don't think we are on the same page.

[Carlton Banks]

https://bitcointalk.org/index.php?topic=1823233.0

[AliceWonderMiscreations]

2MB is an action that would "compromise" decentralization and therefore security. and it would be occurring as a result of political pressure rather than technical necessity.

that is not a compromise i am willing to make.

Do you have any scientific research to back this up?

Any centralization of mining is power cost, not block size.

[Lauda]

https://bitcointalk.org/index.php?topic=1823233.0

It is well known that you could attempt to manipulate it in order to fit a lower amount of TXs. However, I was not talking about this part. I was talking about the other steps. The increase of the 'base size' helps in cases where users (or malicious actors) attempt to use a lot of "native keys". I will respond in that thread as well.
I think the system is very hard to game if you set:
1) A lower bound (size which is the absolute minimum when determining the maximum block size).
2) An upper bound (size which is the absolute maximum when determining the maximum block size).
3) Maximum movements per period (up and down).
4) Maximum total growth per year.

However, it may be very hard to gain consensus as this would have a lot of newly 'chosen' parameters.

[Carlton Banks]

The steps come in an order, Lauda. The 1st step, bizarrely, comes first.

There's little point in talking about the subsequent steps, if the 1st step is a significant problem in it's own right

[Lauda]

The steps come in an order, Lauda. The 1st step, bizarrely, comes first.

There's little point in talking about the subsequent steps, if the 1st step is a significant problem in it's own right

So what is your point.. do Segwit and then nothing? That makes nothing better; it makes things actually worse.

[Carlton Banks]

You've changed your tune

Explain how Segwit makes "everything" worse

[Lauda]

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.

[d5000]

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]

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

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]

Oh, you were too fast to answer, I just had edited the post to clarify a bit 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 ) 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]

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

Yeah, sometimes I can be quite fast.

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.

So the last proposal with correct terminology (I hope so ) 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.