or somehow the database folder disappeared.
As I said, on a clean shutdown, the database folder is deleted by newer versions. 0.19 is new enough. Yes, I have observed this behavior, and now it makes sense. It explains why there is no database folder. The wallets work when I loaded them in Knots 29, with labels and all. The HD logo has a crossing line on it indicating it's not an HD. So the experiment may not have worked because Tails did not properly shut down the wallet and I also did not copy the database folder. But the actual wallet did work thankfully, now I need to plan on a watch-only setup. I will also test the migration tool with some backup. An observation: When I loaded the wallet.dat file on Knots 29, the sha256 checksum changed. What changes are made to the original file? This one: He wrote it gets deleted on (clean) shutdown. I have that directory. I'm running Core 29.1 but I don't have it. I guess it's an old directory that's not used anymore? The reason I'm asking is that I wanna make sure that keeping simply the wallet.dat for backup is enough. When you load a wallet, you should see a database folder, but when you close it, it disappears. If you don't see it, then im assuming this behaviour happens with dbd (berkeley) wallets and not sqlite wallets (more modern ones) which never need that database file. And perhaps really old ones (2013) but that never went beyond the old versions (because I did updates on Bitcoin Core, I assume some updates were applied along the way on the wallet file as I updated) always need that database folder and it's never deleted? Not sure about that. On the experiment I did with the 0.8.x version, there was a database folder, even after closing it. I did not see any errors, but I think I also didn't the see the "Bitcoin is clossing please wait..." message, but I don't remember if that message was there back then. But doing this on Tails may not be reliable anyway, I just didn't want to install these binaries so used Tails for it. |
|
|
|
The last wallet file is from 2019. What I noticed is that there doesn't seem to be a database folder on the main folder,
It depends on the version that was last in use. Newer versions would ensure that all the data from the log files ended up in the wallet.dat file, then delete the database folder, on shutdown. This would also happen periodically during operation. However, older versions and unclean shutdowns would still have the database folder. Im looking at the debug.log and the last times I opened Bitcoin Core the version it says it was v0.19.0.1 Lines that have to do with the wallet: init message: Verifying wallet(s)... Using BerkeleyDB version Berkeley DB 4.8.30: (April 9 2010) Using wallet C:\Users\takuma\AppData\Roaming\Bitcoin BerkeleyEnvironment::Open: LogDir=C:\Users\takuma\AppData\Roaming\Bitcoin\database ErrorFile=C:\Users\takuma\AppData\Roaming\Bitcoin\db.log some other lines here about blocks ad chainstate like "Opened LevelDB successfully" etc then No coin database inconsistencies in the last 6 blocks init message: Loading walet.... BerkeleyEnvironment::Open: LogDir=C:\Users\takuma\AppData\Roaming\Bitcoin\database ErrorFile=C:\Users\takuma\AppData\Roaming\Bitcoin\db.log [default wallet] Wallet File Version = 60000 [default wallet] Keys: 0 plaintext, 1000+ encrypted, 1000+ w/ metadata, 1000+ total (im typing this by hand looking at the screen so im not putting exact numbers) Unknown wallet records: 1 [default wallet] Wallet completed loagin init message : Rescanning... Here it starts scanning and I have some AddToWallet new So I was opening the node and the date says 2020 so I was still using the wallet there and reeving transactions... but there is no database folder, not even a file inside the database folder. The testnet3 folder has a database folder with log. It also has the "ErrorFile=C:\Users\takuma\AppData\Roaming\Bitcoin\testnet3\db.log thing" But for testnet3 the last version on the debug used was 0.15.1 So I don't get it, as I never did any manual updates of the wallet format. So either the wallet.dat will work without the database thing because Bitcoin Core v0.19.0.1 is modern enough to not need it, or somehow the database folder disappeared. The last lines do not seem like there was an error during closing: addcon: thread exit Shutdown: In progress torcontrol thread exit net thread exit msghand thread exit opencon thread exit scheluder thread interrupt dumped mempool [default wallet] releasing wallet Shutdown: done |
|
|
|
I've never heard you needed the chainstate files.
I did not say chainstate files. The files in database/ are not for the chainstate, they are the BDB log files and used for Write-ahead logging. Im assuming there is a way to salvage the private keys from the wallet.dat without chainstate files otherwise I would be screwed.
There is no such guarantee. The log files will contain data that has not been written to the database file yet. Depending on when the wallet.dat was copied, the data may not yet exist in the database file and therefore losing the log files is catastrophic data loss. Would actually be insane you need these files to backup your keys but I will try to find them anyway.
Would be insane to continue to use a database system that requires that. Yeah I meant the database folder. Well the thing is, I managed to go into the old drive that had the full node, ages ago I was running a Windows node, and I kept updating that one. The last version I have saved is binaries for 0.16 so I assume that is what the bitcoin folder was running. There's a bunch of wallets from different years backed up. The last wallet file is from 2019. What I noticed is that there doesn't seem to be a database folder on the main folder, there is a database folder in the testnet folder but not on the main datadir folder. I don't remember deleting any folders so that's weird. I'll have to test those files, hopefully the most recent backups work. |
|
|
|
saved the wallet.dat file
Please clarify what you actually did, as there is no "save" action. By saving I meant, I exited 0.8.6 bitcoin-qt, copied the wallet.dat and then pasted it into the hard drive to open it with the knots 29 bitcoin-qt. This is extremely unlikely to be a backwards compatibility issue. Looking at the log snippet you provided, it is highly likely that the error is a result of only copying the wallet.dat file. Contrary to popular belief, the wallet.dat file is not the only file you have to copy when copying a wallet from one node to another. You also have to copy that database folder.
This is especially true for older versions of Bitcoin Core as shutdown did not always compact everything into the wallet.dat file. Furthermore, copying the wallet.dat without unloading the wallet (or stopping Bitcoin Core) will result in data loss, and therefore detected corruption, because the log files in the database directory contains data before it gets committed into the wallet.dat file.
This behavior is also one of the reasons that we wanted to move off of BDB. SQLite can be configured to specifically not do that and to always write into the wallet.dat file.
I've never heard you needed the chainstate files. I may or not have a copy of the chainstate files of the old Bitcoin Core install where the actual wallet with private keys came from. It may still be there in some old Windows install of Bitcoin Core. Im assuming there is a way to salvage the private keys from the wallet.dat without chainstate files otherwise I would be screwed. Im hoping this is a particular thing that happened by doing this on a Tails live session, perhaps something went wrong there. I will try with the real wallet files on the airgap computer just in case, if I get the same error then im going to need some good ideas in case I cannot find the chainstate files from whatever install the wallet was last used in. Would actually be insane you need these files to backup your keys but I will try to find them anyway. |
|
|
|
You're fine to migrate even from very old wallets. Core still opens legacy BerkeleyDB wallets and the current builds include a one-click / RPC migration to descriptor wallets. If you showed up with a 2009 wallet.dat, it would load; what takes time is the rescan, not the file age.
If this were mine, my sanity path would be: first make multiple offline backups of the original wallet.dat and write down a SHA256 of each copy so you can prove they're identical later. Open it on a machine that's offline (or start Core with networking disabled) just to check getwalletinfo, getaddressesbylabel, and that your expected receive addresses and labels are there. If your node is pruned, do the migration on a full node so the post-migration rescan can actually find everything.
Then use the built-in migration (GUI button or migratewallet) to convert to descriptors and let it rescan. After it finishes, make another backup of the migrated wallet. Verify by listing the active descriptors and spot-checking a few funded addresses. At this point you can simply keep using the migrated wallet, but for maximum peace of mind I like to sweep: create a brand-new descriptor wallet, do a tiny test PSBT spend to it, confirm the change goes to an address you control, then move the rest. Keep the legacy wallet backed up forever and stop touching it.
It's not so easy as I expected, see this: https://bitcointalk.org/index.php?topic=5559987.msg65838895#msg65838895 |
|
|
|
Some have been claiming that it's very easy to migrate old wallets into new versions. but Im already seeing this is not as easy as advertised. Did the test by running Bitcoin 0.8.6 on a Tails live session. The file is hosted in bitcoin.org and the SHA256SUMS.asc file has a valid signature by Gavin Andresen. So I created a wallet.dat file, created some addresses, saved the wallet.dat file and moved it into my fully synced Knots 29 node. I tried opening it with just the GUI and it gets stuck loading forever. I then tried to open it with the bitcoin-qt's console with loadwallet wallet.dat (I placed it inside "wallets" folder where I think it's the modern default spot to place wallets) and it returned this error: loadwallet wallet.dat
Wallet file verification failed. "/home/takuma/software/.bitcoin/wallets/wallet.dat" corrupt. Try using the wallet tool bitcoin-wallet to salvage or restoring a backup. (code -4) This action generated these 3 files: /.bitcoin/wallets/database/log.0000000001 (a binary file of 1MB)
/.bitcoin/wallets/db.log
/.bitcoin/.walletlock (empty file) db.log contains this: file unknown has LSN [some number], past end of log at [some number]
Commonly caused by moving a database from one database environment
to another without clearing the database LSNs, or by removing all of
the log files from a database environment
Page 0: metadata page corrupted
Page 0: could not check metadata page
wallet.dat: DB_VERIFY_BAD: Database verification failed I really doubt the file got corrupted, I created it yesterday. I think this is just bad backwards compatibility. So it doesn't sound as easy as just drop your old wallet file into the latest version and that's it. Now im not sure what are the necessary steps to get it working. If you want to recreate this experiment, you can download the binaries here and try generating a wallet.dat file then try to load it into a modern version: https://bitcoin.org/bin/insecure/bitcoin-core-0.8.6/If you cannot run it because it lacks qt4 libraries, you'll have to download them: https://archive.debian.org/debian/pool/main/q/qt4-x11/Specifically, get these: https://archive.debian.org/debian/pool/main/q/qt4-x11/libqt4-core_4.8.2+dfsg-11_amd64.debhttps://archive.debian.org/debian/pool/main/q/qt4-x11/libqt4-network_4.8.2+dfsg-11_amd64.debhttps://archive.debian.org/debian/pool/main/q/qt4-x11/libqt4-gui_4.8.2+dfsg-11_amd64.debI think it worked with these 3, but if there any missing files then the linux shell should point to them, just download them. Place them properly there: bin/64/qt4bundle/lib/
bin/64/qt4bundle/plugins/ Then run bitcoin-qt calling those libraries: LD_LIBRARY_PATH=$PWD/qt4bundle/lib:$LD_LIBRARY_PATH QT_PLUGIN_PATH=$PWD/qt4bundle/plugins ./bitcoin-qt Then you can test and try to actually load an old walet.dat into a new version. I have not tried with the actual wallet.dat files but it's not looking great when it comes to expecting a smooth backwards compatibility experience. |
|
|
|
I don't know what docker is. No one really has saved older versions with the checksums at least?
This isn't mine nor counts as vouching but this website ( in Russian) has those older versions that you're looking for. However, there are no hashes provided to verify the files' integrity, so try to look for those in any archived old official download pages. Link: bits.media/programms/bitcoin/old/ ( download at your own risk) Yeah, I wouldn't download those, links above seem safer, but im testing the given binaries that are on bitcoin.org in the insecure folder for the 0.8.6 version in a safe environment. It appears all these older versions were signed only by Gavin Andresen? I found his key on Ubuntu and MIT's repository, it is a good signature for the sha256 file, and I managed to get some wallets to look at it's structure, I don't really need the node itself. The thing is, there is an error when you try to load the wallet on a modern client: Wallet loading failed: Prune: last wallet synchronisation goes beyond pruned data. You need to -reindex. (download the whole blockchain again in case of pruned node) For testnet, I run prune because who cares, so it looks like these old wallets wouldn't work in pruned mode. I don't see how redownloading the whole blockchain in pruned mode will do, so I will need to run it in assumevalid=0 to play around with testnet coins in old wallets. But I have also tried with a main chain wallet and it wouldn't load and my node is fully synced. It's stuck trying to load in "Opening wallet: walletname" with the loading bar... so yeah, wtf is up with that. Edit: I ran the bitcoin-qt binaries in a Tails live session and got the wallet.dat files from there. I then tried loading with loadwallet on my normal full synced node and looks like there is an error: Commonly caused by moving a database from one database environment
to another without clearing the database LSNs, or by removing all of
the log files from a database environment
Page 0: metadata page corrupted
Page 0: could not check metadata page
wallet.dat: DB_VERIFY_BAD: Database verification failed What went wrong there? It's the same error as here: https://bitcoin.stackexchange.com/questions/100736/corrupted-old-bitcoin-wallet-file-unknown-has-lsnTrying to open the wallet.dat file generated these files: /.bitcoin/wallets/database/log.0000000001 /.bitcoin/wallets/db.log /.bitcoin/.walletlock |
|
|
|
When it comes to P2SH/P2WSH, the problem is the potential anyonecanspend attack vector. It is very unlikely, that any soft-fork will be "reverted". All Segwit nodes will mark such block as "invalid", if coins will be moved without any signatures. Also, if breaking rules would be so easy, then what about P2PK? You can also use "anyonecanspend attack vector" here, and move any coins anywhere, without any signatures. Because if you would have a client, which would allow always spending any coins, then it would be compatible with the current chain. You can start a node, disable the whole Script, make all coins spendable, and you will sync it to the chain tip, without any problems. More than that: what about "Value Overflow Incident attack vector"? Because that fix was also a soft-fork. You can have a client, which would allow producing coins out of thin air, and it will also successfully sync the whole chain, up to the current chain tip. Are you still worried, that this fix will also be "reverted"? but forcing this unto everyone else is a mistake Why? If soft-forks could be easily "reverted", then any rules could be "lifted", by using exactly the same attack vector. For example: what about 21 million coins limit? If you would have a client, where there would be no halvings, and the basic block reward would be set to 50 coins forever, then guess what: it would sync the whole chain without any problems. Because the reward, claimed by miner, can be always smaller. It cannot be bigger, but coins can be burned, and miners could always decide to burn all new coins and fees in the coinbase transaction. So, a node, which would enforce no halvings, would land on the same chain, just because hashrate majority enforces "soft-forked halvings". a single point of failure were a single seed compromises all your existing and future addresses Then, demonstrate me a practical attack on some HD wallet. Show me, how to get 900 BTC from the puzzle. But this will convert the wallet from non-HD to HD. Wrong. If you make an empty wallet, then it is empty. It contains only keys, which you manually import. If there are no descriptors, which automatically can be used to make new addresses, then if you try to make a new address, it won't work. For example: createwallet "" false true
{
"name": ""
}
listdescriptors
{
"wallet_name": "",
"descriptors": [
]
}
getnewaddress
Error: This wallet has no available keys (code -4)
importdescriptors '[{"desc":"pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)#c6fur0yd","timestamp":"now","label":"one"}]'
[
{
"success": true
}
]
getnewaddress
Error: This wallet has no available keys (code -4)
listdescriptors true
{
"wallet_name": "",
"descriptors": [
{
"desc": "pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)#c6fur0yd",
"timestamp": 1231006505,
"active": false
}
]
}
getnewaddress
Error: This wallet has no available keys (code -4) See? Commands like "getnewaddress" can work, if the wallet knows, how to make a new address. But if it doesn't, then it only stores the things you put there, without adding anything new. I don't know what happens to existing keys. Existing keys are imported, so you can see them in "listdescriptors". But if there are just single keys or addresses, then the wallet does not know, how to make new addresses, so you will have to decide about it manually, generate new keys manually, import them manually, and decide, how they should be handled. but any future keys will be derived from the new assigned hdseed key If you start from an empty wallet, then there are no seeds. You don't have to use public keys in a descriptor wallet. You can even use keyless puzzles, if you want to. It is not possible to create a non-HD wallet with current Core software as far as I know. Empty wallet is a non-HD wallet. No new addresses are automatically generated in a deterministic way, if you don't let the wallet know, how to do that. They are also disabling or going to disable importing and exporting private keys "to protect users". If you use "listdescriptors true", then you can dump the content on a paper, and later import it through "importdescriptors". And you can have only WIF keys, without any HD keys, if you want to. Or even keyless addresses, if you need them. and if you cannot import and export private keys separately from your old wallet, then im not sure what you are suggesting there You can do that, key-by-key, from WIF. What else do you need? Edit: By the way, there is also BIP-42, which made the supply finite. So, are you worried, that there will be more than 21 million coins in circulation, when after 64 halvings, miners would start producing 50 coins again? Because I am pretty sure, that if anyone would try it, then it would be an altcoin. Edit: Meanwhile in Bitcoin Knots: createwallet
createwallet "wallet_name" ( disable_private_keys blank "passphrase" avoid_reuse descriptors load_on_startup external_signer )
Creates and loads a new wallet.
Arguments:
...
6. descriptors (boolean, optional, default=true) Create a native descriptor wallet. The wallet will use descriptors internally to handle address creation. Setting to "false" will create a legacy wallet
... So, if your favourite Knots uses descriptors by default, and if it creates HD wallets by default, then what exactly are you using? Because I guess you always called "getnewaddress", without being aware, that you have a HD wallet. You can use "dumpwallet", and read the text file, that will be produced. I bet you will see some HD seed in it, instead of a long list of WIF keys, without any "master private key". All your arguments are "it has not been hacked yet/reverted yet, so it's good to go". Yes, P2PK is less safe long term, that's why people don't use it, and so is segwit, but it's been made mainstream that it is safe. The fact is, you are assuming an increased dependency of miner goodwill compared to P2PKH, and so I will be using P2PKH, you can keep using whatever you want. Extrapolate this to having your entire wallet depending on a seed forever. The problem is when these so called innovations end up screwing up the rest of the users, such as Core 30's VC spamfest. |
|
|
|
|
I don't know what docker is. No one really has saved older versions with the checksums at least?
|
|
|
|
\Now Core wants to do the same with this or force people to relay spam. The conclusion is that one must run Knots to at least have the options to choose what to do with your keys and what is relayed by your node. None of this breaks consensus, so it should be up to the user, not to some so called developers which kick opposition, that isn't even trying to hardfork the network as others attempted.
Then just run Knots and shut up. The ship has sailed for Bitcoin Core on the topic of HD wallets. Nothing and nobody will get them to go back to the legacy format. Accept the reality. They won't do something just because a tiny minority of which you are a part of may want something. Exactly, nothing must be done about spyware on hardware because only a tiny minority uses open source BIOS on their computers. |
|
|
|
Bitcoin shouldn't have anything but base58 addresses that begin with an 1. Then tell me, should it have P2PK? Because in the Genesis Block, and in many blocks after it, coins were sent to public keys, not addresses. the fact that an attacker needs less bits to steal all funds vs a non-HD wallet has not been disputed Of course, because every HD wallet is in practice a single key, that is expanded in deterministic way. And if you somehow break that key, then you will access everything. But good luck with that. The famous puzzle from transaction 08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15 also used HD wallet. And more than that: public keys from 161-bit to 256-bit range were revealed. Many private keys with lower ranges, up to 70-bit, are known. So what? Over 900 BTC is waiting for you, so just break a single key, and grab them all. Hmm, you don't know how? Well, maybe because it is not so easy, to compromise a HD wallet. So, don't worry too much about HD wallet security. This challenge can prove you, that HD wallets can be safe, otherwise you would sweep all of that instantly, if you would know some weakness. no excuse to not support it But they are supported. You can have a descriptor wallet, and load each and every key from WIF manually. So, what exactly is your problem? Edit: For example, let's assume that you are purist, who wants to use only compressed P2PK with descriptor wallet: createwallet "" false true
{
"name": ""
}
listdescriptors true
{
"wallet_name": "",
"descriptors": [
]
}
getdescriptorinfo "pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)"
{
"descriptor": "pk(0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798)#gn28ywm7",
"checksum": "c6fur0yd",
"isrange": false,
"issolvable": true,
"hasprivatekeys": true
}
importdescriptors '[{"desc":"pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)#c6fur0yd","timestamp":"now","label":"one"}]'
[
{
"success": true
}
]
listdescriptors true
{
"wallet_name": "",
"descriptors": [
{
"desc": "pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)#c6fur0yd",
"timestamp": 1231006505,
"active": false
}
]
} See? It works. If you replace "pk" with "pkh", then you will get your favourite addresses, starting with one. So, just migrate your old wallet, and enjoy it. And you can still use the old wallet, if you want to. Nobody would stop you. Or you can call "createwallet" manually each time, when you want to get a new address. It is up to you. P2PKH is the safer available option. When it comes to P2SH/P2WSH, the problem is the potential anyonecanspend attack vector. If after reading about that you are still okay with it, then keep using addresses that do not begin with 1, but forcing this unto everyone else is a mistake. Similarly, if you are ok with having a single point of failure were a single seed compromises all your existing and future addresses, then go for it, but do not force this unto others. Migrating the wallet with the migration tool. But this will convert the wallet from non-HD to HD. I don't know what happens to existing keys. I assume the existing keys are not part of the new seed, so they wouldn't be exposed to this single point of failure risk, but any future keys will be derived from the new assigned hdseed key. Descriptors per se are not the problem, but the single point of failure that is hdseed. It is not possible to create a non-HD wallet with current Core software as far as I know. They are also disabling or going to disable importing and exporting private keys "to protect users". So you are basically forced to use the migration tool, which means your wallet is an HD-wallet. If you create a blank wallet, you cannot generate new addressess since it has no hdseed, and if you cannot import and export private keys separately from your old wallet, then im not sure what you are suggesting there. Having the keys isolated with each having it's own private keys is better. This makes it more cumbersome to deal with it, so what. Having to use some old computer to avoid Intel's/AMD spyware is also more cumbersome, but that is the only option we have. 99% don't do this, and this is part of the problem. HD wallets may be more handy, but introduce risks, same thing. Because Intel and AMD make it hell to flash their BIOS', you are forced to use older computers. Now Core wants to do the same with this or force people to relay spam. The conclusion is that one must run Knots to at least have the options to choose what to do with your keys and what is relayed by your node. None of this breaks consensus, so it should be up to the user, not to some so called developers which kick opposition, that isn't even trying to hardfork the network as others attempted. |
|
|
|
Does the PSBT carry any compromising date on any of its stages? what about if you save the output of "copy to clipboard" on a txt file? specially when signed
Aside from the transaction's Locktime, there's no defined date/time in the PSBT. The " save to file" and " save to clipboard" options just differ on the encoding but the PSBT are the same. The former is in binary format and the latter is in base64. I meant to say data, in general, that could be used by an attacker if they got the file or the base in raw format in some txt file (metadata leakage, derivation paths, etc etc) |
|
|
|
Jameson Lopp is most definitely a bad actor sponsored by god only knows who. Not just that, but he's one of those dumb kinda smart guys who thinks he is way smarter than he actually is and has almost no long-term attention span. He mentioned my website in this little blog, which is part of why we've taken a fairly aggressive blockchain stance in v4. ( https://blog.lopp.net/griefing-bitcoin-testnet/) I don't understand changing Core for an ADHD spaz bad actor who gets off on drama. I've read the parrot answer from "them", but it feels so structured and unnatural. VC's start shitcoin projects and they lobby people with bigger twitter megaphones like Jameson Lopp to promote the platforms which allow these shitcoin projects (such as Bitcoin Core v30). Just follow the VC-money. Everyone supporting v30 has some $altcoin on their twitter bio. |
|
|
|
So what's next, drop base58 support? That would be good, because base58 is never enforced by consensus. If you write everything in base16, then it would work as well, if not better. For example: instead of 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, you can use 0062e907b15cbf27d5425399ebf6f0fb50ebb88f18c29b7d93. It is equivalent. And there is no a single place in the protocol, where people would ever be forced to use base58. Edit: More than that: Nobody forces you to use 32-bit checksum. You can use 256-bit checksum as well: SHA-256(SHA-256(0062e907b15cbf27d5425399ebf6f0fb50ebb88f18))=c29b7d937e3049e279391e62fdf00c12def7444013ddf6215808d10e9f2d5996 And then, instead of writing 0062e907b15cbf27d5425399ebf6f0fb50ebb88f18c29b7d93, you can use the full version, and write 0062e907b15cbf27d5425399ebf6f0fb50ebb88f18c29b7d937e3049e279391e62fdf00c12def74 44013ddf6215808d10e9f2d5996. Nobody will stop you. So, when it comes to wallets, you can use anything you want. No, it obviously wouldn't be good to drop base58 support, im not even going into that. In fact, all of this nonsense started since segwit was introduced, which opened the can of worms we have now. Bitcoin shouldn't have anything but base58 addresses that begin with an 1. At least a proper node can ignore these. As far as HD wallets, the fact that an attacker needs less bits to steal all funds vs a non-HD wallet has not been disputed, and this defeats any ease of use cases of HD wallets over non-HD wallets, for also obvious reasons. Non-HD wallets barely need any maintenance, just let the software load the keys, it's just a collection of private keys sitting on an airgap computer, no excuse to not support it. |
|
|
|
Managing keys with the old wallet.dat format for those that do not feel safe with HD wallets (because the math checks in like it or not) is obviously a much more manageable method than having to create a wallet.dat per address.
I didn't say that it is a good solution, I said that it is one.  You have many options and nobody is forcing you to do anything. You can write your own wallet as the last resort. The whole cryptocurrency environment pretty much uses HD wallets, but sure Bitcoin Core adding it is the problem.  The whole crypto industry is retarded, just look around. Hardware wallets, SVPs, pruned nodes, shitcoiners spamming the blockchain. Everything about the crypto industry is a scam, most people run software on Windows with NSAware on their BIOS. It's all a big joke. If you really believe that then you should leave the space instead of whining here for almost every single thing that is changed. Why would I do that? Im just asking why is Core forcing users into this, no clear answers yet. "Technological debt, look it up." This is as close of an answer I've seen here. So what's next, drop base58 support? Looks like Knots will probably continue to support legacy wallets, so I will be using that. They allow you to create non descriptor wallets on version 29 which in Core they do not, so it points on that direction. They should give users options, and users should choose the tradeoffs, that's all. But that is obviously against Core's ethos, just look at v30. |
|
|
|
The number of bits that need to be obtained by an attacker is always smaller with legacy wallets vs HD wallets, nothing of what you have provided disproves this fact.
You are confusing things. The things are as equal as they come. - Complete compromise: Legacy wallet.dat file or seed phrase from HD wallet.
- Partial compromise: One private key from legacy wallet or 1 private key from HD wallet.
In the case of partial compromise you can't do anything more than empty 1 address with that. Even if your xpub is exposed, if hardened derivation is used there is no danger.
If you are thinking of random guessing attack on the seed phrase then sure you need to guess much fewer bits to steal the whole wallet when compared to the legacy method. What about it? This is not a valid concern. If you believe you are smarter than statisticians and you feel like this is something to worry about, just use 1 HD wallet per address. Generate any number of wallets that you need. Problem solved. Managing keys with the old wallet.dat format for those that do not feel safe with HD wallets (because the math checks in like it or not) is obviously a much more manageable method than having to create a wallet.dat per address. The whole cryptocurrency environment pretty much uses HD wallets, but sure Bitcoin Core adding it is the problem. The whole crypto industry is a scam, just look around. Hardware wallets, SVPs, pruned nodes, shitcoiners spamming the blockchain. Everything about the crypto industry is built to make fiat, not to harden BTC holdings, most people run software on Windows with NSAware on their BIOS. It's all a big joke. |
|
|
|
However, I have not seen a convincing argument that explains how new wallets aren't less safe than old wallets because of how the key derivation works.
Maybe first you have to provide arguments as to why they would be less safe? All the arguments I see are "but you would need to leak your xpub key" or something like that. So what? I still means you need to leak less data to end up a in complete disaster vs having to leak private keys on a key by key basis.
Leaking your xpub is the equivalent of publicly publishing all your addresses online. Why would anyone do this? Very few users will do this by mistake, and so what? We can't prevent users from submitting their seed phrase to a website so why would this be any different? They only need to get one seed and they get all future addresses you will ever generate.
What about it? Why would anyone reasonable would willingly create such a single point of failure when you can avoid it?
The legacy format comes with many of its own issues, which are a bigger deal than any issues with the new format. And then on top of it is suddenly some people decide that you are forced to migrate the wallet into the new format (along with the other nice up and coming Core V30 features being discussed). Like who the fuck are those people to force users into managing private keys the way they want to?
Nobody is being forced to do anything. Using Bitcoin Core as a wallet is entirely optional. You can stay with the old version or you can use any other wallet of your liking. There's no excuse to not maintain support for legacy wallet.dat for those that do not believe in this nonsense. What they should do is keep support for both formats, and try to improve features for the legacy wallet, because watch-only features could be improved without descriptors.
Technological debt, look it up. For people that only need base58 addresses, this seems like yet another excuse to force people into the new VC-backed money tokenfest that comes with V30.
One has nothing to do with the other. And being forced to make backups is a good think actually. How is a backup that only needs to be stolen once a good feature.
Every seed phrase backup works the same way, the legacy wallet.dat works the same way. If someone gets access to your recent backup just once, it is game over. The number of bits that need to be obtained by an attacker is always smaller with legacy wallets vs HD wallets, nothing of what you have provided disproves this fact. |
|
|
|
|
The arguments for the new wallet.dat are clear: descriptors have some easy-of-use features like PSBT, easier to maintain watch-only wallets, no need for wallet.dat backups as you create new addresses and the new fancy signatures.
However, I have not seen a convincing argument that explains how new wallets aren't less safe than old wallets because of how the key derivation works. All the arguments I see are "but you would need to leak your xpub key" or something like that. So what? I still means you need to leak less data to end up a in complete disaster vs having to leak private keys on a key by key basis. They only need to get one seed and they get all future addresses you will ever generate.
Why would anyone reasonable would willingly create such a single point of failure when you can avoid it?
And then on top of it is suddenly some people decide that you are forced to migrate the wallet into the new format (along with the other nice up and coming Core V30 features being discussed). Like who the fuck are those people to force users into managing private keys the way they want to? There's no excuse to not maintain support for legacy wallet.dat for those that do not believe in this nonsense. What they should do is keep support for both formats, and try to improve features for the legacy wallet, because watch-only features could be improved without descriptors.
For people that only need base58 addresses, this seems like yet another excuse to force people into the new VC-backed money tokenfest that comes with V30.
And being forced to make backups is a good think actually. How is a backup that only needs to be stolen once a good feature.
|
|
|
|
|
Does the "Restore wallet" on the GUI do anything else that isn't simply creating a wallet folder inside the /.bitcoin/wallets/[nameofwalletfolder]/ and then makes a copy of wallet.dat in there, or does it do anything else?
How is [nameofwalletfolder] name choosen? im assuming it cannot overwrite an existing wallet.dat if you select the same wallet name for the folder..
I don't think I will be using this, why not just manually create a folder with the name you want and put the wallet.dat file in there.
|
|
|
|
|
Show Posts
