I see that now since BIP91 is locked in, the % of miners signaling has gone down. Interesting.
Yeah.. now it is around 85%. But now the attention seems to have shifted to BIP 141, which is having around 95.1% support now (95.0% support needed to lock in BIP 141). All the blocks seems to be signaling BIP 141 without exception. Signalling bit 4 AKA BIP91 serves no purpose now that its action is locked in. The important part is enforcing it, meaning rejecting any blocks that don't have bit 1 AKA BIP141 set. On the other hand, bit 4 is meant to be signalled up to the time of the 2x hard fork so pools dropping it now might mean something. More likely it's just shuffling of coin daemon code/settings. |
|
|
|
They did this in the hope they could get their (useless) block size increase after activating segwit. However there is absolutely nothing that guarantees the lock in of the hard fork 3 months from now based on bit 4 being active at the moment
The *only* useful thing that could come out of this is that bitcoin could finally jailbreak out of the 1 MB artificial lock-up, and segwit is in fact making this worse by trying to increase a very last time the amount of transactions per block, by delegating part of the block data outside of the "official" block size, but this cannot, as far as I understand, be extended yet another time. In other words, segwit is the "end of the road" for more transactions if the jail of 1 MB blocks remains. Yes, it will get us some temporary relief, but on the other hand, it has graved even more into stone the 1 MB limit and the "danger of hard forks" (which is a non-issue in most other crypto coins which do this regularly). Once you break the jail once, you're free for ever. However, if bitcoin doesn't succeed in overcoming this silly 1 MB limit now, it may even be much, much harder in the future to do so ; this is why it is of utmost importance that 2 MB blocks (with or without segwit) are adopted, to kill this 1 MB hard wall once and for all. That doesn't solve fundamentally the essential design flaws in bitcoin, but at least, it doesn't turn a silly error into yet another extra fundamental design flaw for ever (I'm talking about the 1 MB limit). You misunderstand me, probably because of my flamebait "useless" comment. I'm for a 2MB hard fork and said so earlier in this thread. What I'm against is a rushed hard fork done by morons who don't understand the code they're modifying earlier than is needed. Once segwit locks in it will ease the pressure on transactions for the time being - and there actually ISN'T any pressure on transactions now that the artificial spamming is over. I'd be for a hard fork in 12 months from now, done with the cooperation of core instead of rushed by outsiders forking the code and missing out on other developments in the code. The bulk of the core group has said they'd push for 2MB in the past, BUT the pressure in all directions is making all this information obscured. |
|
|
|
If p2pool runs BIP141 segwit compatible that will likely be enough to avoid building on a dead end chain because it looks like there won't be any dead end chain...
Ironically, the problem is that bitcoin-core doesn't reject blocks that don't flag segwit. That means that p2pool miners who are using core will build on the wrong block whenever a non-segwit block is found. If p2pool built empty blocks when bitcoind is building on a non-segwit block, then almost all the inefficiency goes away. The thing is there is virtually no one left mining non-BIP91 (connectbtc and any solo miners out there who haven't changed as far as I can see) so you'd have to be ultra-unlucky to build on one block in 100 that isn't signalling segwit AND find a block. Possible, yes, but extremely unlikely. I think anyone left will probably change to signal segwit anyway before then. |
|
|
|
I believe that a layman's explanation is that BIP91 facilitates (or forces) the locking in and activation of segwit, which locking in adn activation of segwit process will take place in August.
BIP91 also causes some attention to a possible 2mb blocksize limit increase through a hardfork - however, the language of BIP91 does not seem to mandate those further steps regarding 2mb increase or the hardfork.
So the more important thing about BIP91 seems to be providing a vehicle or a channel to activate segwit - which also nullifies the activation of BIP148 (User Activated Soft Fork) that would have gone into effect on 8/1.
Can anyone say more than that would be more concrete than speculation?
Segwit2x does not have a valid BIP. Miners were meant to signal their intent to fork with segwit2x by adding NYA to their coinbase. BIP91 was proposed by James Hilliard as a way of making segwit2x compatible with BIP141 (the original core segwit activation). Thus it does not have anything to do with the 2x hard fork component in the future. The only thing that says miners are for both is the presence of NYA in their coinbase, which doesn't even activate anything in particular, it's just a comment, along with the continued signalling on bit 4. You can see why the hard fork is precarious in light of this. |
|
|
|
i'm a little confused.. we're getting SegWit, then a 2MB hardfork.. why does Tone Vays refer to segwit2x as "clown code" that's untested or something?
BIP91 somehow allows SegWit and SegWit2x to work together? is that right? is the segwit in segwit2x not the same as regular segwit?
I'm also not 100% sure, but maybe this makes sense?  https://twitter.com/pierre_rochard/status/888163762850717696The NY agreement stipulates that the two are tied together; that by signalling bit 4 they are voting to activate segwit AND the hard fork down the track. They did this in the hope they could get their (useless) block size increase after activating segwit. However there is absolutely nothing that guarantees the lock in of the hard fork 3 months from now based on bit 4 being active at the moment. There is nothing stopping all the miners from simply dropping the btc1 fork code and just using core after segwit is activated, and not all pools actually signed the agreement. Heck there's little sign anyone's actually using the btc1 fork at the moment. Likely they're all custom patched with segsignal just for BIP91 as my pool is. |
|
|
|
Actually it looks like Slush is finally signaling BIP91 so I don't have to switch  Good job Slush!  476713 BIP91 20000012 Slush Pool )Fag�w͏�� /slush/ Great stuff. He saw the writing on the wall. Right now it would be suicide to NOT run BIP91 now that it's a certainty. Yep! I still see Bitcoin.com mining BU blocks though. Hope they enjoy their invalid blocks! Also this: 476729 20000000 Kano CKPool 9F��pY�}^8 ��pY�* .🐈. KanoPool 0p @P /NYA/ Kano doesn't plan to switch daemons? I have nothing to do with his pool nor communicate with him so cannot help you with your query. |
|
|
|
|
And it's done. There are enough blocks to activate it this period. Now for the period to be up and the activation to occur in 14 blocks' time.
|
|
|
|
|
Only 0 more needed now. (heh, edited)
|
|
|
|
Antpool with 9:12; they must have kicked that covert asicboost into high gear.  Funny, but even you know that asicboost doesn't speed up mining. I know it more than most, but I couldn't help myself.  Like I said, it was funny  |
|
|
|
Antpool with 9:12; they must have kicked that covert asicboost into high gear. Funny, but even you know that asicboost doesn't speed up mining. |
|
|
|
|
Once the activation of BIP91 followed by BIP141 is over and segwit is active and the world didn't end as all the BU doomsayers predicted, I'll be able to unignore a substantial number of posters... until their next FUD campaign.
|
|
|
|
Is there a decent Chrome extension for that? I've been going through a couple of them and they look like they're either paid, spyware or both. Super auto refresh is great. It's even better than firefox's reloadevery because it remembers which pages have refresh set and how much and uses it automatically next time you navigate there. |
|
|
|
Yes very interesting.
So I guess we all can learn now how a HF could work very nicely.
... And show to the outer world that bitcoin can move.
Who said anything about hard fork? That's the next hurdle since BIP91 activates BIP141 which is a soft fork so no users need to adjust their nodes. If 2x goes ahead in 3 months' time and most users remain on core nodes, we have a split where the vast majority of users will be using a client running off a minority hashrate chain. |
|
|
|
|
A lot of this discussion may be a non-event now. Since the BIP91 support is overwhelming now, the chance of the network being partitioned is getting smaller by the minute. Very shortly even those pools that haven't been supporting BIP91 will reluctantly convert to the code to avoid having their blocks being orphaned. In which case there really will only be segwit compatible blocks generated once BIP91 being activated except for some very small minority miners that may not have updated. If p2pool runs BIP141 segwit compatible that will likely be enough to avoid building on a dead end chain because it looks like there won't be any dead end chain...
|
|
|
|
Actually it looks like Slush is finally signaling BIP91 so I don't have to switch Good job Slush! 476713 BIP91 20000012 Slush Pool )Fag�w͏�� /slush/ Great stuff. He saw the writing on the wall. Right now it would be suicide to NOT run BIP91 now that it's a certainty. |
|
|
|
|
I went to bed anxious about how close it was and woke up to this. Nice. Let's see how smoothly, or otherwise, the aggressive bip91 deployment process goes. I suspect every remaining pool will be scrambling to signal segwit to not be left with orphaned blocks very shortly and it will be a non-event. Only 3 pools remain not signalling BIP91 but they can't be living in a cave and have been ignoring this. They're just protesting futilely.
|
|
|
|
I must say I'm a bit disappointed with Slush at the moment. On the other hand I really don't want to mine with any of the Chinese pools (no offense to those of you who are Chinese!)
There are plenty of non-Chinese pools... Tis true, but I think Slush is the biggest of them all at this point. Correct me if I'm wrong. Also I love Slush's stats and web front end! (also monitoring and notification features). Make up your mind, are you disappointed or not Obviously not disappointed enough to stop mining here and help activate BIP91. |
|
|
|
I must say I'm a bit disappointed with Slush at the moment. On the other hand I really don't want to mine with any of the Chinese pools (no offense to those of you who are Chinese!)
There are plenty of non-Chinese pools... |
|
|
|
Could you pls explain a little more here since I understand this issue is about to better sync the activation UASF / SW2x ?
Wouldn't it be better the SW2x lock-in is to be delayed to minimize the time difference between those two activations ?
That's what the miners try ?
BIP91 has to lock in and start invalidating non-segwit blocks before BIP148's activation, otherwise BIP148 goes active while the miners continue to mine non-segwit signalled blocks. They aren't really compatible, even though they ultimately lead to segwit's activation. BIP91 being activated earlier is better than them conflicting come August 1. This is the main reason segwit2x rushed and chose to activate 2 weeks before BIP148. |
|
|
|
|
Show Posts
