[Question to ChatGPT:]

Question to ChatGPT:
I create an unsigned PSBT file (P2WPKH) in a watch wallet. I then sign the file offline and import the signed file back into my watch wallet. I can then broadcast the corresponding transaction and the transaction is added to the blockchain. However, when I look at the signed PSBT file, I only find “final_scriptwitness” as an additional value, but no explicit signature. What is the reason for this?

In Bitcoin, when you're working with P2WPKH (Pay-to-Witness-PubKey-Hash) transactions, the signature is embedded into the scriptWitness (for SegWit transactions) rather than in the traditional `scriptSig` field used in legacy transactions. This is key to understanding why you only see a `final_scriptwitness` field instead of an explicit signature in the signed PSBT file. Let's walk through this in more detail.

Key Concepts:

1. SegWit (Segregated Witness) Transactions:

• P2WPKH is a SegWit address type, meaning the signature data is stored in the `witness` field rather than in the `scriptSig` field.
• The `witness` is part of the SegWit structure that separates the witness (signature data) from the rest of the transaction data. This helps to reduce transaction size and enable lower fees.

2. PSBT Structure:

• A Partially Signed Bitcoin Transaction (PSBT) is a container format used to allow multiple parties to sign a transaction in different environments (e.g., one party signs offline, another party signs online).
• The PSBT for a P2WPKH transaction will typically have a `final_scriptwitness`field once it has been signed.
• The `final_scriptwitness` field in the PSBT contains the actual witness stack, which includes the signature, the public key, and any other necessary data for the SegWit script execution.

   
   Specifically, for a P2WPKH transaction, the `final_scriptwitness` will contain:

• Element 0: The signature (which is what you might expect to see directly).
• Element 1: The public key (needed to verify the signature).

   
 However, the signed PSBT you’re inspecting does not directly show the signature in the traditional format, because SegWit transactions store this signature in the `witness` field, which is represented as the `final_scriptwitness` in the PSBT.

3. The Reason You Don’t See the Signature in the PSBT File:

• When you sign the PSBT offline, the client (whether it's Bitcoin Core or another wallet) will create a SegWit-compatible witness stack that includes the signature and public key for the relevant input(s).
• For P2WPKH, the final_scriptwitness will contain a witness stack (usually two elements): 1. The signature. 2. The public key.

The witness stack itself doesn't explicitly look like a signature in a traditional format. Instead, it looks like a data structure that Bitcoin Core (or other wallets) interpret as the witness for SegWit transactions. The signature is implicitly part of that stack.

So, when you look at the signed PSBT, you're seeing the signed witness data (which includes the signature) instead of a traditional, standalone signature field.

Why do I have to rescan the blockchain for hours to see the correct balance when I add a (old) descriptor/key, but when I broadcast a transaction, it is confirmed in no time at all? Sometimes it really only takes a few minutes to get the first confirmation. I usually end up in the next block or the one after that.  

How does the network check for double spending so efficiently?

Sorry for the maybe stupid question, but I'm stumped right now.

Given: A copy of an old non descriptor wallet without special features (originally created 2013) on an new offline system. Only two addresses were used at the time (2013-2014). Bitcoin Core 28 was able to open this old wallet and it was possible to migrate it to a descriptor wallet. Now listdescriptors shows me thousands of descriptors that I don't actually need. All this on an offline machine.

What I would like to do: I would like to set up a watch-only wallet for the two addresses (i think i need to use the corresponding pkh descriptors) on an online machine and then create a unsigned transaction that transfers the coins from the old addresses to a new hd wallet. I could then sign this transaction offline.

The problem I see is that the core client can't generate new keys in a legacy non-hd watch-only wallet (if there is such a thing at all). Change addresses shouldn't actually be necessary in my case, but I still have the feeling that I'm on the wrong track here. What would be the safest course of action in my case?

Is it possible to have legacy descriptors and hd descriptors in one wallet? Would the core client then derive the change addresses from the xpub keys?

Is it safe to use an address twice (privacy excluded)?

I have read that if the random nonce k used for the ECDSA signature is not chosen at random then someone can calculate the private key.

Is this really a problem in practice?

I make a test transaction for new addresses to make sure that they work correctly.

I use Bitcoin Core 27.1.

I am currently using the Core Client 27.1. I only use the demon so far. If you think it is advisable, I can also switch to the GUI client. But let me first describe my scenario.

I have an offline/cold wallet on a Raspberry and a corresponding watch wallet (on a normal x86 computer). Communication between the systems takes place via cameras and QR codes. This worked quite well in tests. I can easily transfer 2k of data per QR code.

I would prefer to use only the BIP 84 addresses that the Core Client uses by default. And generally operate everything in standard mode. I only need normal Bitcoin transactions (no multisig or anything special). I would like to leave most of the work to the Core Client. I have already looked on the Internet and found this article by Pieter Wuille:

https://bitcoin.stackexchange.com/a/106204

The API call fundrawtransaction seems to be exactly what I'm looking for. But later Wuille says that it has been superseded by PSBT. I am now wondering which direction I should go in. PSBT seems to have a lot of possibilities and is therefore probably generally easier. But I just want to be able to send coins from A to B in a secure and controlled way. With devices that can only exchange QR codes.

How would you proceed?

BT forum shows 27.0 as the latest release. But 27.1 has already been released. Two days ago 26.2 was released.

Why is a subversion still being released in the 26 branch when 27.1 has already been released?

What is best to use if you have no special requirements?

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:

Code:

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?

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/bip39

Is 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).

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.

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

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.