...When they were going to signal SegWit a while ago, Wang Chun said that SegWit would be a "disaster" then started signalling really soon after under the guise of following the public..
Yeah, what kind of dick reverses his position based on the belief that holding strong to such a position would create a fork in Bitcoin that's not good for Bitcoin?  A real big dick... but no wait, maybe it's a real small dick and this is their way of compensating by feeling like they have power? |
|
|
|
A few are holding out or have reverted while they get clarification on the latest problem with the fork as pointed out to them by gmaxwell here https://github.com/btc1/bitcoin/issues/85 . They're waiting to see how bad an issue it might be in the real world before deploying it (+/- again). Is this why f2pool and bitfury still holding? Yesterday Bitfury was signaling bip 91, today they changed to segwit. I'm tracking this through xbt.eu Bitfury have said they are now: https://twitter.com/BitfuryGeorge/status/887557125437829121Only f2pool is left of the big pools and there's already enough hashrate so they'll definitely do it knowing that. |
|
|
|
A few are holding out or have reverted while they get clarification on the latest problem with the fork as pointed out to them by gmaxwell here https://github.com/btc1/bitcoin/issues/85 . They're waiting to see how bad an issue it might be in the real world before deploying it (+/- again). |
|
|
|
signalling means changing a variable. this variable is the block version. to support BIP91 which SegWit2x implemented you change that variable to 0x20000010 and to support more than one BIP you add the bits to this number for example to support both SegWit2x (BIP91) and SegWit you change it to 0x20000012 (addition of bit 1 and bit 4 if i am not mistaken) SegWit alone is 0x20000002 for these stuff you don't need to run a specific client, you just edit a single line of code. you may also run btc1 client and change your useragent to something different to mask the fact that you are running that client, maybe to protect against getting DDoSed  No. Changing just one bit is not enough to be safe with the BIP91 fork because part of running BIP91 means orphaning any blocks that aren't signalling segwit once support is over 80% @-ck what client you running? Bitnodes shows only 64 btc1 clients while BIP91 is almost 65% at xbt.eu. Almost no one is running Garzik's client just signaling BIP91 it seems.
I run a custom coin daemon but the extra code for BIP91 comes from here: https://github.com/segsignal/bitcoin |
|
|
|
Just to clarify, this and the shared pool are compatible with the upcoming segwit component of the New York Agreement AKA segwit2x soft fork and any blocks we find will be valid and accepted.
Can ck signal bit 1 and bit 4 both? Yes we're signalling BIP91 and BIP141. |
|
|
|
|
Both of my ckpools are on BIP91.
|
|
|
|
Keep using core 0.14.2 and wait till segwit is locked in and wait for many confirms on any transactions until then in case of chain reorganisations.
I'd like to add: ... and for the love of all that is Bitcoin, take all of your BTC out of anywhere where you don't control the keys..... Definitely do this too. Right now everyone should be pulling everything out of the exchanges they've been treating as banks. |
|
|
|
OK - looks like miners colluded (intention) down to about 90% and choose SW2x - question: what have nodes to do now ? Keep using core 0.14.2 and wait till segwit is locked in and wait for many confirms on any transactions until then in case of chain reorganisations. |
|
|
|
No. The only evidence of mining activity is everyone switching to a BIP91 compatible client. Does anyone have links or information concerning the supposed large number of BIP91 renditions? Is there really a possibility that some might be more inclusive of the 2x portion of segwit 2x and others do not have that 2x portion in their code? There's no way to tell from the blocks alone, but I can speak for at least 4 pools I know of that are running BIP91 only clients  |
|
|
|
Would there be a UAHF on August 1? 1. UAHF on August 1. 2. Segwit2x hard fork by November. This UAHF wouldn't fork the complete network, right? Miners could opt to mine on BCC (altcoin) chain. This is a bit confusing, why go through the whole Segwit2x drama when they still want to deploy UAHF? Maybe because they know there wouldn't be a majority for the hard fork on November? https://medium.com/@ViaBTC/statement-on-bitcoin-user-activated-hard-fork-6e7aebb67e67There won't be a UAHF because segwit will get activated before then. |
|
|
|
No. The only evidence of mining activity is everyone switching to a BIP91 compatible client. |
|
|
|
I lol so hard at the BU blocks. Why? Why oh why! -edit- looks like the BU blocks are slowly dying so whoever was running BU nodes is slowly migrating.
Never fear, the big blockers will be back with their next hard fork coup attempt in the guise of bitcoinABC. |
|
|
|
|
Just to clarify, this and the shared pool are compatible with the upcoming segwit component of the New York Agreement AKA segwit2x soft fork and any blocks we find will be valid and accepted.
|
|
|
|
I have a question,
Since I've read an article that bitmain will split BTC and all the pools they are managing are signaling all blocks with segwitx2
What we will get if we find a block after the split?
This and the solo pool are compatible with the upcoming segwit component of the New York Agreement AKA segwit2x soft fork and any blocks we find will be valid and accepted. Of course we need to actually have a hashrate to find blocks... |
|
|
|
Hopefully it shall help us crack this elusive block. . .
In ck's [BETA] pool, elusive block cracks the pool! - sorry ck, I couldn't resist .earl Dammit I should be annoyed but that's funny. |
|
|
|
|
One by one the pools are starting to solve BIP91 blocks so there is no sign of any of them pulling out now. This of course doesn't mean they're running the btc1 branch as there is a popular BIP91 only branch available too that has only the segwit component of segwit2x...
|
|
|
|
If you want to run a pruned node but have the storage capacity to download the whole blockchain it is indeed much faster to download the whole blockchain and then restart bitcoind in pruned mode to do the pruning afterwards since it is constantly being pruned during the download process otherwise.
Have you actually measured that? If it's true-- it's a bug. the pruning should delete a whole blockfile at a time (128MB) and shouldn't take much time at all. It's totally plausible to me that there is a bug here, but I've not noticed it myself or heard it reported before. Only when pruning was first available did I experience this and I did not do a fair comparison of identical hardware so no I cannot say for certain. I've not downloaded the whole blockchain since. |
|
|
|
Sorry, not completely sure I follow you here. You want me to rebuild with debugging and send you the logs, or you want me to sign up for backtrace service? Can I please ask you to elaborate? Rebuild with debugging and get backtrace output as described in the README-debug I linked above. |
|
|
|
You're all my heroes and you shall be nicely rewarded for your dedication in time.  |
|
|
|
|
Show Posts
