29
If you were a miner, what are the steps you would take to create the extra (21,000,012.5th) bitcoin?
Where in the source code is this exactly (link)?
There are two components to CVE-2018-17144. There is a crash bug and an inflation bug. Both are triggered by almost the same scenario: a transaction contains an input multiple times.
In general, how this would ...
11
The first thing Bitcoin-QT does is verify that the data stored on the disk is valid. Among other checks this includes verifying the last 288 blocks (the past two days in expectation). This task involves a large number of signature checks and will take some time to complete. Only after the startup checks have successfully completed will the connections to the ...
10
Error -28 is defined as RPC_IN_WARMUP, see https://github.com/bitcoin/bitcoin/blob/master/src/rpc/protocol.h.
The bitcoind server has just started and is still processing its stored blockchain data to figure out what it has. It can take several minutes. Activating best chain is one stage of this, where the daemon looks at the blocks it knows so far and ...
9
If you look at the output script for that output, you can see it looks like this:
RETURN PUSHDATA(32) [some garbage]
This script, beginning with OP_RETURN, is called a null-data output, and is used to store arbitrary data in the blockchain. These outputs can never be spent, there is no way to make the script ever evaluate to true. Because of this, they ...
7
try this:
bitcoind getrawtransaction 2f50fdf7adbf58e91d738869948f4b191eb3cafa016c6df7e9182c06e4513852 1
note the 1 at the end, which instructs bitcoind to operate in verbose mode.
7
Click "Show scripts and coinbase" to see what that output really is. In this case it's RETURN PUSHDATA(32)[8013...]
RETURN (or OP_RETURN) causes the output to be unspendable. The PUSHDATA then is just a way to insert the 32 bytes 8013... into the blockchain.
The significance of that data is not necessarily known to anyone except the person who created the ...
6
A signature check failed for a valid transaction. This likely indicates a CPU or RAM problem with the system you're running on (even though you don't see regular errors in normal operation, Bitcoin does so many computations during validation that it's likely to see them more).
The result of this is that bitcoind marked the chain this transaction was in as ...
5
I've found what was wrong. It seems that technical info is not up to date to the current Bitcoin Core version (0.11.2.0). Since version 0.11 (12 July 2015) the minimum relay fee is 5 times bigger (from 1000 Satoshi to 5000) so the transaction has not enough fees to be relayed.
Here you could find a discussion about the topic.
5
bitcoind has a -daemon command line option that will cause it to run in the background. That is likely to work better than using nohup.
There should be a debug.log file in your bitcoin data directory where any errors will be logged.
5
Your wallet is probably old enough that uncompressed public keys are used instead of compressed public keys. Segwit only works with compressed public keys so you cannot currently use segwit with your addresses.
However you can upgrade your wallet to using compressed keys. To do so, first start Bitcoin Core with the -upgradewallet option. That will upgrade ...
4
Define a JAVA_HOME environment variable with the path to your jre/jdk installation in it. That worked for me.
4
Transaction too large
Is your wallet made up up of many, many small amounts? Have you visited any sites giving small amounts of Bitcoin away for "free"? If so, your client is coughing up on the fact that all the small transactions are costing more than the fee they incur to spend.
4
The message ERROR: AcceptToMemoryPool is to do with your node accepting new transactions from the network and doesn't have anything to do with your local sync state. It just means that someone made a transaction and broadcast it to you which does not respect the rules of your current software version.
It should really be "INFO" rather than error, or simply ...
4
This would be normal if you just started your bitcoind service and it is still verifying downloaded blocks.
It can be a result that bitcoind did not had time enough to write changes to disk last time it was used or that it downloaded blocks but didn't prozess them jet.
Just let bitcoind run a bit longer and try the command again.
Here is a similar answer ...
4
What is happening here is that blockchain.info parser seems not to work well when decoding Pay-to-multisig scripts (P2MS).
All the outputs but last two contain Pay-to-multisig scripts as ScriptPubKey (1-3 Multisig for all but the very last one, that is 1-2 Multisig). The last two are normal Pay-to-PubkeyHash (P2PKH).
If you check the information in blockr....
3
The decoding error is not really an error, per se, just an OP_RETURN. OP_RETURN is used for storing data in the blockchain and that's what this transaction is doing. It's not actually a spendable output, so the block explorer is getting confused and puts out a decoding error.
3
Unable to decode output is what Blockchain.info displays for any output that does not conform to a set of standard output script templates. Such outputs do not have associated addresses so there really isn't anything that a block explorer can show about them.
As stated by other answerers, the specific reason that this output could not be decoded is because ...
3
It's possibly omni data, such as tether, which blockchain.info can't decode, see https://www.reddit.com/r/omni/comments/5zs411/i_cant_receive_btc_unable_to_decode_output_address/ - used for coins like tether, safex, etc.
It's like ERC20 tokens on ETH, but on the BTC blockchain instead - these coins, e.g. tether, don't have their own blockchain, instead they ...
3
The ancestors of a mempool transaction T are unconfirmed transactions that this transaction T depends on in order to be included in the block chain (i.e. that are referenced by its inputs).
The descendants of a mempool transaction T are (necessarily unconfirmed) transactions that depend on this transaction T in order to be included in the block chain (i.e. ...
2
The transaction wasn't going through because of the newly implemented "dust transaction" policy that makes it so that no output of a transaction may total less than 54.3 micro-bitcoins. One of my outputs was below this threshold. So I fixed that, but then the output to the "change" address was pulled below 54.3 uBTC and it still failed. I haven't found a way ...
2
An answer can be found on bitcoin talk
https://bitcointalk.org/index.php?topic=177855.msg1852355#msg1852355
Quote from deepceleron on bitcoin talk
This is your GPU returning invalid hashes from it's kernel. This is
because new drivers are crap for older cards.
Uninstall AMD APP SDK
Uninstall AMD Catalyst Install manager: choose "uninstall ...
2
you should download the bootstrap.dat - this will take the time for the blockchains to catch up from days to two hours... google it.
2
It sounds like you are passing the whole transaction on the command line, but your operating system has a limit on the maximum (combined) length of command line arguments, which has been exceeded. The message "Argument list too long" is an OS error, not from bitcoind itself.
You should be able to use the -stdin argument from bitcoin-cli to pass it via ...
2
You have to spend your bitcoins in small amounts. I don't think there is any other way. Try to send as large as possible to pay less fees.
This piece of code is preventing QT from sending transactions that are larger than 100Kb.
unsigned int nBytes = ::GetSerializeSize(*(CTransaction*)&wtxNew, SER_NETWORK, PROTOCOL_VERSION);
if (...
2
I had the same problem and while trying to find a solution I found many people suggesting to install the x86 version of Java which is stupid if you actually run a x64 operating system. Others suggested to try out MultiBit HD which isn't officially released yet, that's probably not a good idea either. Took me quite a while but I figured out how to get it ...
2
What does this mean? I'm running the command on the same machine where the daemon is running, so no remote connection needed.
It's not talking about the connection between your command line and the Bitcoin daemon, it's talking about the connection between your Bitcoin daemon and other Bitcoin daemons.
How can this happen? Why does a stable running ...
2
The error message explains the program. The Flags field has a bad type -- it must be a JSON integer.
2
I finally got assistance from the support agent David. He has explained the situation in details and helped me to solve the problem.
To pass verifications, I needed to confirm email & phone on this page
https://www.coinbase.com/verifications
Then I uploaded my ID photo on this page:
https://www.coinbase.com/verifications/documents/new
After that I ...
2
The regtest difficulty is not 0. It is around 0.0000000005 initially (corresponding to 1 hash in 2 being valid), and retargets the same way that the main network does, every 2016 blocks.
The fact that you see this error is a bug though, which will probably be fixed in Bitcoin Core 0.11.
2
Try changing it to rpcallowip=192.168.0.0/24. Wildcard support was removed from bitcoind, more on reasoning here:
https://github.com/bitcoin/bitcoin/pull/4102
rpcallowip=192.168.0.0/24is CIDR notation that is functionally the same as 192.168.1.*.
Only top voted, non community-wiki answers of a minimum length are eligible
