Bitcoin Core does not interface with ASIC miners directly. Bitcoin Core no longer contains efficient mining code because mining with a CPU is pointless and just a waste of energy. The implementation of SHA256 is just used for the computation of the hashes used all over Bitcoin, not for any mining purposes. I'm curious about interfacing with a rig. Can you tell me if the rigs being sold these days interface directly to the bitcoin network or whether they interface with a computer which interfaces with the bitcoin network. In the latter case, what software is available to run on the computer, and is the interface between the computer and the rig standardized, or does the software need to be customized for each model of rig out there?
Asics these days can either connect to a mining pool directly or connect to a driver running on a computer which connects to the pool. Either way, they usually run some version of cgminer or bfgminer which are software that can communicate with these devices. These software also speak the stratum protocol used by pools and the getblocktemplate protocol used by Bitcoin Core (and some other pools). Would there be any serious interest in publishing my code as part of Bitcoin Core, and would it be possible to license this particular module, or perhaps publish it as shareware, and earn a little money from it?
No, not as a part of Bitcoin Core. |
|
|
|
|
This is just an issue with decoderawtransaction. Those transactions are segwit transactions which decoderawtransaction confuses for 0 input transactions. If you use getrawtransaction with verbose set to true, you'll get the correct decoding.
|
|
|
|
@HCP why can't I decode his rawtx on other decoders? is it because it's (non-standard?) unsigned rawtx created by electrum?
Honestly I'm not 100% sure... I can only guess that given all other "decoders" (including Bitcoin Core) report it as invalid, that Electrum is doing something non-standard when serialising an unsigned transaction using the "export"/"copy" funtionality... most likely to facilitate MultiSig or offline signing. I would guess it's added info regarding the "inputs" being used so that (offline or CoSigner) Electrum knows which private keys it needs to sign with. Electrum uses it's own unsigned transaction format which is incompatible with other wallet software. The format is basically a typical transaction but with some extra data (like xpubs) packed into the scriptSig. |
|
|
|
|
What is the actual response from bitcoind? Usually the error messages are informative.
|
|
|
|
|
You cannot delete things from a wallet file. Deletion is not a supported operation.
|
|
|
|
|
No, probably not. Exploiting any speculative execution vulnerability requires executing malicious code on the target machine. In the binance hack, the attackers did not gain access to the servers themselves but rather abused API keys and other user information in order to construct and authorize a transaction that shouldn't have been authorized.
|
|
|
|
If its not automated how come there was a massive 1000 ish ban at once? each case has a different context, doubt you had the time to check it out with such a short amount of time with so many bans.
Posts are reported to moderators who check out the report. If the poster needs to be banned, the moderator sends a ban report up to a global mod or admin. The global mod or admin handles all of the ban reports they get at around the same time. Either the admins or global mods don't need to check every account because they trust the moderators to have already done so, or they check quickly because every such report contains references and links to the plagiarism post and to the source text so checking takes little time. |
|
|
|
|
The only way to "send from" specific addresses is to use createrawtransaction or createpsbt and make the transactions with the inputs that you want manually. All other commands where you do not select the inputs will have Bitcoin Core do coin selection on all inputs in the wallet, regardless of "input address" (side note, that's not really a thing that actually exists) or label (or account if you are using an older version of Bitcoin Core).
|
|
|
|
|
Protocol version 106 is incredibly old. Bitcoin Core (the most commonly used node software) will not respond to anything older than version 31800.
Why aren't you using the modern version message (which is largely the same format) with a higher version number?
|
|
|
|
Because the redeeming condition requires the pubKey and the sig, does it mean anyone with the pubKey and sig can redeem the bitcoin?
Yes. Anyone who can provide the public key and a valid signature can spend that output. However there is no one signature; the signature is specific to the spending transaction. So in order to create a valid signature, you also need to have the private key for the public key. |
|
|
|
So I was thinking. I just encrypted my wallet for the first time and the file size cut about in half. I am assuming this is due to some sort of compression in the encryption stage, but it causes a possible loss of privacy by doing this.
Say I have an unencrypted wallet of 50mb and it turns to 25mb when encrypted. What happens to the other 25mb of unencrypted wallet file that's left on the hard drive? Couldn't a data recovery specialist recover these keys unencrypted?
Sorry if I am being ignorant and thanks for any input.
Edit: unless the encryption is done before the compression.. Duh lol
The other 25mb of data is not private key data. The reason you see a size reduction is actually not because of compression. When your wallet is unencrypted, the private key format is much larger for backwards compatibility reasons. In the original Bitcoin client, private keys were stored as OpenSSL serialized them. This serialization included things like curve parameters and the uncompressed public key for that private key. This information is redundant and completely unnecessary, but has to be serialized for backwards compatibility reasons. When you encrypt the wallet, the private key that gets encrypted no longer contains all of that unnecessary information, it just contains the private key itself. This is much smaller even when encrypted , and since it happens to every single private key, a lot of space is saved. |
|
|
|
The Windows 32-bit has had some performance and other issues. While it still works, it does also hold back some other future improvements. By removing it now, we won't have to worry about supporting Windows 32-bit for those future improvements. You can read the discussion about this here: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-04-11-19.00.log.html (it's during the Platform Deprecation topic towards the end). It was removed under the assumption that few or no people were using Windows 32-bit. Note that Bitcoin Core 0.18.0 still had Windows 32-bit binaries built. They simply weren't uploaded for now. If there is enough people who are using Windows 32-bit, they can and will be uploaded too and future releases will have them as well. |
|
|
|
Am i right in saying that this warning has been removed in 0.18.0 ?
Yes. It has been removed since it's constantly triggering now. |
|
|
|
50% of blocks using different version of software, or signalling for something? What is that?
The warning is benign. There is no soft fork happening and miners aren't currently signalling for anything. This warning is triggered because miners are using overt Asicboost which basically uses the block version number as a nonce. This means that blocks are being produced with unexpected version numbers which triggers this warning. |
|
|
|
|
What wallet software are you using? Is it fully synced? Was the Bitcoin sent to the correct address?
|
|
|
|
Nevermind, I misread your question. What version of Bitcoin Core are you using? If you do open the debug console and do getwalletinfo for both wallets, do they show the same thing for hdseedid? If you do getaddressinfo <addr> where <addr> is the address that was generated for each copy of the wallet file respectively, do you see the same thing for hdkeypath? You should see the same thing, regardless of HD or not, due to the keypool. It is likely that you simply made an error somewhere or the wrong wallet file was loaded. |
|
|
|
|
This is completely expected. You copied the wallet after generating addresses. and opened the copy. This is the same as opening the original wallet file itself because the wallet file (and thus the one you copied) contains all of the information about the addresses already generated.
If instead you had copied the wallet file before generating addresses, you would see the addresses repeated in the copy.
Regardless, both the copy and the original will generate the same addresses, and you should be able to observe that.
|
|
|
|
This topic has been moved to Trashcan. Duplicate |
|
|
|
Today I thought I would update the windows 7 node (a few days behind) by copying the latest 'blocks' files and copying the whole 'chainstate' folder.
That is guaranteed to not work. Nodes download blocks out of order so they will get written to disk in a different order which depends on the order that blocks were received. If you copy the database from one node to another, that database will be incorrect and say that blocks are exist at a particular location when they actually don't. Furthermore, you didn't copy the block index which is in the index folder inside of the blocks folder. That actually says where blocks are actually located and, IIRC, the chainstate database contains references to the block index. If you want to copy the blockchain from one node to another, you must copy the entirety of the blocks folder and the chainstate folder so that the correct databases and indexes are included. I noticed that not all of the previous .dat files were the same size (more than just the latest on the out-of-date node) and I have no idea why.
Not all blocks are the same size and not all .dat files contain the same blocks. As such, not all .dat files will be the same size. As I mentioned, blocks are downloaded out of order. Furthermore, one node may have received blocks that another node has not. Thus the size of the .dat files will vary based on the contents of the file. |
|
|
|
then I get error code: -4
error message:
Signing transaction failed TBF this error is not actually descriptive of what is actually happening. There are two places where this same error is thrown. In one case, signing is actually failing. In the other case (which is what you are hitting here), the wallet is unable to calculate the estimated size of the final transaction which it does by using the dummy signer. So technically it's correct because dummy signing failed (it fails under the same circumstances that normal signing does too), but it isn't terribly helpful and is kind of confusing. Also, correction to what I said above, walletcreatefundedpsbt doesn't actually fill in the metadata. It is just a version of createpsbt which selects inputs and change outputs for you. The metadata is added by walletprocesspsbt. |
|
|
|
|
Show Posts
