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

[JayJuanGee]

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?

Sounds like they are really dedicated to this matter to secure value.  and with little ploys like these they may inspire confidence and obtain a 10x increase in their participation levels and get 5.0 to run their reliable software.. on billions of devices, including a supercomputer in greenland.      

[spartacusrex]

Just so we're absolutely clear..

1) If you run CORE + BIP91 'without modification'... that is compatible with the first phase of segwit2x ? (SegWit activation only..)

2) If you run CORE + BIP91 'without modification'... that is compatible with BIP 148 ?

[Foxpup]

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?

There are many problems with that, but the specific problem that caused this particular failure is that the hardfork block was delayed not by "a couple minutes", but by 29 hours, because that's how long it took the miners to realise that the segwit2x client won't actually produce >1MB blocks by default, and hence rejects its own blocks when the fork happens. (Many probably still haven't realised the default is broken as it only took a single miner with custom settings to mine the fork block, and since the issue was closed without changing the default behaviour, it's likely to happen all over again if they try to fork on mainnet. Get your popcorn ready.)

[ComputerGenie]

Q: What's wrong with "dummy" transactions to make up the difference?
A: Nothing, as long as 2 years from now you're OK with wasting 2-8GB of HDD space just because some idiot decided there should be a "minimum sized block" and you're in favor of being in direct opposition to scaling.

Q: What's wrong with waiting until the mempool supports the new block size minimum?
A: Let's suppose segwit reduces weight count by 30%. That means that it takes 30% more transactions to fill 1MB of space, compared to pre-segwit. That, also, means that when there aren't enough transactions to fill 1 block, that block will take 30% longer to fill and confirm. That further means that there would be 0 transactions left to start the next block and each successive block would take exponentially longer. This all means that, if segwit actually works, there could be times where there are 1 hour block times and 3 hours to confirm 6 blocks could become a regular thing. This is the diametric opposition to scaling.

[Tigggger]

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

That is THE question though, what will post segwit bitcoin be like.

One side believes segwit will work, the other side believes it will make very little difference.

This is why although I wouldn't pick either of the current solutions, this compromise will at least allow the question to be answered.

If it does work, then the demand for bigger blocks will decline and we will just have segwit. If it fails to make an impact then opinion may swing towards bigger blocks.

Q: What's wrong with "dummy" transactions to make up the difference?
A: Nothing, as long as 2 years from now you're OK with wasting 2-8GB of HDD space just because some idiot decided there should be a "minimum sized block" and you're in favor of being in direct opposition to scaling.

Q: What's wrong with waiting until the mempool supports the new block size minimum?
A: Let's suppose segwit reduces weight count by 30%. That means that it takes 30% more transactions to fill 1MB of space, compared to pre-segwit. That, also, means that when there aren't enough transactions to fill 1 block, that block will take 30% longer to fill and confirm. That further means that there would be 0 transactions left to start the next block and each successive block would take exponentially longer. This all means that, if segwit actually works, there could be times where there are 1 hour block times and 3 hours to confirm 6 blocks could become a regular thing. This is the diametric opposition to scaling.

Maybe I've misunderstood but I thought it was only the very FIRST block that needs to be >1Mb, once that has been done there there is no minimum size, so no bloat or delays.

[-ck]

One side believes segwit will work, the other side believes it will make very little difference.

You're kidding me... you really think segwit won't "work" the way it was intended? It's been deployed for over a year on testnet (unlike segwit2x) and has been deployed on litecoin. Sure litecoin has precious little use for it but it's still in use and does exactly what it's supposed to. Or are you saying that exchanges and users simply won't use segwit transactions? Exchanges will jump ASAP for the benefits it provides and they do the bulk of the transactions (except during mempool spamming and then it's 'someone').

[Variogam]

Q: What's wrong with "dummy" transactions to make up the difference?
A: Nothing, as long as 2 years from now you're OK with wasting 2-8GB of HDD space just because some idiot decided there should be a "minimum sized block" and you're in favor of being in direct opposition to scaling.

Over 1M is just for first block, meant as reorg (anti-wipeout) protection.

Q: What's wrong with waiting until the mempool supports the new block size minimum?
A: Let's suppose segwit reduces weight count by 30%. That means that it takes 30% more transactions to fill 1MB of space, compared to pre-segwit. That, also, means that when there aren't enough transactions to fill 1 block, that block will take 30% longer to fill and confirm. That further means that there would be 0 transactions left to start the next block and each successive block would take exponentially longer. This all means that, if segwit actually works, there could be times where there are 1 hour block times and 3 hours to confirm 6 blocks could become a regular thing. This is the diametric opposition to scaling.

Again, over 1M is just for the first block. If it happens by chance mempool is empty at that time, it usually fills to over 1M within 20 minutes.


Anyway, I hope the SegWit2x activation wont get rushed. It would be prefferable if the code is improved to automatically create first block over 1M even when the mempool is empty. It also means more testing, so activation after Aug 1, but with advantage SegWit2x could be activated only when there is demand for it and most full nodes are SegWit2x compatible to ensure its success. So it has many advantages to dont rush it just to meet the insignificant Aug 1 fork from few people.

[ComputerGenie]

In a world where devs got it right and "it's only the 1st block" were true, devs would have anticipated a small mempool and compensated for it. 

I can't believe that this is all so dicked up that I'm actually rooting for Core to come out on top. 

[pooya87]

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?

There are many problems with that, but the specific problem that caused this particular failure is that the hardfork block was delayed not by "a couple minutes", but by 29 hours, because that's how long it took the miners to realise that the segwit2x client won't actually produce >1MB blocks by default, and hence rejects its own blocks when the fork happens. (Many probably still haven't realised the default is broken as it only took a single miner with custom settings to mine the fork block, and since the issue was closed without changing the default behaviour, it's likely to happen all over again if they try to fork on mainnet. Get your popcorn ready.)

that doesn't exactly answer my question though.
go to http://statoshi.info/dashboard/db/memory-pool and set the dates to

Code:

from 2017-07-09 @16:00:50.187
to 2017-07-10 @20:20:54.700

this is the most recent period of time (more than a day) with no spam attack and a clean and nearly generic transactions
you can see what i mean when i say in reality it will take only a couple of minutes to fill the 1MB+ block if not already above 1 MB!

i still find the insisting part on the 2 MB fork this soon very weird and unnecessary because the current 1 MB is enough without the spam attack and with activation of SegWit it will be more than enough. but that is another discussion for another time and another place 

[chek2fire]

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.

why they have create such a mess? What are they doing this guys?  Did they really want to destroy bitcoin economy and the whole crypto economy. They have lost their minds? Someone must talk to them for what it means the terms k.I.S.S in tech world ( keep it simple stupid)

[Tigggger]

One side believes segwit will work, the other side believes it will make very little difference.

You're kidding me... you really think segwit won't "work" the way it was intended? It's been deployed for over a year on testnet (unlike segwit2x) and has been deployed on litecoin. Sure litecoin has precious little use for it but it's still in use and does exactly what it's supposed to. Or are you saying that exchanges and users simply won't use segwit transactions? Exchanges will jump ASAP for the benefits it provides and they do the bulk of the transactions (except during mempool spamming and then it's 'someone').

Work meaning to have no backlog thereby reduce fees and lower confirmation times, that's all I want.

I don't doubt the technical aspect of it working, but nobody knows how much it will help with the above until it's implemented.

Segwit is coming and the question will be answered however.

[Foxpup]

that doesn't exactly answer my question though.
go to http://statoshi.info/dashboard/db/memory-pool and set the dates to

Code:

from 2017-07-09 @16:00:50.187
to 2017-07-10 @20:20:54.700

this is the most recent period of time (more than a day) with no spam attack and a clean and nearly generic transactions
you can see what i mean when i say in reality it will take only a couple of minutes to fill the 1MB+ block if not already above 1 MB!

The mempool has nothing to do with it. It doesn't matter how many transactions there are, the current segwit2x code has a default block size limit of 750kB and there are no plans to change it. Miners using the default settings will (and did) refuse to mine the required >1MB block, causing the fork chain to freeze completely. The so-called developers do not consider this to be a problem.

[-ck]

Work meaning to have no backlog thereby reduce fees and lower confirmation times, that's all I want.

I don't doubt the technical aspect of it working, but nobody knows how much it will help with the above until it's implemented.

Segwit is coming and the question will be answered however.

Well I no longer see a fee or confirmation time problem now that the mempool bloat (which was obviously from spam) has now magically disappeared. The only high fees I see now are from services/wallets that still are set to high levels generically based on past mempool bloat that no longer exists and are missing good fee estimators. With segwit on top of that fees will be embarrassingly small even if the uptake is low. Bitcoind is actually filtering out ultra low fee transactions now the transactions are so low and unable to fill a block. So while it's easy to fill 1MB currently by just including all sorts of crap transactions, it's only the garbage that is below standard transaction limits and most pools won't include those. I see this on my own pools which are configured to keep block templates as full as possible but there's nothing to fill them with at times.

[FandangledGizmo]

Wouldn't it be optimal for Core to publish a statement that Segwit2x is a terrible option which they are strongly opposed to, then list the reasons why.

But then state, given its' high probability of being implemented, they will work/do everything in their power to try make it usable & help with testing. If it fails, Core are still heroes for doing their best and if it works it may well be thanks to their efforts in this rushed testing phase & quick reactions when it's implemented.

[warrior333]

Very high rates for small transactions and it leads to a decrease in the number of transactions, but also hinders the development of trade in bitcoins and not allow him to develop. This will lead to a decrease in income of miners. Isn't it better to reduce the Board size and to increase the volume. From this the earnings of the miners can only increase.

[Searing]

Wouldn't it be optimal for Core to publish a statement that Segwit2x is a terrible option which they are strongly opposed to, then list the reasons why.

But then state, given its' high probability of being implemented, they will work/do everything in their power to try make it usable & help with testing. If it fails, Core are still heroes for doing their best and if it works it may well be thanks to their efforts in this rushed testing phase & quick reactions when it's implemented.

I agree.  But unfortunately, with bad blood, no trust, and egos on both sides, I'm not holding my breath.

[ComputerGenie]

Wouldn't it be optimal for Core to publish a statement that Segwit2x is a terrible option which they are strongly opposed to, then list the reasons why...

Given that some literally responded/voted

LOL

good luck with that.

[The One]

Q: What's wrong with "dummy" transactions to make up the difference?
A: Nothing, as long as 2 years from now you're OK with wasting 2-8GB of HDD space just because some idiot decided there should be a "minimum sized block" and you're in favor of being in direct opposition to scaling.

Q: What's wrong with waiting until the mempool supports the new block size minimum?
A: Let's suppose segwit reduces weight count by 30%. That means that it takes 30% more transactions to fill 1MB of space, compared to pre-segwit. That, also, means that when there aren't enough transactions to fill 1 block, that block will take 30% longer to fill and confirm. That further means that there would be 0 transactions left to start the next block and each successive block would take exponentially longer. This all means that, if segwit actually works, there could be times where there are 1 hour block times and 3 hours to confirm 6 blocks could become a regular thing. This is the diametric opposition to scaling.

What about POW?

Win POW... waiting for over 1mb worth of txs... 12 minutes later... win POW. What will happen to the 2nd POW when the first has not yet been propagated to the network?

[dinofelis]

Q: What's wrong with "dummy" transactions to make up the difference?
A: Nothing, as long as 2 years from now you're OK with wasting 2-8GB of HDD space just because some idiot decided there should be a "minimum sized block" and you're in favor of being in direct opposition to scaling.

Of course I'm OK with that.  Only the miner pool nodes and a few big players need to keep an integral copy, and for them, such an investment is not a problem.  All normal users can use light wallets. 

In fact, "when the blocks are full" and an upper bound is hindering the system, changing this former upper bound against which the demand is hitting, by a lower bound, is not going to waste much in the hypothesis of continued adoption.  If 1 MB blocks are most of the time full (they are), then requiring a 1 MB LOWER bound will only waste those few differences of those few smaller blocks than 1 MB (which are almost not there, otherwise the 1 MB limit wouldn't be a problem).

So the "wasted space" is limited by changing the former upper limit which became to small and should normally naturally be crossed by changing it into a lower bound.  But the nice thing is that the old and the new blocks are now fully incompatible, which is what is needed for a clean hard fork (bilateral incompatibility).

Q: What's wrong with waiting until the mempool supports the new block size minimum?
A: Let's suppose segwit reduces weight count by 30%. That means that it takes 30% more transactions to fill 1MB of space, compared to pre-segwit. That, also, means that when there aren't enough transactions to fill 1 block, that block will take 30% longer to fill and confirm.

As I said, no, because miners can fill them up artificially.  They won't be letting their expensive mining hardware sit idle 30% of the time, waiting for people to send transactions before they can START mining.  No, like now, from the moment there's a block found by a competitor on which they will build, they will make a legal block, with enough junk in it for it to be a legal >1MB block so that they are not wasting time NOT mining.

That further means that there would be 0 transactions left to start the next block and each successive block would take exponentially longer. This all means that, if segwit actually works, there could be times where there are 1 hour block times and 3 hours to confirm 6 blocks could become a regular thing. This is the diametric opposition to scaling.

No, not at all, because miners can put as much junk into a block as they wish.  They can make many fake transactions, even without fee, or by paying a fee to themselves.  Miners are never short of transactions if that's what they need.
They prefer of course juicy real transactions with nice big fees from other people, but if they just need to generate random transactions at no cost to be able to mine, they can always do so, unlimited.

[ComputerGenie]

The only thing worse than me finding out I was wrong about 1st vs successive blocks is reading the dumb shit people write whilst trying to justify what I was wrong about.