Show Posts
|
Pages: [1] 2 »
|
Since 4/2023 the chainset/UTXO set size started to increase much more rapidly than all years before. What's going on? While the exact size varies between node instances, here's one node as reference. From a peak of a 34% increase between 2019-2020, and an average of 15% per year between 2019 and 2023, the year that ended now saw a size increase of 100%, and a big rate increase since the last week of April or so: There's no corresponding increase in blockchain size: While the rate of increase in blockchain size did change since 2/2023 (not sure why, Ordinals?), due to an apparent increase in average block size from maybe 1.2MB to 1.7MB, it's nowhere near the change in UTXO set size. Also the start date is misaligned.
|
|
|
In a multi-wallet file configuration, I executed "reconsiderblock". The console said "Executing command using ... wallet", making it appear only one is affected. I chose another wallet file and executed the same command again.
Despite of what it says, does it only affect the single selected wallet or all of them?
If just one, what are the implications?
Background:
This is on v0.18.
Core crashed during catching up due to being out of space for the UTXO db. I fixed it and restarted. It recovered and continued syncing blocks for about a minute, then stalled doing nothing. The log revealed repeated "ERROR: AcceptBlockHeader: block ... is marked invalid" for the same block. I restarted, the same situation continued, so I executed "reconsiderblock". It seemed to resume okay.
|
|
|
Bitcoin Core (0.18) crashed due to chainstate LevelDB hitting "not enough space". Freeing up some space and restarting seemed to have worked without a hitch. I think not even a hint in the log file (after the restart, not the previous crash run).
Is it absolutely safe as far as data consistency is concerned, or is it better to continue from a backup?
|
|
|
What's a simple way to create in Core a transaction with a fee < 1000 sat/kb? (That's kvbyte, right?)
Does the testnet behave the same as far as fees are concerned?
|
|
|
I haven't used Coinbase in a while. Is anyone able right now to use Coinbase as a wallet without any phone number linked? Logging in now, some actions like deleting "Confirmed Devices" redirect to the Security settings page, which looks like this: The 2 available options are: adding a phone number, and choosing when to require 2-step verification. The 2-step setting shows a loading animation that never disappears, and I can't change the mode. When changing and clicking "save", it opens an unclear window titled "Change Send Limit Settings" which can't be confirmed without, I'm guessing, a phone number defined. By the way, what's the lowest tx fee they allow nowadays?
|
|
|
I'm encountering IBD getting semi-stuck, without any errors in the log. It's something I've noticed a few times in the past, and it was usually resolved by quitting and restarting Core. But now that doesn't help. I'm hitting consecutive cases where Core just sits idle 10-15 minutes, downloading continuously at 150KB/sec (slow for normal sync), but with practically no CPU usage, no disk I/O except occasional flushing (I'm guessing), and no special log messages. Running v0.18.0 on Windows, pruned mode. The first time I noticed this behavior now was after block 561672. Don't know if that's significant. Here's Core's CPU and disk I/O graph for about 10 minutes:
|
|
|
Can Core be told to list the sizes of all blocks?
And particularly also in pruned mode, assuming all headers are stored permanently.
|
|
|
Is there a list of wallet.dat format versions, and what's changed in each? What are some reasons to want to -upgradewallet, or the contrary, to not upgrade? While debug.log reports nFileVersion, it isn't the format version. Is there a way to get Core to report the actual format version?
|
|
|
Since upgrading from v0.15 to v0.17 the log shows: Unknown wallet records: 1
Can this be considered normal? What might the unknown record be?
|
|
|
Core's ZIP and signed setup hold different EXE files. The hashes of all contained EXE are different. Shouldn't they be the same? In bitcoin-0.17.0.1-win64-setup.exe: b6654d2434bfef6e8f81ff3bc549539374c940a844dcaf9469415132711a449b bitcoin-qt.exe 561442e669badd354d3dfefc9a7b5c4567edf5f68b56124954856d408c17e2c1 bitcoin-cli.exe b0b3df442169f93bc62289964407c8a48b6ad1119e164c9d0b0996b5b9010a41 bitcoind.exe
In bitcoin-0.17.0.1-win64.zip: cf3a82120ff04a5aee448e689a1dbb0e481c641c48492da4d664097fd330a0ac bitcoin-qt.exe 4119eefced33a5a91dd42eb1e68b3f492fd5218ffa544c92ce2365d6766c1ed2 bitcoin-cli.exe cb6f8183c30e57ac1d5faea4cda4bbe1c3651598aa6a481108b9e9dbfc63e32a bitcoind.exe
|
|
|
Different sites report different blockchain sizes. Some of that might be explained by base-2 or base-10 sizes, but that's not enough to explain the large difference between the extremes. Is there a site that accurately reports in bytes both the raw size and Core's on-disk size (without the UTXO set)? 201.57 GB (= 187.72 GB 2 if it's GB 10) - BitInfoCharts (block 527,582) 178.99 GB (= 192.18 GB 10 if it's GB 2) - Coin Dance171,292 MB (= 179.61 GB 10 if it's MB 2) - Blockchain.info (updated once per day) 161.20 GiB (= 173.08 GB 10) - Bitcoin.com
|
|
|
With Core in pruned mode, is there a command to get the hash of the oldest stored block?
|
|
|
The "increase transaction fee" option doesn't offer a way to customize the new fee. How come, and how's the automatic new fee calculated?
|
|
|
Almost all of the files under chainstate are touched frequently, but I have a handful that are unchanged since the initial sync months ago. These files start with 0, unlike the recent ones that start with 6.
Are the 0 files still in use, or are they leftovers that weren't automatically deleted?
|
|
|
As far as I understand, signmessage just proves knowledge of the pubkey in a P2PKH. Once you send from an address the explicit pubkey becomes known. Ignoring "don't reuse addresses", am I correct in understanding that once you spend a TXO sent to an address there's no point anymore in signmessage for that address?
And if so, why does signmessage prove knowledge of the pubkey instead of the privkey? I get the impression almost everyone believes it's there to prove privkey control.
|
|
|
Why doesn't Core's GUI mark differently spent transactions? Is there a simple way to check whether a TX(O) was spent?
|
|
|
gettransaction for a tx that was sent with RBF shows "bip125-replaceable": "no". Is the flag reset once a tx gets into a block?
|
|
|
Are there plans for a minor or bugfix update for Core, or is the next version going to be 0.17?
|
|
|
In a GitHub discussion related to multi-wallet there was a mention of (optionally?) each wallet having "its own bdb environment", and storing each wallet.dat in a directory along with db.log and a /database subdirectory. What's the idea here and what's the database directory supposed to hold?
|
|
|
|