text:
Is it possible to add custom data on blockchains transaction such as a payment reference?
As we traditional bank it is possible to add a reference when sending money away.
Is it possible to put some short custom data when sending a blockchain transaction, such as payment reference ?
I'm not seeing this anywere on Bitcoin Core. Seen a parameter "input data" for ethereum but look like its only sued for smartcontract ABI.
I'm asking this because it would help to put reference on transaction to apply accounting betwen two parties (eg if one sent multiple invoice to someone wich pay through blockchain)

No, there is no “reference” field on Bitcoin transactions. While the recent Inscription hype demonstrates (once again) that you can attach arbitrary data to Bitcoin transactions, the “Bitcoin way” of keeping track of payment context is by using a fresh Bitcoin Invoice Address per transaction and using the address itself as the unique identifier to store the context of the payment locally.
It is generally considered bad practice to reuse invoice addresses.

Thank you this make sense. So thats the way most bitcoin merchant work I guess.
I'm not sure how they handle the transaction fee to unify their bitcoin tho, especially for little amount invoices

@MaximeCATY Generally they try to consolidate their UTXOs during low-fee periods. Additionally, an increasing number of merchants are accepting payments exclusively over Lightning which avoids this problem.


text:
Buying and selling Bitcoin on a hardware wallet and not sending to an exchange
How can I buy and sell my Bitcoin from a Trezor or Ledger hardware wallet, without sending Bitcoin to an exchange?
For example, are there any hardware wallets that allow you to keep your Bitcoins on a hardware wallet and buy and sell. This would mitigate the risk of an exchange getting hacked.

Since your core point is not to trust the exchange, you can do either of the two:

find a person who wants to sell you bitcoin, give them your bitcoin address on your HWW & once confirmed, give them money. For selling, the process would be reversed, find a person who wants to buy, ask their address, send them bitcoin from you HWW, and then ask them money. Problem is, you will have to trust this person or the platform instead.
buy bitcoin on exchange, send from exchange to your HWW. Now when you want to sell, do the opposite, send from HWW to exchange and sell!

All hardware wallets give you control of your funds. As for buying or selling without an exchange, yes it is possible you just need to find the end-user yourself. Exchanges simply connect you to other people who want to buy or sell.  In the simplest form, if you want to sell without an exchange find a buyer, they give you cash and you give them bitcoin in return. Or vice-versa if you are buying.

Both are quite easily done. Selling and buying bitcoin, straight from a hardware wallet, can be done at the so called 'fiatgateways' such as www.satos.nl (dutch), I believe Changelly deals with the same strategy. You simply open an sellorder and simply send the amount you have set to sell to the walletadres (straight from your ledger) given by the fiatgateway. Buying is exactly the same at these fiatgateways, not an exchange which comes in between your coins. Your keys, your coins! :)

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Cannot send BTC. "Insufficient funds"
Yesterday I've sent transaction from my 2-of-4 Multi-sig wallet in Copay for Mac.
Transaction was signed by me and 1 more user.
It was broadcasted to Blockchain (As Copay says).
But when I copy TX ID and search it on Blockchain.info or Insight - i see "No transaction found" message.
For now, I cannot create new transaction from this wallet because I receive an error "Insufficient funds".
Is there any workaround for this?

Can you past the txid here? This will sacrifice some privacy, but may help someone answer your question. It sounds like your tx might not have been broadcast.

d13421b4bd5a2ad215ab3349d9baa3ff220143faa0a5d7000e70bd18b1e2dfd2
Here it is.

If you can get the raw transaction hex, you can broadcast it yourself with a transaction broadcast api like https://live.blockcypher.com/btc/pushtx/.

@AndrewChow seems like I cannot get TX raw from the Copay :(

It was self-fixed. Frozen Transaction just disappeared.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Get Bitcoin Wallet balance with Python
On a tutorial in Youtube
it uses pybitcointools. Upon searching it's github repository, I have found that it was not maintained anymore. Are there any alternative to this library which can get wallet balance?
Thank you.

i assume you want to create a wallet for bitcoin, here the lib for that: https://github.com/1200wd/bitcoinlib

Try this one https://github.com/mcdallas/cryptotools

Assuming you have a Bitcoin node to execute RPC calls against (i.e. you're running bitcoind with the RPC turned on), you can do this rather simply with pyjsonrpc:
#!/usr/bin/env python
from pyjsonrpc import ServiceProxy

bitcoin = ServiceProxy("http://127.0.0.1:8332")  # this is your bitcoind node and RPC port
bitcoin.username = 'testuser'  # rpcuser
bitcoin.password = 'testpass'  # rpcpassword
print(bitcoin.getbalance())

Thank you @Motoma. I am not aware if I have run any local RPC node unless pybitcointools is running it on the background. My intent is to have a personalized payment gateway and be able to track balances of multiple wallet addresses.

@CodeJammer In that case, you'll need to run a local Bitcoin node in addition to the script above. Doing that is probably beyond the scope of this question, but Bitcoin Core or Bcoin are two such options for running a local node.


text:
Is it secure to collect common public addresses under a wallet using BlockCypher Wallet API
I am working on an exchange platform with users having separate pair of public and private keys using blockcypher api. I encountered Blockcypher Wallet API, and it seems its a pleasant way of collating Set of Public Addresses to Query Together. For some reasons, i intend to add all new generated public addresses created by any user under a single wallet name (the site name) using the "Wallet API", this will come in handy in the case where by i need to filter all incoming transactions webhook to only the public addresses under the site name into a callback url. So i needed to confirm if this is a secure way to handle it. I would appreciate if an elegant way to handle this can be suggested.

If you’re building an exchange, and want ‘a secure way to handle things’, you should consider running your own node, not trusting a third party.

When using a third party, you will be trusting them to give you correct information. This is not just about being dishonest but also about not having bugs.
For instance consider the recent cve-2010-5141 vulnerability. If you are running a full node on your own, you can know what is going on and you can upgrade when you find out about it. But if you rely on a third party you have to trust that they upgrade and are aware of it.
As a matter of fact they apparently have not yet upgraded and on TestNet they are showing a block with exploiting transaction as valid. So theoretically you, as an exchange, can lose money if you were relying on them and if this was MainNet.


text:
Cannot mine Genesis / First Block (PIVX Fork / Clone)
Whatever I do, I am unable to mine the 1st block after the genesis block. All the while, I have assumed that I have mined the Genesis block, and I am unable to mine the 1st block using "setgenerate true" command. But, I may be wrong. I may have NOT actually mined the genesis block. Yes, I have got confused. I have generated new keys. So, here is what I have done from start.
1) Code before genesis block:
In "chainparams.php", I have updated the following.
boost::assign::map_list_of(0, uint256("0x01"));
static const Checkpoints::CCheckpointData data = {
    &mapCheckpoints,
    1538530667, // * UNIX timestamp of last checkpoint block
    0,    // * total number of transactions between genesis and last checkpoint
                //   (the tx=... number in the SetBestChain debug.log lines)
    500        // * estimated number of transactions per day after checkpoint
};

pchMessageStart[0] = 0x91;
pchMessageStart[1] = 0xc5;
pchMessageStart[2] = 0xfa;
pchMessageStart[3] = 0xe3;
vAlertPubKey = ParseHex("04ae6724abca5c2e2e9524d3cd10a303e0ef3f02d324bac4d06aceb873fb8591f1a968d9a2e5ac7024d5a45643d189b99015314d7ef1ff5f8799b9680d6e668471");

const char* pszTimestamp = "my new message here. trying to learn how to create an altcoin.";
txNew.vout[0].nValue = 50 * COIN;
txNew.vout[0].scriptPubKey = CScript() << ParseHex("047394ed7e750f6202487e7c8ec1e61bbd2fb5cdc6f0f5488af4d2ea082bec606fea95eea381cd0466cf6ea53d8f42c299f9d0e2a3bc313515fc52f02a16fef0a0") << OP_CHECKSIG;
genesis.nTime = 1538530667;
genesis.nBits = 0x1e0ffff0;

assert(hashGenesisBlock == uint256("0x01"));
assert(genesis.hashMerkleRoot == uint256("0x01"));

fRequireRPCPassword = false;
fMiningRequiresPeers = false;
fAllowMinDifficultyBlocks = false;
fDefaultConsistencyChecks = false;
fRequireStandard = true;
fMineBlocksOnDemand = true;
fSkipProofOfWorkCheck = false;
fTestnetToBeDeprecatedFieldRPC = false;
fHeadersFirstSyncingActive = false;

vFixedSeeds.clear();
vSeeds.clear();

In the main.cpp file I changed the following
int64_t nSubsidy = 0;

if(nHeight == 0) {
    nSubsidy = 0;
} else if( .......

Please note, I have also tried changing nSubsidy value for nHight = 0 to "50 * COIN" and also to higher value like "5000 * COIN". Everything results in the same issue.
2) Used the following code to create the genesis block.
if(genesis.GetHash() != uint256("0x"))
{
      printf("MSearching for genesis block...\n");
      uint256 hashTarget;
      hashTarget.SetCompact(genesis.nBits);
      while(uint256(genesis.GetHash()) > uint256(hashTarget))
      {
          ++genesis.nNonce;
          if (genesis.nNonce == 0)
          {
              printf("Mainnet NONCE WRAPPED, incrementing time");
              std::cout << std::string("Mainnet NONCE WRAPPED, incrementing time:\n");
              ++genesis.nTime;
          }
          if (genesis.nNonce % 10000 == 0)
          {
              printf("Mainnet: nonce %08u: hash = %s \n", genesis.nNonce, genesis.GetHash().ToString().c_str());
          }
      }
      printf("Mainnet block.nTime = %u \n", genesis.nTime);
      printf("Mainnet block.nNonce = %u \n", genesis.nNonce);
      printf("Mainnet block.hashMerkleRoot: %s\n", genesis.hashMerkleRoot.ToString().c_str());
      printf("Mainnet block.GetHash = %s\n", genesis.GetHash().ToString().c_str());
}

3) I got the following results.
block.nTime = 1538530667
block.nNonce = 3916247
block.hashMerkleRoot: 668d1e9c1c4f354589b9357d0ac0135b5e236f13ea8cf3bdf79e3670d347e07b
block.GetHash = 00000320986bcdf6c2e62f36321232ce1dfc77dc0e0b4a79e2199d8b77fa4820

4) Updated the above info in the file "chainparams.cpp".
boost::assign::map_list_of(0, uint256("00000320986bcdf6c2e62f36321232ce1dfc77dc0e0b4a79e2199d8b77fa4820"));

genesis.nTime = 1538530667;
genesis.nBits = 0x1e0ffff0;
genesis.nNonce = 3916247;

assert(hashGenesisBlock == uint256("00000320986bcdf6c2e62f36321232ce1dfc77dc0e0b4a79e2199d8b77fa4820"));
assert(genesis.hashMerkleRoot == uint256("668d1e9c1c4f354589b9357d0ac0135b5e236f13ea8cf3bdf79e3670d347e07b"));

5) Removed the code that I used to create the genesis block which I used in step 2 (above).
6) Compiled again, no errors or issues.
7) I made this current VPS as server and created a "coin.conf" file and added the following:
server=1
rpcuser=user
rpcpassword=password
listen=1
daemon=1

8) I did NOT clone this server to create a new client. Instead, I created a new VPS, installed all the dependences and copied the full folder - complete project into that client VPS to setup the client.
9) I added the following in "coin.conf" file in the client VPS.
addnode=<ipaddress of the server> (Ex: 207.87.10.2)

10) Started the wallet - "coin-qt" on the server. No errors.
11) Started the wallet - "coin-qt" on the client. No errors.
12) Both connected without issues.
13) Ran the following command on the client to mine the 1st block.
setgenerate true

Got the following error.
"wallet keypool empty"

stopped setgenerate using
setgenerate false

14) Executed the following command.
keypoolrefill

15) Again tried setgenerate
setgenerate true

16) Checked the debug.log file. This is what I am getting.
CreateNewBlock(): total size 1000
ERROR: CheckProofOfWork() : hash doesn't match nBits
ERROR: CheckBlockHeader() : proof of work failed
ERROR: CheckBlock() : CheckBlockHeader failed
CreateNewBlock() : TestBlockValidity failed
keypool return 2
keypool reserve 2

I printed the hashes in the debug file. This is what I get.
Hash = 35301222bb9164c21222107e1c43045c50c190d63eb8be2ad193ed38228b26a1
bnTarget = 00000fffff000000000000000000000000000000000000000000000000000000

I am stuck here. Whatever I do, how many times I start from scratch, I end up here.
Are there any other setting that I have to change related to ProofOfWork? What am I doing wrong? Can someone help me?

I've been hacking away at a PIVX fork as well.
I will try generating a genesis block with your code in my fork tomorrow, and see if I get a different result. We could compare the source code we're using via GitHub.
Do you mind sharing a link?

Downvoted. We have many questions regarding programming issues when creating a new altcoin. I don't believe such questions benefit a general audience, and this is a Q&A site, not a place for support. Furthermore, as a learning experience, contributing to an existing project is far more valuable.

Were you able to solve this issue? No proper answer has been given but yet it seems that you have been successful in mining past the genesis block according to your newer question: https://bitcoin.stackexchange.com/questions/79977/how-can-i-simulate-proofofstake-pos-for-a-testnet-clone-of-pivx

Hello Joe, well, I could not get this working with PIVX fork. I used an other fork which was a fork of PIVX and then, changed false to true for fSkipProofOfWorkCheck = true (this is not the proper way) and get it working. But, I never got this working with keeping fSkipProofOfWorkCheck = false;


text:
How Many Clients Could Not Send to Bech32 Addresses?
For my client, I have set up a custom BTC payment solution using BTCPay Server.  The wallets I have configured in BTCPay Server produce only bech32 (bc1xxx) addresses for payments (cheapest transaction fees).
My client (who ordered the solution) has asked me how many of his customers would be unable to send a payment to a bech32 address?
His concern is that his clients will be unable to pay their invoices in BTC because their wallets will be unable to send payments to the bech32 addresses.
As I can see it, I can go back to my client with one of the following two answers:

Nearly all (??%) of wallets can send to bech32 including all\most commercial wallet providers so you don't need to worry, or
This is a problem and instead of bech32 addresses I need to set up a payment wallet that supports legacy addresses (either 1xxx or 3xxx).

Could someone please tell me whether I can reassure him that the solution is fine as is, or whether I need to add legacy address support into it?

@Prayank Thanks for your comment. I'm not looking for a wallet provider or utilising one that has a problem sending to bech32.  My question is asking what proportion of the market is unavailable to me as a payment recipient if I only accept payment to bech32 addresses.

As an answer didn't appear to be forthcoming, I did my own research in order to address this question.
Based on the information provided by the Bitcoin Wiki on Bech32 adoption, I surmised the following information.

All mainstream software wallets support sending to Bech32.
All mainstream hardware wallets support sending to Bech32 (either directly or via Electrum).
All major web wallets support sending to Bech32.
Most exchanges support sending to Bech32 (although notably Bitrex and LBC don't).

Note that I have specified sending because a lot of these do not support receiving funds via a Bech32 address as of yet.  However, for my particular requirement that is unimportant as it is about sending only.
With the above facts confirmed, the answer I actually gave to my client was:
Nearly all wallets can send to bech32 including most commercial wallet providers so you don't need to worry.
When he asked what percentage, I was unable to answer it.  I would need to know what percentage of daily volume went through the exchanges that didn't support Bech32.  However, given then pretty much every wallet does support it I felt that this was less relevant.

It's difficult to give a definitive answer on the percentage, since it is difficult to know which wallets are creating transactions in the first place. Another good resource is the Optech compatibility matrix: https://bitcoinops.org/en/compatibility/, however that was created in 2019, and I don't know if all of it is up to date.


text:
Can't Make Sense of Why OP_CHECKSIG Fails Here
I'm try to get to grips with verifying the signature of a P2PKH transaction.
I have an example transaction:
9ec4bc49e828d924af1d1029cacf709431abbde46d59554b62bc270e3b29c4b1

I am trying to verify the signature of the first input in this transaction using OP_CHECKSIG.  The JSON is:
{
   "txid":"9ec4bc49e828d924af1d1029cacf709431abbde46d59554b62bc270e3b29c4b1",
   "hash":"9ec4bc49e828d924af1d1029cacf709431abbde46d59554b62bc270e3b29c4b1",
   "version":1,
   "size":402,
   "vsize":402,
   "weight":1608,
   "locktime":0,
   "vin":[
      {
         "txid":"01f7ba55e5baac3d9cbc38722b19c07cb0cd2d2b25f4c270af4d9f2f3e604cf6",
         "vout":1,
         "scriptSig":{
            "asm":"30440220d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1022044e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e01 04dbd0c61532279cf72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69c21e23f1859a95f06d52b7bf149a8f2fe4e8535c8a829b449c5ff",
            "hex":"4730440220d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1022044e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e014104dbd0c61532279cf72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69c21e23f1859a95f06d52b7bf149a8f2fe4e8535c8a829b449c5ff"
         },
         "sequence":4294967295
      },
      {
         "txid":"4a85d9c86ba415f489be1ec68f67e862e9c3d8d13c892a3afacaa02bdb41f829",
         "vout":1,
         "scriptSig":{
            "asm":"30440220d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad102209a5f1c75e461d7ceb1cf3cab9013eb2dc85b6d0da8c3c6e27e3a5a5b3faa5bab01 04dbd0c61532279cf72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69c21e23f1859a95f06d52b7bf149a8f2fe4e8535c8a829b449c5ff",
            "hex":"4730440220d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad102209a5f1c75e461d7ceb1cf3cab9013eb2dc85b6d0da8c3c6e27e3a5a5b3faa5bab014104dbd0c61532279cf72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69c21e23f1859a95f06d52b7bf149a8f2fe4e8535c8a829b449c5ff"
         },
         "sequence":4294967295
      }
   ],
   "vout":[
      {
         "value":0.001,
         "n":0,
         "scriptPubKey":{
            "asm":"OP_DUP OP_HASH160 70792fb74a5df745bac07df6fe020f871cbb293b OP_EQUALVERIFY OP_CHECKSIG",
            "hex":"76a91470792fb74a5df745bac07df6fe020f871cbb293b88ac",
            "reqSigs":1,
            "type":"pubkeyhash",
            "addresses":[
               "1BFhrfTTZP3Nw4BNy4eX4KFLsn9ZeijcMm"
            ]
         }
      }
   ]
}

From this I have defined the script to do the OP_CHECKSIG as:
OP_PUSHDATA1 71 0x30440220d47ce4c025c35ec440bc81d99834a624875161a26bf56ef7fdc0f5d52f843ad1022044e1ff2dfd8102cf7a47c21d5c9fd5701610d04953c6836596b4fe9dd2f53e3e01

OP_PUSHDATA1 65 0x04dbd0c61532279cf72981c3584fc32216e0127699635c2789f549e0730c059b81ae133016a69c21e23f1859a95f06d52b7bf149a8f2fe4e8535c8a829b449c5ff

OP_DUP OP_HASH160 20 0x70792fb74a5df745bac07df6fe020f871cbb293b OP_EQUALVERIFY OP_CHECKSIG

Everything runs correctly up until the OP_CHECKSIG.  The HASH160 is correct (70792fb74a5df745bac07df6fe020f871cbb293b == 70792fb74a5df745bac07df6fe020f871cbb293b) and OP_EQUALVERIFY completes as expected.
The OP_CHECKSIG fails, but I don't understand why.  Please can someone shed some light on what I've got wrong here?

Where do you run this? OP_CHECKSIG needs the whole tx

Checkout https://github.com/bitcoin-core/btcdeb for debugging Script :)

https://github.com/bitcoin-core/btcdeb/blob/991348d7ec208f3c95e83bf77a1e82f2c01394ab/doc/btcdeb.md#signature-checking ?

@MCCCS I'm using an online tool to test it: https://bitcoin-script-debugger.visvirial.com/.  Based on the comments, I think I'm maybe supplying the incorrect information

OP_CHECKSIG needs to have the whole transaction to hash and to verify the tx. Btcdeb has the feature of allowing the tx as an argument however the website you linked doesn't hence this opcode is doomed to fail every time on this website.
It is reasonable to expect supplying the signature to verify the script/tx because otherwise to steal his coins, I would be able to copy one of his signatures and put them in my transactions.
Therefore I do suggest downloading and using the complete btcdeb.


text:
Correct Approach for Payments on Multiple Addresses
I have clients that would like to pay for services in BTC.
TL;DR
To generate a new payment address must I generate a new private key (essentially a new wallet)?
Is it better to generate independent private keys for each payment from each client, or to use a determinstic wallet?
Is it possible to automatically move the BTC to a central wallet address without storing the private key for either solution?
How To Generate Multiple Addresses?
Based on this bitcoin.it article:

Addresses are not intended to be used more than once, and doing so has
numerous problems associated [with it].

Therefore, the logic I have follows that each payment received from each client should be to it's own address.
However, I am confused about the generation of multiple addresses, and the best way in which to do it.
Other questions on here, such as this one and this one, indicate that each private key will result in a single address only.  Am I therefore right to conclude that each address for each payment from each client must have it's own private key?
If that is the case (as in my limited understanding it would seem to be), and I am generating the wallet addresses using software, is it better to:

Use a deterministic wallet that generates each payment address for each client from a single 'master key', or
Generate an indepedent private key for each payment address for each client?

Moving BTC To Central Wallet
I need to move the BTC from the received wallet into my wallet in order to spend it.
In either of the scenarios I mentioned, would the 'master key(s)' be securely stored on the server for programmatic use in order to facilitate moving the received funds into my wallet?
If that is the case, would it be more secure to have independent private keys for each instance of a payment from a client?

Short answer: check out BTCPay, it does what you ask. You don't have to create your own server to use it, you can just create an account on an existing instance, for example this one should be fine to being with.
Long answer: you're right when you say that one private key generates one address, but Hierarchical Deterministic (HD) wallets are made to solve that.
Basically they allow to generate a virtually unlimited number of private and public key pairs from one piece of data. Deterministic means that if you know this piece of data, the "seed", you will always generate the same keys in the same order.
But it gets better than that, as you can derive only the public keys, meaning that you can use an unsecured server to generate addresses and receive bitcoin payments without ever exposing your private keys! That's the way BTCPay server work, and that's why you can use another person server to receive payments without trusting him. Worst case he will only know all your addresses, but can never steal your bitcoins.
I'm simplifying a bit, but that's the general idea.
As for your last question, you could have the private keys on another wallet like Electrum, or a Ledger, and then just use that to spend the bitcoins you received on your BTCPay server. I won't go into more details here, you can have a look at the BTCPay documentation or get in touch with their community.
NB: I recommend BTCPay because as far as I can understand your need I think it is the best option, but if you're not confortable with it you could as well use Electrum or a Ledger and send new addresses to your client in email or a secret pastebin for example.
That's great if your customers are okay to pay you in bitcoins. Stay safe, and remember never ever give your seed, or private keys to anyone or any service on the internet.

Thank you for your detailed answer.  I have tried BTCPay Server to achieve this already but was having some difficulties with it.  Given what you have described here I am going to persevere with trying to get it to work rather than try to implement my own solution.

I believe there are two key decisions to be made, for your case, and essentially the second would depend on the first that is: Would your customer want control over their own funds? If so, a private/public key(s) is in order. If they don't then you can decide if you want to have separate private keys for each client or not.
What it's important in any case is that each payment should be sent to a different public key. You can have as many public keys as you want and only one private key. What I mean is you don't need to create a new pair just to get a new payment address.
Note: BTCPayServer allows you to operate with such different setups.

Thank you for your answer.  My customers have no control of the funds once paid so I do not need them to be able to access their keys.  Given this and the other answer, I have decided to attempt to get BTCPay Server working and to integrate with that via the API.

This is slightly incorrect: each public key will have its own related private key, that will be required to spend the funds. Multiple public keys are not derived from the same private key. A modern HD wallet does use a single mnemonic seed phrase to create a master private key, but that key is then just used to derive child keypairs.

Thanks for the heads-up @chytrik. Now I'm intrigued on how does that work for regular/legacy wallets. Will check that implementation whenever I find some spare time.

Non-HD wallets will just generate random new keypairs as needed. This makes keeping a backup difficult: you have to create a new backup every time a new address is created!


text:
Bitcoin core How do I get the transaction fee while using sendtoaddress
I have a bitcoin core running on testnet, so for suppose I have a wallet balance of 1BTC and I have to send it to an addressx, so how can I know the amount of transaction fee so that I can subtract it from the sending amount.
bitcoin-cli sendtoaddress x 1

This will return an error stating that
error code: -4
error message:
Error: This transaction requires a transaction fee of at least 0.00000488

How can I know it beforehand the fee required for a transaction?

As the bitcoin-cli help sendtoaddress states:

subtractfeefromamount    (boolean, optional, default=false) The fee will be deducted from the amount being sent.

So you can change your call to:
bitcoin-cli sendtoaddress x 1 "" "" true

So that the fee is deducted from the amount to send

doesnt sound like it really answers the question to me, what if the merchant/recipient expects the full amount?

I think you want estimatesmartfee or estimatefee it takes one argument which is the confirmation target in blocks.  You can also select from Economical or Conservative fee modes which may affect the suggested fee rate.

How should I dermine the blocks, also estimatesmartfee does not work for bitcoincash, and estimatefee do not take any argument now.
Also, how is the fee determined for this sendtoaddress. Is it the average fee or the lowest possible value?


text:
How to handle multiple transactions from the same account(address)?
I am new to bitcoin so please bear my question. To understand the IN's and OUT's of this crypto world, i am creating a dummy bank to have a better understanding of the system.
So I have a bitcoin core running in my local system. Now for each user in the system I create an account for them using the getaccountaddress.
So let us consider I have one account named A having a deposit of 10 BTC. Now, suppose the user A wish to withdraw 1BTC from his account so, I first find all unspent transactions filter it by address associated by account A and send this 1BTC to user A. Now as I understand that the bitcoin cannot be partially spent so the remaining change will go to a change address so I provided account A's address from which the transaction was created.
Now my problem is that if the user again wishes to withdraw, I cannot find any unspent transaction since the change is not yet received immediately and will only be available when the transaction is confirmed.
So what is better way to handle this? What is a typical standard to handle such situation? How does wallet like Electrum works as I can see that I can send multiple transactions one after another.

Why send them one after another rather than aggregating them into a single transaction?

How about an order processing system where I wish to process an order as soon as I receive?

Then I'd just treat all the bitcoins that I had as one common pool. If the payment was on behalf of a particular account, I'd debit that account for the payment but I wouldn't try to use segregated bitcoins for each account, it makes things much less efficient. When you have $10,000 at a bank, there's no specific bills they have that are your $10,000 -- that's what creates the problem you're having.

I got your point. ;-)

can you help me with this?
https://bitcoin.stackexchange.com/questions/88085/bitcoin-core-what-default-values-should-i-pass-for-some-positional-rpc-params-in

Confirmation concept is generally useful for the counterparty to be sure that the transaction through which he has received the BTC cannot be reversed. Nothing stops you from creating a new transaction referencing the outpoints (txid and n) of the transaction through which you just spent your 1BTC, if you do not plan on changing the previously broadcasted transaction by say a higher fee. Either both transactions can get mined in the single block, or the second transaction can get mined in block after the first transaction has been mined.


text:
What are the web3py equivalent for communicating with bitcoin in Python?
I am fairly new to working with Python, I have a requirement where I need to perform some basic bitcoin operations on my local system rather than relying on some external API's, those function mainly include :
1. Wallet Creation
2. Address Creation
3. Transaction signing
For other operations, I am willing to use external API's like blockcypher. I need the above operations to be performed locally so to ensure some security. FOr ethereum I use web3.py which provides me these functions.
Can anyone help me with the same for bitcoin?

Please have a look at the API reference (JSON-RPC) (which has a python example, but might be out of date) and available Bitcoin Core apis.
Here is a nice clickable version of docs for bitcoin-python.

Libraries like Web3py or Web3js are connected to a node using JSON-RPC behind the scene. I am not aware of any library for bitcoin like Web3py. But Bitcoin do provide JSON-RPC interface, which you can use to perform these operations.


text:
Understanding default bitcoin wallet in bitcoind
I am new to block-chain, so please bear with my questions. I need to understand the basics of a bitcoin-wallet.
So I have setup a bitcoin full node using bitcoind in running in testnet mode. As I understand that by default a wallet is created. Now when I am trying to get the address of the wallet by this command bitcoin-cli -testnet getaccount "", I am geeting an empty list.
So is there no default wallet as such, also how do I create a new wallet? As I understand that a bitcoin wallet is basically a pot which holds several child addresses?

getaccount command was deprecated in Bitcoin Core 0.18, the wallet uses "labels" now.
When the wallet was created, it created a seed for you. This is used to generate the addresses in a BIP32 heirarchy. To generate the first address, you can use the getnewaddress command, followed by an optional label (to save the address in the address book), and an optional address type. E.g.
$ bitcoin-cli -testnet getnewaddress my_first_address

As I understand that a bitcoin wallet is basically a pot which holds several child addresses?

A Bitcoin wallet is generally considered software that manages your Bitcoin addresses and transactions, as well as your private keys to those addresses. In Bitcoin Core it is also used to describe a heirarchy of addresses with their own unique seed. Addresses used within a "wallet" on Bitcoin core are all derived from the same master key and seed. In fact you can have multiple wallets using the same installation of Bitcoin core, see createwallet


text:
How to differentiate between sending and receiving address in blockcypher api result?
I am using BlockCypher's API to get a list of transactions for a bitcoin address. I need to maintain a record of IN and OUT transactions from this address with time and transaction hash. However, I am not able to differentiate between the receiving and sending address. It is so much clear with Etherscan.
API Endpoint :
https://api.blockcypher.com/v1/btc/main/addrs/1rundZJCMJhUiWQNFS5uT3BvisBuLxkAp/full?confirmations=3&limit=2000

Can someone please help me differentiate it?

You should look at
   "inputs": [
        {
          "prev_hash": "017ce1c080eda9c5364b6efbcbd2d9b790983bb36fb81316d53269bb83703f08",
          "output_index": 0,
          ...
          "output_value": 269570000,
          ...
          "addresses": [
            "1rundZJCMJhUiWQNFS5uT3BvisBuLxkAp"
          ],
          "script_type": "pay-to-pubkey-hash",
          ...
        },
        {
          "prev_hash": "02be075b8e6cf357fd34f81eaa273e9e4f5f970af3dc01b9fa07ae0d1795cb75",
          "output_index": 1,
          ...
          "output_value": 3876180000,
          ...
          "addresses": [
            "1rundZJCMJhUiWQNFS5uT3BvisBuLxkAp"
          ],
          "script_type": "pay-to-pubkey-hash",
          ...
        },
        ...],
        "outputs": [
        {
        "value": 47981690876,
        ...
        "spent_by": "fe6a1669bc5c00171b921d7883ff674a7ac3fb8cd6a986ef6c69175d336ffc89",
        "addresses": [
            "15Z9atbppxt97unmzBdGkHuSx9UdptwqDb"
        ],
        "script_type": "pay-to-pubkey-hash"
        }
        ]

These are the relevant lines.


text:
Closing tx stuck in mempool
I'm running core lightning 23.11. I have a channel closing tx stuck in the mempool:
https://mempool.space/tx/9245a9fc09ada2b1709d6f83ed2fa0875c91996a4c81eb6a03e84946f13c1042#flow=&vin=0
How can I bump the fee?

There is no easy way to rbf a transaction, but it is possible with the low lever API

Can you give me some pointers for how to do that?


text:
During initial synchronization: ERROR: ReadBlockFromDisk: Errors in block header at FlatFilePos
After more than a week of synchronization Bitcoin Core v22 shut down with a fatal error:ERROR: ReadBlockFromDisk: Errors in block header at FlatFilePos(nFile=3058, nPos=104560604). What could cause this? A malicious peer or is it some hard drive error? I noticed the final two blocks in the blocks directory where very small compared to previous blocks, about 1kb.
I can't start Bitcoin Core anymore due to this error. I really hope I don't have to start downloading the chain from scratch again.
debug.txt
2022-10-22T17:26:30Z Bitcoin Core version v22.0.0 (release build)
2022-10-22T17:26:30Z Qt 5.12.11 (static), plugin=windows (static)
2022-10-22T17:26:30Z Static plugins:
2022-10-22T17:26:30Z  QWindowsIntegrationPlugin, version 330752
2022-10-22T17:26:30Z  QWindowsVistaStylePlugin, version 330752
2022-10-22T17:26:30Z Style: windowsvista / QWindowsVistaStyle
2022-10-22T17:26:30Z System: Windows 10 (10.0), x86_64-little_endian-llp64
2022-10-22T17:26:30Z Screen: \\.\DISPLAY1 960x540, pixel ratio=2.0
2022-10-22T17:26:32Z Assuming ancestors of block 00000000000000000008a89e854d57e5667df88f1cdef6fde2fbca1de5b639ad have valid signatures.
2022-10-22T17:26:32Z Setting nMinimumChainWork=00000000000000000000000000000000000000001fa4663bbbe19f82de910280
2022-10-22T17:26:32Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
2022-10-22T17:26:32Z Using RdSeed as additional entropy source
2022-10-22T17:26:32Z Using RdRand as an additional entropy source
2022-10-22T17:26:32Z GUI: "registerShutdownBlockReason: Successfully registered: Bitcoin Core didn't yet exit safely…"
2022-10-22T17:26:32Z Default data directory C:\Users\John Cox\AppData\Roaming\Bitcoin
2022-10-22T17:26:32Z Using data directory D:\bitcoinwin
2022-10-22T17:26:32Z Config file: D:\bitcoinwin\bitcoin.conf (not found, skipping)
2022-10-22T17:26:32Z Using at most 125 automatic connections (2048 file descriptors available)
2022-10-22T17:26:32Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2022-10-22T17:26:32Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2022-10-22T17:26:32Z Script verification uses 3 additional threads
2022-10-22T17:26:32Z scheduler thread start
2022-10-22T17:26:32Z Using wallet directory D:\bitcoinwin
2022-10-22T17:26:32Z init message: Verifying wallet(s)…
2022-10-22T17:26:32Z init message: Loading banlist…
2022-10-22T17:26:32Z SetNetworkActive: true
2022-10-22T17:26:32Z Using /16 prefix for IP bucketing
2022-10-22T17:26:32Z Cache configuration:
2022-10-22T17:26:32Z * Using 2.0 MiB for block index database
2022-10-22T17:26:32Z * Using 8.0 MiB for chain state database
2022-10-22T17:26:32Z * Using 440.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2022-10-22T17:26:32Z init message: Loading block index…
2022-10-22T17:26:32Z Switching active chainstate to Chainstate [ibd] @ height -1 (null)
2022-10-22T17:26:32Z Opening LevelDB in D:\bitcoinwin\blocks\index
2022-10-22T17:26:32Z Opened LevelDB successfully
2022-10-22T17:26:32Z Using obfuscation key for D:\bitcoinwin\blocks\index: 0000000000000000
2022-10-22T17:26:42Z LoadBlockIndexDB: last block file = 3061
2022-10-22T17:26:42Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=58, size=80508240, heights=738494...738885, time=2022-05-30...2022-06-01)
2022-10-22T17:26:42Z Checking all blk files are present...
2022-10-22T17:27:52Z Opening LevelDB in D:\bitcoinwin\chainstate
2022-10-22T17:27:52Z Opened LevelDB successfully
2022-10-22T17:27:52Z Using obfuscation key for D:\bitcoinwin\chainstate: 9d9048f3a0cb99bc
2022-10-22T17:27:52Z Loaded best chain: hashBestChain=000000000000000000070b49a59630c7204afdd471641538b41fcb66b120f702 height=738571 date=2022-05-30T12:25:09Z progress=0.960385
2022-10-22T17:27:53Z init message: Verifying blocks…
2022-10-22T17:27:53Z Verifying last 6 blocks at level 3
2022-10-22T17:27:53Z [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
2022-10-22T17:28:21Z No coin database inconsistencies in last 6 blocks (11982 transactions)
2022-10-22T17:28:21Z  block index          109846ms
2022-10-22T17:28:21Z loadblk thread start
2022-10-22T17:28:21Z ERROR: ReadBlockFromDisk: Errors in block header at FlatFilePos(nFile=3058, nPos=104560604)
2022-10-22T17:28:21Z *** Failed to read block
2022-10-22T17:28:21Z Error: A fatal internal error occurred, see debug.log for details

The last line of your debug.txt says "see debug.log for details" -- are there any? 2) Is there a blk03058.dat in the blocks directory?

yes, I pasted debug logs above. There is a blk3058.dat and it's smaller than the other blk files

Does this answer your question? special block version or is my data corrupt?. The message "Errors in block header at FlatFilePos(nFile=3058" suggests to me that blk03058.dat" might be corrupt. Maybe as a result of shutting down a computer without waiting for Bitcoin Core to finish closing. Maybe for some other reason.

yes, something must have happened that corrupted the file. Unfortunate to have it happen so close to finishing, but I'll just have to redownload again.

I would delete blk03058.dat and later files then start Bitcoin-core

yeah, I tried that but it wasn't able to rebuild from an earlier block. Luckily, redownloading isn't so bad because I'm using better hardware now


text:
Blockchain taking several days to download to external SSD
I'm downloading the blockchain onto the ssd t7 touch which has a max 1000Mbps, so the limiting factor should be my download speed which is 57Mbps. Still the blockchain download has taken a few days and only made 15% progress. Also, why is it saying the blockchain height is 405355, yet the highest downloaded block.dat file is 483? I started the download process by entering command bitcoind in my linux terminal. As a sidenote, I am downloading from a chromebook, so not sure if there is a limiting factor there, thought it does have usb3 support.

The initial synchronization is not just a download, but your node also verifies every single transaction that ever happened in the history of Bitcoin. Very likely, the limiting factor is the computation rather than the Download or Disk Writing speed. Please check out the linked questions and let us know if that didn't answer your question.

thank you, it is the computation I am downloading on a pc now and will just copy over the blockchain to the chromebook. Though it is still taking a few days, it is progressing faster

Good to hear, thanks for the update


text:
Bitcoin re-org stats
Does anyone have a table of historic Bitcoin reorgs?
Something like

[yyyymmdd] [blockheight] 1 stale block
[yyyymmdd] [blockheight] 1  stale block
[yyyymmdd] [blockheight] 2 stale blocks
[yyyymmdd] [blockheight] 1 stale block
...

I can't generate this myself unless I have a full node running since genesis, correct?
Thanks!

Not an answer, but an obvious complication of such data is that it depends on the observer. Not every node will see every reorganization, by definition (if everyone saw the same thing, there'd never be a reorganization). It depends on their network distance to the miners who created the relevant blocks.

Does anyone have some sort of idea at least? How often to single, double and maybe triple stale blocks happen?

You can find some of this data here: https://bitcoin.stackexchange.com/a/4638/5406. For more recent infos you can check out the RSS feed of BitMEX Research's forkmonitor: https://forkmonitor.info/feeds/stale_candidates/btc.rss

You may also be interested in https://bitcoin.stackexchange.com/a/97197/5406


text:
Hello, I want to know if they use blockchain and if I have to pay any transaction fees
yesterday I made a bitcoin transaction and they did not receive the full money and I was checking what it could have been and I think it was the blockchain and I have several doubts about that, can they charge a commission?

I think it was the blockchain [...] can they charge a commission?

Small b blockchain
The word blockchain, with a small "b", usually refers to the list of all Bitcoin transactions worldwide since the beginning. This is a chain of blocks (like a book of pages). Every full Bitcoin node keeps a copy of this list called the blockchain, including wallets using software such as Bitcoin core.
Since this list is not a person a business or any type of organisation it can't do things like charge a commission.
When you use a wallet to spend money, your wallet gathers enough amounts of money as "inputs" to make the desired payment "output". Your wallet reserves an additional amount you select called the transaction fee. The transaction fee pays the miners. Note that miners can't take money or make charges, they can only collect the fee you have set when you create your transaction. If there is any money left over from the inputs - output - transaction-fee, your wallet specifies an extra output that returns this "change" back to you.
Note that you choose the amount of the transaction fee. A small fee means it takes longer for miners to run out of better paying transactions to include in new blocks and get around to including yours. No one can alter your transaction to add a commission charge.
Note also it isn't possible for the recipient to only receive a part of the amount you specified as the output amount to send them. They get the whole amount when the transaction is confirmed or they get nothing if the fee is so low that the transaction never gets confirmed - in that case, you still have the money.
Big B Blockchain
There is at least one business that chose to include the word blockchain in their name. This is Blockchain.com, Inc. They have had other corporate names in the past. They are not in charge of Bitcoin and they are not in charge of the blockchain. Lots of Bitcoin users never use this business. Nor any other business like it.
Bitcoin was designed to be used without the involvement of this type of business but many people choose to give their money to this sort of business to look after for them.
This business can charge you whatever fees they want, the legal jurisdiction in which you live probably requires that any such fees are described in the terms and conditions document that the business makes available to its customers.
Unexpected fees
Swindlers and confidence tricksters like to persuade their victims that extra fees need to be paid. Unexpected fees are a common feature of this kind of fraud.


text:
After a long connection to the wallet, it offers to reinstall blocks and synchronize all Bitcoin core blocks
1)I installed bitcoin core on an ssd drive. Some time did not include it, a month after the inclusion of bitcoin core when you start the application with ssd asks to re-download all the blocks, the path is correct , and the folder has already downloaded the blocks. I don't understand, my old wallet can't download or wants to download the resulting blocks while offline. Please help to understand.                                      2) If I installed a portable ssd drive I can connect it to any device and use the wallet and funds on it? In such an attempt, it requires downloading blocks again

Your screenshot is a duplicate of that in https://bitcoin.stackexchange.com/q/83799/13866 - if that is also your question, you should have edited more information into your original question rather than add a duplicate question. Edited questions get pushed to the top of the front page, consequently there is no advantage to cluttering the website with multiple copies of the same question.

The restart after moving data to a new machine might be because some program data is stored in the Windows registry (Computer\HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt) which you might have left behind on a conventional HDD.
In particular the path to the data directory is stored in the registry. However simply the absence of any bitcoin key in the registry may be enough to convince Bitcoin core that it is running for the first time.

You can copy the blockchain data from an old install over the data directory created by a new install, so you can prevent the new install downloading the data you have already downloaded.
See How to transfer only the blockchain to a friend's computer?


text:
How difficult is it to confirm a Bitcoin Block?
If I have done the math right to come up with this hash, to confirm a true block and this is a confirmed hash. You can look it up here Bitcoin Block #570240
00000000000000000027b68db9d26885fec8dd3e785013f2355271b3ed991829
That should be 64 digits. If I try it on my phone calculator, is it y to the x power the right button to push? That gives a result of 26 lowercase letters + numbers 10 to equal 36. Would I push in 36 y to the 64 power? That gives a result of 4.01199191 to 99 digits long almost 100.
Is that math right for how many combinations there are?

It's in hexadecimal, so that's 10 digits and 6 letters.

Plus a valid block hash isn't a predetermined 256-bit (64-hexit) value, which would be completely infeasible; it's any value below the current target, often approximated by a number of leading zero bits or hexits. The target for that block (and all until the next recomputation) requires zeros for about 74 bits, or 18.5 hexits. A more exact cost is obtained by multiplying the difficulty shown at that link by 2^32 = 4294967296.


text:
How can i look into the Blockchain
I have read that the blockchain is a public ledger with all transactions of a decentralized community, furthermore i read that everyone can check that ledger for transactions that happened within the network. My question is how i am able to look into the blockchain to check for transactions without using sites like blockchain.info.

Are you referring to transactions or trades on an exchange?

No what I meant is how and where I can get the same data like you can see on sites like blockchain.info show.

It would be better to specify the blockchain platform that you're referring to. For example, Bitcoin blockchain, as the blockchain is referred to as a "data structure", while the Bitcoin is referred to as a "protocol" that uses the blockchain. Each blockchain platform may have different behavior and features depending on whether blockchain-based protocol is public permission-less or private permissioned etc. Briefly blockchain does not include necessarily all of Bitcoin features such as transparency etc.

All of the transaction history is communicated between peers over a binary gossip protocol. You can request specific blocks, sequences of blocks, or specific transactions, and clients will normally communicate by broadcasting all of the information they receive to other peers they are connected to - enabling each client to stay mostly up-to-date once they've downloaded the historical ledger. It is required that you connect to multiple peers to request information so that you are sure to get up-to-date information if a potentially malicious peer tries to withold information.
If you are already running a full node (which is a software client which uses the above protocol and stores the valid information it receives), then you already have the transaction history on your machine running the software. For Bitcoin Core, the files are stored in the ./store/blocks/ subdirectory of bitcoin's storage directory. The directory contains many files named blkXXXXX.dat, which are serialized sequences of blocks. Each file contains many Block File structures in serial, up to a limit of 128MB per file. The files are numbered ascendingly, with blk00000.dat being the oldest containing the genesis block as its first Block File. The Block File structure mimics the structure of the information of a block message received over the message protocol, except is prefixed with a magic number and size of the block.
Typically, if you want to write a block explorer, it would be simpler to read the information from the block files stored by Bitcoin Core, unless you need your block explorer to contain live information, in which case you will need to get information over the gossip protocol directly, or through Bitcoin Core's ZMQ interface, because the node software only commits confirmed transactions into block files.

authors: Иосиф Виссарионович Сталин


text:
Are corporate wallets visible to public
If a company has created a corporate wallet for me to receive funds back to my crypto account is that publicly visible

a company has created a corporate wallet for me ...

Thieves love to create Bitcoin wallets for victims they have deceived.
Whether such a wallet is visible to the victim depends on whether it is real or some sort of fake. Even if it is visible, the criminal creator has control, not the victim.
The inventor of Bitcoin intended that every Bitcoin user create their own wallet by downloading free software which can be used without requiring a customer relationship with any business. They intended that no one ever needed someone else to create a wallet for them.

... to receive funds ... is that publicly visible

Wallet visibility
The sort of wallet Bitcoin's inventor created free software for is always visible to the owner and intended to be not visible by anyone else.
Transaction visibility
Even though wallets are generally not visible, all transactions are public information. The public transaction data does not explicitly identify the participants in a transaction - so in some sense your involvement is not explicitly visible. Determined investigators might be able to identify participants in some cases.


text:
Does 'listunspent' work for any address is `txindex=1`?
The listunspent Bitcoin Core RPC method by default works only for addresses loaded in the wallet.  Does it work for any address if the node has full index (txindex=1)?
(Technically it could I think, but since this is a 'wallet' RPC, it may be restricted.)

Correct, this is a wallet RPC, so it only deals with outputs belonging to the wallet.
If you want to query the entire unspent transaction output set, you can use the scantxoutset RPC. It doesn't even depend on txindex=1.

I have not considered scantxoutset, because it is marked experimental. It works, but I find it quite slow.

It's slow because it scans through the entire UTXO set, which is currently a few gigabytes of data.

The Bitcoin Core Wallet tracks addresses associated with its own keys. listunspent is a wallet RPC that refers to the wallet data only.
Beyond the wallet's tracking of its own data, Bitcoin Core does not have functionality to keep an address index regardless of whether txindex is used or not. I surmise that address tracking was never prioritized by a Bitcoin Core contributor (or even pushed back upon by others) due to the intended single-use nature of addresses.
If you want to keep track of UTXOs per address you may want to look into blockchain explorer projects such as esplora or mempool.space.


text:
In Utreexo, how is it guaranteed that the validator has the same accumulator state as the proof-generator?
In Utreexo a validator node (fully validating Utreexo light node), when validating transactions, uses the proofs supplied by the proof-generator (a Utreexo-aware full node, bridge node).
As far as I understand, for proof validation to succeed, the validator has to have the same accumulator state (same root hashes) as the state used when creating the proof. I wonder how can this be ensured in the different use cases.
For the newly confirmed blocks/transactions, I see no problem, as the confirmed blocks and transactions have a well-defined ordering, and it is safe to assume to base the proof on the accumulator state as after the previous block.
But what about a long-confirmed but still unspent UTXO? Relative to what state can it be proved/verified? Does a new current proof have to be created with the current block height? Or it's not possible in Utreexo?
Also, what about mempool transactions? Their arrival time can differ in nodes, so there is no clear block height or block state.


text:
Funds was sent to my blockchain for the past 24 hours it’s not reflecting by
Funds was sent to my Bitcoin address since yesterday it been 24 hours the funds is not available in my blockchain wallet
Here is the address: bc1quu54az2v6rkfny77z2mu4c38ypsf4agml8zskw


text:
Understanding bitcoin-cli commands walletlock and walletpassphrase
I am trying to understand two commands listed in the following link.
1. walletpassphrase
Stores the wallet decryption key in memory for <timeout> seconds.

2. walletlock
Removes the wallet encryption key from memory, locking the wallet. After calling this method, you will need to call walletpassphrase again before being able to call any methods which require the wallet to be unlocked.

So if I am clear in my understanding, to encrypt my wallet I need to call the walletlockcommand and to decrypt it I need to call walletpassphrase command. Am I correct?

No, use encryptwallet to encrypt the wallet, read this document:
Examples:
Encrypt your wallet

bitcoin-cli encryptwallet "my pass phrase"

Now set the passphrase to use the wallet, such as for signing or sending bitcoin

bitcoin-cli walletpassphrase "my pass phrase"

Now we can do something like sign

bitcoin-cli signmessage "address" "test message"

Now lock the wallet again by removing the passphrase

bitcoin-cli walletlock


text:
Bitcoin Core What default values should I pass for some positional RPC params in sendtoaddress
I am trying to use the sendtoaddress rpc method of bitcoin core. From the documentation I read that I can pass "estimate_mode" parameter to estimate a fee. However as I believe json rpc follows positional parameters, so this parameter falls in the 8th position, before this there is another optional parameter named "conf_target". What value should I pass for this parameter?
bitcoin-cli bchtest:qp4uw0why90dht7texkv3nnws4cjml844y5ck8rr3q  0.1 "" "" false false ? "CONSERVATIVE"

What value should I pass in place of '?' ?

The fee estimator works by targeting the number of blocks that will occur between the time when you broadcast and when it confirms. So a confirmation target of 6 would mean that the fee estimator is trying to get your transaction confirmed within 6 blocks. The fee estimator does not know within how many blocks you want your transaction to be confirmed, so it asks you as a parameter.
The default value for this is 6, but you can set it to whatever you want.


text:
How do I install a specific version of bitcoin-core
I need to run bitcoind version 0.17, however the latest available version is 0.18, if I follow the instructions from this link it installs the latest version.
The below links lists the packages for the version I need however I am not sure how to use it, I mean how to install it on my local machine as apt-get install command does automatically.
https://bitcoincore.org/bin/bitcoin-core-0.17.1/
Can someone help me with this please?

You can just unzip the file and run the binary. Typically the binaries bitcoind and bitcoin-cli, etc. are stored in the /usr/local/bin, man folder in the /usr/local/man, etc. so that it is in your machine's PATH environment variable and can be run from anywhere.
If you choose to download the source code, you can install by following instructions here (for Unix): Build Unix
./autogen.sh
./configure
make
make install

But you may need to install dependencies. See Linux Distribution Specific Instructions

If I plant to run from binaries, how do I set the path so bitcoin-cli can be run from anywhere, typically how it behaves when installed from apt-get?

If you're building from source, you can select a specific version as follows:
First, review the build requirements, dependencies, and instructions for your OS:
https://github.com/bitcoin/bitcoin/tree/master/doc
Once that is done, use git to pull the source code and select a branch:
## clone the bitcoin repository
$ git clone https://github.com/bitcoin/bitcoin.git

## change folders
$ cd bitcoin

## check which versions are available
$ git tag

## find your desired version in the list, and then 'checkout'
$ git checkout v0.x.x

## now you can build:
$ ./autogen.sh
$ ./configure
$ ./make
$ sudo make install

Once you have finished the install and booted up bitcoind, you can confirm the correct version of the client and daemon are running:
bitcoin-cli getnetworkinfo
bitcoind --version


text:
How do I start a bitcoind server in deprecated mode for multiple functions
I have a bitcoind server running bitcoin-core version 0.17. Now since I need to use deprecated RPC methods I need to start the bitcoind server in deprecated mode, so I am already able to run it to support the accounts rpc methods by running the following command
bitcoind -deprecatedrpc=accounts

However, I found that signrawtransaction has also been deprecated, so I ran the bitcoind server with the following command :
bitcoind -deprecatedrpc=accounts,signrawtransaction

The server started successfully, however I was still getting this error :
"signrawtransaction is deprecated and will be fully removed in v0.18. To use signrawtransaction in v0.17, restart bitcoind with -deprecatedrpc=signrawtransaction.\nProjects should transition to using signrawtransactionwithkey and signrawtransactionwithwallet before upgrading to v0.18"

So I started the server again with the following command :
bitcoind -deprecatedrpc=signrawtransaction

And this time the transaction went through, however I need to start the bitcoind server to support both the deprecated methods. How can I do that?

Set the two flags independently.
ie, -debug=bench -debug=net


text:
btc RBF insufficient fee, rejecting replacement
I try to replace this transaction 13bc8f787f7c972702b6d14b8c0b36335aac5d0027800e2de277910a5eff86fb by higher fee, when broadcast return err: broadcast error, -26: insufficient fee, rejecting replacement d05cdb24407169b39abfddd03ae9bef33a1eb49a7f59db4a39c19688a5af99b1, less fees than conflicting txs; 0.00003562 < 0.00009786
I would like to know how to calculate the minimum replacement fee (0.00009786)，
the getmempoolinfo：{"result":{"loaded":true,"size":42800"bytes":80705990,"usage":253822900,"total_fee":6.57420956,"maxmempool":300000000,"mempoolminfee":0.00002600,"minrelaytxfee":0.00001000,"incrementalrelayfee":0.00001000,"unbroadcastcount":0,"fullrbf":false},"error":null,"id":"curltest"}

The replacement transaction must pay for its own bandwidth in addition
to the amount paid by the original transactions at or above the rate
set by the node's minimum relay fee setting. For example, if the
minimum relay fee is 1 satoshi/byte and the replacement transaction is
500 bytes total, then the replacement must pay a fee at least 500
satoshis higher than the sum of the originals.

So to calculate the minimum replacement fee for your tx, calculate the minrelaytxfee from your mempoolinfo times the size of your replacement tx.


text:
Bitcoin.org wallet is no longer available on iphone
I installed bitcoin.org 2 years ago. Now im trying to open it and it’s saying the app is no longer available on the app store (iPhone user). I don’t have any information other than the actual receipts that i get every time i deposit money. I tried downloading the same app but it’s no longer there. I tried downloading another app but it’s asking for my wif which I don’t know what’s this. And since I cannot access the app I can’t find what the wif is.
I need to cash out the money but i can’t since the app is not working. What should i do or who should i contact

bitcoin.org is a website, are you sure this is the name of the wallet? If you have your seed phrase, you can load it to any other Bitcoin wallet

tl;dr: Look for a 12-word recovery phrase which, two years ago, the app would have asked you to write down and keep safe.

I installed bitcoin.org 2 years ago.

bitcoin.org is unrelated to bitcoin.stackexchange.com (this website).
You can use the Internet Archive (the "Wayback Machine") to look at the bitcoin.org website as it existed two years ago.
Mostly bitcoin.org lists a range of independently developed wallets for iPhone
A subdomain of bitcoin.org at wallet.bitcoin.org does advertise a wallet.
However

That wallet is no longer available for iPhone (as you noted) nor for Android.
The "desktop" version for PC has not been maintained for 3 years.
The distributors, "Crypto Distribution LLC" may have gone out of business

I tried downloading another app but it’s asking for my wif which I don’t know what’s this.

WIF stands for "Wallet Import Format" and is a way of writing a private key. Private keys are numbers that can be used to control (i.e. spend) amounts of Bitcoin. What a wallet contains is primarily a list of private keys. If you can extract the private keys from one wallet app, you can, in principle, import them into a different wallet app.
To make things simpler, many wallets generate private keys from a 12-word or 24-word phrase. Such wallets would show this phrase when you first run the wallet and tell you to write down the words somewhere safe. Other wallet apps can, in principle, be given this 12/24-word phrase, enabling you to recover control over money.
At wallet.bitcoin.org it says

Your wallet is secured by 12 words, write these words down, keep them safe, and never have to worry about losing access to your bitcoin or backing up files.

If you did write down thise 12 words somewhere, using that in a different app may be your best way to regain control over the money in the old app.

who should i contact

There is a history of people having trouble contacting the owners of the bitcoin.org website. I believe they don't offer any kind of direct personal support.


text:
Intermittent connection issues - 'DataStream::read(): end of data: unspecified iostream_category error'
2 nodes run by me locally sometime connect sometime not and getting 'Connection refused' error on the node I am connecting from.
On the node I am connecting to debug.log error message display the following error:
ProcessMessages(version, 115 bytes): Exception 'DataStream::read(): end of data: unspecified iostream_category error' (NSt3__18ios_base7failureE) caught

Background:
Attempting to connect 2 local nodes to try to resolve exercise 5 from here
"Write the handshake method for SimpleNode":
https://github.com/jimmysong/programmingbitcoin/blob/master/code-ch10/Chapter10.ipynb
Jimmy is no longer keeping the node up so I spun off one using Liana on Testnet (https://wizardsardine.com/liana/)
socket connection is Successful
test_socket_connection(node_ip, node_port) --> Successfully connected to..
Any suggestion to troubleshoot further would be much appreciated.


text:
Hashing Transactions for Mining
After reading that Mining involves Taking a root hash of a transaction and combining that hash with a nonce it is required to find a number that is equal or below the given target, i was wondering if you have to try different orders of hashing the transactions or you just hash them all at once. For example does it make a difference if i hash a transaction A first and then transaction B or B first and then A.

Yes, the order matters. Changing the order of bytes of data being hashed will result in a different hash. Thus changing the order of transactions for the merkle root will also result in a different merkle root. There is no requirement that miners try different orders of transactions. But they may choose to do that instead of re-selecting transactions for the block. Note that transaction order does matter (coinbase must come first, parents must come before children, etc.) so a miner cannot try all possible permutations of transactions.


text:
What happens to .blk files on disk when the Bitcoin daemon switches to a longer chain?
I’m interested in writing a program that will (1) parse the .blk files that my full-node Bitcoin daemon writes to disk and (2) write them to a relational database in an incremental fashion (i.e., keeping tracking of which .blk files I’ve already seen to avoid duplicating work). But it seems that this approach could lead to problems when my Bitcoin daemon says “uh-oh, another chain is bigger than the chain we currently have, let’s switch to it.” Specifically, I could imagine two possibilities:

The Bitcoin daemon goes back into an existing .blk file and deletes the blocks from the old chain. If that’s what happens, my program would need to keep track of the mtime of the .blk files on disk and overwrite the parsed data that was sourced from those .blk files when the mtime changes.
The Bitcoin daemon never modifies “finished” .blk files (i.e., block files other than the latest one that’s currently being written to), but rather knows that some of the blocks inside the .blk files could correspond to rejected blockchains. If this is the case, my program would need to query the daemon for this information and update the destination database appropriately.

Which (if either) of those possibilities is correct?

The second is correct. The blk*.dat files are append only. Once a block is downloaded and written to disk, it is never deleted (except when pruning). A block index (database) is maintained in blocks/index to keep track of block locations on disk and statuses (valid, invalid, etc.).


text:
How to "cash out" of the Lightning Network without closing channels?
I am working on an ecommerce site that accepts lightning payments and was curious about how to "cash out" to pay vendors without closing channels to customers. I was planning to run two LN LND nodes and have two channels between them. One node for personal use highly connected and one running on BTCPay Server. Since not all my vendors accept bitcoin, I was working through the best way to be able to "cash out" my bitcoin to fiat (by closing one of my channels between my personal node and my BTCPay Server business node) to pay my vendors while still having an open channel to the world through which individuals who did not have an open channel with me could route payment. Rather than having my store (BTCPay Server business node) close channels to customers to "cash out" to pay vendors, I thought I would send LN payments from my store node to my personal node and close one of the two channels between my store node and my personal node. My thoughts may be convoluted and unnecessary and I would welcome any suggestions.

You can "loop out" using loop by lightning labs. It allows you to convert offchain funds into onchain funds by doing a reverse submarine swap. You can check the fees beforehand and specify which channel you want to drain.

This will get easier in the future as exchanges will be implementing deposits and withdrawals via LN.
At this time, if you need to deposit BTC and the exchange does not support LN deposits, I'm afraid you are stuck with closing channels for now.
Perhaps there will be a way soon to rebalance the channels to minimize the number of closures required.  Basically, push back funds on channels from customers 1-4, to pull the funds onto the customer 5 channel, and close only the one customer 5 channel.

Closing channels alone is not an adequate solution to rebalancing because all it does is shift the problem around.
Consider the following scenario: You have a node A, which is a store-front, and a personal node B, which is private. You have private channels i and j between the two nodes. There are some channels you have open on your store front, 1, 2, and 3, each of which has channels open with x, y, z respectively. Also, your personal node has channels open with w and v.
I'll use = to indicate the outbound capacity your merchant node has, and - to indicate the inbound capacity.
(x)----|====(1)----|====     ====|----     ====|----(w)
                        \   /    i    \   /
(y)----|====(2)----|==== (A)           (B) ====|----(v)
                        /   \    j    /
(z)----|====(3)----|====     ====|----

Assuming all channels have a capacity of 8ksat above, and are all evenly balanced, lets see what happens if z makes a payment of 4ksat.
(x)----|====(1)----|====     ====|----     ====|----(w)
                        \   /    i    \   /
(y)----|====(2)----|==== (A)           (B) ====|----(v)
                        /   \    j    /
(z)|========(3)|========     ====|----

The inbound capacities of the channels between z, 3 and your merchant node A are now exhausted and you will not be able to receive payments through it. To rebalance this, you need to make a payment through 3 and z, to be received via w or v. Lets say we split this into two payments via both w and v.
2ksat: A -> 3 -> z -> ... -> w -> B(i)-> A
2ksat: A -> 3 -> z -> ... -> v -> B(i)-> A

(x)----|====(1)----|====     ========|     ======|--(w)
                        \   /    i    \   /
(y)----|====(2)----|==== (A)           (B) ======|--(v)
                        /   \    j    /
(z)----|====(3)----|====     ====|----

Channel i is now exhausted, so we can close it to cash out on chain. However, we need something to replace it. We need a new channel k, with the same capacity of 8ksat.
(x)----|====(1)----|====     |--------     ======|--(w)
                        \   /    k    \   /
(y)----|====(2)----|==== (A)           (B) ======|--(v)
                        /   \    j    /
(z)----|====(3)----|====     ====|----

Notice that We've not actually gained anything "on-chain", because we've had to reuse those funds to establish the replacement channel, although we still own the money, it is tied up in the channel.
Assume that now x makes a payment of 4ksat, and we repeat the process above, but using j instead of i as the channel we're going to cash out with.
(x)|========(1)|========     |--------     ======|--(w)
                        \   /    k    \   /
(y)----|====(2)----|==== (A)           (B) ======|--(v)
                        /   \    j    /
(z)----|====(3)----|====     ====|----

2ksat: A -> 1 -> x -> ... -> w -> B(j)-> A
2ksat: A -> 1 -> x -> ... -> v -> B(j)-> A

(x)----|====(1)----|====     |--------     ========|(w)
                        \   /    k    \   /
(y)----|====(2)----|==== (A)           (B) ========|(v)
                        /   \    j    /
(z)----|====(3)----|====     ========|

We can cash out j and create l in its place, but we have the issue that the channels B had with w and v are now completely exhausted of incoming capacity. We won't be able to rebalance anything else if y makes the same payment.
(x)----|====(1)----|====     |--------     ========|(w)
                        \   /    k    \   /
(y)|========(2)|======== (A)           (B) ========|(v)
                        /   \    l    /
(z)----|====(3)----|====     |--------

So unless B is actively spending on the lightning network, through w and v, those channels are not going to be reusable for rebalancing. It isn't possible to spend from B back to A via these channels, as that would exhaust the inbound capacities of its other channels it has open to customers.
In practice, you will probably have more channels open, and each node will be routing payments for other people, so you may have some other rebalancing going on. You might discover that certain paths are used more frequently one direction than another, which would make it ideal for use as a rebalancing path.
However, the end goal is eventually to not need to cash out - but to make your purchases directly on the network. Likewise, you should be able to get paid over the network, and rebalancing will become less of an issue as the number of channels increases, and liquidity increases.
There are a number of services which can be used to "refill" channels, in return for direct on-chain payments. I guess there is a market for the opposite of such service too - to offload payment channels in return for the on-chain payment. There have been some proposals for liquidity markets to be developed directly on the Lightning Network layer so that some of this can be automated in future.
Perhaps the correct thing to do, is not to attempt to rebalance unless absolutely necessary for yourself though. In the above scenario, when z first paid, instead of trying to rebalance the channel A has open with 3, you could just close this channel and cash out. If z wants to make another payment to you, they must either do it through 1 or 2, or some other channel which might be created with incoming capacity in your direction. The problem then is not your's, but z's. If you are a useful routing node, then people will probably want to open more channels with you with inbound capacity to you also.
1, 2, and 3 are not necessarily your customers. Your customers are x, y and z, and the direct channels you have open just facilitate those payments.

You can use a lightning-enabled exchange to "exchange" your BTC locked in lightning channels to on-chain BTC. Afterwards you can use any usual exchange to sell your on-chain BTC for a preferred fiat currency.
A couple of lightning-enabled exchanges from this post are zigzag.io, sideshift.ai, southxchange.com, btcduke.com and coinplaza.it.
However please do your own research before using these: the services are all new and require your trust for the time they hold your funds. Also beware that the fees can be relatively high.


text:
How to discover startup flags or command-line options for bitcoind?
I'd like to query the Bitcoin daemon (bitcoind) to find out what startup flags (command-line options) were sent to it on startup (or the current state if it has changed, e.g. -server=0/1 changing).
For example, I may want to know if -addresstype, -disablewallet, -rescan, or -uacomment=<cmt> or some other flag has been set.
Or for Namecoin, it would be very useful to know if -namehistory has been set.
Is there an RPC or any other method to find out?

Or, to ask the question a different way...
src/bitcoind.cpp's bool AppInit(int argc, char* argv[]) method calls ParseParameters(argc, argv);, which is in src/util.cpp.
In src/util.cpp we have:
map<string, string> mapArgs;
static map<string, vector<string> > _mapMultiArgs;
const map<string, vector<string> >& mapMultiArgs = _mapMultiArgs;

To store flags/options/args.
I'd basically just like to get whatever is in those variables through bitcoind.

On Linux, get the process id of bitcoind and read  /proc/<pid>/cmdline.
On Windows, use wmic path win32_process where "name = 'bitcoind.exe'" get commandline


text:
bitcoin-cli "Could not connect to the server"
Brand new Raspberry Pi mainnet node following this walkthrough:
https://medium.com/@meeDamian/bitcoin-full-node-on-rbp3-revised-88bb7c8ef1d1
When I run this command:
bitcoin-cli -rpcuser=username -rpcpassword=password -rpcport=8332 getblockchaininfo
I receive the error:
error: Could not connect to the server 127.0.0.1:8332
When I tail debug.log, the node appears to be fully sync'd and picking up new blocks
My bitcoin.conf file is:
#is required for Fail2Ban
logips=1
#magic RBP optimizations
maxconnections=40
maxuploadtarget=5000
upnp=1
server=1
rpcuser='username'
rpcpassword='password'
rpcport='8332'
walletrbf=1
My apologies if my formatting is bad here, couldn't figure out how to get the .conf to paste as a block of text. Thank you for any ideas on what I'm doing wrong!

I guess checking your debug.log in your Bitcoin datadir ~/.bitcoin may give you some answers

I think having single quotes in the values for rpcuser, rpcpassword, and rpcport in your bitcoin.conf file is causing problems. Try removing those quotes and restart bitcoind.

The single quotes were it -- thanks so much!

I encountered this error message when I have not started bitcoind.exe.
Starting bitcoind.exe solved the problem.


text:
How to use -txindex to enable blockchain transaction queries?
I am trying getting the raw of transaction. But I am getting the following error with following command and  RPC call as well.

bitcoin-cli getrawtransaction ad844933ceb9cf990fd75ebd2f6731527885e31d1a4c9ea292db235bcd64bdbe

Error
No such mempool transaction. Use -txindex to enable blockchain transaction queries. Use gettransaction for wallet transactions.

use
txindex = 1

in you bitcoin.conf file and restart daemon with -reindex flag if you are building it for the first time, it might take a while but after txindex is defined you can get data for any transaction in blockchain no matter if its related to your wallet or not.
Alternetivly you can start your daemon with
 bitcoind -daemon -txindex=1 -reindex=1

Either way it functions the same

Always I have to add the -txindex flag to restart the daemon. Currently i am using bitcoind -deprecatedrpc=accounts to start a daemon

"Use -txindex to enable blockchain transaction queries." line has been removed from the error But I am still getting the following error "No such mempool or blockchain transaction. Use gettransaction for wallet transactions."

add txindex=1 and reindex=1 in your bitcoin.conf file, and make sure you start your daemon with -reindex=1 for the first time, it will take a while for your blockchain to reindex ,the progress can be seen in debug.log , after the reindexing is done you should not encounter same error again

I have added the txindex=1 and reindex=1 in your bitcoin.conf file and restarted the daemon with command "sudo bitcoind -daemon -txindex=1 -reindex=1" and still i am getting the following error "No such mempool or blockchain transaction. Use gettransaction for wallet transactions."

FYI " Use -txindex to enable blockchain transaction queries. " line has been removed from the error. this is a another error with error code -5

check debug.log file for more info


text:
How to verify a given transaction was sent by a Green Address?
I have run bitcoind. How do I get the funds sent from Green Addresses? If the transaction  is  sent by  Green Addresses, that can be immediately on receipt with zero network confirmations
There are several methods in the list of RPC calls, Is it possible?
Working Example from Block.io Is Green Transaction?

List of RPC calls

There's no mention of "green addresses", a concept from 5 years ago that never took off, in the Bitcoin Core code base at all. It has no support for them, never has, never will.

Did you read out the Block.io Green Transaction Behaviour ?


text:
What were the most popular bitcoin mining softwares, services or platforms in or before january 2010?
My friend who died few weeks back, He claimed that he mined bitcoin using his personal computer

back in the days

he said.
But i had a glimpse of an archive he named

btc.gz

which had file made or modified last in January end of 2010, which made me wonder whether his claims were true.
Now i am curious of how he did it, while trying to profile him.
So were they any free bitcoin mining services, platform or software available by January 2010, please provide possible list?

I suspect that in January 2010, all miners would have been CPU mining with an early version of Bitcoin core (then called just Bitcoin).

Somewhat related: List of Bitcoin exchanges available in 2009

According to Nicehash's History of Bitcoin Mining

The first miner was the official Bitcoin miner.

It is believed that the first GPU miner was developed by ArtForz, who allegedly mined the first block with his GPU farm on 18th of July, 2010

In 2012, the first ASIC projects started to emerge

The first mining pool appears to be bitcoin.cz which started on 18th September 2010.

All the above reinforces the notion that, in or before January 2010, using Nakamoto's Bitcoin software was the only Bitcoin mining software, service or platform.


text:
Is it possible to get bitcoin address from Jan 2010 that still has balance and never send out transactions?
I need to find an unknown address and all i know is that the address received 2 or more block rewards in January 2010 and never spent the coins, So i have used blockparser to dump addresses from 2009 to feb 2010 then filtered then with a file which contains all btc addresses with balance but i still have one hell of a list.
I need to filter further using addresses which never send out transactions but i don't know how to query that.
Please help.

You can use node RPCs: getblockhash, getblock and gettxout for this. See example below.
First, call bitcoin-cli getblockhash 871951, which will return the block's hash: 0000000000000000000233611afd0d00f1e874d8f962c94bdebf40975432b95e
Then, by using bitcoin-cli getblock 0000000000000000000233611afd0d00f1e874d8f962c94bdebf40975432b95e 2 you will get the block's content in JSON format. You can then use some JSON parser (e.g. jq command-line tool) to filter just the coinbase transaction (which will be the 1st transaction in the tx array):
{
  "txid": "9f71b8f4724ead5fa8521e1511867f599064c55237e374c013a5a30ec99be812",
  "hash": "76e359604e2aab1aa5e47829014f78bcbd0b89bd1ad5065f284b7ea44a2c146b",
  "version": 2,
  "size": 325,
  "vsize": 298,
  "weight": 1192,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "030f4e0d04eeca44672f466f756e6472792055534120506f6f6c202364726f70676f6c642f40398451da2c000000000000",
      "txinwitness": [
        "0000000000000000000000000000000000000000000000000000000000000000"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 5.46e-06,
      "n": 0,
      "scriptPubKey": {
        "asm": "1 3daaca9b82a51aca960c1491588246029d7e0fc49e0abdbcc8fd17574be5c74b",
        "desc": "rawtr(3daaca9b82a51aca960c1491588246029d7e0fc49e0abdbcc8fd17574be5c74b)#p35tdfgk",
        "hex": "51203daaca9b82a51aca960c1491588246029d7e0fc49e0abdbcc8fd17574be5c74b",
        "address": "bc1p8k4v4xuz55dv49svzjg43qjxq2whur7ync9tm0xgl5t4wjl9ca9snxgmlt",
        "type": "witness_v1_taproot"
      }
    },
    {
      "value": 3.20244687,
      "n": 1,
      "scriptPubKey": {
        "asm": "0 7086320071974eef5e72eaa01dd9096e10c0383483855ea6b344259c244f73c2",
        "desc": "addr(bc1qwzrryqr3ja8w7hnja2spmkgfdcgvqwp5swz4af4ngsjecfz0w0pqud7k38)#y9upg3rz",
        "hex": "00207086320071974eef5e72eaa01dd9096e10c0383483855ea6b344259c244f73c2",
        "address": "bc1qwzrryqr3ja8w7hnja2spmkgfdcgvqwp5swz4af4ngsjecfz0w0pqud7k38",
        "type": "witness_v0_scripthash"
      }
    },
...

Then, you can extract just the txid and vout.n fields to generate a list of transaction outputs to check, e.g.:
9f71b8f4724ead5fa8521e1511867f599064c55237e374c013a5a30ec99be812,0
9f71b8f4724ead5fa8521e1511867f599064c55237e374c013a5a30ec99be812,1
9f71b8f4724ead5fa8521e1511867f599064c55237e374c013a5a30ec99be812,2
9f71b8f4724ead5fa8521e1511867f599064c55237e374c013a5a30ec99be812,3

Then, for each one you can call gettxout, e.g. bitcoin-cli gettxout 9f71b8f4724ead5fa8521e1511867f599064c55237e374c013a5a30ec99be812 0 and if the result prints anything then the TXO has not been spent yet. If nothing is printed then it has been spent already.
Result will look like this:
{
  "bestblock": "00000000000000000000349653eb5d146e6336ea9a95a7a8bcd3fac852f8c908",
  "confirmations": 4,
  "value": 3.20244687,
  "scriptPubKey": {
    "asm": "0 7086320071974eef5e72eaa01dd9096e10c0383483855ea6b344259c244f73c2",
    "desc": "addr(bc1qwzrryqr3ja8w7hnja2spmkgfdcgvqwp5swz4af4ngsjecfz0w0pqud7k38)#y9upg3rz",
    "hex": "00207086320071974eef5e72eaa01dd9096e10c0383483855ea6b344259c244f73c2",
    "address": "bc1qwzrryqr3ja8w7hnja2spmkgfdcgvqwp5swz4af4ngsjecfz0w0pqud7k38",
    "type": "witness_v0_scripthash"
  },
  "coinbase": true
}

All of this could be easily automated to process the block range you're interested in.

All of this could be done a lot simpler with scantxoutset?

I was looking at that but maybe I misunderstood the docs: doesn't that require you to know which address you're looking for? In that case you'd still have to run getblock to get list of addresses and then call scantxoutset on each.

Never mind, of course.


text:
What is the numeric precision of Network Difficulty?
My understanding is that Difficulty (aka Network Difficulty) is an approximate representation of the Target, a 256-bit number which is hard to reason about or work with in human-readable Decimal format.
The Bitcoin wiki defines Difficulty as: difficulty = difficulty_1_target / current_target, where difficulty_1_target was the Target during the first Difficulty Epoch (the first 2016 blocks).
Is this definition of Difficulty correct? If yes, is it accurate to think about Difficulty as a type of proportion or ratio? And if it is a floating point number, what is its precision?
I don't often work with hexadecimal or 256-bit numbers, so I am confused where the "approximation" piece comes in, making Difficulty values easier to work with than the Target. Is Difficulty rounded after some decimal place?
Lastly, could someone please confirm the formula used to compare a hash against the Target, to see if it mines a valid block? For more practical use, how would you represent this formula using Difficulty instead of the Target?
Thank you

Is this definition of Difficulty correct?

Yes.

If yes, is it accurate to think about Difficulty as a type of proportion or ratio?

Yes, it is how many times harder current blocks are to mine than blocks in the first difficulty epoch were.
For reference, difficulty 1 corresponds to (very close to) 4295032833 hash attempts per block. It has a target of (exactly) 26959535291011309493156476344723991336010898738574164086137773096960.
Block 822627 has a target of (exactly) 374406027949793378682501776760424667692437142927048704.
The ratio between these two huge numbers is (approximately) 72006146478567.1. That is the difficulty of block 822627. It is roughly 72006 billion times harder to mine a block today than it was in January 2009.

And if it is a floating point number, what is its precision?

Whatever precision you calculate it to. Typical implementations will use a floating-point data type in the computation, which necessary limits its precision.
But it's really just the ratio of two huge numbers. You can calculate it to much higher precision too. Block 822627 has difficulty
72006146478567.09941095874369093485414495333341140374503764945604440...
That much precision isn't needed, as the difficulty is really just used for presenting the hardness of mining a block to humans. Internally the software uses the target, which is exact.

Lastly, could someone please confirm the formula used to compare a hash against the Target, to see if it mines a valid block?

The requirement is: block_hash ≤ target (where block_hash is the block hash interpreted as 256-bit little-endian number). The lower the target is, the harder it is to land below it. In a way, the difficulty is a measure for "target lowness".

For more practical use, how would you represent this formula using Difficulty instead of the Target?

Perhaps something like block_hash_diff ≥ difficulty, where block_hash_diff is the ratio between the first block's target (given above) and the block's actual target?

Thanks Pieter!  This is super helpful and clears up a lot of my confusion. At difficulty 1, where target is 0xffff * 2**208 or 26959535291011309493156476344723991336010898738574164086137773096960, I thought the statistical average number of hashes required to find a block was pow(2, 32) or 4294967296, but in your answer you say it is very close to 4295032833.  Could you share how you arrived at your number?

The number of valid hashes (2^208 * 0xffff) divided by 2^256 (number of possible hash outcomes) is (very close to) 1/4295032833. More exactly, it is 1/(2^48 / 0xffff).

To be entirely precise, the number of valid hashes at difficulty 1 is actually (0xffff * 2**208) + 1, as the consensus rule is that the hash value is less than or equal to the target. But the effect of that + 1 is so small that it's generally ignored.

Interesting... in the mining industry, it is common to take an amount of mining shares and multiply by 4294967296 (2^32) to produce an approximate number of hashes.  Divide that by total seconds for an approximate hashrate.  IE, assuming a share difficulty level 1, appx_hashrate = shares * 4294967296 / seconds.  I'm now wondering if it would be more accurate to use 4295032833 for the rate of diff 1 shares-to-hashes?

@sha2fiddy Inside the Stratum protocol used for pool mining there is also a notion of (share) difficulty, however it corresponds to exactly 2^32 hashes per block (so it differs from difficulty as used by the rest of the ecosystem).

is it accurate to think about Difficulty as a type of proportion or ratio?

I think of it as just a number that is an abstract representation of the probability of a mining attempt failing. As with darts or archery etc, smaller targets are more difficult to hit.
difficulty ∝ 1 / targetsize

if it is a floating point number,

As Pieter Wuille clarified, floating point arithmetic is used in recalculating network targets.
For my purposes, I find it easiest to ignore difficulty completely and work with targets. Your subject area scope may differ.

I am confused where the "approximation" piece

See Pieter Wuille's clarifying comment:

The difficulty is an approximation [...] because in practice it's a floating-point number, computed to some finite precision.

the formula used to compare a hash against the Target,

if hash <= target then success

P.S. Targets are ranges
Really the target is a sub-range within the range of numbers that can be represented by a 256-bit integer. It is the size of this sub-range as a proportion of the total range that is important. You can achieve the same effect by saying miners have to find a number in the top n% or the bottom n% or any range n% wide anywhere in between. In a range of 0-1000 the target subranges of 0-10 or 990-1000 or 357-367 are all equally difficult to hit using a pseudo-random number generator such as a hashing algorithm. Bitcoin's inventor made an arbitrary choice of one end of the range. If the other end had been chosen the relationship between target and difficulty would not be an inverse one.

Somehow I thought the Target got larger as hashrate increased,

It is the opposite: the size of the target range is made smaller (more difficult to hit) after total network hashrate increases.

P.P.S Difficulty is a useful concept but a superfluous number for most purposes?
The API docs say

getdifficulty
Returns the proof-of-work difficulty as a multiple of the minimum difficulty.

(my emphasis)
Note that the difficulty number is not actually used in mining or block validation, the target is. I believe difficulty is only used as a way of presenting the target to humans in a way that might be more intuitive.

Thank you.  When I query my Bitcoin node getdifficulty it currently returns 72006146478567.09 , a floating point number.  If Difficulty is not a floating point number, is this transformation just happening at the JSON RPC layer, and why?
if hash <= target then success - now I am extra confused.  Somehow I thought the Target got larger as hashrate increased, and that the formula should look more like this: if hash <= 1 / target then success.

See postscripts to answer.

I don't think the rounding in the "bits" representation is relevant here; that's internal to the target computation algorithm. The bits that come out, and its corresponding "rounded" target are the exact values from the perspective of consensus rules. The difficulty is an approximation of that, because in practice it's a floating-point number, computed to some finite precision.

Thanks @Pieter, I have updated my answer -- but I am not sure if I improved it or just compounded my errors. If I am heading in the wrong direction here it might be best for me to just delete this answer.

@RedGrittyBrick I think I've confused you more. There are two separate processes: (1) the "bits" encoding that has limited precision, and which is applied during difficulty correction and (2) the conversion from target to difficulty which typically happens using floating-point arithmetic. (1) is a rounding operation, but I don't think it is in any way related to OP's question, and I think you should drop mention of it here. This rounding is done during the difficulty correction and the result is the actual network target. (2) is what is OP is asking about.

The Bitcoin wiki defines Difficulty as: difficulty = difficulty_1_target / current_target, where difficulty_1_target was the Target during the first Difficulty Epoch (the first 2016 blocks).

It might be more useful to refer to that as "relative difficulty", while 1/current_target is the absolute difficulty.

If yes, is it accurate to think about Difficulty as a type of proportion or ratio?

Yes, the relative difficulty is the ratio of the absolute difficulty to the original difficulty. The absolute difficulty is the ratio of the total number of possible hash outputs to the number of valid hashes.

And if it is a floating point number, what is its precision?

Uhhh... 256 bits?
"Floating point" isn't a type of number, it's a data type. A datatype is a method of representing a number, it's not the number itself. The difficulty is a rational number. It is uniquely defined by the target, which is a 256 bit number.
You can also, if you want, have a floating-point variable that represents this number. What precision that number has depends on what float you use. If you use a signed 32 bit float, it will have 24 bits of significant precision (as opposed to the exponent part). For 64 bits, it will have 53 bits. If you store it as float with fewer than 256 bits, then it will be rounded when it's converted to a float.
It might be useful to compare it to π. π is an irrational number, and has an infinite amount of precision. math.pi() is a float that represents π and has finite precision, and thus is a rounded version of π.

For more practical use, how would you represent this formula using Difficulty instead of the Target?

A block is valid if the total number of possible hash values divided by the actual hash value is greater than or equal to the absolute difficulty. Or, equivalently, if the actual hash value divided by the total number of possible hash values is less than or equal to the reciprocal of the absolute difficulty, or the actual hash value divided by the total number of possible hash values is less than or equal to the original difficulty divided by the current difficulty.