|
You're going to need to be more specific with output of the commands you are using. Right now, your question is fairly unintelligible.
|
|
|
|
Great help this this start with this [866dda7c] binary and end with 160 character is that right for pubkey
The stuff in (and including) the square brackets is the key origin information I mentioned. The public key will follow the closing square bracket ( ])and is either 66 or 130 hexadecimal characters. After the pubkey will be a closing parentheses followed by a pound symbol ( #) which is then followed by 8 (or so) characters for a checksum. |
|
|
|
That pk is shorthand for public key. It is part of a thing called Output Script Descriptors. Descriptors are a way to represent the information other than private keys that are needed to sign for an input. They also include something called Key Origin Information which just gives the derivation path information for a pubkey if it was derived (and if that information is intended to be shared). Descriptors are mainly used for imports as they succinctly represent everything the wallet needs to know in order to construct a PSBT. As a user, this field is meaningless to you and has no effect on how you receive or send Bitcoin. You could think of it as a different way to write an address, although no wallet will take it. |
|
|
|
0.19.1 Release NotesBitcoin Core version 0.19.1 is now available from: https://bitcoincore.org/bin/bitcoin-core-0.19.1/This minor release includes various bug fixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: https://github.com/bitcoin/bitcoin/issuesTo receive security and update notifications, please subscribe to: https://bitcoincore.org/en/list/announcements/join/How to UpgradeIf you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/ bitcoin-qt (on Linux). Upgrading directly from a version of Bitcoin Core that has reached its EOL is possible, but it might take some time if the datadir needs to be migrated. Old wallet versions of Bitcoin Core are generally supported. CompatibilityBitcoin Core is supported and extensively tested on operating systems using the Linux kernel, macOS 10.10+, and Windows 7 and newer. It is not recommended to use Bitcoin Core on unsupported systems. Bitcoin Core should also work on most other Unix-like systems but is not as frequently tested on them. From Bitcoin Core 0.17.0 onwards, macOS versions earlier than 10.10 are no longer supported, as Bitcoin Core is now built using Qt 5.9.x which requires macOS 10.10+. Additionally, Bitcoin Core does not yet change appearance when macOS "dark mode" is activated. In addition to previously supported CPU platforms, this release's pre-compiled distribution provides binaries for the RISC-V platform. 0.19.1 change logWallet- #17643 Fix origfee return for bumpfee with feerate arg (instagibbs)
- #16963 Fix unique_ptr usage in boost::signals2 (promag)
- #17258 Fix issue with conflicted mempool tx in listsinceblock (adamjonas, mchrostowski)
- #17924 Bug: IsUsedDestination shouldn't use key id as script id for ScriptHash (instagibbs)
- #17621 IsUsedDestination should count any known single-key address (instagibbs)
- #17843 Reset reused transactions cache (fjahr)
RPC and other APIs- #17687 cli: Fix fatal leveldb error when specifying -blockfilterindex=basic twice (brakmic)
- #17728 require second argument only for scantxoutset start action (achow101)
- #17445 zmq: Fix due to invalid argument and multiple notifiers (promag)
- #17524 psbt: handle unspendable psbts (achow101)
- #17156 psbt: check that various indexes and amounts are within bounds (achow101)
GUI- #17427 Fix missing qRegisterMetaType for size_t (hebasto)
- #17695 disable File->CreateWallet during startup (fanquake)
- #17634 Fix comparison function signature (hebasto)
- #18062 Fix unintialized WalletView::progressDialog (promag)
Tests and QA- #17416 Appveyor improvement - text file for vcpkg package list (sipsorcery)
- #17488 fix "bitcoind already running" warnings on macOS (fanquake)
- #17980 add missing #include to fix compiler errors (kallewoof)
Platform support- #17736 Update msvc build for Visual Studio 2019 v16.4 (sipsorcery)
- #17364 Updates to appveyor config for VS2019 and Qt5.9.8 + msvc project fixes (sipsorcery)
- #17887 bug-fix macos: give free bytes to F_PREALLOCATE (kallewoof)
Miscellaneous- #17897 init: Stop indexes on shutdown after ChainStateFlushed callback (jimpo)
- #17450 util: Add missing headers to util/fees.cpp (hebasto)
- #17654 Unbreak build with Boost 1.72.0 (jbeich)
- #17857 scripts: Fix symbol-check & security-check argument passing (fanquake)
- #17762 Log to net category for exceptions in ProcessMessages (laanwj)
- #18100 Update univalue subtree (MarcoFalke)
CreditsThanks to everyone who directly contributed to this release: - Aaron Clauson
- Adam Jonas
- Andrew Chow
- Fabian Jahr
- fanquake
- Gregory Sanders
- Harris
- Hennadii Stepanov
- Jan Beich
- Jim Posen
- Joćo Barbosa
- Karl-Johan Alm
- Luke Dashjr
- MarcoFalke
- Michael Chrostowski
- Russell Yanofsky
- Wladimir J. van der Laan
As well as to everyone that helped with translations on Transifex.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
3a80431717842672df682bdb619e66523b59541483297772a7969413be3502ff bitcoin-0.19.1-aarch64-linux-gnu.tar.gz
657f28213823d240dd3324d14829702f9ad6f0710f8bdd1c379cb3c447197f48 bitcoin-0.19.1-arm-linux-gnueabihf.tar.gz
10d1e53208aa7603022f4acc084a046299ab4ccf25fe01e81b3fb6f856772589 bitcoin-0.19.1-i686-pc-linux-gnu.tar.gz
1ae1b87de26487075cd2fd22e0d4ead87d969bd55c44f2f1d873ecdc6147ebb3 bitcoin-0.19.1-osx64.tar.gz
206d8d92189d22e735393abebeb7a2e7237a119dd448b4a40df8c357da1287b2 bitcoin-0.19.1-osx.dmg
aa7a9563b48aa79252c8e7b6a41c07a5441bd9f14c5e4562cc72720ea6cb0ee5 bitcoin-0.19.1-riscv64-linux-gnu.tar.gz
f2591d555b8e8c2e1bd780e40d53a91e165d8b3c7e0391ae2d24a0c0f23a7cc0 bitcoin-0.19.1.tar.gz
69e4d7f710a29be6ead2ef5da2905736b7cea107213ae6ddde3bcca8affbb8fd bitcoin-0.19.1-win64-setup.exe
56323ec91afecd8e321a2925c0ca5f1da8b2ae1c99f4e08a3652e1dc68908717 bitcoin-0.19.1-win64.zip
5fcac9416e486d4960e1a946145566350ca670f9aaba99de6542080851122e4c bitcoin-0.19.1-x86_64-linux-gnu.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBCAAGBQJeZiE8AAoJEJDIAZ42wulkkQsQAIlvZ9Em4wm2jpn4L7QUJgCE
4Mr6Q/tCPMs4U15q4wkjoBbdP06Bts1DzV0m/qoirTKoTKCCyRwdaeRn+Oj5Kkoh
MuyPt9EEsrnNk80xaPXSpYnhYjqSGrKux+IuHrlZtCy0QEoeIiOVaWWEtEe6I/eU
lvooE8ywxcUvsOwU3Kga0WnCA0WsfwduMAU+LvmtiXgjudsWvoERwHav+eiQva60
kgfwK5W+XI0lt7clFw6zPXBTZeWWhc97fp1uKv7KBPpACHWgKUaXP3WPMHZhsnSF
1L5fi5EcafjNzbbUusmgo807xThM5eMFZQpzHFZhiFNngW6mjxyEo1m2vrvVE8mN
1LZ7h1QahdSUVsgr+w/JkN1Wx9WcJyzGvFuH7dIbe1J6kb5IMyUKESEtTkWgJeo4
5MCk9pwvstAXcXPnWbNolrBo2IB9mrFC9o/9n2ZCyncCofre8BmbIsvxVqBu4hfE
9E4rCTHDGwWvCDYY68iWdlnyUl9FAvYB8UEOYs4o4f1fDMLdbOEqDojIa7ZnOJwV
oPth/MJxHcaCHNTAk7981LbOyn/oJMMzly4br5WFqWbdgzdXUSBTZDoeT26gdX8P
rnCo7JMvaxcvE8AASD9OpegKZP/E5TnHEzcgkVncABj9gVrsuOm7DlTFsE9YuRv+
jerPsU4Izg+hoVdUiuPT
=Iefa
-----END PGP SIGNATURE-----
|
|
|
|
|
Github is an easy place to host an open source project's source code. You don't have to use github, it's just the most convenient and easiest to use. There are other platforms for hosting open source projects such as GitLab and Bitbucket.
You don't need to use any of those, but without open sourcing your code, you are less likely to have success. People prefer to be able to view the source code to verify that you aren't stealing their money.
|
|
|
|
|
What, exactly, are you trying to do or learn?
Old code is probably not easier to learn. It's often more complicated or does not separate things that should conceptually be separate. While the current codebase is fairly complex and tracing functions requires jumping around a lot, it should still make more sense than old code where everything was in one place and all mixed together.
|
|
|
|
I managed to stop bitcoin (it was pretty much unresponsive while trashing the disk, allowing for a mouse click every minute or so) and had to find the configuration settings, which are not in bitcoin.conf. That file is empty.
I found the settings in the registry, and I modified this setting to read 4096:
nDatabaseCache
You probably shouldn't be modifying the registry values. Those are Qt specific settings, if you ever run the bitcoind rather than bitcoin-qt, then those settings won't transfer. Only bitcoin.conf is universal to both. The bitcoin.conf file is supposed to be empty, it has no settings to start with. You add things to it. So you would add the dbacache setting as it is not already there. Anyway, I could be looking into moving the chainstate to a SSD, but I'd like to know the amount of writes it receives before doing so. Is it going to wear down an SSD fast (seeing as SLC is suggested)?
There are fewer writes with a higher dbcache. While I don't have exact numbers, with modern hardware you will probably move on to newer hardware before seeing any noticeable degraded performance. And SLC lasts longer too. As mentioned, I set the buffer to 4096, and bitcoin now uses 5.6GB of memory. I guess there must be some extra memory consumed that scales with the buffer setting (besides the buffer itself).
Yes. dbcache is just the database cache. There is other memory being used that do not have user configurable parameters. Progress is now at 80% (up from 58% yesterday) so I guess a week more and I am done (if I don't do the chainstate optimisation). And if the chainstate is only about 4GB, maybe offer a fast sync, having bitcoin temporarily cache the chainstate in memory and only do bulk writes occasionally? That way, rotating disks would be able to keep up during synchronization.
IIRC the database uncompressed in memory (leveldb does some compression on disk), is 6 or 7 GB. With dbcache=8000, the whole thing fits in memory. This significantly boosts performance because it basically never gets flushed to disk. Perhaps there could be a dynamic dbcache thing where Core tries to determine how large it should be, but no one has done that yet. For now, the default is low so that Core works on low end hardware too. I merely feel there is basis for optimizations so bitcoin synchronization could run much better on rotating disks, and to use less memory than 5+GB while doing so.
Feel free to try to do this yourself. Every release contains several optimizations but at the same time, we are fighting against blockchain growth. If we improve sync time by 20%, but the blockchain grows 20% larger, then it's a wash and the sync time doesn't change. It's hard to make IBD go faster, but there are continual improvements to try to make it faster. |
|
|
|
|
When it crashes, does it crash with an error? If so, what is that error?
Please post the contents of the debug.log file.
|
|
|
|
Previously I managed to make a signature on Console of the Bitcoin Core using the Legacy Address, but when trying with the SegWit Address the following message appears: Address does not refer to key (code -3) Please explain and the solution. Thanks. There is no solution and you cannot sign a message with a segwit address. This has been the case since segwit was introduced. See https://github.com/bitcoin/bitcoin/issues/10542 |
|
|
|
There are many web-service/app which serves bitcoin. What is their tech prototype ?
As my understanding, they must enter bitcoin network by a node. How do they provide service on internet ? I guess they talk to some bitcoin core node by rest/RPC by IP address and then expose their service by web interface.
They run Bitcoin Core as part of their backend. Their APIs and whatever else is part of their service accesses the RPCs as needed. The RPCs are never directly exposed to the internet. |
|
|
|
|
No. RPC is not exposed over the internet and it is not safe to expose it to the internet.
Nodes communicate using the P2P protocol. There is no need for another node to directly control another node using the RPC commands.
|
|
|
|
|
There are many reasons, but it mostly comes down to technical debt in Bitcoin Core's codebase.
Originally, Bitcoin Core did not build a UTXO set. Instead it indexed every transaction in the blockchain and would look up transactions directly. So when a new transaction arrived, it would lookup the transactions specified in their inputs and check whether the specified outputs were marked as spent. There was no separate UTXO set as we do today. So to get the UTXOs for an import, you had to rescan the entire blockchain. Even after the change to construct a separate UTXO set, this hasn't really been changed.
The second issue is the wallet itself. The wallet does not work with UTXOs. It uses entire transactions, which you cannot get from the UTXO set. The wallet computes the balance by iterating through every transaction stored and checks whether each output belongs to it before adding its amount. So there is no explicit UTXO set in the wallet either, it has to check every transaction it stores. Because of this, we cannot use just the UTXO set as we require storing the entire transaction, even if only one UTXO as actually ours.
The last reason is that users expect to be able to see their transaction history and be able to look at transaction details. Both of these are not possible without a rescan. Just the UTXOs do not provide the transaction history, and the UTXOs also do not give any other details about the incoming transaction.
Reworking the wallet so that you can just scan the UTXO set (and so that does things with just UTXOs too) is on my list of things to do. But there are other priorities in the wallet right now as what it does now is still mostly sane.
|
|
|
|
|
This method of pruning was never implemented. Bitcoin Core uses a different method for pruning that is more efficient.
With this method of pruning, parts of the merkle tree is still stored, not just the root hash. It's more than just the block header. As transactions get spent, their txids get pruned from the merkle tree and the intermediate merkle branch hashes are stored. So if you were to perform a double spend, looking up the input would fail either because the txid is no longer stored as it has been hashed with others into a merkle branch, or it is still there but the particular output you are spending has been marked as spent. Either way, it is still safe.
But this is not as efficient and harder to reason about than how Bitcoin Core does pruning today. Bitcoin Core today builds a separate database of just the UTXOs. As a block is processed, all of the transactions are verified and the UTXO set is updated. When a block is done processing, it actually doesn't need to keep the block around because the UTXO set is what determines the chain state. So in Bitcoin Core, after a block is deep enough, its transaction data is discarded in entirety. The block header is still kept in another database, but the block data itself is deleted. This is safe because all of the important information, the UTXOs, are stored separately in the UTXO database. So if a double spend were to occur with a transaction that has been pruned, the output being spent would not exist in the UTXO database and thus that double spend is invalid.
|
|
|
|
|
Sad to see another topic get derailed into another block size and LN argument. /locked
|
|
|
|
generatetoaddress is for regtest only. It is only used for testing purposes. It cannot be used on mainnet. Bitcoin Core no longer has mainnet mining capability. This has been removed for a long time
What? Since when? Works fine for me: Didn't work last time I tried it, but that was also a while ago, so I probably just misremember. |
|
|
|
|
generatetoaddress is for regtest only. It is only used for testing purposes. It cannot be used on mainnet.
Bitcoin Core no longer has mainnet mining capability. This has been removed for a long time because it is not worth CPU mining (as mining with Bitcoin Core was). Even if you do use a version of Bitcoin Core that has mining capabilities, you will never find a block.
If you just want to learn how mining works, do it on regtest or testnet. You will need external mining software. Running a CPU miner on mainnet won't get you anything. You probably won't find any shares that can be submitted to a pool either.
|
|
|
|
1. Yes, this version number (5.7.1) is under "help".
Go to Help > About Bitcoin Core not Help > About QtAddress WIF mqHRuQJ7yZMTy8rYHSJnmUVWC1eY9UsxRW
That's not WIF, it's not a private key. Here's an example TestNet:
Priv Hex: d3751d33f9cd5049c4af2b462735457e4d3baf130bcbb87f389e349fbaeb20b9
Priv WIF: cUfkJKKBr962B4JcCvKv3TZPgsLn6mGxwqDrANjvrsZZvzim1p9V
Pub Key: 03c49741ee0b1c03ec1478da5157bd41709ae7a23f36fbff8b5c18a5222cc62a9e
Address WIF mqHRuQJ7yZMTy8rYHSJnmUVWC1eY9UsxRW
-------------- BitCoin Core -----------------
P2SH Address: 2N8fMnWYo2h9JfZZvYFnPC73baYn5E3oyiU
--------------- My calculation: --------------------
P2SH Address: 2N31hbddcKtjwUyhuN6csz8dNgtYiaXcvZY
How did you compute this P2SH address? I've imported that private key and it does not produce a P2SH segwit address with an uncompressed pubkey. The address that Core produces (the one that you have listed) has a compressed pubkey. What makes you think that it is uncompressed? That you have calculated a different address?
Your calculated P2SH address is incorrect and will result in lost funds. You have hashed the public key and just made that hash the hash inside of the P2SH. That is incorrect. The public key is not a script and it is not the redeemScript. The correct thing to do is to produce the Segwit scriptPubKey, hash that, and put that hash inside of the P2SH. The Segwit scriptPubKey is 00146b227b4934af1a8f9648b40c3614dec300abf435. Note that it contains the pubkey hash but has more to it than just the pubkey hash. The hash of this script is a91a60e23a8ce5654cbefb50cdee7c05acfc82b1 which means that the P2SH scriptPubKey is a914a91a60e23a8ce5654cbefb50cdee7c05acfc82b187. This corresponds to the address of 2N8fMnWYo2h9JfZZvYFnPC73baYn5E3oyiU produced by Bitcoin Core. |
|
|
|
|
It should be in getnetworkinfo under localaddresses. It should also be logged in your debug.log file.
|
|
|
|
Question 1:
Assume some node is offline for a long time. After it reconnects to block chain, how does it know what is latest block? As his peer nodes maybe "wake up just now". From their view of chain, maybe the current tip is not the really Latest block.
A node will connect to many peers in a way that is unlikely to have many peers that are also behind. The reason for this is twofold. Firstly, a node will store a database of peers and some information about those peers. When it starts up, it chooses peers from that database and chooses them based on some "goodness" information it stores. Secondly, if that database is too small or has a lot of offline nodes, then it will use the DNS seeders. The DNS seeders will filter for nodes which are up for a long time so new nodes will be connected to seed nodes that know many peers. Those nodes will return additional nodes for new nodes to connect to based on node uptime and other characteristics. So peer discovery itself will select for nodes that have been up for a while and thus are likely to have the latest block. But even if all of the peers are just coming online, they too will be connected to other nodes and syncing their own blockchain. As they receive new blocks and block headers, they will be able to serve them to their peers. So if you are only connected to nodes that are still syncing, you will still sync from them as they sync their blockchain from their other peers. Question 2:
I am confused how "IsInitialBlockDownload" function works. What is role of this function? It require a node to download a fixed number of block("nChainWork" must more than "nMinimumChainWork").
It is a bunch of heuristic tests that just check for whether the node is likely to be not synced. It is used to disable certain functionality that is dependent on a recent blockchain (IsIBD will return true before being fully synced). Question 3:
I run the a new node and read its debug.log file. I find Node got many inv tx info. But it does not sync all the block data(blk***.dat). And it does not "Requesting tx data of tx hash". why ?
"2020-02-10T12:21:14Z got inv: tx 04ef3414b55e45555ebfad775b6164827a020a25836e6a4db87eeb9ebee462d9 new peer=4
"
Other nodes will just send invs to all of their peers regardless of sync state and other status. It is up to the receiver of those invs to do something with them. Because your node is still syncing, it won't request those transactions as it might not be able to validate them yet. |
|
|
|
|
Show Posts
