So, it's the 25th August and this message just popped up in my Bitcoin Core.
Is it still benign?
Topic: About the "Unknown block versions being mined!" warning (Read 7551 times)
achow, thank you for the explanation! I was wondering, what this means
Not trust to bitcoin-core developers and use bitcoin-core of 2014 https://github.com/bitcoin/bitcoin/releases/tag/v0.9.1
"Unknown block versions being mined!" warning have only in new versions
"Unknown block versions being mined!" warning have only in new versions
Ok, We have BIP91 locked in.
The message of the Core shouldn't be dangeous.
But my Core wallet is not working well. The syncro works fine. But when send a payment there is no connection, and the movement is not broadcasting to the network.
What I'm doing wrong? I was thinking that Core users don´t need to change anything (using 0.14.2)
The message of the Core shouldn't be dangeous.
But my Core wallet is not working well. The syncro works fine. But when send a payment there is no connection, and the movement is not broadcasting to the network.
What I'm doing wrong? I was thinking that Core users don´t need to change anything (using 0.14.2)
But Why I cannot send funds with bitcoin qt wallet?
Ok, We have BIP91 locked in.
The message of the Core shouldn't be dangeous.
But my Core wallet is not working well. The syncro works fine. But when send a payment there is no connection, and the movement is not broadcasting to the network.
What I'm doing wrong? I was thinking that Core users don´t need to change anything (using 0.14.2)
The message of the Core shouldn't be dangeous.
But my Core wallet is not working well. The syncro works fine. But when send a payment there is no connection, and the movement is not broadcasting to the network.
What I'm doing wrong? I was thinking that Core users don´t need to change anything (using 0.14.2)
But Why I cannot send funds with bitcoin qt wallet?
- BIP 9 ("version bits") is a standard for proposing Bitcoin upgrades or "deployments". Code for this is included in Bitcoin Core.
- BIP 141, together with BIP 143 and BIP 147, ("SegWit") is a deployment which follows the BIP 9 standard. Code for this is included in Bitcoin Core.
- BIP 91 ("SegSignal") is a deployment which uses the BIP 9 machinery while not strictly following the standard. Code for this is not included in Bitcoin Core but is included in a fork of Bitcoin Core called "btc1".
By modifying the version field in the block header, miners can "signal" their support for any combination of deployments. Bit 1 of the version field corresponds to SegWit and bit 4 corresponds to SegSignal.
https://blockchain.info/charts/bip-9-segwit charts the signalling of SegWit (bit 1) where each datapoint is in fact the average signalling rate of the prior 2016 blocks (~ 2 weeks). However, as you rightly observe, there has been a recent increase in SegWit signalling. Of the last 144 blocks (~ 1 day), 131 have signaled for SegWit (~ 91%). If the 2016-block moving average chart is at 95% or higher at a difficulty change then SegWit will "lock in".
Thank you tspacepilot. Note: "segsignal" is the name given to this deployment by the author of BIP 91, James Hilliard.
Quote
SegSignal is already locked in and all nodes following SegSignal will consider invalid any blocks at height 477120 or greater (~ 2017-07-23, 8:00am UTC). Note again that Bitcoin Core does not include code for this deployment (hence the warnings) and so Bitcoin Core will not reject blocks as SegSignal requires.
I understand that it's also a theoretical possibility that those who are currently sending SegSignal may not actually follow through and orphan non-segwit blocks. But I understand that we expect them to do so.Yes, I wasn't too clear here. All nodes (miners or otherwise) following the rules of BIP 91 (adopting SegSignal) will consider invalid any blocks which do not signal SegWit when this deployment becomes active. However, there's nothing preventing nodes from giving up on SegSignal at any time. Additionally, there's nothing preventing miners from setting bit 4 whether or not they intend to adopt SegSignal.
Technically, the same applies to SegWit itself.
- BIP 9 ("version bits") is a standard for proposing Bitcoin upgrades or "deployments". Code for this is included in Bitcoin Core.
- BIP 141, together with BIP 143 and BIP 147, ("SegWit") is a deployment which follows the BIP 9 standard. Code for this is included in Bitcoin Core.
- BIP 91 ("SegSignal") is a deployment which uses the BIP 9 machinery while not strictly following the standard. Code for this is not included in Bitcoin Core but is included in a fork of Bitcoin Core called "btc1".
By modifying the version field in the block header, miners can "signal" their support for any combination of deployments. Bit 1 of the version field corresponds to SegWit and bit 4 corresponds to SegSignal.
https://blockchain.info/charts/bip-9-segwit charts the signalling of SegWit (bit 1) where each datapoint is in fact the average signalling rate of the prior 2016 blocks (~ 2 weeks). However, as you rightly observe, there has been a recent increase in SegWit signalling. Of the last 144 blocks (~ 1 day), 131 have signaled for SegWit (~ 91%). If the 2016-block moving average chart is at 95% or higher at a difficulty change then SegWit will "lock in".
Quote
SegSignal is already locked in and all nodes following SegSignal will consider invalid any blocks at height 477120 or greater (~ 2017-07-23, 8:00am UTC). Note again that Bitcoin Core does not include code for this deployment (hence the warnings) and so Bitcoin Core will not reject blocks as SegSignal requires.
I understand that it's also a theoretical possibility that those who are currently sending SegSignal may not actually follow through and orphan non-segwit blocks. But I understand that we expect them to do so.I guess the confusion here comes from the fact that you can signal BIP9 without signaling SegWit. BIP9 signals on bit 4 and we definitely have like 80ish% of blocks in the last day or so signaling on bit 4. SegWit readiness is signaled on bit 1 and I think that's what bc.i is tracking there. As far as I know, in a couple hundred more blocks, the miners who signaled BIP9 are supposed to start rejecting blocks that don't signal segwit on bit 1. We'll have to see whether all the folks who signaled BIP9 start putting bit1 and whether or not those who signaled BIP9 (bit4) actually do start orphaning blocks that don't signal bit1.
Disclaimer: this topic is confusing, I may be wrong.
- BIP 9 ("version bits") is a standard for proposing Bitcoin upgrades or "deployments". Code for this is included in Bitcoin Core.
- BIP 141, together with BIP 143 and BIP 147, ("SegWit") is a deployment which follows the BIP 9 standard. Code for this is included in Bitcoin Core.
- BIP 91 ("SegSignal") is a deployment which uses the BIP 9 machinery while not strictly following the standard. Code for this is not included in Bitcoin Core but is included in a fork of Bitcoin Core called "btc1".
By modifying the version field in the block header, miners can "signal" their support for any combination of deployments. Bit 1 of the version field corresponds to SegWit and bit 4 corresponds to SegSignal.
https://blockchain.info/charts/bip-9-segwit charts the signalling of SegWit (bit 1) where each datapoint is in fact the average signalling rate of the prior 2016 blocks (~ 2 weeks). However, as you rightly observe, there has been a recent increase in SegWit signalling. Of the last 144 blocks (~ 1 day), 131 have signaled for SegWit (~ 91%). If the 2016-block moving average chart is at 95% or higher at a difficulty change then SegWit will "lock in".
SegSignal is already locked in and all nodes following SegSignal will consider invalid any blocks at height 477120 or greater (~ 2017-07-23, 8:00am UTC) (edit) which do not signal SegWit. Note again that Bitcoin Core does not include code for this deployment (hence the warnings) and so Bitcoin Core nodes will not reject blocks as SegSignal requires.
I guess the confusion here comes from the fact that you can signal BIP9 without signaling SegWit. BIP9 signals on bit 4 and we definitely have like 80ish% of blocks in the last day or so signaling on bit 4. SegWit readiness is signaled on bit 1 and I think that's what bc.i is tracking there. As far as I know, in a couple hundred more blocks, the miners who signaled BIP9 are supposed to start rejecting blocks that don't signal segwit on bit 1. We'll have to see whether all the folks who signaled BIP9 start putting bit1 and whether or not those who signaled BIP9 (bit4) actually do start orphaning blocks that don't signal bit1.
Disclaimer: this topic is confusing, I may be wrong.
I guess the confusion here comes from the fact that you can signal BIP9 without signaling SegWit. BIP9 signals on bit 4 and we definitely have like 80ish% of blocks in the last day or so signaling on bit 4. SegWit readiness is signaled on bit 1 and I think that's what bc.i is tracking there. As far as I know, in a couple hundred more blocks, the miners who signaled BIP9 are supposed to start rejecting blocks that don't signal segwit on bit 1. We'll have to see whether all the folks who signaled BIP9 start putting bit1 and whether or not those who signaled BIP9 (bit4) actually do start orphaning blocks that don't signal bit1.
Disclaimer: this topic is confusing, I may be wrong.
EDIT: see next post by achow101: everywhere above that I said BIP9, I should have said BIP91.
The following sentences are written at xbt.eu
BIP91 LOCKED-IN
292 blocks until rejecting non-SegWit blocks.
It seems that many pools are supporting BIP91.
Fake newsBIP91 LOCKED-IN
292 blocks until rejecting non-SegWit blocks.
It seems that many pools are supporting BIP91.
https://blockchain.info/charts/bip-9-segwit
https://blockchain.info/charts/bitcoin-unlimited-share
You can not emit with 0-fee ...
https://bitcoincore.org/en/releases/0.14.0/
standard transaction weight 224B ... 0,00005 BTC of fees (25sat/B).
and now, we have 13600 transactions in mempool (65Mb).
https://bitcoincore.org/en/releases/0.14.0/
Quote
Minimum Fee Rate Policies
Since the changes in 0.12 to automatically limit the size of the mempool and improve the performance of block creation in mining code it has not been important for relay nodes or miners to set -minrelaytxfee. With this release the following concepts that were tied to this option have been separated out: - incremental relay fee used for calculating BIP 125 replacement and mempool limiting. (1000 satoshis/kB) - calculation of threshold for a dust output. (effectively 3 * 1000 satoshis/kB) - minimum fee rate of a package of transactions to be included in a block created by the mining code. If miners wish to set this minimum they can use the new -blockmintxfee option. (defaults to 1000 satoshis/kB)
Since the changes in 0.12 to automatically limit the size of the mempool and improve the performance of block creation in mining code it has not been important for relay nodes or miners to set -minrelaytxfee. With this release the following concepts that were tied to this option have been separated out: - incremental relay fee used for calculating BIP 125 replacement and mempool limiting. (1000 satoshis/kB) - calculation of threshold for a dust output. (effectively 3 * 1000 satoshis/kB) - minimum fee rate of a package of transactions to be included in a block created by the mining code. If miners wish to set this minimum they can use the new -blockmintxfee option. (defaults to 1000 satoshis/kB)
standard transaction weight 224B ... 0,00005 BTC of fees (25sat/B).
and now, we have 13600 transactions in mempool (65Mb).
Ok, We have BIP91 locked in.
The message of the Core shouldn't be dangeous.
But my Core wallet is not working well. The syncro works fine. But when send a payment there is no connection, and the movement is not broadcasting to the network.
What I'm doing wrong? I was thinking that Core users don´t need to change anything (using 0.14.2)
The message of the Core shouldn't be dangeous.
But my Core wallet is not working well. The syncro works fine. But when send a payment there is no connection, and the movement is not broadcasting to the network.
What I'm doing wrong? I was thinking that Core users don´t need to change anything (using 0.14.2)
The following sentences are written at xbt.eu
BIP91 LOCKED-IN
292 blocks until rejecting non-SegWit blocks.
It seems that many pools are supporting BIP91.
BIP91 LOCKED-IN
292 blocks until rejecting non-SegWit blocks.
It seems that many pools are supporting BIP91.
Anyone know what that small percentage of blocks signaling with a 30000000 is about? I saw one or two blocks with that version number yesterday and I couldn't find any BIPs or docs referencing that number.
"Bitcoin Classic" nodes mine blocks with version 0x30000000 by default, if I am not mistaken.
Anyone know what that small percentage of blocks signaling with a 30000000 is about? I saw one or two blocks with that version number yesterday and I couldn't find any BIPs or docs referencing that number.
ty achow101 for the explanation. Very concise, complete and straight to the point explaining the Warning message. You should probably append with: Minimum IQ>0 required lol
You has an old Bitcoin Core (without Segwit recognize).
Only 80 blocks are with an exotic version ...
https://www.xbt.eu/ (144 Blocks)
http://imagize[Suspicious link removed]ageshack.us/a/img924/8840/iqunLG.png
Only 80 blocks are with an exotic version ...
https://www.xbt.eu/ (144 Blocks)
http://imagize[Suspicious link removed]ageshack.us/a/img924/8840/iqunLG.png
Code:
2017-07-20 08:45:34 UpdateTip: new best=0000000000000000007a3eed0bbf2bc517760e19aedc235fca12738ea089f2bd height=476675 version=0x20000002 log2_work=86.79112 tx=240559896 date='2017-07-20 08:42:36' progress=0.999998 cache=215.0MiB(103467tx) warning='83 of last 100 blocks have unexpected version'
Yes. I am running v0.12.1.0. Compiling 0.14.2 on FreeBSD is a headache.
You has an old Bitcoin Core (without Segwit recognize).
Only 80 blocks are with an exotic version ...
https://www.xbt.eu/ (144 Blocks)
Only 80 blocks are with an exotic version ...
https://www.xbt.eu/ (144 Blocks)
Code:
2017-07-20 08:45:34 UpdateTip: new best=0000000000000000007a3eed0bbf2bc517760e19aedc235fca12738ea089f2bd height=476675 version=0x20000002 log2_work=86.79112 tx=240559896 date='2017-07-20 08:42:36' progress=0.999998 cache=215.0MiB(103467tx) warning='83 of last 100 blocks have unexpected version'
Jump to: