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

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

No.

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.

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

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

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.

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.

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

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.

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.

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

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

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)

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.

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

lauda.

take no offense by this..(think of this as a genuine question, requiring your critical thinking cap to be worn)
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.
..
because thats how im reading your thought process on your definition of DoS attack


have you thought about this as a DoS attack:
those limits which you think are defending validation time attack of solved blocks. can actually be used as an attack by filling a block

EG if a block in v.12 only allowed 20ksigops for the block and 4k sigops per tx... it only takes 5 tx to fill a block. and not let anything else in.
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.

thus a native key user can with just 5 tx stop other tx's getting in. and thus all segwit promises cant be met.
no boost to blocksize as no segwit tx's adding to the block.

rmember im not talking about delay in validation times of propagation after block is solved. im just talking about filling blocks (mempool attack leaving everyone waiting)

---

so knowing that the segwit 'activation' does nothing to disarm native keys.
meaning
blocks can stay at 1mb. (either with as little as 5 native(sigopsbloatfill) or thousands of natives(databloatfill))
malleation and sigops are not disarmed.

---

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

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