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.

dont forget the mightyduck child actor turned fund syphoner brock.
once he joined.. it was game over for the BF

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 trainwreck wants to halt developmnt and the have core set up as the regulator to stop anyone else from development..


and he doesnt think thats centralising the project as a FIAT. and only allow the coins to be openly distributed (via contracted LN services that require counterparty signing (banks))

....
45 pages of failed attempts to try nashifying people.. just to attempt to make people(wrongly) think that centralising bitcoin into a controlled centralist currency is good?

seriously!!

looks like brain washing to me
'if i throw economists quotes at a crowd 800 times people will think they need to be controlled by economics and code that becomes closed off and regulated by core.. rather than grow and be revolutionary open code currency beyond the mindset of FIAT

ok guys.

after the 20 minutes of you playing with double your allotment of coins..

..
think passed the selfish greed of the 20 minutes of swapping the coins.

now genuinely think. which will keep bitcoin utility alive and which is just empty promises that only achieve something if you dance around for months

choose what version you prefer based on the actual long term abilities it would bring EVERYONE. not just the few

you do know real consensus is about the nodes..

you do nore core actually avoided that and intentionally chose to give pools the only vote. which nodes officially cannot veto
think about that for a while.

dont jump back to defend core.

think about who gave the pools the voting power.

imagine it the other way. nodes first and pools not allowed to vote until nodes reached X% first

consensus works

the problem is. CORE BYPASSED consensus and INTENTIONALLY only gave pools the vote. rather than nodes then pools.

it done neither successfully, just pretended the majority of members funds were being used for those purposes while they syphoned alot out while doing the minimum

the BF
was originally envisioned to be a place where people can get info. collaborate on projects, organise meetups social events and also fund dev teams.

it was hoped they would have got into going to help governments, legal agencies understand bitcoin better, and ensure governments didnt get too heavy handed with bureaucracy of regulating the fiat<->btc exchanges..

bitcoin itself is not in any countries/government jurisdiction.

but people are.
and businesses using bitcoin could be regulated. especially ones also handling FIAT. such as exchanges. so although you cant regulate bitcoin. businesses working at the edges between bitcoin and fiat can be played around with by governments.

the BF was not intented to ever "regulate" bitcoin or control bitcoin but be pretty much be the noticeboard of bitcoin information.

but they just milked the members dry and walked away.

this is your mis understanding
the 20k limit (old v0.12) is the BLOCK LIMIT for sigops
the 4000 is the TRANSACTION limit
meaning a malicious spammer can make 5 TX of 4,000 sigops in v0.12 without and FILL THE BLOCKS sigop limit (no more tx's allowed)

the 80k limit (v0.14) is the BLOCK LIMIT for sigops
the 16000 is the TRANSACTION limit
meaning a malicious spammer can make 5 TX of 16,000 sigops in v0.12 without and FILL THE BLOCK sigop limit (no more tx's allowed)

as for your link - https://github.com/bitcoin/bitcoin/pull/8438

meaning they acknowledge they are allowing transactions to be more quadratically used to attack.

they simply think that its not a problem. but lets say in the future. things move forward. if they then made it 32000sigops per tx. and 160,000 per block. still thats 5 tx per block and also because a native malicious user will do it .. the TIME to process 5tx of 32,000 compared to last years 5tx of 4000 will impact...

---

the solution is yes increase BLOCK sigop limits. but dont increase TX sigop limits. keep it low 16,000 maybe but preferably 4000 as a constant barrier against native key malicious quadratic creators.
meaning if it was 80,000 a malicious user has to make 20 tx to fill the blocks 80,000 limit. instead of just 5..
and because its only 4000X20 instead of 16,000X5 the validation time is improved
but they havnt

admit there is a 2 tiered system. not the word twisting

i used 0.12 as an example of how many quadratics were permissible prior to segwit
and
i used 0.14 as an example of how many quadratics were permissible post segwit
prior: 4000
post: 16000

but in actual fact it is not v0.14 =4000 prior segwit its actually still 16,000 prior segwit (for pools using these uptodate versions EG 0.14 today)
check the code

something we can agree on.. needing segwit nodes as the 'upstream filters' (gmaxwell own buzzword) is bad for security. plus its not "backward compatible"

i prefer the term backward trimmed(trimmable), or backwards 'filtered' (using gmaxwells word) to make it clearer old nodes are not getting full validatable blockdata
not a perfect term. but atleast its slightly more clearer of what segwit is "offering" compared to the half truths and half promises and word twisting to offset giving a real answer.

you can by filling the baseblock.

EG
a block based on v:0.12 fills the 1mb block with sigop tx's totallying 4000 sigops per tx
a block based on v:0.14 fills the 1mb block with sigop tx's totallying 16000 sigops per tx

edit: here is the clincher justdoing 5 tx's uses up the blocks max tx count.. no one else can be added

READ THE CODE. not the sales pitch by blockstreamers on reddit

nope.

only real defense is keep limit per tx down........................ or blindly think malicious people will move to segwit keys to disarm themselves so everyone is using segwit keys

sigop attack
v0.12 had a 4000 sigop per tx limit (read the code)
v0.14 had a 16000 sigop per tx limit (read the code)

so now check the code.
https://github.com/bitcoin/bitcoin/tree/0.14/src
core 0.14: MAX_BLOCK_SIGOPS_COST = 80000;
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
meaning
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = 16000

https://github.com/bitcoin/bitcoin/tree/0.12/src
core 0.12: MAX_BLOCK_SIZE = 1000000;
core 0.12: MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
meaning
core 0.12: MAX_BLOCK_SIGOPS = 20000
core 0.12: MAX_STANDARD_TX_SIGOPS = MAX_BLOCK_SIGOPS/5;
meaning
core 0.12: MAX_STANDARD_TX_SIGOPS = 4000;
nothing stops a native tx from sigops spamming, you can only control how much spam is allowed

blockstream just thinks that people using segwit keys is enough defense they have not realised native users will stick to native keys

lol segwit doesnt solve it!!

even after segwit activates native key users are not disarmed.
segwit only offers to disable people who voluntarily use segwit keys to perform quadratics by not having the quadratics problem in a segwit key tx signing.

it does not take the quadratics opportunity away from native key users.

reducing or keeping tx sigops limit at or below 16,000 sigops per block no matter what the blocksize is. ensures quadratic spammers cannot spam large sigop quadratic tx's
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
core 0.14: MAX_BLOCK_SIGOPS_COST = 80000;
meaning
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = 16000

core 0.12: MAX_BLOCK_SIZE = 1000000;
core 0.12: MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
meaning
core 0.12: MAX_BLOCK_SIGOPS = 20000
core 0.12: MAX_STANDARD_TX_SIGOPS = MAX_BLOCK_SIGOPS/5;
meaning
core 0.12: MAX_STANDARD_TX_SIGOPS = 4000;

segwit actually allowed increasing tx sigops limit since v0.12 from 4000 to 16000 . while thinking that people will all be using segwit keys will be enough defense.. they have not thought about native users taking advantage.

oh and please dont instantly reply, untill you read the code.
read the code dont just reply "wrong because blockstream are kings"


edit: after reading lauda's instant reply below.. i actually pasted in and done the maths for him from cores own code...
lauda: read the code.

if you want a private conversation between 2 people then go to Private message with them


even core deemed 8mb network safe but decided 4mb super safe.. go ask your buddies.
as for how...

are you forgetting the example of dynamics . i even drew you a picture to keep your concentration span open.

what you need to understand by having the limits is that the NODES flag what they are happy with and POOLS work below that.
meaning it wont get out of control of what general nodes can cope with. because the nodes are flagging it.

oh and i remember rusty russel (blockstream) had some stats of 8mb being fine. so try not to proclaim that 8mb is evil as its your gangs own agreement that 8mb is fine as a upper limit, but a preference for less as a lower limit

then stop throwing speculations of things like 20mb blocks... or ur gangs other fake doomsdays of "gigabytes by midnight" "visa by tomorrow"

as thats speculative predictions of the future.

stick to rational REAL abilities now

8mb upper limit and 2mb lower (dynamic) limit.

that gives a while to reassess the 8mb over time.
rather that waiting and halting growth for years due to fears of 20mb blocks.

much like in 1996(in the days of 56k and 4gb hard drive) shouting
dont make Call of Duty:MW in the future an online multiplayer download 'coz 60gb download and 1mb/s bandwidth'..

in short w wont have 20mb blocks tonight. so lets NOT stop dynamic blocks starting at 2mb this year. purely with the '20mb blocks by midnight' doomsday rhetoric..
...when the reality is years away