Topic: Bitcoin Unlimited doesn't fix quadratic hashing - page 2. (Read 1905 times)

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

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)

Yeah, old Bitcoin addresses.

Segwit addresses look like this: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

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

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?

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

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.

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?

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

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

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.

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

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

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

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.

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.

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

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.

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.

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.

**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