Bitcoin Forum

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  ;D

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

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

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

---

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

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.

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.

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

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.

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.

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

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

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

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.

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.. :D
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

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?

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.

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

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" :D

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)

i thought they were suppose to begin 3.. meaning accounting for the extended LN addressing. it would be BC3 not BC1

the BC part of the address is all because rusty russel wants BC at the front so that address formats for LN can do things like offchain swaps with other altcoins easier, where i feel that litecoin will have LC3 for instance...

---

and yea years ago when i seen Luke want tonal, i facepalmed that

 I'm lost

Doesn't look like it:
http://bitcoin.sipa.be/bech32/demo/demo.html

even multisig uses version 1.


"But it only takes 5 minutes to learn!"

He even put tonal into the gentoo Bitcoin package, along with Satoshi Dice tx relay blocking. But it is gentoo, all software on that has insane defaults, people expect it to be crazy.

oh no, prefixed with bc1 ??? no no no this doesn't look right anymore.

i guess its unavoidable to add a new prefix to addresses in the context of a soft fork, since users nodes need to know if they are sending to segwit address VS  native address

with HF segwit, it should be possible to not add this ugly prefix. ( i wonder if its just us die-hard-bitcoiners that would notice the prefix changed)

I think you still need to change the format because of the old Bitcoin addresses.

Good thing about the new format is it's all lower case. Plus has a bunch of error correcting stuff, so if you type in a couple letters wrong it can correct it for you.

in short, by going soft. blockstream nodes need to strip away the segwit witnesses to make the block appear valid to old nodes downstream. so need to completely separate the signature away.. thus needing 2 merkles to keep them linked without being linked..just t be able to cut the witness away..

however if everyone was upgrading by going hard, then there is no need to have to play the strip data down to meet old block game of a tier network, because everyone would be on the same playing field.

so the witness can just be appended to a tx and not need a second merkle thus the base block limit becomes irrelevant and the 4mb weight because the new block limit with no more 1mb (old native node rule)

Actually I know the person who blocked gentoo from defaulting to luke's fork and insisted it be a user choice to enable his religion driven censoring fork instead of core bitcoin. Most users were not aware it was even doing that, assuming it was just some high performance version of the bitcoin daemon.

that was march 2016.. before segwit or LN realy gained any traction at code level.. things have moved on from then(obviously)
i know in last 6 months they were thinking of segwit keys being 3. and the LN guys wanting BC: at the front to help them out for their altcoin inter-playability..

poeple actually type out these addresses?!?! ( i might do that once in a full moon to get into a paper wallet )

i think, BU proposes similar kind of change along side hf-segwit
https://bitco.in/forum/threads/buip045-unified-addresses-format-for-buip037.1725/
I commented first with reasons why i dont like it. i think these are legitimate reasons...
of course devs are like " oh thats a silly argument "

Sometimes, I've had to do it before. The error correcting also helps when scanning QR codes, which have error correcting themselves but is not as good and can go screwy.


It's kind of frustrating that implementations are rewriting others stuff from scratch. I mean just steal the others code and modify it to your needs, it's open source, no need to waste time rewriting everything from scratch, plus it's better for everyone as it means that code will be better tested and both implementations can share patches.

I think devs want to force Satoshi's hands into moving his coins from old 'native' addresses to multisig addresses, anyways this debate more seems like a power play you know when 2 males measure their dicks to see which one is bigger, I apologize for being rude but honestly I'm saying what the wider picture looks like when I stand far away and see the whole thing.

When I first came to this forum I thought the development of bitcoin is a consensus in GitHub as they over GitHub wont let any changes takes place until a number of votes from many developers been cast in consensus, and even thought MIT university has a board dedicated to developing bitcoin I mean damn what a douche I was :D :D :D.

He won't have to do that with core's softfork segwit, he can transact in the 1MB block if he wants. With the BU devs HF segwit proposal he'd have to convert it over before he could use it.


That is how Core development works. Though one developer can veto a change. I'm not sure thats the best way to do it, it is a safe enough way to go but blocks innovation, honestly they should just copy every other open source project and go with the "dictator" approach. If the "dictator" goes evil we can switch away to another implementation, there are competing implementations. It's ultimately the users who control the code they run on their machines, there isn't some kind of "forced auto-update" mechanism.

BU supporters want some kind of "decentralized" development. Ultimately there has to be some sort of centralization when it comes to developing a specific implementation. Unless you want anyone to be able to commit whatever code they want in and have that put in the binaries. Someone should do that and call it anarchocoin, I'm sure it'll turn out fine.

yp it does not need 400 contributor votes to add a line of code. it just need the maintainer and a couple main guys to acknowledge it.

i know for sure that the devs dont read every single line of code. because i have seen many cases where the main regular contributors end up asking each other about lines X even afters its in a release candidate.

for instance gmax amended a few of the tx fee things which led to the fee rise happen more easily, but question them about it and they cant remember how or what happened or by who

they just blindly trusted that gmax coded something and let it pass.
hense why i think a few of them are now blaming pools. when it was actually core code caused simply because not everyone knows the whole code, and each person just concentrates on a certain area.

Why can't everyone move to segwit within say 2 weeks to 1 month. Is that not possible?

its possible.  but then businesses/wallets/etc running legacy code would all need to upgrade.

Not enough block space. It would require around 2 months of blockspace to move all native UTXO's to segwit keys, assuming no other tx's take place. That's assuming everybody would do that.

lets say the base block was completely empty. no one doing their regular business..
to move 46m utxo's could take 3 months+

and thats if EVERYONE was to change over.. the issue is.. malicious people that want to quadratic spam.. wont.

so even if 99.99% of people did change across.. only 1 person making a dozen tx's could screw with quadratics.
especially if they now have 16k ops to mess with instead of 4k. meaning expect lots of validation delays and also
alot of mempool issues of the innocent people moving across

Not only does any blocksize increase need segwit to fix quadratic hashing so BU needs it, but BU adds the problem of having to raise the maximum amount of 21 million coins 120 years from now so EC doesn't explode.

BU doesn't work, no one wants to raise the 21 million limit, not now, not in 120 years.

Oh great. Segwit somewhat looking far worse now. It only has benefit if people uses it. Hardly going to increase capacity then isn't.

https://bitcointalk.org/index.php?topic=1871610.msg18613989#msg18613989

Perhaps i stick to my original decision. Nothing in the last month of reading and debating is making me lean in any directions.

stop lying.  obvious shill is obvious.