Topic: The Barry Silbert segwit2x agreement with >80% miner support. - page 28. (Read 120014 times)

I have been a little out of the loop recently, but that is some damn shady behavior.

I guess that it is a good idea from their perspective.

But Roger told me Garzik has code in billions of devices

Obviously. Blaming an attacker for faulty code is nonsensical.

wasn't this supposed to be activated in two steps, one is the segwit and then the hard fork? which is why miners were not in agreement with this one?

also what's up with all this bugs in those new "chain" that are not with core, seems that only core dev is competent here

Hahaha - that's a really good one - but think of how many idiots there are in our world (yes - incl me ...) and you end up in the minority chain in a sudden.

That is funny. Obviously there will be attackers when Segwit2x is deployed. In my opinion, it would be better for them not to rush things and make the release after UASF, just in case it is not successful.  

Sometimes it feels like someone on the top is protecting and working directly with the miners.

Would still be a good Idea that a block which is only filled with 600 kb only takes 600 kb of space and not the full 1 MB.

There may be a acceptable goal of attempting to lock everyone into the 2mb agreement and the hardfork at a certain time frame - however, a strange part would be that smaller blocks would not be accepted and maybe that they are attempting the lock in with a kind of stealth tactics rather just transparently asserting that everyone is going to be locked in after a certain passage of time.  

They likely don't want to be transparent because they are trying to cause a locking in that people likely are reluctant to agree to it (even though they would be asserting that everyone already agreed to be locked into the hardfork and the 2mb limit upgrade by the NY agreement and by running the software..

Not exactly. There's more to it than that. They can't use the hardfork bit because they're trying to trick lite clients into following their fork, thus causing maximum disruption (they don't seem to have any other goal). In that respect, forcing >1MB blocks is a very good idea, or it would be if their code actually produced >1MB blocks. The inherent flaw is that it actually doesn't with the default settings (even if the mempool has more than 1MB of transactions), with the result that all their miners stopped dead as soon as the fork activated, and it took over a day for anyone to figure out what the problem was (and the so-called developers spent most of that time denying that there was any problem at all and insulting anyone who tried to point it out).

It's the typical level of incompetence we've all come to expect from these clowns.

Basically them right now:

https://twitter.com/petertoddbtc/status/884534547202940928

---

Things are getting ridiculous.

I fully agree. The idea to force blocks bigger than 1 MB is inherently flawed. Anyhow, this place is full of idiots that post their worthless opinions.

Moronic, encouraging miners to create pointless transactions to make big enough blocks... Let's help contribute to blockchain bloat.

For the record, by the way, it only needs to be one block to big enough to break the deadlock but it's still a stupid mechanism to secure the hardfork.

Well, I don't see why a miner wouldn't fill up the block to 1 MB with dummy transactions, just to not waste his hash rate, and get the next block while all others are waiting to start to mine until they can fill up a 1 MB block...

A lower limit on block size will never be a problem, because miners can make blocks as large as they want with own dummy transactions.  This makes that miners cannot play games with small blocks as they are now not part of the protocol any more, and all "relative network advantage" between 1 MB and 2 MB is much smaller than between 10 KB and 1 MB.

There it is, the dumbest thing I've read in 59 pages.  

Q: And what happens when there isn't 1MB worth of segwit transactions?
A: 1 hour block times. 

Nowadays I have seen a lot of the miners wasting the available block space, by refusing to include low-fee transactions. Yesterday I saw F2Pool mining a block of just 111KB. This needs to be stopped and making 1 MB the minimum size is a good step in ensuring that.

Well, it could be a way out of segwit2x - because there won't be too many folks who are going to want to run segwit2x if it is having difficulties passing through test phases, no?  On the brighter side, testnet is supposed to help to find bugs, and might they be able to fix the bugs in an expedited way?

A big crap. One that I'm sure will create lots of confidence in this 40 billion dollar economy.

that means that this segwit2x fork will activate only if miners built a block with more than 1mb? And if not the network will be stall until this happen? lol
What a crap is this

Nevermind. I seem to have misunderstood what -ck was saying.

Showstopper? Doesn't look like it. Code working as intended. On reaching specified block height, block must be over 1MB to be valid. There are not enough transactions on the test net to hit 1MB before block mined. Why not? Someone threw massive hashpower at the testnet all of a sudden. 6000 blocks mined in 24 hours. Troll? Extreme tester? Doesn't matter. When mining slows sufficiently such that transactions can accumulate, chain will fork.  Actually sounds like a success case to me.

Okay and back on topic, it looks like a showstopper bug has shown up in their segwit2x code.

They've hit the >1MB hard fork on testnet which refuses to accept a block unless it is bigger than 1MB:
https://github.com/btc1/bitcoin/issues/65
At this point there aren't enough transactions to create a second block with more than 1MB of transactions on testnet, leading to a fork with 6000 blocks that aren't using the 2x code and the two forks not speaking to each other.

They argue that mainnet is busy enough that there will always be blocks with more than 1MB of transactions so it won't be a problem.

This is utter bullshit as over the past week I've seen my mempool easily get down below 1MB of transactions now that the transaction spam has ended on mainnet. Making a followup block mandatory 2MB when nothing forces mining to do so is a showstopper IMO.

Now they're all scrambling and arguing how to tackle it... This is going to be interesting. I might start selling popcorn.

In terms of your frameworks, I don't know what I am describing.

I thought that I was describing part of the dynamic of the historical propositions of XT, Classic and BU, which was that they were wanting to achieve a change in the governance - but they were arguing that there was a technical necessity that was justifying their position.. so each time, there was a threat of a hardfork in the soon future in the event that core did not accommodate in order to make the technical change (which was argued to be an upgrade to 2mb blocksize limits).  Initially, in about late 2015, Segwit was communicated as a compromise change to the code that would partly address scaling issues without a need to hardfork or to immediately implement a 2mb increase or further increases or changes to governance that would allow increases to be easier in the future... or even the automatic increases that were initially part of the XT proposition.

Anyhow, I was just suggesting that the arguments about technical necessity were merely guises to allow for easier future changes by either having the changes automatic or changing the process in order to allow for easier future changes (which are all significant changes to governance - that makes it much more difficult to make changes to bitcoin).

Initially, in late 2015, it seemed that a large number of folks were onboard with segwit; however, with the passage of time, there has been more expressions of disagreement about it - but still seemingly that a lot of the disagreements have been dressed up in terms of concerns about technicalities, when in reality there are underlying motives that are ongoing attempts to change governance and to make it easier to change bitcoin in terms of how BIPs are made, discussed, tested and implemented through procedures followed by core...and seemingly some hate regarding the influence over the procedure of some of the core personalities.

If we are saying the same thing with different words, then maybe we agree?  Why do I get the feeling that we don't agree?  Must just be me, no?  We are arguing over semantics..   Oh?





Seems to me that you were suggesting a hardfork that would be consensual without really defining what consensual would be except that people would like to follow it... for you consensual seems to be anything that people follow, go figure!!!

Regarding my reading, if you are making arguments that are all over the place and internally contradicting, then of course, you should expect that I might get confused about what point(s) you are attempting to make.



Yeah of course, if there is consensus (at what ever level that is deemed non controversial), then that seems to be just a reinforcing of the current rules - and even a confirmation of an agreement that the rules are working for that particular application.


Of course, I have a point.  This is the crux of the argument to determine at what point (or what consensus) threshold a hardfork would be imposed and still be considered to be safe to write off the minority - 95% seems pretty good for those kinds of scenarios, but of course, it could still work out at a lower consensus threshold, even if it would be more risky. 

We both likely recognize that there is a continuum here.. The lower the consensus threshold in a contentious hardfork, the more risk of an actual chain split... The inverse is true, too.  The higher the consensus threshold, the less risk of an actual chain split.  The actual number in which to achieve nonsplitting is not any kind of exact science and reasonable people will likely have different opinions about making such predictions regarding how others might behave, whether that is a minority of 5% or a minority of 20%, or some in-between variant.


It does not really matter that much, and maybe there is a kind of inevitability that some users are going to feel more strongly about forking and less value about keeping the chain together.  Maybe it would stop at two splits, but maybe there would be further splits.  It is not easy to determine.  We could imagine that having more than 1000 alts, already that there would be considerable desire to NOT create another alt - but the problem with this thinking is that we cannot really control human behavior, and any fork splitting might not be calculated to create another alt, but instead of the belief that they are going to become the longest chain, as we already seem to agree on some variation of this.



I doubt that we are done yet, and sure, I am o.k. with agreeing to disagree at some point - even if I might not be clear about which parts we are agreeing to disagree about.  Seems that we are largely disagreeing about semantics including what is potentially likely outcomes in the future based on some of the cards that are on the table or what might be in the deck or in the hands of the other players including whether the other players are bluffing or if they have sufficient cards to either win or to double down with confidence. 

Hahahaha... some of what we are arguing about seems to be unknowns or how we think another player may play his hand.    What a dumb argument you started.!!!!       

Are you sure you're not describing the versionbits modification part of The SegWit Omnibus Changeset?