Current SegWit code does not fix O(n^2)

[jbreher]

Like the title says. The current iteration of The SegWit Omnibus Changeset does not fix the O(n^2) hashing problem. At least according to Peter Todd:

We haven’t actually fixed the O(n²) signature hashing problem yet, although we’re fairly confident that we can, and there’s a open pull-req implementing the cache that we need.

- https://petertodd.org/2016/segwit-consensus-critical-code-review

Not necessarily an insurmountable problem. And I suppose PT might be... err... uninformed. However, it certainly puts some specious claims (e.g., April; e.g. safe scaling) into perspective. One wonders what other major claimed features of The Omnibus SegWit Changeset remain technical pauperism.

Might be worth a discussion, donchathink?

[1714041728]

1714041728

[crazywack]

Wow all the hype and it's not going to help clean up the mem pool right away, I'm I getting that right?

[RealBitcoin]

1 THING:  DONT RUSH THEM.

Whatever happens, dont rush the devs. They are working hard and they dont need pressure on their heads.

If you rush them, they might fuck it up, and we dont want that to happen. The network can easily work well 5-6 more months, so no need to rush things.

They should take their time, think ,research, develop, and test many times the proposals. Then we can implement it.

[crazywack]

1 THING:  DONT RUSH THEM.

Whatever happens, dont rush the devs. They are working hard and they dont need pressure on their heads.

If you rush them, they might fuck it up, and we dont want that to happen.

Or do we?! cheap coins.

I'm kidding. I just thought that with all the press in the BTC space of its implementation going live, we would actualy see it working and cleaning up he pool. That's all, just disappointing it's not ganna work out that way right now.

[Lauda]

Wow all the hype and it's not going to help clean up the mem pool right away, I'm I getting that right?

No, you're not getting this right. This has nothing to do with "help clean up the mempool".

Like the title says. The current iteration of The SegWit Omnibus Changeset does not fix the O(n^2) hashing problem. At least according to Peter Todd:

We haven’t actually fixed the O(n²) signature hashing problem yet, although we’re fairly confident that we can, and there’s a open pull-req implementing the cache that we need.

While I must admit that I was unaware of it at first, I don't see this as something problematic especially if you consider the last part. I've read some parts of that review last night and it seems very well done.

Might be worth a discussion, donchathink?

Maybe. However, don't be surprise if you see a lot of 'unusual' accounts joining in to bash Segwit.

I'm kidding. I just thought that with all the press in the BTC space of its implementation going live, we would actualy see it working and cleaning up he pool. That's all, just disappointing it's not ganna work out that way right now.

Again, you have no idea what you're talking about. There's no reason for it "not to work out that way right now".

[Foxpup]

So what? SegWit only makes linear verification time possible, it doesn't necessarily implement it. And the reason there's no rush to implement it is because scaling is not the purpose of SegWit! How many times do we have to explain that before people get it? It seems like people have the expectation that when SegWit is "implemented" (a word which seemingly nobody can agree on a definition) blocks will stop "being full" and transaction fees will drop to almost nothing so they can buy their coffee on the blockchain. These people then get inexplicably angry every time someone tries to tell them that this is not actually the case.

[jbreher]

So what? SegWit only makes linear verification time possible, it doesn't necessarily implement it.

I realize that SegWit -- in and of itself -- does not do anything about the quadratic verification time. That is but one reason I refer to it as The SegWit Omnibus Changeset - there is considerably more *stuff* in it than SegWit. Indeed, my impression is that SegWit itself has absolutely nothing whatsoever to do with the alleviation of quadratic verification time.

And the reason there's no rush to implement it is because scaling is not the purpose of SegWit! How many times do we have to explain that before people get it?

Well, you might be saying that, but the message that is coming through loud and clear is 'we don't need a simple increase in maxblocksize because SegWit!'

Well, that and 'The SegWit Omnibus Changeset is superior to other solutions from a scaling perspective because other solutions merely limit quadratic hashing time, rather than fixing it!'

It seems like people have the expectation that when SegWit is "implemented" (a word which seemingly nobody can agree on a definition) blocks will stop "being full" and transaction fees will drop to almost nothing so they can buy their coffee on the blockchain. These people then get inexplicably angry every time someone tries to tell them that this is not actually the case.

Maybe if the company line wasn't always changing, we'd latch onto it.

But whatevs...

You _are_ aware that The SegWit Omnibus Changeset is being sold as a solution to the block congestion problem, right?

[Foxpup]

You _are_ aware that The SegWit Omnibus Changeset is being sold as a solution to the block congestion problem, right?

How can I be aware? I've actually never heard the phrase "The SegWit Omnibus Changeset" before your post, and a Google search for that phrase doesn't turn up much either. You say it's "more stuff" than SegWit, but what exactly is it? Who's selling it? Is anyone buying it? You need to define your terms.

[Carlton Banks]

OP makes out like he's the one reporting the issue. He's not.

None of the coup-attempt Developers noticed this, even though they were most incentivised to do so. lol

It's pretty sad really, jbreher, all you can do is dance around like a child sticking your tongue out. Why not do something productive with your "life"?

[Lauda]

None of the coup-attempt Developers noticed this, even though they were most incentivised to do so. lol

I'd like to hear their failed attempts at gather excuses as to why they didn't notice it. Either they have failed to recognize this, or they haven't looked at it at all (which tells us more than we need to know).

It's pretty sad really, jbreher, all you can do is dance around like a child sticking your tongue out. Why not do something productive with your "life"?

Doesn't working count as being productive?

[Carlton Banks]

Doesn't working count as being productive?

Depends on whether your work involves building or destroying. jbreher is hell-bent on destroying a productive (not to mention innovative) system, so he's no better than those sociopathic bullies that bat food out of a stranger's hand and then walk off down the street laughing at their hilarious "joke".

[mayax]

this discussion belongs to Development & Technical Discussion. it's useless for 99% from those who are using BTC.

[jbreher]

You _are_ aware that The SegWit Omnibus Changeset is being sold as a solution to the block congestion problem, right?

How can I be aware? I've actually never heard the phrase "The SegWit Omnibus Changeset" before your post, and a Google search for that phrase doesn't turn up much either. You say it's "more stuff" than SegWit, but what exactly is it? Who's selling it? Is anyone buying it? You need to define your terms.

All the features bundled together as part of the impending SegWit release.

[jbreher]

jbreher is hell-bent on destroying a productive (not to mention innovative) system

Well, no. Destroying a productive system (assuming you are referring to Bitcoin) would be directly against my financial interests. Accordingly, I am working towards its success.

[jbreher]

this discussion belongs to Development & Technical Discussion. it's useless for 99% from those who are using BTC.

I disagree. The amount of traffic dedicated to the subject shows that transaction volume is a topic of near-universal interest. In light of the fact that the O(n^2) hashing issue bears directly upon the ability of certain transactions to impair transaction volume, it would be a topic perfectly suitable for general discussion.

[gmaxwell]

Weird thread.

Fixing the O(n^2) issue required a change in how signature hashes are computed so that the work of hashing the transaction can be reused between multiple signatures.  Then it requires making use of that change van an optimization to actually reuse the computation.  (This optimization has earned the cheeky name, hashcache).

The segwit consensus rules do the former.  The segwit PR to Bitcoin core didn't include the latter optimization, because it isn't wasn't for the system to work (assuming we don't care that it can be slow), and packing everything in at once complicates review and increases risk. The correctness of the optimization is easier to verify as a change by itself, and the correctness of segwit was easier to verify without the optimization in the way.

But the code to actually make use of the format change is the queue as well https://github.com/bitcoin/bitcoin/pull/8259  (which was open 5 days ago, but the code for it was written January 19th).  This optimization is also part of the btcd implementation and has been since they originally wrote it.

Considering this, the presentation of this as some kind of flaw or surprising find make it look to me that people are desperate to find something wrong.  I suppose that is good: more eyes may reduce the risk of unbound actual issues. Hopefully the next time it won't be over a missing optimization which we've had an implementation of for six months.

[franky1]

Weird thread.

Fixing the O(n^2) issue required a change in how signature hashes are computed so that the work of hashing the transaction can be reused between multiple signatures.  Then it requires making use of that change van an optimization to actually reuse the computation.  (This optimization has earned the cheeky name, hashcache).

The segwit consensus rules do the former.  The segwit PR to Bitcoin core didn't include the latter optimization, because it isn't wasn't for the system to work (assuming we don't care that it can be slow), and packing everything in at once complicates review and increases risk. The correctness of the optimization is easier to verify as a change by itself, and the correctness of segwit was easier to verify without the optimization in the way.

But the code to actually make use of the format change is the queue as well https://github.com/bitcoin/bitcoin/pull/8259  (which was open 5 days ago, but the code for it was written [January 19th).  This optimization is also part of the btcd implementation and has been since they originally wrote it.

Considering this, the presentation of this as some kind of flaw or surprising find make it look to me that people are desperate to find something wrong.  I suppose that is good: more eyes may reduce the risk of unbound actual issues. Hopefully the next time it won't be over a missing optimization which we've had an implementation of for six months.

lets get to the short and curlies of it.
lets not talk about the segnet(altcoin/sandbox) implementation. or the testnet(altcoin/sandbox) implementation.. i truly hate people back-dating availability by including the time its played around with in sandboxes of non bitcoin data

but in regards to a publicly downloading implementation that handles real bitcoin data on the real live bitcoin network.
will the optimization be included in the next release. (just needs to be pulled) or are you saying it wont be because it "complicates review and increases risk"

im asking respectfully. will the next version of bitcoin-core including segwit be "optimized" or will it be another release at a later date that the "optimization" is added.

all i ask is a simple reply without waffle. even something like "next release" or "at a later date after initial bitcoin core segwit release" would suffice

[Carlton Banks]

Frankys, do something. Something real, in the real world. Anything, to prove that you're not just some computer science back-seat driver. You just have no clue about this stuff, and seriously expect to waste everyone's time with your rambling moronic over-wrought tl;dr posts.

[gmaxwell]

lets get to the short and curlies of it.

Can you explain to me what the change does and what significance it has?

I think that would do more to get the details, like making it clear that your "concern" is motivated by harassment rather than actual concern.

but in regards to a publicly downloading implementation that handles real bitcoin data on the real live bitcoin network.
will the optimization be included in the next release.

I expect it to be included in any release with segwit activated.

[jbreher]

Considering this, the presentation of this as some kind of flaw or surprising find make it look to me that people are desperate to find something wrong. I

Hello Gregory. I was not trying to insinuate anything was wrong, per se. We layfolk are not party to the detailed development plans, and that is OK. However, with several Core supporters deriding alternative node implementations for limiting the effects of the O(n^2) issue, rather than solving it head on -- specifically with the claim that The SegWit Omnibus Changeset addresses this in a better manner -- it is somewhat of a surprise to learn that this feature is not yet integrated. At what point is this feature scheduled for integration? How long has it been in test, and in what environment?