Bitcoin Unlimited doesn't fix quadratic hashing

[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?

Yeah, old Bitcoin addresses.

Segwit addresses look like this: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

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

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

[1714486948]

1714486948

[1714486948]

1714486948

[1714486948]

1714486948

[1714486948]

1714486948

[1714486948]

1714486948

[1714486948]

1714486948

[jonald_fyookball]

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

 I'm lost

[anonymoustroll420]

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

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

even multisig uses version 1.

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

"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.

[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?

Yeah, old Bitcoin addresses.

Segwit addresses look like this: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

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

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)

[anonymoustroll420]

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.

[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

 I'm lost

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)

[-ck]

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.

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.

[franky1]

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

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

even multisig uses version 1.

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

[Killerpotleaf]

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.

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 "

[anonymoustroll420]

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

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.

i think, BU proposes similar kind of change along side hf-segwit

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.

[digaran]

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 .

[anonymoustroll420]

I think devs want to force Satoshi's hands into moving his coins from old 'native' addresses to multisig addresses

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.

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

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.

[franky1]

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 .

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.

[The One]

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

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

[jonald_fyookball]

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

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.

[AngryDwarf]

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

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.

[franky1]

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

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

[BillyBobZorton]

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.

[The One]

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

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

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

[The One]

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.

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.