Topic: The Barry Silbert segwit2x agreement with >80% miner support. - page 27. (Read 120014 times)
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.
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.
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.
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.
that doesn't exactly answer my question though.
go to http://statoshi.info/dashboard/db/memory-pool and set the dates to
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. 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
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!
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.
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.What a crap is this
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)
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. 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?
(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
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
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.
I can't believe that this is all so dicked up that I'm actually rooting for Core to come out on top.
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.
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.
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.
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'). 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.
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.
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.
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.
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. 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?
(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.) 
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 ?
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 ?
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.
....
I was wrong, that's the dumbest thing I've read in 60 pages. 
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.
...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.
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.
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
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.
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?
Jump to: