text:
When a node receives a transaction, what steps does it do to verify that transaction?
I know that it verifies the block hash by calculating each hash of the contiguous blocks in order, but does it verify the balance of each wallet sending the transactions as well? And does it do the block hash calculation every time, or does it just do it when it starts up?

When a node receives a transaction, they perform the following steps at a high level.
Inductively, they already have a set of validated transactions; these belong to the blockchain they have adopted as well as their current mempool. From this, the node has extracted a UTXO.

Ensure that the inputs of the new transaction reference valid outpoints in the UTXO. This ensures that the money being spent is real.
Verify the Law of Conservation, i.e., that the sum of value of the outputs does not exceed the sum of the value of the inputs. This ensures that no new money is being created. The one exception to this is when a new coinbase transaction is received with a newly mined block; in that case, new money can really be created.
For each input of the new transaction, ensure that running the scriptPubKey script attached to the outpoint it connects to with the parameters specified in the scriptSig of the input, leaves the Bitcoin Script stack with a non-zero value at the top. Most of the time, this is the step where the digital signature validation happens and ensures the money is being spent by its rightful owner.

The last step above has many subcases and can function in various ways depending on whether the transaction involves a segregated witness or an attached indirect script, for example.
Lastly, once a transaction is validated by the above steps, the UTXO of the node is updated so that they can validate further transactions.
None of the above has anything to do with block validation. Block validation is a separate mechanism from transaction validation. Transactions are validated even when they don't belong to blocks. One of the block validation steps is to validate all block transactions with the above algorithm. Transaction validation does not require calculating any block hashes.

When a node receives a transaction, what steps does it do to verify that transaction?

This reference may be a bit obsolete (and even incorrect), but it is a good start:
https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages

I know that it verifies the block hash by calculating each hash of the contiguous blocks in order, but does it verify the balance of each wallet sending the transactions as well?

No sense in this question. Verifying transactions has nothing with checking block hash. And there is no such thing as balance of each wallet in bitcoin protocol.

And does it do the block hash calculation every time, or does it just do it when it starts up?

Checking the hash of the header of block performed only one time when the node receives the block. No need to check it more than once, because the header and its hash can not be changed later.

I know that it verifies the block hash by calculating each hash of the contiguous blocks in order

This alone just verifies that the chain is unbroken. The node will also hash the block header to verify the that hash meets the difficulty requirements for that block height. It also builds the transaction merkle tree, and verifies that the merkle root in the header matches the merkle root of the transaction data.

does it verify the balance of each wallet sending the transactions as well

A wallet is a collection of addresses. As far as the blockchain is concerned, there is no such thing as a wallet, all addresses are treated individually.
A transaction consumes one or more outputs that were previously created to certain addresses. Each address can be associate with multiple outputs. When spending coins, a transaction must reference specific outputs in the past (identified by a transaction ID + output index). The node will then verify that these outputs have not previously been spent by another transaction. It will also verified that the provided scriptSig in the transaction satisfies the requirements for spending an output (usually a signature by a specific private key).

And does it do the block hash calculation every time, or does it just do it when it starts up?

Block verification is only performed as new blocks are received. If you shutdown a node and start it again, it will only run a complete validation for new blocks.


text:
How to edit the label of an existing address exactly like in bitcoin-qt but instead using RPC calls?
I am trying to edit the label of a bitcoin address in my wallet outside of bitcoin-qt. Currently I only know of 'setaccount' but it results in two addresses after editing one, it assigns a new address to the old label for some reason?
Does anyone know if there is a way to accomplish my goal?

accounts are groups of addresses and the label you see is the name of an account. you may list this with rpc listaddressgroupings. a key that you "relabel" with setaccount will be "moved" to the account with the new label but all other addresses stay with the other account. of course you may move all addresses to another account. basically an address can only belong to one account at a time, not vice versa.
also see How do you delete an account in Bitcoin Core?

bitcoin core version 0.20.0 has: bitcoin-cli setlabel 16ga2uqnF1NqpAuQeeg7sTCAdtDUwDyJav brainwallets

source: Stack Exchange

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

sort: votes


text:
Is there a way to use My Wallet account with bitcoin-qt client?
I have some funds on My Wallet account (Blockchain.info) and I'd like to have a possibility to use them with my bitcoin-qt client. Is there a possibility to do that? Please give short description. I get many "Yes" answears on some forum but still can not do that.

Yes, export the private key(s) of the addresses that have funds on blockchain.info using the settings/advanced section and then import them into the bitcoin-qt software. You will then have full access to the address(es) in both wallets.
in the bitcoin-qt debug console..
importprivkey "keyhere"

Edit:  Don't forget change from transactions may not go back into the original address - so once you've made a transaction it may be that you have to repeat the export & import private key process to have the funds available on both wallets.

I don't think it would corrupt anything, I've successfully shared keys many times. Though I always wait for everything to sync. There is a chance of a double spend but assuming you don't try to double spend and wait for sync you'll be fine.

What would happen is the transaction would be broadcast as normal, but quickly rejected by the network. It wouldn't corrupt his wallet.dat and he wouldn't lose any of his keys. Sure, the software may not notice until sully sync'd but I honestly don't see how it would corrupt anything.

semantics? I quote "then your ref client wallet will become corrupted". That comment is the only reason I replied. Anyway, agreed, enough of this thread.

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


text:
How to start programming using Ethereum?
I'd like to listen opinions of people that have created already their own working contract. What have you read at the beginning and then? What was the most powerful source that helped you understand Ethereum generally and then deeper?

Full Documentation of Ethereum "Frontier":

http://ethereum.gitbooks.io/frontier-guide/content/

Discussion Forum:

http://forum.ethereum.org

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


text:
Why is the opcode limit 201?
In pre-taproot scripts, the maximum number of non-push opcodes is 201 (defined by the constant MAX_OPS_PER_SCRIPT). Is this a result of an off-by-one error where the originally intended value was 200?

Yes. The limit was originally introduced by Satoshi in Bitcoin v0.3.7 in July 2010:
    if (opcode > OP_16 && nOpCount++ > 200)
        return false;

However, because the expression uses a postfix operator, the condition checks what the value of nOpCount was before it was incremented, and this allows it to go up to 201.
Satoshi later noticed the mistake and corrected it in Bitcoin v0.3.12 in September 2010:
    if (opcode > OP_16 && ++nOpCount > 201)
        return false;

He apparently didn't think this small mistake was worth making another change to consensus rules (even though consensus changes were a normal occurrence at the time – according to BitMEX Research there were at least 6 in 2010 alone), which is why the limit remains at 201 to this day.

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


text:
Could the Bitcoin network support billions of nodes?
Current estimates for the number of active Bitcoin nodes range from tens of thousands to hundreds of thousands. However, is there a practical limit to how many nodes the network can support, other than the bandwidth of the Internet itself? Could every person in the world run a full node?
Inspired by this tweet: https://twitter.com/notgrubles/status/1858587084719579171

Scalability context
So far as I can tell, most scholarly articles on Bitcoin scalability focus on the upper limits to transactions per second. This seems to be of greater concern than upper bounds to number of nodes.
Another issue that seems to occupy more attention is the size of the blockchain data that every full node must store and process. See "sharding" etc.
Max nodes
Putting aside Internet bandwidth etc. One limit to number of nodes would be that if the latency of the gossip protocol across the whole network is near or above the ten-minute block interval, it would presumably be likely that the network would naturally split. I suppose an indicator of the approach to this might be an accelerating  increase in the number of small scale reorgs.
Since any node only needs to communicate with a handful of "nearby" nodes, I imagine this issue depends largely on the maximum number of hops between any two nodes (or significant groups of nodes) where one hop is one Bitcoin node communicating with another Bitcoin node (each is invariable many IP routing hops, different use of the word hop)
I think this is probably related to the concept of "version-age" of information in a gossip network. There are many articles on this more general issue (e.g.)
Data throughput is probably less of a constraint on number of nodes since the data throughput for any synchronised node is independent of network size. Around 4 MB per 10 minutes plus overheads. Less for SPV nodes, which might form a majority in a large network.
You will note the above is speculation and unquantified.


text:
Why is my P2P_V2 peer connected over a v1 connection?
Bitcoin Core 27.0 which enables v2 transport (BIP324) by default was released a few days ago. I'm already seeing a few peers with the /Satoshi:27.0.0/ user agent and all of them have the P2P_V2 service flag set. However, one of the peers (inbound) is connected over a v1 connection. Is this evidence of network tampering (as failed v2 connections retry as v1), or could there be another reason?

What version are you running?

27.0, but I don't think there's any difference from 26.0 with respect to BIP324 except for the changed default, right?

Even if both peers support BIP324, the initiator of the connection might not have known that the acceptor did. Bitcoin Core (as of v27) has downgrading logic (i.e., it will retry with v1 if a v2 connection fails in some circumstances), but no upgrade logic (it will not automatically reconnect when a v1 peer tells it it supports v2).
My best guess is simply that your peer did not have up-to-date "addr" information about your node.


text:
Which wallets are spending P2TR with SIGHASH_ALL?
I noticed there are quite a lot of transactions spending taproot key path inputs that use SIGHASH_ALL instead of SIGHASH_DEFAULT in signatures (around 20% in the last two weeks). Recall that SIGHASH_DEFAULT is a sighash flag introduced in BIP341 that is equivalent to SIGHASH_ALL but saves 1 witness byte.
Example transactions: (all from block 799301)
14a5060a907fa55b19fb75173236acee077792816b6cd8d97e3ae226b4acab6a
8c4dcdb47b2e806f1dd2c306e5021bc1b3eb763bf98d3a9b26081e273da55bfe
552b20e3d4b4d97bd03cd8f58fe6979fae74d04cead37f080692a1f6d30356bc
a81d9024708a255b5563dca9c4baf5b0056424fb329840ac97428e814054994e
Which wallets are creating these signatures, and why?


text:
what is fee_estimates.dat data format?
I'm trying to parse the file fee_estimates.dat.
What is the format of the binary data inside fee_estimates.dat ?
I didn't find any information about it in the dev documentation of Bitcoin.
This is the result of the hexdump command for the first 10 lines :
0000000 498c 0002 bf84 0002 bf6d 0007 0000 0000
0000010 0000 0000 00be 0000 0000 8f40 0040 0000
0000020 0000 9068 0040 0000 0000 913a 0040 0000
0000030 8000 9216 6740 6666 0666 92fe 2040 eb85
0000040 2051 93f1 2f40 9db2 61ef 94f0 7e40 3261
0000050 66d5 95fc c540 db4c d25f 9715 0240 d977
0000060 5017 983d f640 0abc 9419 9973 cf40 b1ac
0000070 5b80 9ab9 0d40 ba8f 6ce0 9c0f 0140 c3e3
0000080 98b8 9d76 c140 3414 b9f5 9eef 4c40 54f1
0000090 db3a a03d c340 0c63 bfca a10d c040 f368

I tried to read the code of the file fees.cpp but I'm not an C++ expert.
This is my python script :
# version required to estimate fees
version_r = f.read(4)
# actual version of my node
version_c = f.read(4)
# best block parsed ??
nFileBestSeenHeight = f.read(4)
# first block with historical fees data ??
nFileHistoricalFirst = f.read(4)
# best block with historical fees data ??
nFileHistoricalBest = f.read(4)

After parsing (little endian and bitcoin version decoding) I get :
version required: 0.14.99.00
version client: 0.18.01.00
nFileBestSeenHeight: 507757
nFileHistoricalFirst: 0
nFileHistoricalBest: 0

I have tried to parse the next bytes without sucess.
Any ideas ?


text:
funds in hd wallet
I have a doubt on HD wallets, I have generated a sequence of address.

how to check the balance of each address or how we can look for balance.
Did the amount move to the base address as like monero eg. the funds once send to the integrated address it will move the base address.
How to restore the wallet.

Thanks in advance.

did you find any answer for below question
-Then how exchange are moving funds if they are using HD wallets. They manual move all the funds to cold storage. If they manual, how they can bare the transaction fee. –

How to check the balance of each address or how we can look for balance?

You will have to scan the blockchain and find the UTXOs that are locked with your addresses in the locking script. You can either do that by running a full node by downloading and verifying the blockchain yourself, or run a Simplified Payment Verification (SPV) node and query other nodes using bloom filters. You can also use Electrum and import the addresses to create a watch-only wallet.

Did the amount move to the base address as like monero eg. the funds once send to the integrated address it will move the base address?

There is no funds "moving" to base addresses. Only the private key that can unlock the UTXO will be able to spend the bitcoins. Generally, when you import your HD seed into any standard wallet, it will start generating child keys and scan the blockchain to see if there are any UTXOs that can be controlled by these child keys.

How to restore the wallet?

Just backup the mnemonic or the seed that was used to generate the child keys and addresses. Any standard wallet will be able to generate addresses if you have the seed.

for second, how it can be achieved.

@Sarath - you mean SPV node or Electrum wallet?

-Then how exchange are moving funds if they are using HD wallets. They manual move all the funds to cold storage. If they manual, how they can bare the transaction fee.

'''when you import your HD seed into any standard wallet, it will start generating child keys and scan the blockchain to see if there are any UTXOs that can be controlled by these child keys''' does this men, when a seed is provided , the wallet will start deriving child addresses, and start crawling  blockchain to see if any of the transaction is intendent to that address?

@cryptoKTM If it is a full node, it already has the UTXO database so it can directly query the UTXO set. So the full node will generate the child addresses and query this UTXO set. If it is a SPV node, it would query information from connected full nodes using bloom filters,


text:
Why do transactions have to be bundled in a block? Why not mine single transactions separately?
Why do transactions have to be bundled in a block? Why not mine single transactions separately?
What is the advantage of bundling transactions in a block?
Also are there any blockchains/decentralized ledgers that mine transactions separately?

There are different concerns about the needs transactions and blocks have.
Transactions are created by wallets and other software, whenever they want to transact. We generally want a system that supports anyone creating transactions at any time, with as little coordination needed with other parties, and with as much volume/frequency as possible.
Blocks on the other hand exist to order otherwise valid transactions, so as to decide between multiple conflicting transactions. When two distinct and otherwise valid transactions that both spend the same money are published, we cannot permit both, but how do we decide which one? In Bitcoin, this is performed by miners, by finding and publishing blocks.
Here is the distinction: transactions don't need synchronization with the entire world. They're created by the sender, and may in general be ordered in whatever way compared to most other transactions people worldwide create. But this isn't true for blocks: blocks refer to the the previous block, and whenever a block doesn't do that, there is a fork that needs to be resolved.
Let's think for a minute what the requirements are for the rate of block creation. Clearly we'd want blocks to be as fast as possible. But how fast can they go? If blocks go too fast, the network will fail to converge. Imagine it takes 1 second for blocks to propagate from any one miner to the next one (because the speed of light, and the speed of computer processing is finite, there has to be such a limit - and the more spread out miners are (something we want to encourage), the higher it is), and there would be more than 1 block per second. This would generally mean that blocks would be found by miners before they've heard about the previous block. The result would be massive reorganizations, or possibly just every miner building their own chain, being unable the incorporate blocks from other miners fast enough.
So, we want blocks to generally be slower than the time it takes for them to propagate across the network. But even if they're just a bit slower, they create potentially huge unfairness: when the ratio of interblock/propagation is non-negligible, larger miners benefit. This is because miners can build faster on top of their own blocks than on top of other miners' blocks (simply because it takes time for them to know about it). This generally results in a slight incentive to centralize - either by merging pools, or at least to be geographically/topologically close to other miners. Miners who are further (in terms of delay) away from the majority of the hashrate will win less than proportional to their hashrate many blocks. This is highly undesirable if the intent is a decentralized system.


text:
Do nodes or miners have ids
Do bitcoin nodes or miners have ids that can be used to identify them. Like how do we know if it is the same miner that has added several blocks consecutively? Or how can I identify a node uniquely?

Neither nodes nor miners have unique ids at the protocol level, by design.
Some miners however do voluntarily put messages in the blocks they produce, which allows identification (but, those could also easily be faked, if anyone was so inclined).

Some mining pools also reuse the same payout address, which could only be faked by forfeiting the block reward.

@Pieter Wuille, when you say by design do you mean it can be designed so that miners and nodes have unique ids. Let us say you want to create a protocol called "proof-of-consistency"(bare with me please. :) I do not know much about this,). Can you create a protocol that checks how consistent a node or a miner has been in submitting truthful information to the blockchain for example like timestamp and reward them for it?

When creating hashpower pools you're miner (rig ) is associated as having a miner address which is the same as you're wallet address so technically no the miner itself has no id bit uses the wallet address to be identified when assigning jobs and pools.


text:
Theoretically how large can a blockchain block be?
How large can a blockchain block be? This is not specific to the current bitcoin blockchain or any blockchain. Just assuming you are creating a blockchain, how large can the blocks be?
Also what are the pros and cons of large blockchain blocks?

A blockchain does not have a theoretical limit. The things that limit blockchain is the hardware we have so for example if bitcoins blockchain is 1000000000000 tb then miners need to get more than that tb which is a problem to the miners. Also one more thing that could limit the blockchain security is what hashing algorithm you use. if u use sha1 the limit is much smaller than sha512. But none of these are a limit to a blockchain just some restrictions to consider.

To my knowledge, there is no theoretical limit to the size of a blockchain block - you can design it to be as large as you would like it to be as long as there is enough storage space on the network's devices.
The advantage of large blocks would be that you can fit more data inside them. In the case of Bitcoin, for instance, you would be able to include a larger amount of transactions into a block, which would decrease the wait times for initial mining as well as fees.
The disadvantage is that every block has to be broadcasted over the network, validated by its peers (full-nodes) and subsequently stored. Large block sizes can lead to a blockchain quickly gaining mass, which reduces the amount of devices that it can be stored on. It may also allow the blockchain to be misused for data storage purposes (e.g., Satoshi's whitepaper stored inside the Bitcoin blockchain), as the fees on transaction sizes would generally be lower.
Ideally the block-size should be chosen large enough for the blockchain to fulfill its purpose (e.g., storing transaction data), but small enough so that it does not pose unnecessary burden on the network's peers.

But even in the current bitcoin blockchains more transactions just means more blocks therefore more burden to network's peers.

Yes but the more peers the less load the less pears the more load. So if there are 7 billion miners and 5000 transactions per sec then u dont have to worry but if there are 5000 peers and 7 billion transactions per sec than that might be a problem. But bitcoins peers number is mostly in a uptrend so we dont have to worry.


text:
Can you get the seed phrase of a HD wallet from the private key of one of the wallets?
Let us say I have a HD wallet. Can I get it’s seed phrase from the private key of one of its wallets?
Also are seed phrases just easy to remember private keys? If so does that mean that from the seed phrase private key you can get a public key? And if this is true if I send cryptos to this public key in which HD wallet is it going to appear in? The first one?

Let us say I have a HD wallet. Can I get it’s seed phrase from the private key of one of its wallets?

No, the mathematical processes are one-way processes. See BIP 39 and PBKDF2

Also are seed phrases just easy to remember private keys?

Seed phrases are not intended to be memorised. They are intended to be written down and stored somewhere safe. For example you might use letter punches to stamp the phrase into stainless steel sheet and store the sheet in a safety deposit box.

from the seed phrase private key you can get a public key?

Yes. See BIP 32

if I send cryptos to this public key in which HD wallet is it going to appear in?

Money will appear in, and be spendable from, every appropriately-configured wallet created using that seed-phrase.
If you are thinking of each key pair derived from the master node as a wallet in its own right (which I think is a misleading way to think of things, or at least unhelpfully ambiguous) then the money is only associated with one of the key-pairs in one of the "wallets" derived from the "master node". But that "wallet" (depth 1 derivation) can exist in many wallets (multiple wallet software installations on one or many computers)

Is depth zero (the master node) a wallet that can receive funds?

Not normally, as far as I know.


text:
Bitcoin core RPC FEE
I want to use BitcoinCore for the RPC requests from the site. But I could not find anywhere else how to ask a commission for withdrawal.
 In the instruction there is only:
 sendtoaddress: bitcoinaddress amount comment comment-to - there is nowhere to cover the commision.
 settxfee: amount - it is assigned to the entire account, not to a specific transaction.
How to implement the conclusion with a manual commission?

Welcome @22VOLT, can you explain what you mean by commission, do you mean transaction fee to the miners?

If you want to set the transaction fee manually, then you will need to use the *rawtransaction commands. Those commands give you full control over the inputs and outputs so you can set the fee accordingly (since the fee is the difference between the inputs and outputs).
You can create a raw transaction with no inputs and no change output using createrawtransaction. You do so like this:
bitcoin-cli createrawtransaction '[]' '[{"<address>":<amount}]'

where <address> is the address you want to send to and <amount> is the amount you want to send. You can then take the resulting raw transaction and use fundrawtransaction with it to get inputs and a change output if necessary. fundrawtransaction allows you to set the fee rate. So if you wanted a transaction with a fee rate of 0.0001 BTC/kB (10 satoshis per byte):
bitcoin-cli fundrawtransaction <raw tx> '{"feeRate":0.0001}'

The funded transaction is the one in the hex field of the output of that command. You sign this with signrawtransaction and then broadcast it with sendrawtransaction.


text:
How do I find who sent the transaction

The address: 1A5PsNLUs6BNWvNSzooGSFVKdkaJ4e2TG2
TXID:
Amount: 0.0127

the bitcoin system is a pseudonymous system, where spending of funds is intentionally not linked to names or owners. With the idea of not re-using addresses, it makes it nearly impossible, to relate any spends to a particular person.

Is it possible to find which address sent the transaction? In the ethereum blockchain, it is possible to find the sender and the receiver.

I drop my comment in the answer section, cause there is not enough space...
looking at the raw transaction, one can see many funds from several addresses mixed to other outputs. The closest I can get, is that tx_out[2] is corresponding to the mentioned address. So there is not a single source, from which the funds were sent.
All the inputs are 2-of-3 (multisig) addresses, and none of the included keys of these 2-of-3 corresponds to the mentioned address. As such I cannot say, where the funds came from. Essentially this transaction was compiled to collect funds from 10 transactions, and redistribute them  over 11 output addresses.
As the amounts are fairly similar, I guess it is a payout schema like used in faucets. Also exchanges use this style of "funds moving" between hot and cold wallets.


text:
What is preventing negative balance?
This is probably a stupid question that has an answer somewhere, but I was unable to find anything, so please feel free to redirect me !
I have a basic understanding of how the bitcoin blockchain works, namely, you sign and broadcast your transaction, it gets picked up by the nodes and is eventally included in a block that is mined.
I understand that as long as there isn't someone controlling more than 50% of the mining power, it is unlikely to be able to perform a double spend attempt.
However, what prevents someone from spending more bitcoins that they have ? For example, if I have 1 BTC on my adress, suppose I run a mining node, what prevents me from trying to mine a block in which I spend 1.2 BTC ? At what point in the process is the balance of my adress checked to make sure I do have the bitcoin that I want to spend ?
At first I thought that it was the nodes that verified that the transaction on the mempool are valid before starting to mine them but this can't be it, since you could have a malicious node that does whatever (although it would be difficult to pull off without enough mining power).
This check must be somehow "hard-coded" somewhere, in the sense that it is actually impossible to create a transaction of inexistent bitcoin. Could someone point me to a resource or elaborate how does this work ?

Next to the detailed answers below, I wanted to link to the wiki as well, which shows the protocol rules: https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages

if I have 1 BTC on my address, suppose I run a mining node, what prevents me from trying to mine a block in which I spend 1.2 BTC ?

This is the specific set of code in Bitcoin Core that rejects anyone's transaction who's is putting less money into the transaction (inputs) than the recipients are receiving (outputs), e.g. spending more money than they have added to the transaction:
const CAmount value_out = tx.GetValueOut();
if (nValueIn < value_out) {
    return state.DoS(100, false, REJECT_INVALID, "bad-txns-in-belowout", false,
        strprintf("value in (%s) < value out (%s)", FormatMoney(nValueIn), FormatMoney(value_out)));
}

Technically, this isn't checking the "balance" of an address, since in Bitcoin system itself, addresses don't have balances.  When you receive bitcoins, you receive them to an individually-identifiable output (payment).  When you spend bitcoins, you identify exactly which output (or outputs) you want to spend and spend all of that value at once.
If you want to pay someone less than the full value of one of your outputs, you add an extra output on to your payment that returns the remainder to yourself.  This is like paying for a $2 snack with a $5 bill and receiving $3 change back to yourself (and it Bitcoin, we call that extra output paying yourself the "change output" by analogy).
So in the code above, by checking every single spend in the system to prevent anyone from receivng more bitcoins than were initially spent (except for newly-minted bitcoins), we prevent negative balances.

At what point in the process is the balance of my adress checked to make sure I do have the bitcoin that I want to spend ?

As explained above, inputs and outputs (rather than address balances) are what's checked.  They're ultimately checked when a block is received; however, the software may check them for unconfirmed transactions and cache the result so that it can process newly-received blocks faster.

Somewhat related, you also can't pay someone a negative output:
    if (txout.nValue < 0)
        return state.DoS(100, false, REJECT_INVALID, "bad-txns-vout-negative");

Is that the actual code, and if so, why does it check for "less than" rather than "not equal"?  Wouldn't it make more sense to require that each transaction cause no net change in the total amount of Bitcoin available?

@Mark The difference is paid as fees to the miner

However, what prevents someone from spending more bitcoins that they have ? For example, if I have 1 BTC on my adress, suppose I run a mining node, what prevents me from trying to mine a block in which I spend 1.2 BTC ? At what point in the process is the balance of my adress checked to make sure I do have the bitcoin that I want to spend ?

You may be working from a faulty mental model. Bitcoin is an electronic cash system. This probably doesn't mean what you think it does.
https://bitzuma.com/posts/bitcoin-think-of-it-as-electronic-cash/
Electronic cash is a system in which users exchange digital tokens for goods and services. In Bitcoin these are called "coins," or more technically unspent transaction outputs (UTXOs).
A UTXO will be completely spent in a transaction. The state of a transaction output can, in other words, only be spent or unspent. An output (coin) can never have a negative value - just like in physical cash systems it's impossible for a bank note or coin to have a negative value.
There are no accounts in Bitcoin. Addresses are a higher-level construct that make it appear as if accounts exist. It's a potentially dangerous misconception:
https://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/

Thanks for the precisions, they are helpful. What I still struggle to understand is where is the verification "is the output negative" done.
If I have a program running on my computer it is my computer that will do the computations and verify if the output is negative. If this is the role of nodes, what prevents a node from being malicious ? In other words, what enforces it to use the code that checks "is output negative" ? Maybe there isn't any, but my understanding was that even if you have full mining power, you cannot do "anything", i.e. cannot create more bitcoins for example.

The verification is done by a full node (yours, for example). If a transaction contains an output with a negative value, the block containing it will be rejected as invalid. This applies even if the block has sufficient proof-of-work. Overall network behavior is a composite of individual node behavior. In other words, all honest nodes will also reject such a block.

Thank you, that clears things up. Does that mean that if a networks contains more malicious nodes than honest ones, anything like spending inexistent bitcoins or creating bitcoins would be possible ?

No. The purpose of the network is to allow users to detect double spending. A node will never accept a block spending nonexistent coins or creating money out of thin air. But it does need the network as a check on double spending. The network does this by creating a cost for rewriting the block chain in the form of proof-of-work.

Each output on the chain is assigned a certain value. When you spend outputs in a transaction, the sum of the new outputs created cannot exceed the sum of the outputs being consumed (the inputs). This is part of transaction validation.
Moreover, even if a malicious miner were to mine a block in which they created extra bitcoins, the rest of the network would reject it as it would not longer meet the consensus rules which includes the transaction amount check. Thus, the miner's block would be rejected, and they would lose any money they spent on mining that block, as the block reward is invalidated as well.

What do you mean "the rest of the network would reject it" ? How does this rejection happen ?

Any nodes that receive a transaction or block that doesn't follow the rules will simply refuse to broadcast it any further. It'll be like it never existed. Other miners will continue mining on a chain that doesn't include that block.

I see. Does that mean that there could be potentially a "node attack", in the sense that you run several full nodes that broadcast transactions that don't follow the rules ?

You would pretty much just end up running a minor network then, since the larger btc network would still not accept your transactions. All you would achieve is a fork that only you are on


text:
Any idea how to download a small part of the chain for testing purposes?
I am experimenting with Python and Rust libraries on my laptop. I don't actually want to get a node going on it and download the full chain; I just need some blocks to play with.
I want to keep my question general enough though; what is the easiest way for someone to download just a small portion of the blockchain, given specific beginning and end points in block numbers? Are there any libraries that would do that either in Python, JS, or Rust (or any other languages, so my question applies to all developers)?

If you know what hashes of the blocks you want, you can use the P2P protocol to connect to a node and request those specific blocks. However, you cannot just do that with block heights as the block's height is not a unique identifier for the block. There are many libraries available that can speak the P2P protocol. The python-bitcoinlib can be used to send the P2P messages necessary for doing this.

As far as I know, there is no way to download arbitrary blocks (although I suspect it's not too hard to do if you implement your own client).
If you just want blocks for testing, you won't have much trouble finding bootstrap.dats that contain a few hundred thousand blocks. Alternatively, you could just run bitcoin core for half an hour or so and get a few thousand blocks from the start of the chain - The early blocks are mostly empty and download pretty quick.


text:
Where can I see a Pay to Anchor output in the wild?
I'm reading about the new features of the Bitcoin Core 28 release and would like to see one of those PayToAnchor outputs on either mainnet, testnet, or signet. Can anyone provide me with a link to one?

Here are some links for them on mempool.space:

Mainnet
Signet/Testnet


text:
Can I trace Bitcoin transactions using spent_transaction_hash?
I've spent some time analyzing Bitcoin transaction data and found out that the input column has this value called "spent_transaction_hash". In the dataset, the definition of this value is "the hash of the transaction which contains the output that this input spends".
I wonder if I can use this value to trace previous transactions. For example, let's say I have this Bitcoin transaction data:
Hash     Input      Output      Spent_transaction_hash
1234       1          3               5678
5678       2          1               8910

Since spent_transaction_hash means the hash of the transactions whose output was the input to the current transaction, is it safe to say the second transaction(hash: 5678) was the previous transaction of the current transaction (1234) and they are connected?
Thank you.

Yes the previous transaction hash links the two transactions. More accurately it identifies the transaction in which money was received into the control of the person spending that money in this transaction.
Firstly, note that a transaction can have many inputs not just one, so there can be several previous transaction hashes linking several transactions to the current one.
Secondly, note that there is no link between specific inputs and specific outputs of a transaction. So you cannot trace the flow of money with any certainty. Especially if the creator of the transaction takes simple measures to improve their privacy.

Related:

Trace fund flows between Bitcon addresses using transaction data
How can someone steal bitcoins and hide it?
Is it true that all the bitcoins in existence are on the blockchain (the ledge), but it just depends on who the owner (address) is?


text:
How does bitcoin determine whether or not a peer is lying about having a valid chain?
I'm interested in the exact specifics of how Bitcoin rejects a "false" chain. Suppose I create thousands of arbitrary low POW chains and launch peers on the BTC network that clients will (with some probability) connect to. If I make enough of these fake peers the probability will be quite high (perhaps even enough that many clients would get all 8 random peers that are fake).
How do the clients that receive data from these fake peers determine that the chains being provided are fake?

There are multiple different lines of defense against the scenario you describe.
When nodes connect to each other, they exchange information about the best chaintips they know about. Nodes will then aim to catch up with the one that has the most work in total accumulated difficulty. Low-work chains will be easy to dismiss in comparison. This means that when a node has a single peer that has the best chain, it'll end up on the best chain.
When nodes connect to the network, they first try finding the peers they knew about already from their previous connections. If they have no previous connections, to find the first nodes on the network, they reach out to a DNS seed. These DNS seeds provide long lists of potential peers from nodes they've seen on the network themselves. The node then makes outbound connections to eight of them. The DNS seeds are run by community members and have been reliable. The node will ask for further peers and continuously check whether there are actual Bitcoin nodes associated with the addresses it hears about to build up a list of potential peers.
If however the attacker operated a DNS seed, they could eclipse new node victims by only providing IPs of their own nodes. If this attack were aimed at everyone that connects to this DNS seed, such an attack would probably be noticed quickly and the DNS seed fixed/removed. If it were targeted against a specific individual it would be extremely unlikely that the victim connects specifically to the attacker's DNS seed, and the attacker would need to know the victim's IP address in advance. Also, node operators subject to the eclipse attack could easily break out by manually connecting to a single honest node. If the node operator notices that something is weird (e.g. the latest blocks don't correspond to the publicly documented blokchain), the node operator could find an IP address of a honest node either on one of the many forums or a site that tracks Bitcoin node population like https://bitnodes.io/ and manually connect to it. Once they have a single honest connection, this connection will gossip more peers to them.
Nodes actively manage their peers. They prefer to stay connected to nodes that have provided them useful information. When they connect to a new peer, they drop the peer that hasn't provided new useful information for the longest time. If a peer has both honest peers and low-POW attacker peers, the attacker peers would get dropped first. This would cause the attacker nodes to be practically expelled from the network: nobody would gossip about them, they'd not be on DNS seed lists, nobody would ever connect to them.
There are a few more things that Bitcoin does, like picking peers from different IP spaces, block-only connections, feeler connections, etc., but that might go a bit too deep into the weeds.

Thanks this is very helpful. Deep in the weeds is exactly what I'm looking for as I'm implementing a full crypto currency from the ground up. If you have any links to the source code for peer management that'd be super helpful. I've looked through the bitcoin source but it's quite a large project, difficult to find these nuances portions.


text:
How to download just the blockheaders for the blockchain
I'd like to download all the blockheaders for the blockchain directly from the network (not an external API) ... what is the best way to do this?
I don't actually care about the transaction data and have no need for it, specifically, I need the difficulty level at each block, along with the timestamp. I know there are API's etc. to get this information but I specifically do not want to do that for my use case. I would not like to run the entire bitcoind service locally (there is too much overhead downloading the whole chain, verifying it etc.)

You can make it with getheaders p2p message, will return headers of blocks in a range.
Remember of handshaking and setting tx-relay to false.

Thanks! This is what I'm looking for. Is there a C++ library that could handle sending/receiving the data?

A procedure for doing this using Electrum 4.5.5 on Ubuntu:

Download the Electrum Python code (from here; https://electrum.org/#download
) and save to /your/path/electrum455

Ensure you have the necessary dependencies (consult /your/path/electrum455/README.md, sudo apt-get install libsecp256k1-dev typical)

Clear the file /your/path/electrum455/electrum/checkpoints.json (ensures all headers are downloaded, can be left if only recent headers required)

Change directory to /your/path/electrum

run Electrum using the command ./run_electrum and go through wallet setup

Electrum will now create a file called blockchain_headers in the ~/.electrum directory.
Within a short time <30 mins, the file will contain the binary block headers in order, that can be parsed.


text:
What are the risks of using a non-randomized context with signing contexts?
I am designing an API which will utilize libsecp256k1.
I am trying to hide most of the low-level stuff, and context is one of the things I want to handle for a consumer of my API. It would be difficult to have the user mess with contexts when they don't want to care about the crypto low-level things.
As I understand, the signing context should be randomized for security purposes.

What is the worst case scenario if I release a library that uses a non-randomized signing context for these functions? Side-channel weakness? Definite secret key leakage? etc.
How much would a weak prng randomization help, if any? (for environment where csprng is not available, etc.)
I read that they are moving toward possibly removing need for context management and including some sort of precompiled global solution. Would this remove the need to worry in exchange for slightly larger binary if used?

Thank you in advanced!

Assuming no bugs, obviously:

Only potential side-channel leakage, and on major platforms likely no timing leaks even (there are tests to detect non-constant time behavior in the compiled code).

Any randomness an attacker does not have access to helps.

There will likely still be context objects (among other reasons, to carry randomization data), but they will be more lightweight to construct. The "default" static context will likely be expanded to support all operations, but not have any randomization.

In general I would advise you to hide contexts from the user, but construct them at initialization time using randomness, and cache them for later usage.
Source: am co-maintainer of the library.

Thank you for your contributions. I am glad to know my understanding is correct.


text:
REST API to fetch block by height
I am trying to incorporate bitcoin in one of the applications and want to integrate the REST API which exposes all the public information.
I tried using https://chain.api.btc.com/v3/block/3 but upon multiple requests, it starts to error out with message "Do not abuse the api".
Kindly provide the reference to API which I can use
Note: Tried https://testnet.blockexplorer.com/api as well but doesnt work. Even the link on https://github.com/blockchain/api-v1-client-python#request-limits-and-api-keys leads to error page on web

I don't know if there  is an unlimited and free service as you looking for,  but you can easily setup your own Bitcoin node and make all the calls you want, in addition it helps the Bitcoin network to be healthier and safer.
https://bitcoin.org/en/full-node
https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md

If you plan to using any API extensively I suggest installing bitcoin core and using RPC provided.


text:
Parsing P2SH address from output script
I have already looked at link.
I am trying to generate P2SH address from output script but no luck. I am using transaction  40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8 for testing purpose which has one input and one output. The output goes to P2SH address that starts with 3. Output script looks like below
OP_HASH160
e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a
OP_EQUAL

And destination address is 3P14159f73E4gFr7JterCCQh9QjiTjiZrG as per open source explorers. I tried
Base58Check(e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a)
Followed instructions on https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
But could not land to the address. Can anyone help me decoding the output script to fetch address.

Did you use the correct version byte? P2SH is 05.

Yes. I tried 1 and 5 both but didnt work

Can you post all of the steps that you did?

The hash160 of the script is
e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a

Prepend the version byte 05
05e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a

Double sha-256 gives a checksum of
1. 5dad64852fbff1510074011803d9bf50b9650a517240d298a07ea5c525cdc5e7
2. 7f297f3156a14d114af23b33c339817a1241afcb52a154d19683c67c538b7278
first 4 bytes: 7f297f31

Encoding
05e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a7f297f31

as Bitcoin's Base58 gives
3P14159f73E4gFr7JterCCQh9QjiTjiZrG

By the way, that's a pretty cool address. I assume it's a vanity address, 3 P(oint) 14159 = π.


text:
How can I force estimatesmartfee to return estimates on regtest?
Creating an app that utilizes estimatesmartfee, and it works in production, but I use regtest for automated testing and can't get it to return a value.
Looking at bitcoind tests it is splitting UTXOs in a loop etc.
What is the bare minimum I need to do as far as dummy transactions and mining blocks in order to get estimatesmartfee to work like it does on mainnet.
Thanks.

what is the error message that you get? Or are you getting a constant recommendation at 1 sat/B? I am guessing you need more than 1 vMB of pending transactions

Question related to my unanswered question: https://bitcoin.stackexchange.com/questions/84983/how-to-convert-fee-estimates-dat-into-a-human-readable-format

You need to fill up the mempool of your regtest nodes and mine blocks (this means creating transactions --eg by using sendtoaddress-- and generating blocks --with generatoaddress).
For reference here is how it's done to test estimatesmartfee.


text:
Get crypto-currency price at a timestamp without limits
I'm trying to get the price of a crypto-currency at a specific timestamp. So I used the API cryptocompare :
https://www.cryptocompare.com/api/#
For example :
https://min-api.cryptocompare.com/data/pricehistorical?fsym=ETH&tsyms=USD&ts=mytimestamp
This solution works well but I have some issues related to the limitation of the API.
I need to get the price more than 26k times and unfortunately this API won't let me do as many requests.
It returns me this error :

{"Response":"Error","Type":99,"MaxLimits":{"Minute":300,"Second":15,"Hour":8000},"Message":"Rate
  limit
  excedeed!","Aggregated":false,"Data":[],"YourCalls":{"hour":{"Histo":16},"minute":{"Histo":16},"second":{"Histo":16}}}

Do you have a solution to avoid that ? Is there a way to get all the prices in only one request ?
Someone as mentionned that on reddit : https://www.reddit.com/r/ethereum/comments/6xbwxp/ethereum_price_history_api/
But I didn't find how to do it.

did you find any solution to this?


text:
Electrum multisig 2of2 on separate machines and both offline(cold storage)
I am lost sending coins from these Electrum 2of2 multisig wallets. Call them mutisig1 and multisig2. Both wallets have the 2of2 heading, presumably that means they are correctly setup, they were created with their own seeds and then each used the other's seed for multisig.
I use an online watch wallet(using xpub of multisig1 wallet) to create an unsigned send txn, save it to a usb drive.
load unsigned txn into multisig1  , sign it , save and export to usb drive.  (what is the difference between save and export ?)
load signed txn into multisig2. There is no sign option(greyed out) then what ?
I tried 3 methods to send the coins , all 3 different, all 3 worked(confirmed sent), at least 1 was certainly wrong(only 1 sig). Now I'm worried ! I conclude that this does not achieve 2of2 in electrum or I have screwed something up. You can pretty much do anything as long as you have at least 1 sig, it will confirm.
Test1

Online watch wallet-send txn , export to usb
Offline multisig1 wallet-load unsigned txn,  sign, save, export
Offline multisig2 wallet- load unsigned txn, sign, save, export(this overwrites the prev signed txn file from multisig1 wallet )
Load signed txn file from step 3 onto watch wallet and broadcast

Test 2
l
Only signed on 1 multisig wallet and then broadcast from watch wallet. (sent and confirmed only 1 signature !)
Test3

and 2. are the same, but 3. I just loaded the signed txn on multisig2 and then saved and exported it back. Sign button was greyed out.

A watch only version of a multisig wallet must be created using the xpubs of both wallets not just the xpub of one wallet. Now there are two possibilities here:

You created a wallet with one xpub and one seed. This wallet is not watch only and transactions generated by it need only be signed by the wallet whose xpub you used. You can tell if this what you did in two ways. One way is that when you open the wallet there should be no warning dialog that it is a watch-only wallet. The other is that when you attempt to spend your coins the resulting transaction preview dialog should show "partially signed 1/2" up top below the tx id.
You created a single sig watch only wallet with just one of the multisig wallet's xpubs. Transactions created by this wallet can spend bitcoins sent to single sig p2pkh or p2wpkh addresses. You need only sign it with one of the multisig wallets i.e. the one whose xpub you used. You can tell that this is what you did if you get a warning dialog about watch only wallets when you open the wallet and if it says standard for wallet type under wallet menu > information.

In order to create a proper watch only version start by creating a new wallet file via file menu > new/restore, enter a unique filename and click next. Then select multisignature as the wallet type, 2 of 2 as the number of cosigners and signatures required, choose "Use a master key" or "enter a cosigner key" when asked to add a cosigner and then enter the xpub of one of the cosigning wallets. Repeat this last step until you've entered both cosigner's xpubs.

thanks Abdussamed that makes perfect sense and explains my error. However, the security is terrible and negates the multisig imo. If an attacker just gets hold of 1 multisig private/xpub and creates a watch wallet with that, as I did, then they can spend the from either wallets with one sig,  just as I did !

I might add that I am sure that both my wallets are 2of2 (2 sigs required) because 1. it says so in the headers of both wallets 2. that is the default setting for multisig on electrum and 3. I expect that there would be a problem in the setup if the wallets were of different M of N when the mutually respective keys were entered during setup  ?

@grjack you seem to have misunderstood. The security is fine. You made a mistake setting up your watch only wallet. How about you read what I wrote and see if you can find the mistake you made?

You don't understand ! The mistake I made ,yes, enables me to drain the wallet ! That's a security flaw. What happens if an attacker makes the same "mistake" intentionally, he steals money from an M of N wallet with only 1 sig ! That makes the M of N wallet useless wrt the intention of M of N security.


text:
Running LND on testnet and mainnet at the same time on the same pc
I have two instances of bitcoind running, one on mainnet, one on testnet, without any problems.
I can't seem to find any decent documentation on running two instances of LND at the same time on the same computer. Currently I switch between the two.
Is it possible? Are there caveats? Any pointers would be appreciated.

Have you tried creating two different lnd.conf files, having different ports specification and matching the bitcoin.conf spec, and running two instances of lnd specifing the parameter --configfile?

@StefanoAngieri Yup, you were right. I've answered my own question.

It's perfectly possible to run several LND nodes on the same computer.
This is how I did it:

create separate folders for each LND node
In each folder create a lnd.conf file
make sure you set the datadir and the logdir to point to the folders you just created
make sure that each configuration uses different ports for rpclisten, listen and restlisten
adjust all other configuration to your liking. You can have multiple clients point to the the same btcd client (that's the one I used, but I'm sure it also would work with bitcoind) and the same chain or different chains
run lnd --configfile=path/to/your/lnd.conf for each lnd client you want to run

"pro"-tip
I've made aliases in .bashrc for the lnd and lncli commands for each different node.
So:
alias lnd-alice="lnd --configfile=path/to/alice/lnd.conf"
alias lnd-bob="lnd --configfile=path/to/bob/lnd.conf"
alias lncli-alice="lncli --rpcserver=localhost:10001 --macaroonpath=path/to/alice/data/chain/bitcoin/mainnet/admin.macaroon"
alias lncli-bob="lncli --rpcserver=localhost:10002 --macaroonpath=path/to/bob/data/chain/bitcoin/testnet/admin.macaroon"

To run the lnd node for alice I just type lnd-alice and then lncli-alice create if it's the first time or lncli-alice unlock if the wallet is already initialized. (The macaroon path isn't needed for create and unlock but it doesn't hurt either.)
Same thing for Bob.
This guide was very helpful in finding the right info: https://dev.lightning.community/tutorial/01-lncli/index.html


text:
Paper backup of Core descriptor wallet
As I understand it, using dumpwallet for a non-descriptor wallet in Core will give you the wallet seed in WIF format. This seed can then be used with sethdseed in a new wallet, thereby recovering the original wallet. So in effect, one can make a paper backup of a Core wallet.
But with descriptor wallets, dumpwallet does not work.
Is there a way to make a paper backup of a Bitcoin Core descriptor wallet?

For normal (not "paper") backup and restore see https://bitcoin.stackexchange.com/q/112176/13866

This is working now, with version 23 of the bitcoin-core:
How to create the descriptors wallet?

createwallet("my_wallet", False, False, "", False, True, False)
getnewaddress("my_label", "bech32")

How to save the wallet?

backup = listdescriptors(True)['descriptors']
Dump backup into a json file

This file can be printed or saved for later reuse.
How to restore the wallet?

createwallet("my_wallet_2", False, True, "", False, True, False)
Load the json file into backup
importdescriptors(backup)
getnewaddress("my_label", "bech32")

This should give the same BTC address as before.

There is currently no way to make such a backup of a Bitcoin Core descriptor wallet. There are open PRs that will allow you to export the descriptors stored in the wallet, however these have not been merged yet.

thanks. Am I right in thinking that backing up just the descriptors is not sufficient to recover a wallet? Or will the PRs you mentioned allow Core users to make paper backups?

Descriptors that contain private keys will be sufficient to recover the entire wallet.

Where are these PRs? I searched but apparently I'm bad at finding them.

The PR is here but now it is merged.

when you create the wallet, you will be shown the seed used. that is when you write the seed down.

I downvoted. This answer is not correct for Bitcoin Core's wallet, but may be true for others.

yeah im used to electrum and similar so I just assumed that btc core would work the same, my bad


text:
Can individual private keys in Bitcoin Core compromise any part of the HD wallet?
I am attempting to understand Bitcoin Core and its use of BIP32 HD hardened keys -
https://developer.bitcoin.org/devguide/wallets.html
The article explains that the HD protocol uses different index numbers to determine whether a hardened key should be used or not.
My question is does the default Bitcoin Core implementation (HD wallet) always generate hardened keys in all cases? Say I want a legacy address and run 'getnewaddress "test" "legacy"' at the console -- will it be HD generated and will it always be hardened? Is there a way to check?
If the private key of that specific generated address was later compromised, can anything be leaked about the Bitcoin Core HD wallet from which it came? Is each private key as independent as keys in a "loose keys" wallet? (as mentioned in the article)

My question is does the default Bitcoin Core implementation (HD wallet) always generate hardened keys in all cases?

HD wallets of the default wallet type, known as the legacy wallet, always uses hardened derivation. It cannot be changed to use unhardened derivation nor can it be changed to use other derivation paths. So it will always be hardened. There are no known issues with hardened derivation. Even knowing child private keys cannot result in learning a parent private key.

Say I want a legacy address and run 'getnewaddress "test" "legacy"' at the console -- will it be HD generated and will it always be hardened? Is there a way to check?

If the wallet is a legacy wallet and is set to use HD, then use, it will always use hardened derivation. You can check this by using getaddressinfo to get the derivation path used. To verify the derivation path, you can use dumpwallet to get the master private key and do the derivation yourself.

If the private key of that specific generated address was later compromised, can anything be leaked about the Bitcoin Core HD wallet from which it came? Is each private key as independent as keys in a "loose keys" wallet? (as mentioned in the article)

Hardened derivation means that it is not possible to learn anything about parent or sibling private keys given a child private key. It is, for all intents and purposes, the same as a set of randomly generated private keys.
However Bitcoin Core now supports BIPs 44, 49, and 84 which specify a set of standard derivation paths which happen to use unhardened derivation. There are used in the experimental descriptor wallets added to introduced in Bitcoin Core 0.21. Unhardened derivation has an issue where it is possible to learn the parent private key if the parent public key and a child private key is known. This can result in the compromise of an entire wallet. It is because of this that descriptor wallets do not support exporting individual private keys, and currently does not have any form of export at all.


text:
Forgot password
I got myself a wallet back in 2015. I put bitcoins in there and forgot about them. Of course, because of the course, I remembered about this wallet, but I forgot the password. I have a wallet backup, but I can't do anything. Is it possible to remove the password from the wallet? please help me

Which wallet did you use? The answer will depend on that information.

To recover your wallet you'll need to crack the password on it, since the password is used to encrypt the wallet file.
You can use a program like https://github.com/gurnec/btcrecover to attempt to crack it. If you have any idea of what the password might have been, you can supply them as hints to the program to have a better chance of cracking it. If the password was very long and you cannot provide a hint, you may be SOL until you remember it.


text:
Recovering and transferring Bitcoin to new wallet
Question from a new bee.
I received a bitcoin in 2013.
That one is on my old computer with a Bitcoin wallet (version 0.8.1-win32).
It is visible and verified
Unfortunately this wallet still has over 4.000 days to sync.
And it takes ages to complete
Besides the fact that the old laptop keeps running out of storage space :-(
On my new computer I now have the wallet Bitcoin Core (version v0.21.0)
How can I move the Bitcoin from my old laptop to my new one?
As I said, I am a bit of a nitwit on this, so please do not make it to technical ;-)
Appreciate your help.

Bitcoin Core is not a general purpose wallet. I have instructions here to extract the private keys and import them to Electrum.
You can skip the first step there. Make sure to back up the wallet.dat though.


text:
I have an hw.1 I want to access
I have an HW.1 I had lost and finally found.  I tried to access but the new ledger software does not work.  i tried with electrum, but have managed to lock myself out of pin attempts.
What can I do to recover my bitcoin from this device?  I have searched and can't seem to find much on it.

What can I do to recover my bitcoin from this device?

If the device believes it is in the hands of thieves (many failed PINs) it should never divulge its contents to anyone under any circumstances. I don't know much about the HW 1 but I'd hope (and you should too) it would either self destruct or require some sort of full-reset to be usable again - losing all its contents in the reset process.
The way to recover control over the money is to use the recovery words you wrote down and kept safe back when you first set-up the device.
As one reviewer said in 2016:

The on-boarding process is quick and easy, asking the user to pick a four-digit PIN and to write down a series of ‘recovery words’ on a bundled informational sheet.

These words allow the wallet to be regenerated onto a replacement HW.1 should you lose or damage your original, and represent the device’s weakest link. When you’ve recorded the words, the card should be sealed away in a safe and treated with the same care you would furnish upon a stack of banknotes to the value of your Bitcoin hoard.

Ledger no longer provide support for the HW 1 but the recovery words will work with later Ledger devices.


text:
Other than relying on "side-chains", is there any way that Bitcoin could solve "micro transactions"?
I am very aware of the Lightning Network, and have repeatedly tried to gain a full understanding of it and start using it. I find that, whether it's due to it being too complex or me being too stupid, I just can't seem to start using it. Even though I have a high motivation to figure this out, I just "zone out" and give up due to all the complexity and how obscure it feels.
Maybe it will be a big thing, but I have my serious doubts. It seems too complicated and confusing, like the 32X add-on to the Mega Drive/Genesis video game console. Few bought it. Its power should've been included in the main console, or in the game cartridges.
What would it take for Bitcoin itself (no add-ons) to start supporting some kind of "microtransactions" with much smaller (or no) fees and a near-instant settlement period? Perhaps there could be a maximum value for such transactions, or something, but as long as you keep under that number, you can send as little as one (1) satoshi to somebody else for free and no waiting?
At least in theory, that sounds reasonable to me. Since the transactions are so small, it doesn't matter as much as a huge/large transaction, sent via the classic Bitcoin transaction mechanism with the high fee and minimum six confirmations, etc.
But would it be possible technically?

Also: https://bitcoin.stackexchange.com/questions/102293/does-or-will-bitcoin-core-support-lightning

The main challenge is that any transaction that is transacted on the main chain will have to be stored on the blockchain in perpetuity, and processed by all full validating Bitcoin nodes. To my knowledge, all cryptocurrencies have the same property... they just aren't large enough where this is a real problem yet.
The other thing you should consider is that the actual value of a transaction to the Bitcoin network as a whole is irrelevant. A 1 satoshi transaction takes up the same blockspace as a 1 BTC transaction.
Hopefully this explains why small transactions must take place off-chain to achieve the cheap and quick settlement you mention.
The goal of a project like Lightning Network is to have microtransactions take place so they aren't taking up block space and needing to be stored and processed by all Bitcoin nodes forever. It will hopefully become easier to use as time goes on.


text:
Accepting Bitcoin Settlement for Business Invoices, Important Business Considerations
Our company is intending on accepting Bitcoin as a settlement option. Currently, we create invoices based on services we perform with 30 day payment terms and want to offer the option of settling the invoice in Bitcoin for an X% discount.
It's been very difficult finding a good definitive guide for this, so I'm attempting to get that going here. Would be open to 3rd party solutions, but also would like to know what to consider without 3rd parties.
What are the business considerations for starting to accept invoice settlements in bitcoin?

All you need in order to accept bitcoin payments is an address or addresses. Provide one address per invoice. Service recommendations on this site are not allowed.

I'm voting to leave this open, as there is useful advice to give even ignoring the 3rd party solution aspect.

@PieterWuille appreciate that. I think this is essential knowledge for any business professional looking to accept Bitcoin as a payment option. I always look for stackexchange answers.

What software do you use for billing? What software do you use for accounting? Have you made your software? Do you have access to the source code?

@Mercedes we have our own software for invoicing and marking payments. It is not very sophisticated, but we do develop it internally and have access to the source code. Other accounting activities are outsourced, but that shouldn't apply here.

I can't suggest a particular library, but worst case, you simply need to have your node create addresses and parse their balance from your stack.


text:
How do you import an air-gapped created multisig wallet from Coldcard to Electrum?
I went through the process of creating a 3/5 multisig with coldcard, air gapped. I generated an electrum wallet file, but now I'm struggling to figure out how I use electrum to import the multisig wallet (as a watch-only).
Thanks

I do not own coldcard devices but this tutorial goes through the whole process of creating a multisig wallet with Electrum.
When you open Electrum for the first time it will ask you to select a wallet file (or create a new wallet). Just select the electrum wallet file you previously created on the microSD card. As stated in the linked tutorial, the electrum file should be named something like el-CC-M-of-N.json.
This will import your multisig wallet i.e. all cosigner xpubs, allowing you to view transactions, derive addresses and create transactions for signing.


text:
How do Lightning Explorers like 1ML register closed channels?
I want to do analytics on unilaterally and mutually closed channels. To do so I need to scan know when channels close. It seems to me there's no other way than to actively scan the network graph for closed channels.
But I'm not sure if that's the right approach. How do explorers like 1ML do this?

Every Chanel that us public is announced on the gossip protocol and in the channel announcement message linked to a funding transaction. What you can do (and what 1ml most likely does) is to save spent funding TX as close channels. As the gossip protocol will only forward channel announcement messages for open channels (those where the funding TX was not spent) it will be impossible to query your lightning node for closed channels from the past. You will only be able to collect this data for the future. Or you could crawl 1ml if their robots.txt allows this.

Thank you for this. This is how I understood it to work, but I wanted to be sure I didn't overlook something.


text:
Why someone send this transaction
I've just received strange transaction from unknown address: transaction hash is 6e41f6acb7541cf4ffeddf126dbd87a01092be8d021a897350a6a332ba67a071, the sender sent 0.0215 BTC to about 3000 outputs (0.00000546 BTC to each), where one of the output was mine, full transaction is about 95 KB of size. I used the address (which is on of the output) only for private use and didn't share it explicitly.
What can be the purpose of such transaction? Does this sender is trying to spy on all receivers, or what it can be?


text:
Can't see balance after some time
I'm trying to use bitcoinj library to receive bitcoin payments and monitor the balance on the address. My implementation is based on DeterministicKey watching public key. The code below is working fine for some time, it prints a message when coins received and print correct balance after it. But if I restart it, the balance becomes zero and the wallet loses all received previously transactions (getTransactionsByTime() is empty list), so it's working only if I send some coins to the static address while the code is running. Also if I start the code again and send new coins to the same address (it's static), I'll see only new transaction, all previous are lost. This is my demo code to check it's working (groovy):
def net = TestNet3Params.get()
def wlt = Wallet.fromWatchingKey(net, DeterministicKey.deserializeB58('tpubD9xtwS1WLdbdLQKCSiR8kiwBwWzL1C1qq7LTgMq12ugeqyGbDCoFic2zqrNgwthyvq8DUubn6CSev58Ja2o9KgMQxafDd6UZWG9JSZWcdGY', net))
def store = new SPVBlockStore(net, new File("/tmp/spvbstore.blockchain"))
def chain = new BlockChain(net, store)
def peers = new PeerGroup(net, chain)
peers.maxConnections = 5
peers.maxPeersToDiscoverCount = 5
peers.addPeerDiscovery(new DnsDiscovery.DnsSeedDiscovery(net, 'testnet-seed.bitcoin.jonasschnelli.ch'))
chain.addWallet(wlt)
peers.addWallet(wlt)
peers.start()
peers.downloadBlockChain()
wlt.addCoinsReceivedEventListener(
  new WalletCoinsReceivedEventListener() {
    @Override
    void onCoinsReceived(
      final Wallet wallet,
      final Transaction tx, final Coin prevBalance, final Coin newBalance) {
        println("RECEIVED: $tx: $prevBalance -> $newBalance")
    }
  }
)
while (true) {
  println("BALANCE: ${wlt.getBalance(Wallet.BalanceType.ESTIMATED)}")
  println("transactions:\n$wlt.transactionsByTime")
  Thread.sleep(10000)
}

i didn't understand as per your question:  if I restart it, the balance becomes zero and the wallet loses all received previously transactions, if I start the code again and send new coins to the same address, how can you sent the coins with zero balance ?

@Zombie my code only watches the balance, it can't send coins because the wallet doesn't have private key here. I mean when I send coins to the address of running code, not from.

when you run the code again, are you loading wallet from the file ?

@Zombie no, I'm creating it from fixed public key (watching key)

Sounds like a watching wallet, but you need to save the wallet as well as you're saving spv file

@Zombie thanks, it helped. Feel free to post an answer here, I'll accept it.

pleasure, alright

Sounds like a watching wallet, but you need to save the wallet file as well as you're saving spv file. As per documentation


text:
is every Block of blockchain is connect to each other?
like as we create a new block , so it will connected to existing Blockchain or it will create a new blockchain?

@darkknight: The other way around. This one was first. ;)

Yes, every block (except the first one) gives reference to the previous block, and it's not possible to change a part of the block without invalidating it.
To create an altcoin, you have two options:
1) Fork the blockchain by using invalidateblock, which permanently considers a block and the following blocks invalid, then create your alternative chain.
2) Generate a blockchain starting from the genesis block.

Every block contains the hash of the preceding block in the header.
It follows that you can go back block by block until you reach the genesis block.
This structure has a few interesting properties:

Every block reconfirms all preceding blocks.
There can only be a single block at the same height that is part of the most-work chain.

Sometimes, two miners succeed at the same time and publish two competing blocks at the same time. Since a new block can only commit to one predecessor, one of the two competing blocks will form a stale blockchain-tip that is not part of the most-work chain.

No i Just Want to know that as we are creating a new block that is first block so it will connect to the existing blockchain in the world  or it will create a new blockchain?

A new genesis block would not connect to the existing blockchain. How would it otherwise be the first block? ;)


text:
Understanding the advantages/pitfalls of using one/two keychains for wallets
I'm trying to make sure I understand the question: Why Do We Use Change Descriptors when Building Wallets?
Context: I work on the Bitcoin Development Kit, where one of our core types is the Wallet type. It has typically required 2 descriptors (an external descriptor and a change (internal) descriptor). This idea is standard practice and used widely in the industry, but when pressing myself to write about it in our documentation, I was left wondering if I really knew why this was the case. Furthermore, users that request the Wallet be usable with only one descriptor had strong opinions about how the practice of using 2 descriptors was maybe outdated and not required under certain circumstances. One user told us that it was a mistake to double down on the internal/external descriptor schism, and that it was a relic of the past of people that use electrum wallets.
As a library maintainer, this is the sort of thing I want to have a solid grasp on. I'm also leading our documentation efforts, and plan on including a page on this.
Here is my current understanding and questions.
Advantages of using 2 descriptors

It potentially allows you accept 0-conf coins when they are coming to change addresses, because you must have been the one to initiate that transaction and will not double-spend yourself.
Privacy when using a public electrum server: in cases where you might send a whole xpub to an electrum server, you're better off not giving up your whole keychain but only half? (at this point it seems trivial to reconstruct transaction history but still, I guess not giving it out is better than doing it).
Having only 1 descriptor forces you to keep track of addresses you've given out when building transactions, because otherwise your wallet might use an external address already given out as change, and if this address given out to someone ends up being used by them, you'll double transactions at that address.
In cases where a wallet is recovered, change addresses can still be labeled as change.

Questions I Still Have

Are there other pitfalls users of single-descriptor wallets should be aware of in the case where wallets use more private sync tools like private Electrum servers and CBF, and using modern wallet practices that never give out repeat addresses?
Does the "change" keychain come into coin selection at all in Core? For example, are there algos for coin selection where knowing if a UTXO is part of the change keychain rather than the external keychain matters? If so, how does it come into play?
Any other historical info that's good to know and take into consideration for builders of wallet would be appreciated.

Thank you!

Hi, it would be helpful if you added links to the feedback from you got from these users with strong opinions.

There were some more discussions on Discord servers, but here is one issue related to this: https://github.com/bitcoindevkit/bdk/issues/1511

Using a separate keychain for change addresses is one of those things where as a wallet author you think "wait a minute.. But that doesn't make sense!" and end up implementing it anyways because moving away from the standards would put too much cost on your users.
Technically you could have all the advantages of using a separate keychain by enforcing a simpler standard which doesn't require to backup two descriptors. For instance: use even derivation index for receive addresses and odd ones for change addresses.
I disagree with most of the advantages you listed of using 2 descriptors:

you should not blindly trust unconfirmed coins received on change addresses, you always need to check if the transaction that created them is in fact entirely in your control. Otherwise someone can trivially double spend you by sending an unconfirmed transaction paying to one of your change addresses;
regarding privacy from public Electrum servers, wallets which use a different keychain for receive addresses use a unhardened derivation index to differentiate between change and receive addresses. So an Electrum server having your xpub for the receive keychain can trivially derive all your change addresses too. In any case if you give away all your receiving addresses to someone figuring out your change coins from your onchain activity is trivial in the first place;
you don't need to keep state, you can just use a better standard: the odd vs even indexes trick gives you this property;
same, this doesn't need two keychains, just a smarter standard.

As per your questions:

I think the main reason to keep the two-keychains standard is because everyone else is using it! That is if you want to introduce your new smarter standard, your user who want to import his descriptor backup in any other wallet who'd still be using the two-keychains standard might end up reusing a bunch of addresses. Since we now have BIP389 to mitigate the cost of having to backup two keychains, the cost of introducing a new standard is not worth the risk to the user;
I am not aware of any coin selection algorithm where a coin is treated differently if it's a change output (except if unconfirmed of course). And i don't think it's relevant for the matter of using two keychains or not;
I don't have much historical info. Maybe this Liana issue from two years ago where i pondered using a new better standard for handling change addresses and ended up settling on using BIP389 for the reason detailed above. Another argument given there is "be explicit in the descriptor itself how to derive receive/change addresses".


text:
Importaddress and conf
I'm wondering if its possible to add imported addresses into the bitcoin conf file.
So, rather than calling the cli with importaddress, I would add the address to the conf file, with say, importaddress=1123345678A
Is this supported in the conf file?


text:
I've read that bitcoin addresses are never destroyed, but do they get recycled/reassigned?
What happens to old bitcoin addresses? I've read that they never get destroyed, but do they get reassigned?
The story is I sent some bitcoin to an exchange using an address I've used with them before, but then found out that they had just retired/stopped using that address. I saw the transaction coming through though. Where did the bitcoin go?? Is there an official network that manages bitcoin addresses? Please help, it is a rather large sum.
Address in question:
12aAEnfc6192cm4KLfV5eY13jYRqy684Ym
transaction ID:
0db1e2f9f4233592b5f6ac5c881727e3c5694cfbd21af1744bfb11d069a1ae2d

If the exchange controlled that address before, they almost certainly still control it, as it is actively used. They just don't want to credit the money to your account. Your chances lies in customer's support, and if it doesn't fix it, a lawyer.

This is the equivalent of "I deposited a money order to myself at my bank. My bank now says it cashed the money order, but they can't find where the money went? WTH? No way, I'd call/email customer support until they credit you.

What happens to old bitcoin addresses? I've read that they never get destroyed, but do they get reassigned?

Bitcoin addresses are not reused or reassigned to anybody under any circumstances.

The story is I sent some bitcoin to an exchange using an address I've used with them before, but then found out that they had just retired/stopped using that address.

This is almost certainly a scam. There is no reason to ever "stop using" an address, especially as the one you're referencing contains over half a million dollars of value. If they had lost access to their own funds that's not really your responsibility, but that seems like a highly unlikely story.

Is there an official network that manages bitcoin addresses?

No.

"There is no reason to ever 'stop using' an address" -> There are plenty of reasons to stop using an address. First and foremost, reusing an address destroys your privacy. Bitcoin addresses are intended to be single-use only. And why not since it's free to make essentialy an unlimited amount of them for everyone.

Bitcoin addresses are essentially just large random numbers. So there's nothing to destroy or reassign - it's just a number.
When you "create" a new address, what you're really doing is just picking two random numbers (that are cryptographically linked to each other) called a "private key" and a "public key". The public key is like a house address or email address - other people use it to send you money. The private key is like a house key or email password - you use it to send your money from your wallet to other people's "addresses" (public keys).
The chance of you generating someone else's address is basically zero because of how large the numbers are.
When an exchange generates addresses for its customers, they internally manage how they're allocated. A responsible exchange would never use one person's address for another person and old addresses should still work.
The reason exchanges generate new addresses is to protect your privacy. Since all crypto transactions are public, sending money to different addresses (generated by the exchange) helps limit the amount of information other people can deduce about your finances.

Looking at the address you provided in a block explorer(OXT Explorer)

12aAEnfc6192cm4KLfV5eY13jYRqy684Ym

it seems your exchange has been reusing that address quite a bit since December to now and has not really cut down on using it. I do not think they have retired the address and it is definitely still under their control.

Is there an official network that manages bitcoin addresses?

No, each individual generates their own addresses and it is entirely their own decision on how to use them. Most people simply use an address once and then put them aside once they are done with them. The address is still perfectly valid, it is just not good for privacy to reuse addresses. Large institutions on the other hand might find it more convenient to reuse since privacy is not their biggest concern.
Depending on how HUOBI uses their addresses, they could have jumbled up your funds with other peoples' funds if they simply re-assign addresses on an as needed basis. It is generally good practice for exchanges to generate separate addresses for each user to avoid an accounting mess like this but not all exchanges do this.
They definitely still have your funds somewhere in their systems and might just be too lazy about getting it back for you. Go to their website and open up a support ticket or something. Keep pestering them to find your funds or they'll just BS you about "we retired the address" and hope you let them keep the funds.
The beauty is you can track everything on the blockchain, you have proof you sent it to an address they control (they still control) and you can prove the transaction went through. If they make it difficult, you may have to open up a legal case against them with a regulatory body but they definitely have your funds.
It makes no sense for them to toss a seed after just 2 months of use especially since they can generate infinite addresses from just that seed.

edit: They've stopped using that HUOBI wallet address since 01/30 they said. The subsequent transaction in Feb 2 is mine, which was withdrawn by someone in after 2 hours. https://bitinfocharts.com/bitcoin/address/12aAEnfc6192cm4KLfV5eY13jYRqy684Ym
As to why they change: In order to ensure the absolute security of the account, the exchange will periodically change the account address, and cancel and abolish the original BTC address.
Is this a valid reason?

@cannabiccino no, you can't cancel and abolish a BTC address

@cannabiccino Someone is lying to you. Whether it's laziness or a scam, I cannot say, but what they are telling you is objectively wrong, and an exchange should know these things.

@cannabiccino The exchange even moved the funds, they are really messing with you.
Only their key can control that address.
That's why I only buy p2p from trusted people.


text:
How to set a specific fee in satoshis per transaction?
I'm currently working on a personal project which is a small bitcoin exchange website, I've figured out how to create a raw transaction and broadcast it (createrawtransaction -> fundrawtransaction -> signrawtransactionwithwallet -> sendrawtransaction).
There's a option in fundrawtransaction which lets you set the fee but it's in BTC/kB. Are there any options on how to send the transaction specifying the final fee in satoshis? Or how do I know the final size of the transaction to calculate the fee? I want users to choose the fee in satoshis and not in BTC/kB.
I don't know if this has something to do but I'm using bech32 addresses. Thanks for your help!

How to set the absolute fee
The transaction fee is implicitly defined by the difference between the sum of input and the sum of output amounts.
fee = Σ(inputs) - Σ(outputs)

Since you are building your transactions explicitly, you can set the exact transaction fee by defining the corresponding specific amounts of the outputs for the recipient(s) and the change output. As the weight of inputs and outputs is predictable, you can calculate the appropriate fees by knowing the count and type of inputs and outputs in advance.
Why it's a bad idea
While your wallet can determine the input count during the transaction building, your users will not know in advance how many inputs it will take to fund their transaction. Since transactions get processed in order of their feerate rather than their absolute fee, the user will not be able to make an informed decision for an absolute fee without knowing the weight of the transaction. Per my experience, users get absolute fees wrong more often than not (most users even get feerates wrong), which leads to substantial support traffic with complaints about overpaying or underpaying. This is why withdrawal interfaces usually give predetermined choices (e.g. express, normal, thrifty) or take a feerate rather than an absolute fee.
If you want the recipient to pay the fee, you may want to consider using subtractfeefromamount.

Thanks for the reply! I did take a look at other Bitcoin online wallets and they do give predetemined choices, so that's what I'll be going with!


text:
Find my Bitcoin Account
I signed up for Bitcoin many years ago and I have no clue on how to find my account. I googled "how to find my bitcoin account" and I got this platform. Any help is appreciated.

There's no such thing as a Bitcoin account.
If you mean an account on a Bitcoin exchange, then I'd check your emails and maybe old bank statements from that time to see if you can find which exchange it is, then try and recover your account.
If you mean a Bitcoin wallet, and you have completely lost the wallet file and have no backup of its keys, then it is probably gone for good. You can try looking through your old computer backups if you have any; if you used the Bitcoin Core client you're looking for a file called wallet.dat.

Thank you so much! This is very helpful.


text:
Loading wallet crashes bitcoin core wallet
When trying to load a wallet I last used in 2017 December, in bitcoin core wallet 0.21.0 x64, the UI exits abruptly, last few lines in the debug.log shows the following:
2021-02-10T07:20:22Z Using wallet d:\btdata\dijitalparaciklar.dat
2021-02-10T07:20:22Z BerkeleyEnvironment::Open: LogDir=d:\btdata\database ErrorFile=d:\btdata\db.log
2021-02-10T07:20:22Z init message: Loading wallet...
2021-02-10T07:20:23Z [dijitalparaciklar.dat] Wallet File Version = 130000
2021-02-10T07:20:23Z [dijitalparaciklar.dat] Keys: 0 plaintext, 214 encrypted, 214 w/ metadata, 214 total. Unknown wallet records: 0
2021-02-10T07:20:23Z [dijitalparaciklar.dat] Wallet completed loading in 175ms
2021-02-10T07:20:23Z init message: Rescanning...
2021-02-10T07:20:23Z [dijitalparaciklar.dat] Rescanning last 173423 blocks (from block 496540)...
2021-02-10T07:20:23Z [dijitalparaciklar.dat] Rescan started from block 0000000000000000009e546a2183eb90aea183bd153f2d7b3c34f67b4aa6abc5...
2021-02-10T07:20:23Z [dijitalparaciklar.dat] AddToWallet 0f1162a63b3ae14a3bc8907f8edbb57e392fc5dfadfe866de0eb5d470f7504df
2021-02-10T07:20:25Z New outbound peer connected: version: 70015, blocks=669964, peer=2 (full-relay)

Windows records the crash as follows:
Faulting application name: bitcoin-qt.exe, version: 0.21.0.0, time stamp: 0x00000000
Faulting module name: bitcoin-qt.exe, version: 0.21.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x000000000038ca40
Faulting process id: 0x5128
Faulting application start time: 0x01d6ff7aa101f703
Faulting application path: D:\Bitcoin\bitcoin-qt.exe
Faulting module path: D:\Bitcoin\bitcoin-qt.exe
Report Id: 49909fad-f4bd-4f8c-9423-a585cbeaba86
Faulting package full name:
Faulting package-relative application ID:
Any ideas why this could be happening? db.log is empty btw..

I am having the same problem (with different dates and using the cli version). My post. Your situation seems to indicate that the problem I am having is not related to platform or gui vs cli, which is helpful (at least to me). So thanks.

Check this file: ErrorFile=d:\btdata\db.log
Errors are logged in there. You are viewing the debug logs which will not print any error.

Thanks, checked that file however it's empty as mentioned in my question.

Did you try reindex and rescan option ?

I tried rescan but not reindex, will try that..

--rescan --reindex allowed me to load the wallet. Thank you!


text:
Basic overview of fees
Can someone explain fees in layman’s terms
I thought I would throw a few dollars into bitcoins more for a laugh than anything - but the fees are confusing me.
I googled best wallet for newbies & most people suggested Exodus as simple and easy for beginners.
Using Apple Pay I bought $100 at around 44k - I got $99 worth of coins and paid $1 fee (seems fair)
They are now at 48k and my $99 is up to about $109
I have no interest in cashing out, but still leaning my way around so thought I would check how much the fee would be to cash out.
From what I can tell, I have to use a company like coin base to convert to hard cash and so I’m looking at paying a transaction fee to send the money to coin base plus a fee to coin base for converting my Bitcoin to hard cash / depositing in my bank account.
The transaction fee exodus shows me to send my coins anywhere is $15 which seems a bit steep.
Would I be better off having a coin base wallet so I’m not having to pay that $15 when I want to cash out on top of cashing out fees?
Looking online people say coin base fees are a few % and exodus is 5% plus - but they are quoting me 15% (or is that just because I only have small amounts & it would be cheaper if I had $1,000)
I may throw $50 or $100 a month into BC moving forwards, nothing big, an amount I can afford to forget about for years or even lose large amounts of, but don’t want to lose 20% when I cash out between transfer & cash out fees!
Any help would be much appreciated

Currently, there is a lot of demand for bitcoin transactions, you're sort of looking at "surge pricing".
Transaction fees in Bitcoin are paid for the blockspace that a transaction occupies. This means that the fees for a transaction scale with the number of pieces of bitcoin (UTXO you spend and create, irrespective of the amount of value you transfer. Assuming that you have actually taken custody of your funds in your Exodus wallet when you bought them, you would end up having a lot of UTXO in your wallet if you buy in chunks of $50 to $100. This could cause significant transaction fees when you finally want to move your funds.
To mitigate these costs, you could proceed in multiple ways:

Consolidate your funds: before you move your funds out of your Exodus wallet, send all your bitcoins to yourself. This will consolidate all your UTXO to a single piece. Create this transaction at a very low feerate. The transaction will likely take a long time to confirm, but most of your value will be preserved. After that, a more expeditious transaction to transfer your funds to another market or pay someone can be made at a higher feerate without as high of a relative cost.
Buy bigger chunks: bigger chunks means fewer UTXO and less fees.
Use a custodial market to buy: Buy on a custodial service instead, and withdraw at greater intervals whenever you have accumulated more bitcoin or when the blockspace market is less competitive.

If you want to find out more, I've written about the current situation a bit more here: https://bitcoin.stackexchange.com/a/99699/5406

Thanks but can you put that in total layman’s terms. Is coin add a custodial service?