It depends a lot on the kind of locking condition you want to satisfy. The addresses that you have mentioned would depict 'standard' locking condition where the user reveals their public key and associated signature in order to spend the locked bitcoins. However, you can create custom scripts and then convert them into standard addresses.
For example, ...
To go from account xpub to address, you must first derive an xpub at the External index (0) or Internal index (1), then derive another xpub from the External/Internal xpub. Take the public key from the resulting xpub and this is the public key used for the address.
For a detailed explanation of extended public keys and how to derive child public keys, take ...
EDIT: I wrote this hours ago, but apparently forgot to hit the post button. There are now a couple great answers, but I'll still post this anyways.
A has previously transferred 10BTC to B. So B has an unspent transaction output (that it can spend) referenced by the address of A.
UTXOs are not 'forwarded to an address', they exist until they are used ...
UTXO are uniquely identified by their outpoint. An outpoint consists of the id of the transaction that created the output and the position in the output list. As transaction ids are the full transaction body's hash, they are collision resistant, and as each position in the output list can occur only once, outpoints can be expected to be unique.
E.g. the ...
A first thing to correct is that UTXOs are not referenced by address, but by the txid that created them. The addresses are purely a human abstraction about locking conditions to help think about ownership.
So in your example what happens is that in the initial transaction tx0 created by A, B was credited with 10 BTC. Assume that transaction only had one ...
For Pay2PubKey addresses, it's always 160 bits of entropy, regardless of the address format (old, 1... or the new Bech32 format)
Pay2ScriptHash addresses, in the old Base58 format (3...) have 160 bits of entropy. In Bech32, they have 256 bits. You can read more about why the developers increased it here and here.
It's possible to do this externally, but it's tricky to get right and a cause of loss of funds if you do.
You need to correctly identify transactions you can spend. This is relatively trivial with P2PKH addresses, but a little more involved if using more exotic script types. You need to understand rules like transaction maturity before considering a UTXO ...
So how we can calculate txn fee before signing and sending txn for external addresses?
As a reference:
P2PKH P2SH-P2WPKH P2WPKH
Input : 592 WU 364 WU 272 WU
Output : 136 WU 128 WU 124 WU
All transactions include 40 WU by default. If your transaction spends a P2SH-P2WPKH or P2WPKH ...
"fundrawtransaction" and "walletcreatefundedpsbt" are wallet RPCs. They add inputs and change outputs from your wallet to aim for a specific feerate for the transaction.
These operations inherently require the relevant wallet. Change addresses are generated by the sender's wallet, and inputs have to come from the wallet of the sender. If you don't have that ...
You can use scantxoutset command which was introduced in Bitcoin Core 0.17. It scans the UTXO set for any UTXOs for the address (or output script) provided. It is faster than the rescan when you import a private key.
Type help scantxoutset to see the help.
If I understand correctly you can use this command getrawtransaction to get a transaction that is in your node's mempool i.e. an unconfirmed transaction.
However, if you are looking for a transaction that has been confirmed, you'll need to know the blockhash of the block in which that transaction resides.
> bitcoin-cli getrawtransaction "...