The Barry Silbert segwit2x agreement with >80% miner support.

[ComputerGenie]

...What are the relevant and material facts being ignored?...

I guess you're right, ad hom attacks claiming that every skilled dev in the entire world already works for Core and not one single qualified coder would ever work on a non-Core project (let alone ensure that a non-Core project was thoroughly tested) are 100% factually based. My bad.

[1713985044]

1713985044

[1713985044]

1713985044

[1713985044]

1713985044

[1713985044]

1713985044

[JayJuanGee]

...What are the relevant and material facts being ignored?...

I guess you're right, ad hom attacks claiming that every skilled dev in the entire world already works for Core and not one single qualified coder would ever work on a non-Core project (let alone ensure that a non-Core project was thoroughly tested) are 100% factually based. My bad.

Isn't that called a strawman attack?

You are creating an argument that no one made.

On the other hand, if there is already non-exclusive and open process in place through core procedures that have been working and evolving for nearly 8 years in which code is tested and vetted through a Core open process, and if non-core code goes live, but seems to have experienced a less open and less robust testing and vetting process (and maybe even a bit rushed process), along with spot checks of vulnerabilities, questionable usage of some discretionary code language and historical instances in which those non-core software implementations had caused crashing and even orphaning issues - then there could be a bit more confidence to run the tested and vetted code, no?  maybe even some economic incentives not to get orphaned or maybe some other vulnerability? or even some questions about the political significance of running some code that may have some non-vetted discretionary language?

[ComputerGenie]

...What are the relevant and material facts being ignored?...

I guess you're right, ad hom attacks claiming that every skilled dev in the entire world already works for Core and not one single qualified coder would ever work on a non-Core project (let alone ensure that a non-Core project was thoroughly tested) are 100% factually based. My bad.

Isn't that called a strawman attack?...

No.

You are creating an argument that no one made...

Actually, he did:

... It's only a matter of time they get exposed for being amateurs. Meanwhile Bitcoin Core will continue being the most robust and stable software...

You can't say that it's a strawman that no one made when the original base claim is exactly that. The base claim is that if it's not coded/tested by Core, then it's inferiorly made by "amateurs". There can't be a claim whereby those that aren't involved in  and/or part of Core are only "amateurs" without the included claim that all qualified non-"amateurs" (i.e., professionals) are already part of core. And why can't that be a claim, you might ask; because, English!

When you attempt strip away the validity of one pointing out the absurdity of the original base claim, especially when you attempt to incorrectly grasp the language being used, you fail at any attempt of even grasping what is being said on either side.

[JayJuanGee]

...What are the relevant and material facts being ignored?...

I guess you're right, ad hom attacks claiming that every skilled dev in the entire world already works for Core and not one single qualified coder would ever work on a non-Core project (let alone ensure that a non-Core project was thoroughly tested) are 100% factually based. My bad.

Isn't that called a strawman attack?...

No.

You are creating an argument that no one made...

Actually, he did:

... It's only a matter of time they get exposed for being amateurs. Meanwhile Bitcoin Core will continue being the most robust and stable software...

You can't say that it's a strawman that no one made when the original base claim is exactly that. The base claim is that if it's not coded/tested by Core, then it's inferiorly made by "amateurs". There can't be a claim whereby those that aren't involved in  and/or part of Core are only "amateurs" without the included claim that all qualified non-"amateurs" (i.e., professionals) are already part of core. And why can't that be a claim, you might ask; because, English!

When you attempt strip away the validity of one pointing out the absurdity of the original base claim, especially when you attempt to incorrectly grasp the language being used, you fail at any attempt of even grasping what is being said on either side.

Fair enough, but it still seems to be a bit meaningless to get too caught up upon the exaggerations of either side to make an argument and try to stay with the facts of the matter, which is mostly the system that is in place with core is much superior to various challenging coders that seem to have a much smaller code testing and vetting system....

So, sure, we could grant you that individually there may be similar levels of competence, yet it seems that there is going to be greater inspirations of confidence if there is broader vetting of code before it is proposed to be run.. so we will see..   It is possible that with the passage of time the anti-Core coders are going to build up better testing and vetting systems - and so I agree with you that it is probably NOT productive for BBZ or any of us to make individual claims of competence.. but you also seem to be engaging in your own outrageous exaggerations (and even to take the exaggerations a step further) to  overly personalize the discussion, no?

[-ck]

We already seem to have some shifting in core by the release of BP148 code, correct?

"Core" did not release BIP148. A number of core devs support it and released it but there is enough opposition to it such that it is not in the core codebase and won't be.

[JayJuanGee]

We already seem to have some shifting in core by the release of BP148 code, correct?

"Core" did not release BIP148. A number of core devs support it and released it but there is enough opposition to it such that it is not in the core codebase and won't be.

I seem to understand that Core is not any kind of quasi-centralized entity, even though it is frequently accused of being such, and maybe I am coming around to labelling core a s a system with loosely affiliated individuals and some have commit authority within the group.

And, maybe also I am just using the wrong words to describe what I perceive to be taking place when there seems to be a release of software?

Does it mean anything when I see listed "signing keys" as Luke and Wladimir, like in this?

https://bitcoinuasf.org/

[jbreher]

And the safer means would be running some kind of core implemented software, right? 

I don't see how. SegWit opens several new unique attack vectors not present in pre-segwit bitcoin. The SegWit Omnibus Changeset opens several more.

[JayJuanGee]

And the safer means would be running some kind of core implemented software, right? 

I don't see how. SegWit opens several new unique attack vectors not present in pre-segwit bitcoin. The SegWit Omnibus Changeset opens several more.

I thought that the framework of this current line of discussion was between the kinds of segwit to run, rather than not running segwit at all, which seems to be the additional framework that you are adding, Jbreher.

[ComputerGenie]

I thought that the framework of this current line of discussion was between the kinds of segwit to run, rather than not running segwit at all, which seems to be the additional framework that you are adding, Jbreher.

There is no "kinds" of segwit. The contention is "what comes after segwit?" On the Core side is "nothing" (i.e., just segwit) and on the "other" side is "larger blocks" (i.e., segwit and 2MB). That's what all of this boils down to, which is why it's laughable that some go around claiming that the want of a quick adoption of segwit with the guarantee of larger blocks to follow is an "attempt to delay segwit".

It's sad that it's often hard to follow the actual facts with so much FUD from both sides.

[jbreher]

And the safer means would be running some kind of core implemented software, right? 

I don't see how. 

I thought that the framework of this current line of discussion was between the kinds of segwit to run, rather than not running segwit at all, which seems to be the additional framework that you are adding, Jbreher.

OK, let us posit that there is some differential in 'safety' for some different 'kinds' of segwit. I still have no idea what you're getting at. Maybe you can explain why you would think some core implemented segwit code might be 'safer' than some other segwit code.

[JayJuanGee]

I thought that the framework of this current line of discussion was between the kinds of segwit to run, rather than not running segwit at all, which seems to be the additional framework that you are adding, Jbreher.

There is no "kinds" of segwit.

O.k.?  There could be a better way of expressing the matter.

I was responding to what appeared to be Jbreher's differing framework, which seemed to be an argument not to run segwit at all.... however, the previous line of discussion in this thread seemed to be about whether anyone was going to have enough trust in some of these anti-core persons or entities in order to run any of their variations of segwit2x software - or if they might just wait for some variation that may get published by core.

If we are talking about the present or we are talking about the future, our way of framing this can be different, because in recent times, it seems that there has not been any kind of segwit2x software to actually run, so instead we have miners and nodes who are signaling some kind of intention to run future software that would be segwit2x, so it seems to me that within that question, that particular group might not be arguing directly that segwit itself is bad because segwit is part of the package that they are proposing to go forward with.

In the end, unless they start running actual segwit2x software, it remains unclear what extent of significance or meaning to attribute to their signaling about something that is either not yet available or is only in a kind of testing phase - and might be available in the near future.

My understanding is that there are more than one possibility of what various nodes and/or miners could end up running, so that is my reference to "various", and really it seems difficult to speculate about how it might all add up to achieving some kind of locking in result of segwit or 2x or hardfork or changes in governance.

The contention is "what comes after segwit?"

That might be the contention, but we also have questions regarding how to get from non-segwit to segwit activation.  From what I understand, we do not yet have a situation in which we could proclaim that segwit is locked in, and if we are talking about the future, there is going to be some difficulties talking about what happens after x, if we are not even sure if x is going to happen for sure, yet... and so what happens after x seems to depend to some extent in how x is achieved, assuming that it is achieved, and when.

On the Core side is "nothing" (i.e., just segwit) and on the "other" side is "larger blocks" (i.e., segwit and 2MB).

You really believe that the matter is that straight-forward?  I will concede that we have the issues of segwit and larger blocks, but we also have the issues of hardfork and changes in consensus that are dangling in the midst of the implications of various possible paths forward, no?

That's what all of this boils down to, which is why it's laughable that some go around claiming that the want of a quick adoption of segwit with the guarantee of larger blocks to follow is an "attempt to delay segwit".

Well, if we have a whole lot of individuals who are considering what they should do, beyond merely signaling intention, then they likely need to think a few steps ahead if they actually start to run different software and what ramifications that might have... or maybe they attempt to hedge in one direction or another, which may be difficult if there is a kind of forcing of the issue and shortening of the timeline, then they may be watching what others are doing, too in order that they don't get left orphaned in whatever they end up doing.

It's sad that it's often hard to follow the actual facts with so much FUD from both sides.

It does not seem to be an easy issue - and it seems to me that most of the FUD comes from the big blocker side of this matter, but you could be correct that some FUD is coming from others.

[JayJuanGee]

And the safer means would be running some kind of core implemented software, right? 

I don't see how. 

I thought that the framework of this current line of discussion was between the kinds of segwit to run, rather than not running segwit at all, which seems to be the additional framework that you are adding, Jbreher.

OK, let us posit that there is some differential in 'safety' for some different 'kinds' of segwit. I still have no idea what you're getting at. Maybe you can explain why you would think some core implemented segwit code might be 'safer' than some other segwit code.

How the fuck do I know what is safer and what is not safer?

All I am saying is that there may be various economic nodes that might not be willing to change what they are running unless they are comfortable that it is sufficiently tested and vetted.  I don't know all the factors that they weigh, but it seems to me that there remains a considerable difference between a variety of folks saying that they are planning to do something and what the fuck they actually do when the option is available to them and what options might come available to them.  It seems that historically some economic nodes and miners might signal intention based on thinking that there is going to be some kind of core related variation that they are going to be able to run in the future, but if that core related variation does not come available, then they do not end up following through with their earlier signaled intention.  Their reasons can vary and their concerns about safety would likely be one of their consideration.. right?  aren't we talking about economic value that could be at risk in making some kinds of changes?

[Last of the V8s]

With apologies to ck, I have to post my last reply to the tech issue here.
Because they've decided to lock the thread in the tech forum.
(usual Core tactics, if they can't troll you or prove you wrong they'll just censor you)

No, I censored you all on my ownsome. They had trolled you quite satisfactorily and proved you wrong many times over.

[JayJuanGee]

With apologies to ck, I have to post my last reply to the tech issue here.
Because they've decided to lock the thread in the tech forum.
(usual Core tactics, if they can't troll you or prove you wrong they'll just censor you)

No, I censored you all on my ownsome. They had trolled you quite satisfactorily and proved you wrong many times over.

You mean troll buster is a troll?  OMG!!!!

[JessicaG]

There is no "kinds" of segwit. The contention is "what comes after segwit?" On the Core side is "nothing" (i.e., just segwit) and on the "other" side is "larger blocks" (i.e., segwit and 2MB).

Spot-on...

It amazes me how this tiny little difference is creating such huge opposites; it is reminding me on some famous words a president back in 2001 once spoke: "You are either with us, or against us"... I mean, wasn't the current cap purely implemented as a temporarily measure, because back then it was noticed that the chain could be spammed? And sure, we have seen that, yet the chain would only be congested for a few days max...
The current congestion though, is a whole different story in my opinion. The size of the blocks were already reaching their near cap, and when Japan kicked in by officially legalizing the BTC, it got quite clogged; and that's just 1 single country... I think SegWit alone would be enough to unclog the current situation, but I also think we would be nowhere further than just a few months ago (like, when the blocks were nearly full). So personally, I wouldn't mind to see larger blocks implemented as well, rather sooner than later...

[JayJuanGee]

There is no "kinds" of segwit. The contention is "what comes after segwit?" On the Core side is "nothing" (i.e., just segwit) and on the "other" side is "larger blocks" (i.e., segwit and 2MB).

Spot-on...

It amazes me how this tiny little difference is creating such huge opposites; it is reminding me on some famous words a president back in 2001 once spoke: "You are either with us, or against us"... I mean, wasn't the current cap purely implemented as a temporarily measure, because back then it was noticed that the chain could be spammed? And sure, we have seen that, yet the chain would only be congested for a few days max...
The current congestion though, is a whole different story in my opinion. The size of the blocks were already reaching their near cap, and when Japan kicked in by officially legalizing the BTC, it got quite clogged; and that's just 1 single country... I think SegWit alone would be enough to unclog the current situation, but I also think we would be nowhere further than just a few months ago (like, when the blocks were nearly full). So personally, I wouldn't mind to see larger blocks implemented as well, rather sooner than later...

You are talking nonsense Jessica...

You are basing your conclusion of a supposed need for 2mb blocks on facts that do not exist... there is no clogging of the bitcoin blockchain, except for the extent to which some miners must be directing their hashpower to make such appearances of clogging... such recent precipitous rise and then drop in mempool back up seems abundantly obvious evidence that the clogging of the mempool is not based on some kind of actual organic growth - but instead is a fabricated situation that would not be solved by a mere doubling of the blocksize limit.. and therefore a doubling of the size of the blocksize limit would likely cause more troubles than it resolves.


So, yeah, it is possible that some day there is going to exist a situation in which a hard increase of the blocksize limit might be necessary, but it is not even close to being true in today's level of bitcoin usage... and surely it will be interesting to witness how segwit plays out and whether any of that would cause any changes in the blocksize usage, either in one direction or another.

[gmaxwell]

The contention is "what comes after segwit?" On the Core side is "nothing" (i.e., just segwit)

lol

In fact, the Core has many things after segwit; some of which are already done (compact blocks), signature aggregation, weakblocks, flexcaps, etc.

All anyone else has is MOAR BLOCKSIZE REGARDLESS OF THE CONSEQUENCES and some heads on spikes.

[franky1]

The contention is "what comes after segwit?" On the Core side is "nothing" (i.e., just segwit)

lol

In fact, the Core has many things after segwit; some of which are already done (compact blocks), signature aggregation, weakblocks, flexcaps, etc.

All anyone else has is MOAR BLOCKSIZE REGARDLESS OF THE CONSEQUENCES and some heads on spikes.

in short core is not promising to copy the 2mb base within months of segwit.. thus expect big issues in regards to the 2mb event 3 months after segwit, due to lack of node support.
(expect major orphan drama)
hey gmax, how about re-implement a new fee priority formulae and stop this mindless 'just pay more' mantra

[jbreher]

All anyone else has is MOAR BLOCKSIZE

Yes. Thereby cleanly -- and in one fell swoop -- solving the biggest bug in the Bitcoin system today (well, yesterday and the day before as well...)

[Cuber Krypton]

All anyone else has is MOAR BLOCKSIZE

Yes. Thereby cleanly -- and in one fell swoop -- solving the biggest bug in the Bitcoin system today (well, yesterday and the day before as well...)

Often the simplest solution is the best one.