 Show Posts
|
|
Pages: [1] 2 »
|
For example: If you're using bitcoind without an arg to change the datadir but rely of the config file to set a custom datadir,
then by setting the default datadir in bitcoin-qt will make it use the same config file in the default data directory and use the settings in it.
In the same manner, if you've been using bitcoind with an arg to set the datadir instead of the bitcoin.conf file, set that datadir in the GUI.
If you already set a custom datadir in Bitcoin-qt, you can use: bitcoin-qt --choosedatadir to set it.
Under Linux, I use the standard ".bitcoin" directory in the user's home directory. I have not changed the location of the directory at all. I start the bitcoind with the command: bitcoind -conf=<MY_PATH>/bitcoin.conf
Similarly, I would start the qt client using: bitcoin-qt -conf=<MY_PATH>/bitcoin.conf
If I have understood you correctly, the bitcoind is a headless "qt" client. If I accidentally start both at the same time, can this lead to data corruption? |
|
|
|
[Yes,
If your wallet is a watching-only descriptor wallet, the "Send" button in the send tab will be replaced with "Create Unsigned".
The wallet is considered "watching-only" if it's created with "disable_private_keys" arg or checkbox.
Then you can only import descriptors with extended pubKey/pubKey into it.
A very valuable tip. I will definitely look into the GUI client next. I assume I can use the same data directory as for the Bitcoind? Can the GUI client hide behind a full node like the Bitcoind? Could the GUI Client be configured like this? connect=FULL_NODE_ADDRESS
discover=0
dns=0
dnsseed=0
listen=0
See: https://bitcointalk.org/index.php?topic=5485846.msg63753896#msg63753896 |
|
|
|
In case the first step to migrate to descriptor wallet isn't followed, and only a single address is available:
Bitcoin Core won't let you proceed to create the (unsigned) transaction for having no available change,
Does this mean that you can also create unsigned transactions with the GUI client? If you want to proceed, you'll have to manually set it by enabling "Coin control features" in the GUI's settings to display "Use custom change address" in the send tab.
Once ticked, you can paste any address that you own to receive the change. In the command line, the transaction has to be manually created.
To be on the safe side, I could perhaps import a handful of the empty addresses in addition to the one or two addresses with a balance and then transfer the balances to new bc1 addresses ? Maybe making a separate transaction for each utxo to a new bc1 address in the new wallet to have relatively easy-to-read transactions. If you set the transfer amount slightly below the balance of the utxo, then that is automatically the fee right? |
|
|
|
Now the fun part, if you have/want to import all those 100 single address descriptors, you'll have to import them using the instructions above.
So instead of just the funded ones, get all the descriptors from the offline wallet's listdescriptors command and import them to the watching-only wallet.
The ranged descriptors still require the range, active, internal, etc. to be specified (refer to the instructions in the link).
What about wallets that have very few addresses with balances? If you create an empty watch wallet in which there is only a single address/descriptor and you create a transaction that does not fully spend the bitcoins on the address, where does the exchange go? Finally, some extra privacy, explain how to run it through a VPN or Tor. This should cover it all.
I'll leave this to others. I had posted something here: https://bitcointalk.org/index.php?topic=5485846.msg63753896#msg63753896However, I use a total of three devices. A server with Tor at a hoster. A laptop at home that connects to the server directly via SSH. And my offline device (not the subject of my little guide). Also I use Bitcoind. |
|
|
|
Thanks again for your comments. I have now successfully implemented this. The VPN was very helpful because I was temporarily connected directly to the Bitcoin network due to a configuration error. However, you don't need a VPN for the finished (very simple) setup. C L I E N T S I D EConfiguration of the Bitcoin Daemon on my local system:daemon=1
connect=127.0.0.1:28333
discover=0
dns=0
dnsseed=0
listen=0
listenonion=0
Host NAME
Hostname SERVER_IP
User USER
LocalForward 28333 127.0.0.1:8333
The connection is then simply made with S E R V E R S I D EConfiguration of the Bitcoin Daemon on my server (replace ONION_ADDR with your own value):bind=127.0.0.1
discover=0
externalip=ONION_ADDR
listen=1
proxy=127.0.0.1:9050
HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8333
TorAddress 127.0.0.1
TorPort 9050
OnionAddrRange 127.42.42.0/24
After you have restarted TOR, you will find your ONION_ADDR under /var/lib/tor/bitcoin-service/hostname |
|
|
|
So this is what you need, basically: - Install Bitcoin Core in your new computer, do not open yet.
- Paste a copy of your wallet.dat somewhere in that computer.
- Open Bitcoin Core with GUI for simplicity, set your preferred settings in the Welcome Screen.
(make sure to set a directory with enough space or enable pruning).
If you are only interested in the keys and the corresponding addresses are known, then you can also inspect the old wallet on an offline machine, right? What does Bitcoin Core actually do when restoring old non-HD wallets? Does it convert them into HD wallets with the old key pool added? |
|
|
|
Why not -addnode instead of -connect, if I may ask? You will most likely want to add other nodes to connect to, like Tor onion nodes and such, in the event that your server node becomes inaccessible or goes down for some reason. But you will at least be able to control which nodes you will get inbound and outbound connections to, instead of showing your IP address to the entire network.
I have now started like this for testing. I might switch later. PS. dns=0 and dnsseed=0 completely shuts down the DNS system in Core, so your IP won't be leaked though that way.
Thanks for the tip! |
|
|
|
Although you're exclusively connected to your full node in the virtual Linux server and prevents inbound connections,
that node may still advertise your IP through addr message or when it receive getaddr message from its peers.
But I'm not sure if any of your config makes a difference on how the remote node create the addr message though.
I see. I have placed the full node behind the Tor network. My bitcoin.conf on my full node now: bind=127.0.0.1
discover=0
externalip=************************.onion
listen=1
proxy=127.0.0.1:9050 I have set up Tor on my server accordingly. The bitcoind now only listens locally. It just works.  I would therefore use SSH port forwarding on my laptop for the connect. Something like this Whereby 28333 is forwarded to 8333 on my full node. That should work, right? I just wonder if my real IP@home can be leaked via DNS or some other detail. That's why I don't dare to start bitcoind at home yet. I think I'll use a VPN with kill switch to be on the safe side. |
|
|
|
I have been running a Bitcoin Core full node as a Tor hidden service for some time now. The node runs on a virtual linux server at a large provider. Now I want to set up (watch-only) wallets with a local bitcoind on my laptop using this full node. The aim is to to be able to generate unsigned transactions with the help of the wallets and to feed previously signed transactions into the network. Above all, I want to prevent my real IP address from being leaked to the Bitcoin network. I will also use VPN software on my laptop. But I don't want to rely on that alone. Below is the configuration I came up with: daemon=1
connect=<address of my full node>
discover=0
dns=0
dnsseed=0
listen=0
listenonion=0
Would this setup suitable for my target to hide my real IP from the Bitcoin network (even without VPN) and using my wallets locally? Is there perhaps a fundamentally better way to achieve what I want to achieve? |
|
|
|
In IanColeman's BIP39 Tool; your binary seed is equivalent to that tool's "BIP39 Seed" that is derived from the BIP39 mnemonic.
Your Master Private key is equivalent to that tool's "BIP32 Root Key" that's derived from the above.
Additionally, your watching-only descriptor's xpub (extended public key) are equivalent to the "Account Extended Public Key" of each address type's specific derivation path.
Thank you again. It's really a great help, even if I've run out of Merit. Would the Core Client fail to create the wallet or issue a warning or block if it does not have enough entropy available when generating the binary seed? Does it read the entropy from /dev/random or also from /dev/urandom? I'm on some kind of embedded system, without a fine-grained clock, with no network, with little inputs, reading from flash which much more deterministic timing for operations. I therefore depend on the hwrng of the Raspi. Hence my concern. Unfortunately dieharder is currently broken on the 32-bit Raspis under Bookworm. I can probably fix this and have other testing options. In case there is a developer reading here: For the future it would be nice to have the option to pass a binary seed to the Core Client when creating a new wallet. Or to have something analogous to sethdseed for the new wallets. Creating a Master Private key and descriptor yourself is not necessarily what a beginner wants to do. But rolling the dice and handing over a binary seed (in a denfied format) is a minor intervention which requires only general computer and mathematical skills, no specific knowledge about Biicoin. |
|
|
|
But what does the Core Client actually do? Doesn't it also have to create a seed internally? So something like: Binary random seed (or is it the master key?) -> xpriv key -> everything else derived from it?
Yes, basically like that, binary seed->m->.... For the " master private key" ( xprv), it's the " m" that you see in derivation paths, it's not the binary seed but is derived from it. The xprv from the lower depths should be called " extended private key" Sorry, I still haven't quite got it. I use https://github.com/iancoleman/bip39 for computation (ironically, not to convert Mnemonic) and terminology. The command bitcoin-cli listdescriptors true gives me, among other things, the lines "desc": "wpkh(xprv............../84'/0'/0'/0/*)#......"
"desc": "wpkh(xprv............../84'/0'/0'/1/*)#......" If I choose BIP84 and enter as BIP32 Root Key, then the tool computes an Account Extended Private Key and an Account Extended Public Key. I also receive the Account Extended Public Key via the command: bitcoin-cli listdescriptors The BIP32 Extended Private Key and the BIP32 Extended Public Key (which the tool shows me below) are then derived from the above Account Extended Keys plus the BIP32 derivation paths. The child keys are then derived from the BIP32 keys. Is that correct? Now my questions: Where exactly does the binary seed come into play? And what do you call the master private key? My guess: The master private key ist der BIP32 Root Key and the binary seed is used to create it? Correct? |
|
|
|
I continued reading the documentary and discovered sethdseed. As I understand it, I can use it to set the seed from which the xpriv key is generated. Do I understand that correctly? I don't know if I want to do that, but would be a nice option.
Yes, but you'll have to encode the " seed" into WIF before it can be accepted by the command. Is there a command for this? But I'd like to confirm that you're actually talking about the "seed" and not the "seed phrase" (words).
Yes, I learned from your posts, among other things, that the Core Client does not support these BIP 39 word lists. I actually mean a binary seed. If so, then you're correct, you can only use that in legacy wallets though.
Okay, then that's out of the question for me. I decided against legacy after your comments In descriptor wallets, importing descriptors built from the master private key derived from a seed is basically the same
So I can't see any advantage of using a legacy wallet to use that command.
Master key is the xpriv key I have in the descriptor list? And I can create this myself with a binary seed that I choose myself? What tools can I use to generate an xpriv key from a seed? Maybe I'll let the Bitcoin Core Client take care of everything. With my level of knowledge, this is perhaps more secure. But what does the Core Client actually do? Doesn't it also have to create a seed internally? So something like: Binary random seed (or is it the master key?) -> xpriv key -> everything else derived from it? |
|
|
|
FYI Linux use various input for it's RNG, including mouse and keyboard you use. Using your Raspberry Pi for few minutes should guarantee strong entropy/randomness.
I continued reading the documentary and discovered sethdseed. As I understand it, I can use it to set the seed from which the xpriv key is generated. Do I understand that correctly? I don't know if I want to do that, but would be a nice option. |
|
|
|
Hi people. I got years trying to restore my wallet.dat file. I think it has 0.02 btc or something like that.
I tryed intallis bitcoin core 25 (actual version) but it tellsme that the wallet restoring file is from another chain.
Either your wallet is incorrect, or your wallet is indeed for a different chain. The error is unlikely to be wrong. Does the Core Client perhaps need the blockchain? Or does it open the old wallet without it? |
|
|
|
It's no cold wallet when the daemon runs on a device that is still connected to the internet, even when the daemon runs with "noconnect". By definition a cold wallet is never ever directly connected to the internet at all.
Yes, I know that. I just want to prevent the daemon from running into unnecessary timeouts and issuing error messages. |
|
|
|
Bitcoin.org is operated by Cobra, not by the Bitcoin Core developers; bitcoincore.org is. I'd advice you to visit that.
Yes, I have already switched to bitcoincore.org. Thanks for the tip. Then, why do you care about the version of Bitcoin Core? You're probably not going to use it in the first place. Cold storage software is better to be a lightweight client like Electrum or Sparrow. Nevertheless, you can still use Bitcoin Core to sign transactions (and of course, nothing crucial of that matter changes from 25.0 to 26.0).
Just uncertainty. But I have received my answer. Thanks for the reference to other clients. I'll keep that in mind. "Manually but using the wallet still" is what I intend to do. See: https://bitcoin.stackexchange.com/a/106204This is certainly also possible with other clients. But I have been running a full node based on Bitcoin Core for weeks. And I run the daemon with "noconnect" on the cold wallet. With this option it didn't use many resources during my tests. |
|
|
|
If it is a non-HD wallet, upgrade it with -upgradewallet (introduced in 0.17+, I believe).
Then use -migratewallet in 0.25 to upgrade to the descriptor wallet.
Sorry, I have a small OT question about this: I thought all wallets were HD wallets. But I think I misunderstood something. Legacy wallets newly created with Bitcoin Core are HD wallets, but the old ones from 10 years ago are/were not, right? |
|
|
|
Thank you all for putting me on the right track once again. And also for the references to the specific algorithms. If this is about finding an easy way to backup your Bitcoin Core wallet to a paper or metal plate,
it should be done the other way around (I've seen your thread about creating cold-storage Bitcoin Core):
Create a BIP39 mnemonic->Derive the Master Private Key->Manually create descriptors with it->Import to a blank wallet
Yes, it was a bit of a XY problem. I actually thought about creating a mnemonic from the master key, which I have now learned is impossible. But the obvious downside is you'll have to use a third-party to generate the entropy which could be using insecure RNG.
So try to find a safe open-source BIP39 tool/wallet that you can audit if you really have to use a mnemonic seed.
Exactly, that's why I don't want to do that. With what little knowledge I have, I prefer to handle things canonically (although I am only just learning what that actually means), You can also just backup the master private key and your descriptors' various derivation paths if the whole descriptors are too long.
I will back up the wallet offline but digitally. Nevertheless, I would like a paper back-up in case of disaster. It should be sufficient to note the master key and the root of the path of the descriptor used (for example /84'/0'/0'/0/*), right? The public part is stored in my watch only wallet (full node), which I use to create the unsigned transactions, which I then transfer to the cold wallet and sign there. That's how I've understood it so far. |
|
|
|
I play around with Ian Coleman's Mnemonic Code Converter. A tool for converting BIP39 mnemonic phrases to addresses and private keys. See: https://iancoleman.io/bip39/Standalone offline version: https://github.com/iancoleman/bip39Is it also possible to calculate a mnemonic from a given extended private key? (For example, the extended key of a wallet created with Bitcoin Core). |
|
|
|
|
