Topic: Last Time. In small words. Why 2MB impossible. Why Soft Fork. Why SegWit First.. - page 9. (Read 6499 times)

Can't fit that many sigops in a 1MB block.

It's interesting that 1MB is the biggest size you can have without it being quadratically spammy (over 10 minutes to validate). Satoshi picked a good limit.

come on CK. even you know segwit keys sit in the baseblock too. and if the baseblock has native quadratic spam of 5tx's of 16k sigops each.. thats about 40 minute validation delays. ven after sgwit activates.

cores hope/utopia is that everyone including malicious people will morally move funds to segwit keys. and then the utopian dream of everyone being disarmed 'could' be seen..
but

even you know native key use cant and wont get turned off after segwit activation. otherwise people cant spend their native utxo(16m+coins)
even you know those intentionally wanting to spam wont opt-in to move funds to segwit keys.. so its not solved

Why on earth did you start a thread trying to dispel the nonsense of the march of the full time anti-core propaganda trolls and not make the thread self-moderated, hence inciting the very same morons back to post here?

Op codes are data. You can only fit so many spammy op codes into a block. You cannot attack a 1MB block even if it was completely full of the spammiest OP codes. Sigop's limits are a new thing, we didn't have them before.


*sigh*

On their 1MB BLOCK, which cannot be used to craft a quadratically spammy tx that takes 10 minutes to validate. Sure, native key users can fill a block. They don't need quadratics to do that. Segwit keys can fill a block too. Anyone can fill a block if you got enough money to burn in tx fees and outbid everyone else.

1mb, 4mb is just data limit..
if there was only the 1mb limit. then quadratics could make a single tx of hundred thousand sigops taking HOURS to validate..

this is why there is the maxtxsigop limit.. to reduce quadratic risks.
in recent years it got added and put down to 4k sigop limit and 20k blocksigop limit. meaning quadratic spammers can no longer make a single tx of hundred thousand sigops. but at most 5x of 4000 sigops.. which calculates to 50seconds of validation time instead of hours

your also forgetting that native keys will still be functional even after segwit activation. so the attack still exists.
all sgwit key users are doing is disarming themselves from performing it. but people sticking with native keys can still perform it.
and as my other post mentions.. which most people dont realise is that segwit keys need to be in the base block too.. even if their ass is hanging out in their weight area.
its not like segwit key users are completely separated from native keys, just their ass (the sig/witness)

You keep saying this but it's just NOT TRUE.

This is why there is a 1MB base blocksize limit.

The old keys can spam away at their 1MB block all they want. The new keys which are 'disarmed' from quadratics can spam away at the 4MB total.

You cannot attack this way, no matter the sigop count, we could remove that limit and we probably should. Sigop limit's are only a bandaid.

You simply cannot craft a tx that takes 10 minutes to validate with only a 1MB block. And segwit isn't quadratically spammy, so 4MB is OK.

It's precisely why segwit+2MB HF was the dumbest proposal in the world. That would be quadratically attackable.

It's also one reason why BU sucks big time. They can't fix quadratics without a new address format like segwit. So they are using 'bandaids' like sigops and a 1MB transaction size limit to try solve it. None of it works, it's still quadratically spammy. When you explain this to the devs, they say that the miners would never attack the network. I beg to differ:
https://bitcointalksearch.org/topic/ghashio-and-double-spending-against-betcoin-dice-327767

The only long term plan they have to fix this is to hardfork in segwit at a later date: https://bitco.in/forum/threads/buip037-hardfork-segwit.1591/

this is where lauda misunderstands.

segwit transactions do not wholely sit in the weighted area separate and safe from native tx's. they sit in partly in the base block. along side native tx's where a segwit tx has its ass (the sig/witness) hanging in the extra weighted area..

now if 5 native quadratic spam tx's are in the base block.. nothing else gets in. not even segwit tx's .. in short its used up all the baseblock limits and makes that block take 40 minutes to validate.

Wow!!!

@Spartacusrex & Lauda

According to you Guys, BTC is really just a piece of shit.  

BTC can't support 2mb blocks, but there are Alts going as high as 10 MB per block, (without segwit).

BTC can't move to a faster block speed, but LTC runs at 4X faster blockspeed with zero problems, and other alts even faster.


So either you guys don't know what you are talking about and BTC is able to match the alts if the code is updated.
or
BTC is just an old clunker that should be left in the junkyard.


I'll let the reader decide which they want to believe.  


 

not fixed
because
core v0.12  buglet (quadratics) 4k tx limit (10 seconds buglet delay per tx) block limit 20k (ability to have 5tx of the the txsigop limit)
core v0.14  buglet (quadratics) 16k tx limit (8minutes seconds buglet delay per tx) block limit 80k (ability to have 5tx of the the txsigop limit)

the segwit 'activation' itself solves nothing.
even if 99.99% of people move funds to segwit keys to DISARM themselves from causing (your buzzword buglet) quadratics. 1 person can make just 5 quadratic transactions to use up all the sigop limits and cause 40minutes of validation delay instead of 50 seconds.

the solution is not segwit. the solution is maxtxsigops to remain at 4k (less than a couple years ago) or bring it down further... definetly not raise the limit to allow it to become more of a problem/ attack vector

Franky has a misleading understanding of Segwit, and jonald is a hired baboon. Franky1 will argue that this isn't fixed with SegWit, and he's partially right. The thing is (post Segwit):
1) You could use native transactions to abuse this quadratic validation time problem. However, you are not able to attack the network this way as using only native keys results in =< 1 MB block size.
2) This is fixed for Segwit keypairs and Segwit transactions as validation time is linear. Meaning, with Segwit transactions you can safely do >= 1 - 4 MB.

---

Pools can and will prioritize Segwit transactions over the native ones if an attacker tries to abuse this. It's a non issue.

You won't wake up if you're paid only to sleep.

Ok.

Jhonny's got 3 threads up about mean nasty Core and how they are destroying Bitcoin.

Here is my LAST attempt at explaining 'what is going on' rationally.

1) There is a 'buglet' in Bitcoin that means that you can construct a TXN that uses a lot of time to process / check. Let's not worry about what it is but agree that it exists. The larger the blocks the easier it is to construct this TXN, and IF we had 2MB blocks, right now, you could bring down the network. This issue is fixed with SeqWit. So Core thought, let's introduce SW first, THEN we can make the blocksize bigger. Safely.

2) Soft fork vs Hard-fork. The 'poison pill' Jhonny and Franky keep ranting about is actually because CORE thought that NOT forcing you to upgrade was a GOOD thing. This is a Soft Fork. It means if you don't upgrade - no problem. No Split. We all carry on as before, and all the clever SegWit shit will happen in a way that doesn't affect the old nodes. Safely.

3) Bigger Blocks would ALREADY be here IF we had just upgraded to segwit 6 fucking months ago. This ridiculous stalemate is what is causing this total cluster fuck of a situation.  Once we get SegWit.. oh mama.. ALL the clever things people have dreamed about can START to happen. AND Bigger Blocks!.. Safely.

..

If you are saying - NO! You Bast***ds! We want to jump ship to BU, which has a new consensus model, and software that crashes every 3 weeks, you are NOT acting SAFELY. Fact.

CORE are NOT your enemy.

.. Wake UP! (My New Chant..  ) .. before it's toooo late..