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

[chek2fire]

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.

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

[1714907277]

1714907277

[1714907277]

1714907277

[1714907277]

1714907277

[1714907277]

1714907277

[1714907277]

1714907277

[-ck]

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

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

[JayJuanGee]

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

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

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?

[Sithara007]

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

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.

[ComputerGenie]

...This needs to be stopped and making 1 MB the minimum size is a good step in ensuring that.

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. 

[dinofelis]

...This needs to be stopped and making 1 MB the minimum size is a good step in ensuring that.

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. 

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.

[-ck]

...This needs to be stopped and making 1 MB the minimum size is a good step in ensuring that.

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. 

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.

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.

[Lauda]

Basically them right now:

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

Things are getting ridiculous.

...This needs to be stopped and making 1 MB the minimum size is a good step in ensuring that.

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

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.

[Foxpup]

The idea to force blocks bigger than 1 MB is inherently flawed.

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.

[JayJuanGee]

The idea to force blocks bigger than 1 MB is inherently flawed.

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.

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

[mike4001]

...This needs to be stopped and making 1 MB the minimum size is a good step in ensuring that.

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. 

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.

[Wind_FURY]

Basically them right now:

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

Things are getting ridiculous.

...This needs to be stopped and making 1 MB the minimum size is a good step in ensuring that.

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

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.

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.

[hv_]

Basically them right now:

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

Things are getting ridiculous.

...This needs to be stopped and making 1 MB the minimum size is a good step in ensuring that.

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

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.

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.

[Amph]

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.

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

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

[Lauda]

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

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

In that respect, forcing >1MB blocks is a very good idea, or it would be if their code actually produced >1MB blocks.

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

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

But Roger told me Garzik has code in billions of devices

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. 

Obviously. Blaming an attacker for faulty code is nonsensical.

[gmaxwell]

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.

You think it has been low recently, wait until after segwit is active and starting to get used by major transactors.. :-/

Best part of it was hours of going on about the attacker while making it clear that almost no one on that repo is even running their own testnet, and letting it go ~29 hours for a block.  If it takes 29 hours to fix an issue that takes a simple modification, restart, and potentially running a shell-one liner to generate txn if there aren't enough-- how may people can possibly be working on this thing for real?  0.5?

[pooya87]

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

EDIT: let me rephrase this question here
i fail to understand what the drama is all about.
the fork only needs  1 block to happen, and this one block can be delayed a little bit (a couple of minutes tops) before being mined. then the rest of the blocks building on top of it can be from nearly 0 (empty block with only coinbase tx) to 2 MB.

so where is the problem with that?

and please not that my question is not about why fork to 2 MB part, my question is about this issue and all the confused drama about it when it is pretty simple.

[dinofelis]

...This needs to be stopped and making 1 MB the minimum size is a good step in ensuring that.

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. 

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.

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, it is a very smart way to make in a very very simple way, a bilateral hard fork, which is a GOOD thing.  And BTW, nobody cars about "block chain bloat".  Mining pools have enough hardware to do so, and normal users only need light wallets.  Those really wanting to play with a full node in their basement will not see much difference with today, where the average block size is already close to 1 MB.

I never thought about this simple way of making a bilateral hard fork.  Usually, one thinks about a modification in some or other format or so.  But obliging >1MB is genius and simple. 

[JayJuanGee]

  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.  

There would not be any incentive to attempt to activate once UASF goes through because it seems the whole purpose is to attempt to control the direction of the implementation and to avoid the UASF.. might be sloppy and messy game theory, but some variation of sloppy, messy and illogical game theory has been going on since late 2015 and through XT, then Classic then BU... so what else is new?  more sloppy game theory, an attempt at segwit2x to muddy the waters and confuse things and continue to whine.. that seems to be the goal.. whining.   

[ComputerGenie]

.... 

I was wrong, that's the dumbest thing I've read in 60 pages.