Latest posts of: tiffy

Show Posts
Pages: « 1 [2]

Bitcoin / Bitcoin Technical Support / Re: Some help would be great as I am lost.

on: December 29, 2023, 12:50:01 PM

I'm not a Windows user so not much help here. But I would like to share my modest knowledge. I followed these instructions to set up a full node behind Tor: https://en.bitcoin.it/wiki/Setting_up_a_Tor_hidden_service I used "Linux Method 2". The page also describes how to do this with Windows. You have more plans, but maybe this will give you a start. Quote from: edk1988 on December 28, 2023, 10:14:27 PM this is an enormous barrier to entry, somebody pls help me, i can pay u in sats . I could reformat the SSD and try to re-do the whole business in ubuntu if I had to, but would rather not. If you can invest a bit of money in the project, you could consider purchasing a suitable v-server. This should cost between 10$ and 20$ for a Linux machine per month. Windows is probably more expensive.

Bitcoin / Bitcoin Technical Support / Re: Which version of the Core Client for a cold wallet should I use?

on: December 29, 2023, 01:48:26 AM

Quote from: BitMaxz on December 28, 2023, 11:59:40 PM I don't think Bitcoin Core would work normally on Raspberry 2 it didn't meet the minimum requirements. Read the minimum requirements here https://bitcoin.org/en/full-node#secure-your-wallet It requires 2 GB so this unit where you plan to install the Bitcoin core would not work normally due to low memory unless you configure it to use less memory. Thanks for the tip. But what would be the limitations for my use case (cold wallet)? The page also says: Quote A broadband Internet connection with upload speeds of at least 400 kilobits (50 kilobytes) per second It's about a full node, isn't it? However, the Raspberry 2 will run without a network connection. I start the daemon with the "-noconnect" option. My main concern so far has been not so much the RAM but the RNG. I don't see that there are any problems with memory consumption. But I will allocate another 1GB of swap space.

Bitcoin / Bitcoin Technical Support / Re: Which version of the Core Client for a cold wallet should I use?

on: December 28, 2023, 05:08:05 PM

Thank you very much, so I will use 26. Quote from: satscraper on December 28, 2023, 02:25:59 PM BTW, what is your setup for a cold storage, running Bitcoin Core on persisted volume of Tails or something else? It's a Raspberry 2 with Raspberry Pi OS (based on Debian bookworm).

Bitcoin / Bitcoin Technical Support / Which version of the Core Client for a cold wallet should I use?

on: December 28, 2023, 01:57:10 PM

I apologize if this has been asked before. I know that version 26 of the Core Client was released at the beginning of this month. But Bitcoin.org is still prominently offering version 25. See: https://bitcoin.org/en/download Does this have anything to do with stability? I want to set up a device as a cold wallet. This machine will be disconnected from the network at some point and then never updated again. That's why I'm thinking about it. Should I use the 26 version or should I stick with 25? I am planning a (nowadays) normal hd wallet, as the core client currently generates by default.

Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core: New HD Wallets vs. Legacy

on: October 11, 2023, 10:09:11 PM

Quote from: nc50lc on October 11, 2023, 04:08:06 AM The reason for the same xprv key is because it's your wallet's "master private key" which is the 'm' in the derivation path which is at the upper most level of the hierarchy. The different xpubs on the other hand, are derived down to the account level (see its position in the descriptor) which are derived with different derivation paths as seen in your 8 descriptors. They implement the different address types? (I see: pkh, sh(wpkh), tr and wpkh). When I switch to BIP 44 (in IanColeman's BIP39 tool), I get legacy addresses. Exactly the legacy addresses that getnewaddress outputs with: Code: bitcoin-cli -rpcwallet=MyWallet getnewaddress -address_type legacy And as Account Extended Public Key the xpubkey of the corresponding descriptor is displayed. I think I'm starting to understand this. I don't understand the math but what it does. Quote from: nc50lc on October 11, 2023, 04:08:06 AM Example descriptors: Yes, that's what they look like. When you talk about "change", do you mean the Bitcoins, which are transferred to yourself if you do not spend the total amount in the inputs? This is the path with the "1" (m/84'/0'/0'/1) I think. If I set "External / Internal" to "1" in the BIP39 tool, the path changes and other addresses are generated. These are then the internal addresses for the change? Quote from: nc50lc on October 11, 2023, 04:08:06 AM Quote from: tiffy Can I then also create unsigned transactions with the watch-only wallet, which I then sign on my cold wallet? In Bitcoin Core, it can be done with RPC commands. Or in the GUI, you'll just need to activate "Enable PSBT controls" in the wallet settings. You have helped me a lot again.

Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core: New HD Wallets vs. Legacy

on: October 10, 2023, 08:57:31 PM

Quote from: achow101 on October 10, 2023, 01:18:50 AM The reason is that keys are not the same as addresses, and it is not a one-to-one mapping of pubkey to address. There are multiple addresses for a single pubkey as there are multiple address types. The purpose of descriptors is to make it clear which address type to create. However you've completely bypassed that by taking the key out of the descriptor and trying to compute the address manually. The reason you don't get the same address is most likely because you have chosen the wrong address type. Quote from: nc50lc on October 10, 2023, 04:37:36 AM I see that you've referred to my reply there. Since you've successfully derived the correct public key, the issue is the selected tab under derivation path: IanColeman's BIP39 tool has reserved different address type per tab, Where the standards "BIP44", "BIP49" and "BIP84" tabs derive legacy, nested-SegWit and native-SegWit respectively. While in "BIP32" tab, it'll default to legacy no matter what the derivation path is; and in "BIP141" tab, it'll derive the one selected in "Script Semantics" drop-down menu. Through your explanations, I think I finally understood. Thanks a lot. It was in front of my eyes all the time. My hdkeypath starts with "m/84". This means that it is an address in BIP84 format. Gosh, now I understand what those numbers in front of the paths mean. IanColeman's BIP39 tool generates all addresses, pubkeys and privkeys when I select BIP84. Great. Is BIP84 ok? Can I use such an address normally on an online exchange like Kraken? I did nothing else. Bitcoin Core has chosen this format itself. Thus, I would hope that it is a common standard. When I call "listdescriptors true" I get 8 entries, but they all have the same xprivkey. If I call "listdescriptors" I also get 8 entries, but with a total of 4 xpubkeys. IanColeman's BIP39 tool also shows me one xpubkey out of the four. In the line "Account Extended Public Key". With this xpubkey I can then make myself a watch-only wallet right? Can I then also create unsigned transactions with the watch-only wallet, which I then sign on my cold wallet? I will of course never transfer a private key to the watch-only wallet. Another thing I'm wondering: Aren't hd wallets easier to crack? After all, you "only" have to guess a private child key and then you can use the xpubkey to calculate the xprivkey. Right?

Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core: New HD Wallets vs. Legacy

on: October 09, 2023, 10:34:08 PM

Quote from: achow101 on October 08, 2023, 10:45:34 PM You keep talking about HD wallets, and I want to stress that both legacy and descriptor wallets are HD wallets. There is no way to create a non-HD wallet in Bitcoin Core. Regardless of whether you make a legacy wallet or a descriptor wallet, you will be making an HD wallet. Being HD or not is not really relevant to your question. Hello achow101 Thank you for your patience. Yes, I thought hd wallets and descriptor wallets were synonyms. Now I understand it much better. So excuse my ignorance. Quote from: achow101 on October 08, 2023, 10:45:34 PM If you really want to have a paper backup, it is possible to do this with descriptor wallets by using the RPC `listdescriptors true`. This will output all of the descriptors in the wallet (there aren't many) with their private keys included. You can write that down on paper if you really want to. Note that it is case sensitive. Also, you can't do this with legacy wallets. Thank you. That is already close. I have experimented with it and also used "bitcoin-cli getaddressinfo". To calculate the missing private keys in the hdkeypath I therefore followed these instructions https://bitcointalk.org/index.php?topic=5351210.msg60007045#msg60007045 The tool calculates the public key for my test address in the keypath correctly but shows another bitcoin address. I will research further there. But if you have any idea what could be the reason, please let me know. You have helped me enough as it is. Thanks again for that.

Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core: New HD Wallets vs. Legacy

on: October 08, 2023, 10:08:09 PM

Hello achow101 Thank you so much for your detailed answers. I really appreciate it. Quote from: achow101 on October 08, 2023, 02:02:25 AM Note that all newly created wallets are HD wallets. "Descriptors" and "legacy" refer to the internal structures of how the wallet manages keys and scripts. Descriptor wallets use output script descriptors specified in BIPs 380-386. Legacy wallets are just a bunch of keys that may or may not be generated deterministically (depending on the wallet version) and have some confusing and unexpected behavior when it comes to determining what transactions belong to the wallet. Good to know. I still have a lot to learn. Quote from: achow101 on October 08, 2023, 02:02:25 AM The implementation of descriptor wallets is entirely transparent to the user. The user should not feel or have to do anything meaningfully different with a descriptor wallet than with a legacy wallet. As such, backups are done in the same way - you must backup the entire file. There is no paper backup method. This is currently my main problem with the new hd wallet. I can find instructions on the net on how to save something on paper again. But they are quite obscure instructions and so far I do not really understand what I would really do there. Not having a paper wallet, not having my keys on paper, makes me feel insecure. I'm creating something, backing it up, but I don't understand exactly what it is. Quote from: achow101 on October 08, 2023, 02:02:25 AM Quote from: tiffy on October 07, 2023, 09:22:19 PM How do I get the private key to an address? This is one of the most noticeable differences. With descriptor wallets, you cannot export the private key for one address. This is because a child private key combined with the parent public key can be used to compute the parent private key (and hence all other child private keys). This is a risk inherent in BIP 32's unhardened derivation. As such, descriptor wallets disallow the export of child private keys in order to mitigate the risk of accidentally exposing the parent private key. Thank you for pointing this out. It shows me once again how little I know. Now I understand a little bit better why the client does not give out the keys, I think. Quote from: achow101 on October 08, 2023, 02:02:25 AM But you shouldn't be exporting individual private keys anyways. The wallet does not use just one private key, so having an individual child private key is really not that useful. Why not? Every Bitcoin address still corresponds to a ECDSA keypair where the private key gives me control over the corresponding UTXO. Or does the hd wallet change anything about that? Quote from: achow101 on October 08, 2023, 02:02:25 AM Quote from: tiffy on October 07, 2023, 09:22:19 PM What disadvantages do I have when I use a legacy wallet as cold wallet? It's rather difficult to create a watchonly wallet from a legacy wallet. You want your private keys in cold storage, but you still need to have an online wallet that contains the public things in your wallet so that you can learn about new transactions as well as create unsigned transactions that will be signed on your cold wallet. With a legacy wallet, this is rather difficult to do. Descriptor wallets make this very easy to do. In a pinch, I can just use a web blockchain explorer. Quote from: achow101 on October 08, 2023, 02:02:25 AM Since legacy wallets will soon become unsupported, you'll be unable to make use of any new features that may become available on Bitcoin. Notably, legacy wallets already cannot create Taproot addresses, so they are completely unable to use Taproot at all. Descriptor wallets support Taproot out of the box already, and will be able to support any future address types as long as a descriptor is designed for them. I don't even know what taproot is. Working without printed keys or at least a seed goes against my personal guidelines of robustness. Of course, I could get over it, but I wouldn't feel safe with it. Having the private keys for the UTXO on paper is just a good feeling. When I only have wallet backups on electronic storage media, this is not robust for my taste. Software changes. The keys remain. I have to save the keys anyway. Why shouldn't I be able to write them down as well? It's just my emergency backup when everything else is lost. And it's independent of electronic devices. That's just to explain my motivation. Am I missing something or is my position suboptimal? What actually happens when I convert a legacy wallet to an hd wallet? Then the already existing ECDSA keypairs remain the same or not? Please excuse the many questions without proper understanding. For me hd wallets are completely new.

Bitcoin / Bitcoin Technical Support / Bitcoin Core: New HD Wallets vs. Legacy

on: October 07, 2023, 09:22:19 PM

Hello I would like to set up a cold wallet with Bitcoin Core. Here's how I would created the wallet: Code: bitcoin-cli -named createwallet wallet_name="MyWalletName" descriptors=false So far so good only this warning worries me: Code: { "name": "MyWalletName", "warnings": [ "Wallet created successfully. The legacy wallet type is being deprecated and support for creating and opening legacy wallets will be removed in the future." ] } I understand that it's all done through hd wallets now. But I can't find any good documentation on how to store and handle this for a cold wallet. What am I backing up there on paper and how do I get it in a simple way? How do I get the private key to an address? Will signing transactions with bitcoin-cli work the same way as with a legacy wallet? I find it all confusing compared to how it used to be. How long will legacy wallets be supported? What disadvantages do I have when I use a legacy wallet as cold wallet? I really only want to use bitcoin-cli (in combination with "bitcoind -noconnect") and the usual Linux tools on my cold wallet machine (Raspberry Pi 2 ). Everything on the terminal. So should I better switch to a hd wallet or can I stay with legacy? Thank you for your attention. tiffy

Bitcoin / Bitcoin Technical Support / Re: Best practices installing Bitcoind on a Linux Server (Debian 11)

on: June 11, 2023, 08:13:19 PM

Thank you all for the useful advice. I'm working through right now. Quote from: ETFbitcoin on June 11, 2023, 09:59:53 AM Maybe OP wanted to say he want to run pruned node. In fact, I don't know exactly what a full node is. In the meantime I have done some more research and I think the option "blocksonly" does what I want (only download blocks and ignore unconfirmed transaction). I would like to limit the network traffic for the time being. And now maybe another stupid question: The Bitcoin Daemon doesn't do any mining? I haven't found any option with which I can switch off mining. As far as I understand, the mining software runs separately and only uses the Bitcoin Daemon to communicate with the network. Is my understanding correct? In that case, there would be nothing else for me to do at this point, because I don't want to mine.

Bitcoin / Bitcoin Technical Support / Best practices installing Bitcoind on a Linux Server (Debian 11)

on: June 10, 2023, 12:47:45 PM

I apologise if this has already been answered somewhere. But I'm having trouble finding best practices instructions for installing the bitcoin daemon (bitcoind) on a Linux Server (Debian 11). Requirements: No mining No full node The daemon should connect to the network via a VPN or TOR (both are present) I'm interested in a watch-only service that provides the complete blockchain online for me personally. I would like to be able to use RPC commands, e.g. to query the balance of a specific address. I have solid experience with running Linux servers. No experience with running Bitcoin services. My understanding so far is that the bitcoin daemon is included in the Core Client and can be started independently of the QT client. Thank you for your attention.

Pages: « 1 [2]