Bitcoin Unlimited doesn't fix quadratic hashing

[anonymoustroll420]

So recently I decided to look into Bitcoin Unlimited's fix to quadratic hashing. I decided to do this because, segwit doesn't fix quadratic hashing for legacy addresses, making it unsafe to increase the base blocksize, the only safe way it can be increased in the future is with extension blocks, and I wanted to see how BU had fixed this for legacy addresses.

The issue is that it's possible to craft a 1MB transaction that takes much much longer to validate than 10x 0.1MB txes, 30 seconds in fact. A 2MB transaction takes 10 minutes to validate with current hardware. This would mean that 2MB "attack blocks" would prevent nodes from ever being able to catch up with the chain.

The way segwit fixes this is that a 1MB segwit transaction takes the same amount of time to validate as 10x 0.1MB txes. Problem solved.

BU's fix to the quadratic hashing problem is that the maximum size of a tx is limited to 1MB. This would mean that a 2MB attack block would take 2x30secs (60 secs) to validate, rather than 10 minutes.
However with a 20MB attack block, it would take 10 minutes to validate and nodes will never be able to catch up. So eventually when BU blocksizelimit grows to 20MB, attack blocks will be able to DDoS the entire network permanently, and probably cause all kinds of chain splits too.

The BU devs are hoping that the blocksize won't increase faster than moore's law. They have also proposed "parallel block validation" to help, as this will speed up block validation by validating two blocks at the same time. This means that they actually expect that the situation will occur where a new block is found while the rest of the network is still validating the old. To make it even worse, "parallel block validation" only exists as a forum post, there is no formal proposal, no benchmarks and no code, so they don't even have any idea how much, if at all, this will help.

So what have the devs proposed to try and fix this?

https://bitco.in/forum/threads/buip037-hardfork-segwit.1591/

Yup. They want to hardfork segwit into BU in the future!

The other thing that got me thinking is, what happens in the future when things like smart contracts are common and BU approaches the 1MB transactionsize limit they have added. There will be people complaining about high fees for 1MB txes from having to split them up, and that their 1MB txes are not making it into the blocks. I foresee another huge debate over this limit just like the blocksize  

[1714485862]

1714485862

[franky1]

**BU & CORE **/blob/release/src/consensus/consensus.h

Code:

BLOCKSTREAM_CORE_MAX_BLOCK_SIGOPS = BLOCKSTREAM_CORE_MAX_BLOCK_SIZE/50;

**BU & CORE **/blob/release/src/policy/policy.h

Code:

static const unsigned int MAX_STANDARD_TX_SIGOPS = BLOCKSTREAM_CORE_MAX_BLOCK_SIGOPS/5;

by doing the blocksize/50/5 maths for MAX_STANDARD_TX_SIGOPS.. ends up as

core v0.12 MAX_STANDARD_TX_SIGOPS=4000 1mb base
core v0.14 MAX_STANDARD_TX_SIGOPS=16000 (1mb base, 4 weight) meaning 16kops, even when native keys are still locked to the 1mb limit

BitUnlim v0.12 MAX_STANDARD_TX_SIGOPS=4000 1mb base
BitUnlim v0.12 MAX_STANDARD_TX_SIGOPS=16000 4mb base (still spammy but atleast the base block is bigger.)

this is done because core have already proclaimed the limit..


however.

bitcoin unlimited did add a little extra nugget that core did not.. they would prevent certain tx's getting relayed that could become quadratically spammy
https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/release/src/policy/policy.h

Code:

static const unsigned int MAX_P2SH_SIGOPS = 15;
/** The maximum number of sigops we're willing to relay/mine in a single tx */

i think that ALL implementations 'should' just do
MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50; //this adjusts to allow more tx's as the blocksize increases
MAX_STANDARD_TX_SIGOPS=2000; //this never changes. no matter what the blocksize becomes.


making sure that tx's never get a chance to be quadratically spammy, but allows more leaner/cleaner tx's in as blocksizes grow

[anonymoustroll420]

Aren't those limits only enforced by miners? meaning if a miner mined a block that contained a tx over the sigops limit, nodes will still see it as a valid block and try validate it.

Anyway even if thats not the case, it still has the problem. You can still do 4x 1MB txes and cause a 2min validation time with a 4MB base block.

The easy solution is segwit's address format which scales linear instead of quadratic, so we don't need sigop limits or anything like that, it addresses the root of the problem and fixes it. Seems like even BU devs agree on that.

[franky1]

Aren't those limits only enforced by miners? meaning if a miner mined a block that contained a tx over the sigops limit, nodes will still see it as a valid block and try validate it.

Anyway even if thats not the case, it still has the problem. You can still do 4x 1MB txes and cause a 2min validation time with a 4MB base block.

The easy solution is segwit's address format which scales linear instead of quadratic, so we don't need sigop limits or anything like that, it addresses the root of the problem and fixes it. Seems like even BU devs agree on that.

your maths on timings are not quite right.
EG

based on QUADRATICS (sigops not bytes)
a 4k sigops ~10 seconds
meaning 5 tx's to hit the blocksigop limit= 50seconds validation time

a 16k sigops under 8 minutes
meaning 5 tx's to hit the blocksigop limit= 32minutes validation time.
yep even i facepalmed that.

however if all implementations just allowed 2k sigops no matter what the size was.
2k= ~0.1 second.

so say the blocksigop limit was 20k(1mb) it would take 20tx,s not 5tx's. and the time would be under 2 seconds
so say the blocksigop limit was 80k(4mb) it would take 80tx,s not 5tx's. and the time would be under 8 seconds

which is much better than 32 minutes that core have imposed.

[ebliever]

The BU devs are hoping that the blocksize won't increase faster than moore's law.

Note that Moore's Law died a long time ago. I estimate the last doubling took about 8 years (2009 to 2017), not 18 months as stated in Moore's Law. With the industry roadmaps I've seen through ~2021, it's apparent there will not be another doubling of speed or storage capacity or anything in that time frame. Doubtless there will continue to be refinements in processor speed, efficiency, cost and storage and so forth, but unless and until completely new breakthroughs occur, it is imperative that we be more conservative in our estimates of future speed/capacity.

It will be lovely if things do improve at a faster rate, but planning for it and then having it not happen will lead to a worse mess than we have now.

[jonald_fyookball]

Flextrans (which is bundled with Bitcoin Classic btw) solves mallaebility and quadratic hashing ,
arguably better than segwit.

[-ck]

The quadratic hashing problem is the elephant in the room. The solutions proposed by BU are not solutions at all. Parallel block validation is nice enough but doesn't change the massive CPU and memory workload that happens when a massive sigop block hits that the node still needs to do. It's bad enough for fast hardware, but on slower lesser hardware, it can even trigger an out of memory issue. Limiting the size of transactions as a "solution" is a very restrictive approach, and as you said doesn't change the fact that multiple 1MB transactions would still be extremely expensive. Additionally, citing Moore's law as a requirement for it to not be a problem is absurd given we fell off the curve of Moore's law almost a decade ago and are now proceeding at about 1/4 the rate Moore predicted - it's also likely to get even slower than that.

Hand waving by BU shills without actual solutions to this particular problem has gotten beyond a joke. The fact that they see segwit as a real fix for it speaks volumes for what segwit actually fixes and goes a long way towards dispelling the nonsense that segwit is the enemy and the reason BU exists. Turning the argument around and saying that segwit as a hard fork is fine while as a soft fork is not is truly absurd. The level of moronic arguments here is off the scale... Even Moore didn't predict that the Moron level would grow at such a rate.

[anonymoustroll420]

Note that Moore's Law died a long time ago. I estimate the last doubling took about 8 years (2009 to 2017), not 18 months as stated in Moore's Law. With the industry roadmaps I've seen through ~2021, it's apparent there will not be another doubling of speed or storage capacity or anything in that time frame. Doubtless there will continue to be refinements in processor speed, efficiency, cost and storage and so forth, but unless and until completely new breakthroughs occur, it is imperative that we be more conservative in our estimates of future speed/capacity.

It will be lovely if things do improve at a faster rate, but planning for it and then having it not happen will lead to a worse mess than we have now.

I know. I say this to people and nobody ever believes me. Intel haven't been able to make microprocessors smaller than 14nm for a long time. We've reached the limits of silicon. Every new processor simply has more cores and other tech like new instruction sets to do specific tasks more efficiently.

[Killerpotleaf]

In a perfect world we'd get EC for blocksize + Core's segwit for mall&quad fix and everyone would be equally discontent.

[Killerpotleaf]

Flextrans (which is bundled with Bitcoin Classic btw) solves mallaebility and quadratic hashing ,
arguably better than segwit.

right, Flextrans is an interesting proposal that come up few months back.
i'm on the fence between Flextrans  or  HF-segwit for the wanted malleability and quadratic hashing fixes for BU.
altho I have not completely given up on the idea of a simpler SF for segwit, but there Appears to be some drawback with doing it soft as OP mentioned... form what i see BU community is unwilling to let these disadvantages slip though simply for the sake of SF'ing

[franky1]

The fact that they see segwit as a real fix

but its not..

only those people who use segwit keys are disarmed from quadratic spamming . but native key users are not.
thus spammers can just stick to native keys and spam the base block ..

thats why keeping a tight grip on txsigop limits is still needed as a ultimate solution FOR EVERYONE native or segwit key users

[anonymoustroll420]

but its not..

only those people who use segwit keys are disarmed from quadratic spamming . but native key users are not.
thus spammers can just stick to native kys and spam the base block ..

thats why keeping a tight grip on txsigop limits is still needed as a ultimate solution FOR EVERYONE native or segwit key users

Native keys can spam away at their 1MB block all they want. Segwit keys can take advantage of the extension blocks.

Or you could do what the one BU dev proposed and go full out hardfork segwit and block native keys and force everyone over to segwit keys and increase the base block as much as you want, but blocking native keys is a real dirty solution.

[-ck]

Or you could do what the one BU dev proposed and go full out hardfork segwit and block native keys and switch everyone over to segwit keys and increase the base block as much as you want, but blocking native keys is a real dirty solution.

LOL blocking native keys worth 16 million bitcoin in a 20 billion dollar industry is a great way to make bitcoin worth... zero.

[franky1]

Or you could do what the one BU dev proposed and go full out hardfork segwit and block native keys and switch everyone over to segwit keys and increase the base block as much as you want, but blocking native keys is a real dirty solution.

LOL blocking native keys worth 16 million bitcoin in a 20 billion dollar industry is a great way to make bitcoin worth... zero.

fully agree with CK. he beat me to that..
blocking native keys .. i facepalmed when i read that from anonymoustroll420
lol

and if anonymoustroll420 thinks segwit can just 'convert' everyones funds over to segwit with a magic wand.. well another facepalm is needed

its far far easier to just have txsigop limit at sat well under 4000 forever.. none of this txsigops upscaling with blocksize crap that actually makes quadratic spamming worse not better

[Killerpotleaf]

but its not..

only those people who use segwit keys are disarmed from quadratic spamming . but native key users are not.
thus spammers can just stick to native kys and spam the base block ..

thats why keeping a tight grip on txsigop limits is still needed as a ultimate solution FOR EVERYONE native or segwit key users

Native keys can spam away at their 1MB block all they want. Segwit keys can take advantage of the extension blocks.

Or you could do what the one BU dev proposed and go full out hardfork segwit and block native keys and switch everyone over to segwit keys and increase the base block as much as you want, but blocking native keys is a real dirty solution.

dirty isn't the right word.

code wize, HF is cleaner by definition, its just very shitty that it forces the upgrade.

I wonder if a sorta Soft & Hard fork would be possible, in that it would initially be soft, but once 98% of nodes are upgraded ( like ~1-2years out?? ) the softness is dropped and it become hardforked in, at which point its no biggy. best of both worlds?

[anonymoustroll420]

fully agree with CK. he beat me to that..
blocking native keys .. i facepalmed when i read that from anonymoustroll
lol

It's not me proposing that! thats what one BU dev proposed and you bet I facepalmed hard when I read it, though they have proposed some sort of conversion system for legacy utxo that generates some giant tx script to achieve this.

https://bitco.in/forum/threads/buip037-hardfork-segwit.1591/

It's still blocking keys as from what I understand, you'll only be able to convert over and not use native keys as much as you want.

[franky1]

as for the hard vs soft..

a 1 merkle hard is cleaner than a 2 merkle soft. for things like no need for the tier network of upstream filters because all implementations would need to upgrade and thus no need to 'strip' blocksor need of a 2 merkle to allow stripping.
that way the 4mb weight does become the 4mb base. for everyone to take advantage of native or segwit keypair

but the txsigoplimit still needs to be kept down for the sake of native key abusers

[Killerpotleaf]

can someone explain what is meant by "native key"

you mean people who choose to stick with the current/old TX format, in the context of SF only?   right?

[anonymoustroll420]

can someone explain what is meant by "native key"

you mean people who choose to stick with the current/old TX format, in the context of SF only?   right?

Yeah, old Bitcoin addresses.

Segwit addresses look like this: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

Don't complain! atleast luke-jr didn't push for "tonal addresses"

[franky1]

can someone explain what is meant by "native key"

you mean people who choose to stick with the current/old TX format, in the context of SF only?   right?

yep
some people use the term 'legacy' which also refers to standard/current/old keys
but legacy is more about inheritance after death..(real world definition... not bitcoin buzzword definition)

i prefer using native (like real word definition: the natives [indians] who existed prior to the invasions of newcomers)