text:
Can nLockTime TX be used to flood Mempools?
What would happen, if I would create a large number of large transactions with a very high nLockTime?
Would something stop me from filling not only the miners', but also regular nodes' mempools?
Would miners drop transactions with unreasonably high nLockTime and low transaction fee?
What would BitcoinCore do?

The following was removed from the question, but would probably help to start an answer: theymos: "lockTime prevents a transaction from getting into blocks. Once it's in a block, it can be spent."
https://bitcointalk.org/index.php?topic=131443.msg1432948#msg1432948

There is no size limit to the mempool from what I can find. It might be possible to flood it but rather difficult and expensive / slow. I see two approaches:
A) minimum relay fee

connect to 1000 nodes
send plenty of txs that meet the minimum relay requirements

how many?: 32 000 000, 32 000 on each node
nLocktime in the far future so they don't get into blocks
tx fee: minimum relay fee: 0.0001
amount: very low
size per tx: 250bytes

mempools are filled with 8gb of dust

It would take a while to generate that many addresses and tx and get them broadcasted. Also it would cost at least 3200BTC.
B) 0 fee txs with minimum output of 0.01 so they still get relayed
Mempool is gated by a rate limiter for free tx:
// Continuously rate-limit free transactions
// This mitigates 'penny-flooding' -- sending thousands of free transactions just to
// be annoying or make others' transactions take longer to confirm.

// Use an exponentially decaying ~10-minute window:
// -limitfreerelay unit is thousand-bytes-per-minute

// At default rate it would take over a month to fill 1GB

So this will be at least very slow. Also you need to have 320 000 BTC for 8GB. :)
There might be ways to artificially make txs larger. Alternate clients might do things differently.

I'm not sure whether this got changed after this answer was written, but transactions with a nLockTime will not be relayed until the blockheight one before they can be included is reached or until the timestamp in the nLockTime has been reached. Therefore, a mempool flooding attack with locktimed transactions is not possible.

nLocktime transactions that are not valid yet are not relayed and possibly even dropped. It's the responsibility of the sender and/or receiver to store the transactions until they are valid and then broadcast them.

Transactions with a nLockTime set to a date or blockheight in the future will not be considered valid by Bitcoin Core until the timestamp has passed, or the block height one before they become valid has been reached. Only at this point, full nodes will keep them in their mempools and forward them.
Therefore, a mempool flooding attack with locktimed transactions is not possible.


text:
Why not retarget on every block?
Should make things smoother and result in less oscillation. Is there a reason why retargetting is only every 2016 blocks?

Note: This does not exclude filtering.

Also see: https://en.bitcoin.it/wiki/Adaptive_difficulty

I suppose the only right answer is "because that's how Satoshi implemented it". His reasons for doing may have included easy of implementation, easy to guarantee consistency among nodes, or little worry about instability of correction algorithms.

Why not 1 week then? 1 week doesn't seem much more work to implement compared to 2 weeks, but give us considerably more flexible retargetting (twice more!).

How much work it is to implement isn't relevant. The question is how much work it is to change, and changing this would require pretty much every single piece of Bitcoin software to be rewritten. Unless the alternative is some disaster there is no reason that could justify taking such a risk.

Doesn't only half of the hashing power have to get their software rewritten, and then anyone who wanted to be sure about collecting all the transactions that get confirmed?  Personally, I expect a valid transaction to be honored because it was published, regardless of  whether or not it gets confirmed.  The problem is finding out about it if there's no confirmation, and then getting others to see the logic of my position.

@DaveScotese No, every fully validating node would reject a block whose difficulty was computed using the new rule. The amount of hashrate isn't relevant here.

@PieterWuille  Is there an inaccuracy in the following?  Every fully validating OLD node would reject new blocks that don't meet the old difficulty.  It would be a hardfork as soon as a NEW node found a block whose hash is between the two difficulties (and OLD nodes have a higher difficulty).  At that point, NEW nodes would see one branch and OLD ones would see the other.  Thanks for helping me understand bitcoin a little better!  Then NEW nodes would get cut off from the OLD ones for violations.

@DaveScotese Yes, as soon as the two difficulty rules give a different result, the first block that follows it will split the network into just old nodes and just new nodes. Thus in order to not fork, you need 100% completely every node to switch to a the new code. If any old node remains, they'll be cut off from the network. Hashrate does not have anything to do with it, and a majority of anything isn't enough.

@DaveScotese Oh, I see what you're missing. Every block contains the difficulty it is mined at. If that difficulty field is incorrect, the block is invalid. So it is a hardfork in both directions - whether the old or new rules says the difficulty should be higher.

The update frequency results in some trade-offs.
Faster updates increase the exposure to isolation attacks-- where a partitioned part of the network speeds back up to the nominal speed. Faster updates also increase the amount of oscillation possible.  On the plus side they make the network respond faster to changes.
Many altcoins have changed to faster rules, but the vast majority have managed to do it in wrong and vulnerable ways.  For example: Some apply a sliding window filter but then apply the same change over and over again instead of it's n-th root, causing massive oscillation.  Others use the timestamp of the immediately prior block to set the current difficulty-- this lets you set your timestamp slightly lower than you should in order to make the next block have epsilon higher difficulty and thus guarantee it will win in a race due to having more total work.  Other schemes have wild non-linearities that make it a lot more profitable for miners to mine in bursts rather than continually.
When I look at all the different ways other rules have been messed up, and how inconsequential the 'slow' updates in Bitcoin have been in practice. I think Bitcoin's creator made a good decision, all considered.

Retargeting on every block would result in ridiculous oscillation in the difficulty level when there's a hot streak and several blocks are found in short succession or a cold streak where a block isn't found for a long period.
As for why it's 2016, at an average rate of 1 block per 10 minutes, it readjusts fortnightly.
Why 10 minutes was picked is unknown, AFAICT.

It's perfectly possible to design an algorithm that retargets continuously and is no less stable that the current one (for example, at every block, multiply the difficulty by the 2016th root of the ratio of the time for the last 2016 blocks over two weeks).

Retargetting every block based on the time from the last found block would result in a ridiculous oscillation - as compro01 writes. But if the target is based on the time for the last 2016 blocks, but evaluated every block, this would be a sliding window and I don't see why it wouldn't work. But most likely it is difficult to have consensus this way which doesn't result in a chain fork, as every node has to have the same opinion.

Why would be more difficult to achieve a consensus?

In fact, I don't know, effectively asking the same as you. When two nodes have a different opinion of the last 2016 blocks (e.g. a chain fork, got to know of a different 'highest' block) together with a bad coincidence (one block was mined just after the previous, the alternative chain didn't find a block in long time) their target would also differ. But: rejecting of blocks happens on same chain where the target is calculated, so what's the problem?

There would be no problem. It would be the same situation as it is now: As soon as the chain forks, the two chains have no influence on each other (except that the mining power is reduced for each).

I built the better scheme. I look at the last 1000 blocks, but I give more importance to the newer blocks. It is a geometric distribution such that the last 50 blocks are 1/2 the total weight.
My scheme recovers from a 90% loss of mining power in 10 blocks.
https://github.com/zack-bitcoin/basiccoin

Is it clear that this is desirable? That means if an attacker can mount a denial of service attack that knocks a few big pools offline for a couple hours, they can get a quick drop in difficulty and make it much easier to perform a 51% attack.

@NateEldredge A 51% attack is just as difficult no matter what the difficulty is.

@NickODell Without the rapid difficulty change it takes a long time for a low hashrate attacker to mine 6 blocks (or whatever the target requires) even if the outage has given them >50% of the current hashrate.  When difficulty is slow to change that sort of attacker isn't just fighting the current hashrate they're also fightning the recent past's hashrate in a sense.

source: Stack Exchange

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

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

sort: votes


text:
Tx Malleability: Why is the Script not included in the Signed Hash?
Sipa lists sources of tx malleability here: https://gist.github.com/sipa/8907691
It is clear to me how a change in the signature itself or the signature formating leads to a different tx hash (1. & 2.). But why is it allowed to modify the rest (may be "") of the scripts?
From what I understand only the txin script can be modified because the txout scripts are included in the signature hash(es). Obviously the signature itself can not be included in the signed hash.
For each signature the corresponding txin script is replaced by the appropriate previous output script (?) and all other txin scripts in the tx are removed.
Why is the txin script (without signature, so it is an empty string for a standard tx) not included in the hashed and signed data?
(Please correct me if I got something wrong.)
edit: trying to express myself more clearly:
Of course the range and format of the signature needs to be standardized. But there are other cases of malleability as Sipa points out like adding nonsense OPs to the tx_in script or using alternative OPs that have the same or a similar effect. I am only talking about these other cases.
My point is: The signature itself can not be signed but why are OP codes that may or may not be present in the txin script not signed?
Example:
Today:
 normal txinscript: "sig"          -->  signature format: "" --> valid
 malled txinscript: "OP_NULL sig"  -->  signature format: "" --> valid
Why not:
 normal txinscript: "sig"          -->  signature format: "" --> valid
 malled txinscript: "OP_NULL sig"  -->  signature format: "OP_NULL " --> FAIL
Signature format today replaces the whole txinscript with "". To me it seems that it would be safer to only remove the signature itself but keep the opcodes if present so that it is impossible to alter existing opcodes or add nonsense opcodes.
Is it because it is not know what part of the script is the signature? I think it could be marked as such should that be the issue.

You are absolutely right.
The only reason why this is done, is because that is not how the consensus rules currently work. Changing it would require a hard fork, updating every node and eventually every wallet.

You saved my sanity. We should hard fork more often and properly fix things up long before running into trouble. I realize you are the wrong person to bitch at.

My point is: The signature itself can not be signed but why are OP codes that may or may not be present in the txin script not signed?

The updated question provides a more specific context, and so I will answer it as a new answer.
There is no reason that Bitcoin couldn't be hard forked to accomplish what you indicate.  If you are wondering why such a complex signing scheme?  As Pieter says "ask Satoshi".
Even before we encountered these issues I always found the signature portion of the transaction to be overly complex and counterintuitive.  If Bitcoin tx were signed like they are in just about any other cryptographic system the signature wouldn't be part of the input.
It could look something like this
tx header
input(s)
output(s)
signature(s)

The tx header, input(s), and output(s) would comprise the "tx body".  The hash of the tx body is the tx_id.
To construct a transaction the client would create the tx body, compute the tx hash.  The tx hash + priv key for each input would be used to generate a signature.  The signatures would be appended to the tx body and the entire thing broadcast as the tx message.
To validate, remove the signatures from the tx and you are left with the tx body.  Hash the remaining tx "body", verify signature.  Verify the inputs, verify the outputs.  Verify each of the signatures is correct.
Of course such a radical change to Bitcoin is still "possible" but it is unlikely it will ever be forked to accommodate that.  Satoshi got a lot right but he wasn't perfect and this is one example.

Thanks for elaborating. I am giving the answer to Sipa as he was a little faster and +1 to you.

The tx_in "script" is the signature (and pubkey and some formatting).  It is a somewhat confusing name which kinda implies there is a tx_in script and then somewhere else these is this signature, but that isn't the case.
The signature can't be included in the input which forms the signature.
This diagram might help.
https://en.bitcoin.it/w/images/en/e/e1/TxBinaryMap.png
The diagram on the left is a "standard" tx_in.
The tx_input structure consists of
Previous txout-hash (tx_id)
Previous Txout-index
Txin-script length
Txin-script
sequence_no

However this is really just an abstraction the Txin_script is just the signature and pubkey which consists of:
L(sig)
0x30
L(rs)
0x02
L(r)
Sig r
0x02
L(s)
Sig s
0x01
L(key)
0x04
Key X
Key y (only for uncompressed keys)

So you saying the txin script is mutable is simply another way of saying the signature (and the formating).  There isn't one single method to mutability.  ECDSA itself has mutable signatures,  the padding and formatting of the signature can be modified and still be valid.
Making tx_id immutable requires either computing the tx_id (hash) using an alternate method, where the payload of the hash is all immutable elements, or restricting the ECDSA signature to a particular subset of parameters, formatting, and padding such that for a given payload there is only one possible "correct" Bitcoin signature.  Anything else while it may be a valid ECDSA signature would be considered invalid on the Bitcoin network.
It is a non-trivial task.  Not impossible but it will not be resolved "fast and easy" and as far as I can see will require a hard fork of the network.  This means additional time in testing, adding forward compatibility, and consensus building to avoid unintended consequences like leaving a significant portion of the network on the old fork.

Thanks for the link. But that is only valid for a standard tx. Sipa describes several routes of malleabilication that change the tx_in script. Why not include tx_in opcodes other than signature and pubkey in the hash to be signed?

I am not sure I am following.  If the tx_in "script" is already mutable adding additional opcodes isn't going to make it immutable.

@phelix Ask Satoshi. If we'd design Bitcoin today, it would sign everything except the actual signature.

authors: Gıио Јоаqυιи

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


text:
How does a client decide which is the longest block chain if there is a fork?
Is it only the block height or is it the effort that went into the forks? In other words: does this decision account for different difficulties?

Gary's answer is not entirely correct. When comparing two chains, their total "scores" are compared.
Each block counts as (2^256 / block_target); this is the expected/average number of attempts that were necessary to create it.
Obviously, within one series of 2016 blocks, the difficulties are all equal, so for most small reorganizations, the score will tell you the same thing as just counting the number of blocks. However, as an attacker may well try to rewrite blocks that cross the multiple-of-2016-boundary, you need to take this into account. The actual rule always favors the chains which required the most "work".

Thanks Peter. I was confused as I initially read your answer as "this is the expected divided by average..." That is a minor point tho. Your answer seems to be at odds with @NickOdells answer here: http://bitcoin.stackexchange.com/questions/37273/how-is-a-blockchain-split-resolved?noredirect=1&lq=1, which claims there is not a score, but a series of rules set out in CBlockIndexWorkComparator.

This answer only elaborates on the first criterion in CBlockIndexWorkComparator. The others are just for tie-breaking.

Why isn't the block hash used to calculate work done?

@JBaczuk Because among the set of acceptable hashes, every hash is equally likely. Counting some as more than others would simply introduce additional variance (where one branch, without merit, randomly would count more than another). The only practical effect would be seeing far more forks, and needing more confirmations to be sure a transaction made it in.

According to the Satoshi paper, the following applies:

The steps to run the network are as follows:
1) New transactions are
  broadcast to all nodes.
2) Each node collects new transactions into a
  block.
3) Each node works on finding a difficult proof-of-work for its
  block.
4) When a node finds a proof-of-work, it broadcasts the block
  to all nodes.
5) Nodes accept the block only if all transactions in it
  are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
Nodes always consider the longest chain to be the correct one and will keep working
  on extending it. If two nodes broadcast different versions of the next
  block simultaneously, some nodes may receive one or the other first.
  In that case, they work on the first one they received, but save the
  other branch in case it becomes longer. The tie will be broken when
  the next proofof- work is found and one branch becomes longer; the
  nodes that were working on the other branch will then switch to the
  longer one.

That pretty much sums it up. If you have more valid blocks, you win until someone comes along with more valid blocks.

This is what the paper said and this is what the original Satoshi code did, but this is no longer correct. If you always pick the longest chain then there are some relatively easy attacks that work by making long and easy chains. In 2016 the bitcoin core code switched to using the "most work" chain, which is not necessarily the longest. Here is the commit...
https://github.com/bitcoin/bitcoin/commit/e86756193ebdbf71504e2a1a8db43e38d57f9673


text:
What unconfirmed transactions in Mempool get into a block?
I have a question regarding picking unconfirmed transactions from the mempool. Let's say, there are 1000 transactions in the mempool. Can I randomly select some transactions, say, transaction a, b, c, d from them, and work on the nonce and create a new block? Is there any criteria about what transactions need to be in the next block?

Does https://bitcoin.stackexchange.com/q/57823/5406 answer your question?

Thanks for the suggestion! I added an extra question in the question you linked.

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


text:
What is the difference between Consensus and Distributed Consensus?
This is more of a clarification than as a question. Since I didn't have the rep to post a comment in this question, I'm putting this itself as a question.
Sources I've referred till now:

A fundamental problem in distributed computing and multi-agent systems is to achieve overall system reliability in the presence of a number of faulty processes. -Wikipedia

It explicitly indicates that consensus is a fundamental problem in Distributed Systems.
However,

"Consensus" means when everyone is on the same page. -Bitcoin SE.

My understanding till now is that if every node had one vote, then for the whole network of nodes to agree on a decision, use of consensus is required. If the system at hand is not distributed, then the environment reduces to just one node which doesn't need consensus mechanism at all to come to a decision. So my confusion is, are there any situations where consensus is required even when the system is not distributed?
If yes, please explain what's the difference between the terms "Consensus" and "Distributed Consensus". If possible, present an example.
If no, does that mean the terms are the same?

I actually put that line because I didn't want my question to get dismissed or downvoted because it seemed to be a small & silly question to me. However, it was a gap in my knowledge. So, I had to ask anyway.

Consensus is a concept used by bitcoin, however exists in other computer systems as well.  I recommend you look at the computer science stack exchange.

A consensus is an agreement between several agents. So it's always distributed in that sense.
But here it is about the process of how to achieve such consensus.
It's not dictated by one master. But agreed on by distributed voting.
Due to temporal logic being a nasty beast, you can't assume everyone to be on the same page at a specific point of time. But eventually everyone will reach a certain state of consensus.

So, Are you conveying that the answer to the final question is "No, they're both the same terms" ?

I think this is correct. Consensus is more a generic non-technical term, that doesn't even need to apply to computers or networks. Distributed consensus is a more specific term referring to the sort of solutions that are used in distributed computing systems to reach consensus.

Nope nroot, I don't! In addition to what Pieter wrote, I see a huge difference. Consensus is referring to a result. While distributed consensus is also about processes to achieve such a result.


text:
How to extract all the bitcoin addresses with bitcoin-cli?
I am trying to get all existing addresses on the bitcoin blockchain with bitcoin-cli.
It seems that I can get addresses from vout that are of type "pubkeyhash".
If the type of vout is "pubkey" there are no addresses.
pubkeyhash type:
  "vout": [
    {
      "value": 0.00000001,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 b04e3fb6f6c96ba23233c809e42d8e6a0e0e31ca OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914b04e3fb6f6c96ba23233c809e42d8e6a0e0e31ca88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1H5DfbDtCnKUdke9xH9svwwxqga41Z5xbz"
        ]
      }
    }

pubkey type:
  "vout": [
    {
      "value": 50.63517500,
      "n": 0,
      "scriptPubKey": {
        "asm": "04b0bd634234abbb1ba1e986e884185c61cf43e001f9137f23c2c409273eb16e6537a576782eba668a7ef8bd3b3cfb1edb7117ab65129b8a2e681f3c1e0908ef7b OP_CHECKSIG",
        "hex": "4104b0bd634234abbb1ba1e986e884185c61cf43e001f9137f23c2c409273eb16e6537a576782eba668a7ef8bd3b3cfb1edb7117ab65129b8a2e681f3c1e0908ef7bac",
        "type": "pubkey"
      }
    }

Is there an easy way to get ALL the addresses on the blockchain?

Answering this question requires first defining what an address means.

Historically (before BIP16 activated in 2012) an address was a synonym with a "public key identifier", as there were no addresses for multisig constructions or anything like that. Under this interpretation, pay-to-pubkey or pay-to-pubkey-hash outputs would be seen as having the same address - after all, the key is the same. This is problematic, because sending to the "address" corresponding to a pay-to-pubkey script would not actually send to that script, but to its corresponding pay-to-pubkey-hash script. Sufficiently old software, and some newer software (including some block explorers) use this interpretation, leading to confusion.

Most software now treats an address to be a human-readable notation for encoding specific scripts (corresponding to the script that would be constructed if a wallet were to be instructed to pay to said address). Under this interpretation, pay-to-pubkey outputs simply don't have an address (as there is no way to make wallet produce such outputs), and certainly not the same address as for the pay-to-pubkey-hash output with the same key.

The software you're using follows interpretation (2), so the question makes little sense. It is showing you all addresses observed, but in this case, there just isn't any address involved. Transaction outputs in Bitcoin are freeform scripts, and only some of those have a corresponding address notation. Others are just scripts.

The second output you are showing is using the pay to pubkey output script. Pay to pubkey (P2PK) eponymously locks funds to a public key. The corresponding input script only needs to provide a signature by the corresponding private key to spend the funds. The P2PK fell out of disuse for everything except mining outputs early on, and there never was a standard for encoding P2PK output scripts as addresses. The best way to track these is probably via the paid public key.

So for the second transaction here is what I see on blockchain explorer: (https://www.blockchain.com/btc/tx/dbaf14e1c476e76ea05a8b71921a46d6b06f0a950f17c5f9f1a03b8fae467f10)
It shows the address 1MdYC22Gmjp2ejVPCxyYjFyWbQCYTGhGq8
You say there is no way to get this address directly from scriptPubKey ?
When you say paid public key does it mean I have to check this output as the VIN of another transaction? (if so JSON RPC doesn't show addresses for VIN)
Thank you very much !

@Daniel See my answer, it's not that the address can't be computed from the scriptPubKey, it's that depending on interpretation, that script doesn't have an address.


text:
How does a Merkle proof differ from the Merkle tree?
I'm not sure how Merkle tree and Merkle proof are different. I thought Merkle proof is the same as the Merkle root in each block. However, it seems like Merkle proof contains all Merkle roots of all blocks. Could anyone explain about Merkle proof visually?

Hi, I suggest you first browse the questions that have been asked here on the same topic, for example https://bitcoin.stackexchange.com/questions/69018/merkle-root-and-merkle-proofs which I believe could answer most of your questions. If after reading all this you still don't understand then ask again more precise questions

Merkle proofs are not for blocks nor is there a singular "the merkle proof." Merkle proofs are for transactions. They prove that a particular transaction is contained within a particular block.
A merkle proof begins with the transaction that is being proved. Then each branch in the merkle tree that cannot be derived from the transaction is provided, all the way up to the root. The result is a path from the merkle root to the transaction. A verifier can then use this path to compute the merkle root and check that it matches the one in the block header.


text:
Port forwarding for pooled mining?
It does not seem to be necessary but does it help to use port forwarding for pooled mining? I mean forwarding the same port as the pool port on the incoming side of my router to the rig.

When the miner needs work, it contacts the pool. So the miner makes the connection.
The only time the pool needs to contact the miner is when a new block is found, to invalidate existing work units so the miner doesn't waste time finishing a work unit when the block wouldn't be accepted anyway. But this case is handled with long polling -- the miner keeps an open outbound connection to the pool manager at all times to receive this notification.
So there is no need to forward the port, and such a forward would never be used anyway. The mining program isn't listening for inbound connections.

I wonder if anyone has looked into using an open inbound port for server -> miner communication.  Some users seem to have trouble with long polling.  One common problem is router closing long polling connection.  I wonder if a direct inbound port would improve overall stale rates.

@theUnhandledException: Yeah, some routers will close a connection that's idle for ten minutes. A common fix is for mining pools to 'dribble' some data on the connection to stop it from being idle.

Port negotiations for mining occur via the same protocols as connecting to a web server, which means the port on which your system listens for return data is not the same as the port the pool is listening on, nor is it the same port every time. Forwarding the pool's port to a single machine will do absolutely nothing.


text:
What is the coin selection algorithm?
When creating a transaction in the standard client, what is the algorithm used to determine which unspent outputs will be used as inputs?
Has this changed since the first version? What different algorithms are used by alternative clients?
Does the client make any attempt to optimize which 'coins' are used based on minimizing the transaction size, the resulting fragmentation, or the 'age' of the coins (value/transactions) used as the source?

Here's more info: http://en.bitcoin.it/wiki/User:Gmaxwell/coin_selection

I couldn't find the results of the Coin Selection written out anywhere, and just finished piecing it together from the code. It works as David mentioned, but here are more details.
The Coin Selection Algorithm logic to transfer Target amount

If any of your UTXO² matches the Target¹ it will be used.
If the "sum of all your UTXO smaller than the Target" happens to match the Target, they will be used. (This is the case if you sweep a complete wallet.)
If the "sum of all your UTXO smaller than the Target" doesn't surpass the target, the smallest UTXO greater than your Target will be used.
Else Bitcoin Core does 1000 rounds of randomly combining unspent transaction outputs until their sum is greater than or equal to the Target. If it happens to find an exact match, it stops early and uses that.
Otherwise it finally settles for the minimum of

the smallest UTXO greater than the Target
the smallest combination of UTXO it discovered in Step 4.

As David mentioned, the subset problem will first restrict to UTXO that have at least one confirmation if sent by yourself, or six confirmations if received from another wallet, then later relaxes these requirements in two further passes if no suitable set of UTXO could be discovered.

Some examples
Alice has four UTXO:
• UTXO_A 0.1BTC
• UTXO_B 0.3BTC
• UTXO_C 0.5BTC
• UTXO_D 1BTC
I will be ignoring transaction fees for simplicity's sake.
Example 1:
Alice wants to send 0.3BTC.
Bitcoin Core discovers that UTXO_B matches the Target, and it only uses UTXO_B as input.
Example 2:
Alice wants to send 0.4BTC.
Bitcoin Core finds that UTXO_C is the smallest UTXO greater than the Target, and that the sum of all UTXO smaller than the target (i.e. UTXO_A + UTXO_B = 0.1 + 0.3 = 0.4) matches the Target here. Both UTXO_A and UTXO_B are used as inputs.
Example 3:
Alice wants to send 0.45BTC.
Bitcoin Core finds that UTXO_C is the smallest UTXO greater than the Target, and that the sum of all UTXO smaller than the target (i.e. UTXO_A + UTXO_B = 0.1 + 0.3 = 0.4) does not surpass the Target. UTXO_C is used as the sole input, being the next smallest input greater than the Target.
Example 4:
Alice wants to send 0.35BTC.
Bitcoin Core finds that UTXO_C is the smallest UTXO greater than the Target, and that the sum of all UTXO smaller than the target (i.e. UTXO_A + UTXO_B = 0.1 + 0.3 = 0.4) does not match the Target. It adds up randomly selected UTXO 1000 times until they surpass the Target, remembering the smallest sufficient combination. The smallest sufficient combination is then compared with the smallest single input greater than the target. Assuming that it does find the best combination here which would be UTXO_A + UTXO_B, it finds that Target < UTXO_A + UTXO_B < UTXO_C and uses UTXO_A and UTXO_B as inputs.
Example 5:
Alice wants to send 0.6BTC.
Bitcoin Core finds that UTXO_D is the smallest UTXO greater than the Target, and that the sum of all UTXO smaller than the target (i.e. UTXO_A + UTXO_B + UTXO_C = 0.1 + 0.3 + 0.5 = 0.9) does not match the Target. It starts trying random combinations as before, and in this situation would probably discover that UTXO_A + UTXO_C = Target. As it finds a combination that matches the Target, it breaks and immediately goes with that combination. UTXO_A and UTXO_C are used as inputs.

¹"Target" is used here for the amount to be spent.
²UTXO = Unspent Transaction Output

It seems like the algorithm optimizes for smallest change. Is there any reason why it isn't optimized for lowest transaction fee (fewer inputs resulting in a smaller transaction size)?

@MichaelEnriquez That's my understanding as well. Apparently, a lot of people aren't happy with this part of Bitcoin Core, but nobody has improved it yet. Most likely, there are also some disagreements what an improvement would constitute.

As coin selection is an implementation defined behaviour rather than being part of the protocol, few people attempt to improve it.

Yes, that is exactly what the client does. It uses heuristics to do this, solving a subset/sum or knapsack problem.
It uses a multi-pass approach, first trying to use only coins with at least six confirmations. In the next two passes it relaxes these requirements. Within each pass, it tries to minimize the number of transaction outputs claimed and then the amount of change returned.
Note that all coins in your wallet are considered. In the accounting model that the Bitcoin client uses, specific coins do not belong to specific accounts.
If you want to check the code yourself, search for SelectCoins in wallet.cpp.

Actually I think it even goes further and tries to use the oldest coins first.

no, it does not.

It also doesn't really try to "minimize the number of transaction outputs claimed".  It will use a single output if there's one which is the exact right size, but other than that it doesn't care about the number of outputs and tries to minimize the amount of change.

David, thanks for the detailed answer.  I'm looking through the wallet.cpp now, but was wondering if you could talk a bit about the performance considerations when finding unspent outputs (especially with Berkeley DB).  For example I can imagine a naive approach that would essentially be foreach address in account { foreach transaction { foreach output ...if spent?... }}}  But some values could be cached/denormalized..are they?  Thanks!

why do you need a knapsack algorithm?  knapsack is important when you want to not go passed a certain amount,  but that's not important here cause you can give change.  In particular, the sorting on this line  https://github.com/bitcoin/bitcoin/blame/3c098a8aa0780009c11b66b1a5d488a928629ebf/src/wallet/wallet.cpp#L2459 seems  like a huge over kill


text:
Are Bitcoin addresses case sensitive?
I sent $20 to my wallet ex. bc1qa4dk0fqvw7jfpvzgy9xpf7572kv9env9y748ct.
But instead I sent it to that address in all caps.
I haven't received the money and it's been 3 hours.
Are BTC addresses cap sensitive?
And what should I do?

As you mentioned below that your node is still synchronizing, you will likely find
I didn't receive a Bitcoin Payment. What does it mean when the Client is synchronizing? useful.

Segwit addresses like the one you posted are case insensitive. Assuming your wallet is up to the spec, it should be able to send the BTC just fine.
If you have a transaction ID, look it up on an explorer to see if it has been confirmed.
If you don't have a transaction ID, and you have the private keys for the wallet, you should simply be able to make another transaction.
If this is a custodial wallet like an exchange or other wallet service, you will need to contact them.

To elaborate a little on the question in the title:

base58 encoded addresses (1... and 3...) are case sensitive - however, getting the casing wrong will result in a checksum error, and a well designed wallet will not let you send a transaction to an incorrectly entered address
bech32 addresses like the one involved here are case insensitive but, as pointed out by Murch, must be entirely uppercase or lowercase - a compliant wallet should reject a mixed case bech32 address.

Okay tracked the id and it went to the lowercase one so the correct one, I think it wont show because im waiting on the syncing process on Bitcoin Core, that is taking forever.


text:
What would be an example for an insertion into the blockchain?
I'm reading the paper The Bitcoin Backbone Protocol:
Analysis and Applications. On page 21, definition 8 reads:

An insertion occurs when, given a chain C with two consecutive
blocks B and B, a block B* created after B′
is such that B , B*, B′ form three consecutive
blocks of a valid chain. A copy occurs if the same block exists in
two different positions. A prediction occurs when a block extends
one which was computed at a later round

The word round seems to be indicating that the network is considered synchronous and time is divided into rounds. My understanding is that an insertion has a negligible probability but what would it look like if it did happen? I could use an example and more explanation for how insertions could happen and under what conditions.

Hi @mike, I've edited your question to include the context you had provided in the comments. Please see whether my edit left the gist of your question intact, otherwise please feel free to rollback or edit as you wish.

An insertion occurs when, given a chain C with two consecutive
blocks B and B, a block B* created after B′
is such that B , B*, B′ form three consecutive
blocks of a valid chain.

For an insertion to occur in the Bitcoin blockchain, block B* would need to be a valid child of B:

a valid block at the corresponding height
commit to B as its prevBlock

B* would also need to be a valid predecessor of B':

The prevBlock in block B' would need to match the hash of B*

Finally, the block B' would need to be a valid block at a height one greater than the one it was previously found at.

These requirements are not just improbable but actually impossible to fulfill. Condition 1. is costly in that it requires expending sufficient work to fulfill the proof-of-work requirement of a valid block. Condition 2. would require finding a block that hashes to an exact value. This means breaking second pre-image resistance of SHA-256 which is considered infeasible. The good news is that if we can break second pre-image resistance, we can also find valid blocks more easily; the assumption that partial pre-images are hard to find are the core assumption of Bitcoin's proof-of-work algorithm. Finally, fulfilling condition 3. is impossible: each block commits to a specific block height in their coinbase transaction as required by BIP34. A block therefore can only be valid at exactly one height in a chain, and inserting another block in front of it invalidates the block.
Looking at the paper, it seems to me that that Definition 8 is chiefly used to prepare Definition 9 (emphasis added.):

Definition 9 (Typical execution). An execution is (ϵ, λ)-typical (or
just typical), for ϵ ∈ (0, 1) and integer λ ≥ 2/f, if, for any set S
of at least λ consecutive rounds, the following hold.
(a) (1 − ϵ)[X(S)] < X(S) < (1 + ϵ)[X(S)] and (1 − ϵ)[Y (S)] < Y (S).
(b) Z(S) < [Z(S)] + ϵ[X(S)].
(c) No insertions, no copies, and no predictions occurred.

I.e. the authors are trying to describe the three defined occurrences as atypical execution.


text:
Is it possible to search for an address (rather than a transaction ID) in the bitcoin mempool?
Is it possible to search pending bitcoin transactions by their "to" address?
I looked at several mempool navigator/explorer type services and they all seem to allow searching by transaction ID but not to/from address?  (e.g. https://mempool.space/)
Why is this? Are the to/from addresses not visible on pending transactions? (I assume they are visible)
If the addresses are visible on pending transactions why do mempool search tools not allow searching by address?

Yes, it is possible. Block explorers such as mempool.space allow you to search by address, and they will show you all transactions involving that address, including unconfirmed ones.


text:
Does bitcoin core save the seed in a brand new descriptor wallet when it gets created?
When I create a brand new descriptor wallet in Bitoin Core 24.x, does it save the seed anywhere, and if so, can I export/import it?
I understand that exporting descriptors only is not the same as exporting the seed - because the seed is hashed in order to obtain the private master key. So if I only have the master private key, the seed is basically lost.

No it does not save the mnemonic seed phrase when you create a new descriptor wallet.
Those descriptor wallet use xpub/xprv (extended public/private keys) to generate addresses and manage keys.
However, if you have the master private key (xprv), you can still recover your wallet and funds without the mnemonic seed phrase.
The reason why Bitcoin Core does not save the mnemonic seed phrase when creating a new descriptor wallet is for security reasons, it could be compromised because the seed key is the master key to the wallet and so an attacker could potentially gain access to all its fund. The xprv is effectively derived from the seed phrase, and so it is not necessary to save the seed phrase in order to recover the wallet

I see. Do you happen to know why it does not save the seed? If I understand it correctly, the extended private key is made by hashing the seed. So if the seed is not saved, then it is lost forever? If so, why is it okay and why that decisioon was made? Thank you.

Yes, I updated my answer.

I don't think that's the reason (there is even a PR to change this: https://github.com/bitcoin/bitcoin/pull/26728); I think it's just historical that doing the alternative was hard to do with how the code was originally structured. Also note that the seed and the mnemonic phrase are distinct things. The Bitcoin Core wallet has a seed, even though it is not saved. There is however no mnemonic phrase, which is a separate concept, introduced by a separate standard, which is not implemented in Bitcoin Core.

To make the information complete - the seed is not saved in so-called "descriptor wallets" in contrast to so-called "legacy wallets" for which the seed is got by the RPC command "dumpwallet" (in a line with "hdseed=1"), right?


text:
Does Bitcoin Core version v22.0.0 support SLIP-0132?

Launched my own Bitcoin Core with regtest.
Installed Specter and made it connect to that node.
In Specter, I created a new bitcoin wallet, basing it on the bitcoin core hot wallet.
In Specter, I exported an extended public key:

[cf308846/84h/1h/0h]vpub5YK...

Now, when I try to getdescriptorinfo with bitcoin, it says: "key 'vpub5YK...' is not valid".

The argument values I tried for getdescriptorinfo are:
6.1) wpkh(vpub5YK.../0/*)
6.2) wpkh([cf308846/84h/1h/0h]vpub5YK...)
6.3) combo(vpub5YK...)

Either I am doing someting wrong, or bitcoin core 22 simply does not understand SLIP-0132 addresses.

No.
The supported key expressions in the descriptor language are:

Individual public keys in hexadecimal
xpubs as defined in BIP32, possibly followed by a key derivation path
Individual private keys in WIF
xprvs are defined in BIP32, possibly followed by a key derivation path

The zpub/ypub/vpub were extensions designed with a similar intent as the descriptor language itself, trying to convey how the keys are to be used. That role is more completely covered by e.g. the wpkh() you're using, so no need to add it to the public key encoding.


text:
signrawtransactionwithwallet for a multisig-transaction, after getnewaddress
I created a descriptor wallet in bitcoin core 24.
Next, I created a new address with using getnewaddress.
I took pubkey of that address, and used it as one of the three pubkeys when generating a typical 2-of-3 multisig address.
After funding the multisig address, I am trying to sign a raw transaction that spends UTXOs from the multisig address.
I am trying signrawtransactionwithwallet, but I'm getting the following error:
"errors": [
      {
        "txid": "...",
        "vout": 0,
        "witness": [],
        "scriptSig": "",
        "sequence": ...,
        "error": "Unable to sign input, invalid stack size (possibly missing key)"
      }
    ]

My assumption is, since one of the public keys of the multisig script is managed by the wallet, I should be able to "sign by wallet". What am I doing wrong.

My assumption is, since one of the public keys of the multisig script is managed by the wallet, I should be able to "sign by wallet".

That is not how descriptor wallets work.
If you want them to be able to sign for something, there needs to be a descriptor in the wallet for it. Without that, the wallet won't consider that output to be something that even belongs to it, much less know how to sign for it, as the ways all its keys can be combined in multisigs is not practically enumerable.
To do so, use importdescriptors with a descriptor that describes your multisig policy exactly. For example wsh(multi(2,KEY1,KEY2,KEY3)) is a descriptor for P2WSH addresses for 2-of-3 multisig scripts using the 3 key expressions provided. These key expressions can be xpubs or xprvs, and include derivation paths.
Further, you really want to use the PSBT-based RPCs for this, rather than the raw transaction based RPCs. PSBT carries far more information about the to be signed transaction, which may be relevant if some signers don't have access to the full script or UTXOs.

Do I importdescriptors into the original wallet that generated the addres whose public key is one of the three of the multisig address? Also, regarding KEY1, KEY2, KEY3, can I use the actual public keys taken from addresses instead of xpubs?

It doesn't matter which wallet you import the descriptor; it is self-sufficient in any case. The KEYn expressions can be xpubs, xprvs (with derivation paths), hex public keys, or WIF private keys. Note that you'll need at least one privkey or xprv, or you won't have any ability to sign. Of course, if they're just individual keys and not derivation paths, you'll only get a single address, and they can't be made active.

"you'll need at least one privkey or xprv, or you won't have any ability to sign" - this is what is the most confusing to me. If I created the address through bitcoin core, in a descriptor wallet, I don't get any private keys nor can I export them. They're handled by the core and are stored somewhere in the wallet. So at the end of the day, I don't have a way to sign the transaction? -- because I cannot export the key, nor I can import a descriptor that has at least one privkey or xprv etc.

You can pass a parameter to the listdescriptors RPC to get the private keys too.

Hm, so what you're saying is that, I can first retrieve the private key with using listdescriptors, then import it again as part of the multisig-address descriptor, then sign the transaction. At the end of the day, this is no better than dumpprivkey and then signing with a legacy wallet. One way or the other, it cancels the whole idea of what I'm trying to do - i.e. to sign a transaction without extracting the keys and moving them to the API caller and then back to the bitcoin core.


text:
How do I retrieve my bitcoin balance?
I have a bitcoin balance. What's the process I need to follow to spend my balance in my bitcoin address?

Navigate to the 'send' page in the wallet
Paste in your recipient's address into the 'send to' field (and perform a double check that the pasted address is the same as the address you copied. Do the first 5-6 and last 5-6 characters all match?)
Input the amount to be sent (specify this to the satoshi, for better privacy)
As your wallet allows: select the transaction fee-rate, UTXO(s) to be used as input, and write yourself a memo so that you can later remember what the transaction was about.
Double check all the fields (there are no take-backs once a transaction is broadcast!), and then confirm the send.


text:
How can I contribute content to bitcoincore.org?
I want to contribute relevant quality content to bitcoincore.org that would be valuable to its readers.

The source code for bitcoincore.org (the website) is maintained via a GitHub repository. Content updates are proposed and reviewed by means of pull requests. Instructions for contributing to the website can be found in the repo's CONTRIBUTING.md.
Given that this question was tagged with "news", I am wondering whether the purpose of the bitcoincore.org website is clear. The above linked contribution guidelines state:

Content Policy
The purpose of the website is to be an official mouthpiece for the
Bitcoin Core project as well as be a resource for technical
information that has a direct impact on Bitcoin Core software. This
can include research, presentations, and developer blogs.
Where proposed content is about Bitcoin Core project policy, there
should rough consensus of the Bitcoin Core project maintainers as a
minimum bar and final decision is with the Bitcoin Core project lead.
via
CONTRIBUTING.md#content-policy,
retrieved 2020-06-27

News seems out of scope per these guidelines.


text:
Why is the scriptSig formatted this way in the Genesis Block (inside function CreateGenesisBlock)
I was exploring the function static CBlock CreateGenesisBlock inside src/chainparams.cpp and I was looking at the way Satoshi created its scriptSig:
 txNew.vin[0].scriptSig = CScript() << 486604799 << CScriptNum(4) << std::vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));

CScript is constructing an object of the CScript class with the following inputs:
486604799  is the Nonce
CScriptNum(4) is an extraNonce
pszTimestamp is just a string "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks";
Why is the scriptSig formatted like this and shouldn't the scriptSig contain the signature of the whole transaction (not just little parts of it) and a public key of the person who signs the transaction?

The scriptSig field of a coinbase transaction is special. It doesn't need any signatures at all, as no coins are being spent. The ability to produce new coins, which that input represents, is inherent to the protocol - every block is allowed some fixed amount of produced coins. Requiring a signature on it would be wasteful and pointless. Which key should we expect a signature with? Miners don't have identities by design, as it is intended to be permissionless.
Instead, this field just contains arbitrary data the miners chooses. It can function as an "extra nonce", when the nonce in the header overflows. It is used by BIP34 to store the block height. It can further be used to store messages - which is what happened here.
As for why Satoshi chose that specific structure, i'm afraid you'll have to ask him.
Also note that the genesis block is hardcoded by the protocol, so there are no real rules that apply to it. It could have been declared to be anything.

It does not need to as the coinbase transaction of each block does not spend any other transaction, hence does not need to satisfy the conditions set by the scriptPubKey of an existing output.


text:
What is the point of a soft fork when it's backwards compatible?
I understand a soft fork occurs when changes in the Bitcoin protocol are backwards compatible, but why is that a fork? Is there really a branch or is that just a formality? Or does this give me a chance to run an older version of Bitcoin (older than the soft fork), and still be part of the system? But, again, why would I do such a thing. For example, is there any active "soft" branches in the network that I can transfer on?
Thank you guys!

Related: https://bitcoin.stackexchange.com/q/30817/5406

Seems you answer the first question yourself :-).  Yes, it's a fork as it enforces new rules. But it does allow you to run an older version of bitcoind (not recommended though, but supported) and still be part of the Bitcoin network.

is there any active "soft" branches in the network that I can transfer on ?

This would mean there was a network split, what a soft fork is trying to avoid.
There are still old clients running that for example do not enforce the last soft fork that occured (Segwit), but they are part of the Bitcoin network and not an alternate one because the change was backward-compatible.

Thank you a lot for your quick answer :)


text:
Reversing network hashpower
I'm reading this article by Vitalik Buterin on Problems in Cryptocurrency and don't quite understand what this means:

Ideally, after some number of blocks (perhaps logarithmic in the total size of the network) every transaction should require 51% of network hashpower to reverse. However, solutions where transactions can pay very small fees for a lower "level" of security are acceptable, though one should take care to avoid situations where an attacker can profit by performing one attack to reverse very many small transactions at the same time

I understand that Sybil attack can happen if more than 51% of the network is under one person's control, but I don't understand what it means to reverse network hashpower, and why 51% of it should be reversed.

I think it's about 51% attack. https://bitcoin.stackexchange.com/questions/10936/is-it-a-51-attack-or-a-50-attack It would require 51% of network hashpower to "reverse" any transaction (through reorg).

It's hard to figure out what it is you don't understand. The quote is talking about reversing transactions, not reversing hashpower. When you say "51% of it should be reversed", do you mean 51% of hashpower? Hashpower is never reversed.

I've changed the tags on this question to "majority-attack" instead of "sybil-attack" as a sybil-attack is something you do on the node layer, and the majority-attack is something you do on the miner layer.

In theory, this attacker owns enough computing power that they could execute a "double spend" attack. They could spend coins in one place, allow the coins to enter the block chain as normal until the required confirmations are met, then fire up their 51% of the miners to craft a fraudulent fork of the block chain in which those coins were never spent, allowing them to re-spend the coins. This could theoretically be repeated for as long as the attacker maintained control of 51% or more of the hashrate.
Realistically, 51% is only the point at which this becomes possible not the point at which it becomes likely or easy. An attacker would probably need something like 65% to actually execute such an attack.
What can an attacker with 51% of hash power do?

An attack can only be launched when the attacker have more than 51% computational power.


text:
How does the sender know the receiver's public keys in a m-of-n transaction?
Assume that Alice is controlling an address that requires multisig to spend bitcoins. Someone wants to send Alice bitcoins and this sender needs to create a scriptPubKey as part of the output paying Alice.
The scriptPubKey in the sender's transaction should look like this:
m pubKey_1, pubkey_2, ...pubKey_m n OP_CHECKMULTISIGVERIFY

How does the sender know the public keys to send funds to Alice? And further more, how does the sender know the value of m? Isn't it more logical that Alice determines what the minimal number of signatures is?
If I understood correctly this output format is not used anymore, but I still want to understand how it worked.

Any address that a spender will send to is provided by the receiver. As the owner of the address, the receiver knows these details and will be able to provide the correct sending instructions to the spender. This holds true even for the outdated original multisig construction that required the spender to know the pubkeys, but today most multisig transactions actually make use of pay-to-script-hash (p2sh), so the receiver would simply provide a standard p2sh address to the spender.

In modern times, this problem is solved using P2SH (and later P2WSH). It means the sender only needs to know a hash of the actual script the receiver wants to use, which has its own address format so it's easy to convey.
If your question is how was this done before P2SH: the answer is simply that multisig was not used in practice. Note that P2SH was introduced in 2012; Bitcoin was relatively young at the time and not as much was built on top. There were probably a few experiments that used multisig, but I doubt anything practical.


text:
Is there an active list of BIPs currently open for voting?
How can a miner know from which two (or more) BIPs they can choose when they are about to vote? Is there a list of currently active BIPs for voting?
Thanks!

This question is based on a misconception. Miners do not vote on proposals. Consensus changes to Bitcoin are made by the entire ecosystem transitioning to new rules that they choose, by running node software that enforces these rules.
Miners are a part of that ecosystem, and their enforcing of new rules is part of what makes them safe. But if miners refuse to adopt a rule change that the rest of the ecosystem demands, they have no choice. If a rule is implemented and enforced by the network's full nodes, then miners who produce blocks that do not follow those rules will simply be ignored.
Everything works better however, if miners and the rest of the ecosystem do not diverge on what rules they're demanding and enforcing. For that purpose, several past backward-compatible consensus changes ("softforks"), have used a mechanism where miners can signal that they're ready to enforce a particular rule, and once a certain threshold is reached, all of them (including non-miners) start enforcing those rules in lockstep.
So in reality, such a signalling mechanism is for coordination, not for voting. Proposals may go through even without miners' consent, but it's better for everyone if things are synchronized.
Previous softforks that have employed such a coordination mechanism are:

BIP34 Height in coinbase (2012)
BIP65 OP_CHECKLOCKTIMEVERIFY (2014)
BIP66 Strict DER signatures (2015)
BIP68/112/113 OP_CHECKSEQUENCEVERIFY and associated relative locktime semantics (2016)
BIP141/BIP143/144 Segregated witness (2016)
BIP147 Dealing with dummy stack element malleability (packaged together with BIP141/BIP143/BIP144) (2016)
BIP91 Reduced threshold Segwit MASF (2017)
BIP341/BIP342 Taproot (2021).

The specific rules used by each of these differ (see my answer here for details). Some used a simple threshold of 750 or 950 blocks over the past 1000; some used BIP9.
Earlier softforks (BIP16, BIP30) were coordinated at the human layer. BIP16 did use signalling in blocks as well, but only to inform changes made to the software. The actual activation was time based (as soon as enough support was signalled, node software was modified to start enforcing new rules after a certain date). As BIP16 did have a competing proposal (BIP17), it was easy to misinterpret support for one or the other as a vote. Perhaps that is where the misconception originates.
Right now (as of October 2021), there are no unactivated consensus changes implemented in node software, so there is nothing to signal for.
Disclaimer: I am a (co-)author of some of the BIP documents listed in this answer (BIP30, BIP66, BIP141/143/144, BIP340/341/342).

But this part "the rest of the ecosystem demands" got me confused. Who is demanding the change? When BIP needs considering, who considers it? Who is the one that says: This BIPX is good, and this BIPY is bad? Is that the group of programmers who are currently controlling bitcoin github? Doesn't system that way seems a bit centralized? If you think I should move this to a new question, please tell me, but I commented because this questions are based on your answer.

@ddavi031 Well, that's venturing into politics. But I wouldn't confuse coordination with centralization. Just because some developers (myself included) release software that includes a certain change does not imply people will run it. For example, Bitcoin Core only implemented BIP141/143/144, which miners weren't really signalling for. Other people proposed BIP148 and BIP91 to get it to activate, which were never included in Bitcoin Core, and yet many started running software that did - and miners followed.

People wishing to submit BIPs, first should propose their idea or document to the bitcoin-dev@lists.linuxfoundation.org mailing list. After discussion it will be published Here

So miner can now, at this very moment , mine a block and vote for some of the BIPs from this list?


text:
Is there any other protocol in use besides a "Gossip protocol"
I'm interesting is there any other protocol that is being used inside Bitcoin network besides "Gossip"? And if there is, in which layer of communication and for which purpose is being used? Thanks!

Bitcoin uses many protocols for various purposes. You should perhaps specifiy a purpose. I assume you mean "relaying blockchain data", but it's not clear from the question. If that's the case, there is e.g. FIBRE, which is not strictly used "inside of the Bitcoin network" but check out: Can someone please explain FIBRE to me like I'm 5 and why is it useful?

I'm actually interested in various major protocols that are being used and you pointed me to one of them. So, block propagation - FIBRE, message propagation (transactions in mempool) - Gossip. Is there a link to any other protocol important like these two? Thanks a lot Murch, you helped me a lot!

To be clear: the use of "gossip" is just one aspect of the Bitcoin P2P protocol. It's the mechanism by which transactions and IP addresses, and to a lesser extent blocks, get propagated on the network. But the P2P is far more than just gossip of these things.

If you want to read more about the p2p protocol, check out the Bitcoin Developer Guide's overview of all peer-to-peer messages. Besides transaction and block relay, it is used to announce node services, discover peers, communicate content preferences, and request specific content. Only blocks and transactions are gossiped. Node addresses are shared with connections that ask for them. The remaining messages are just for communication on specific connections. Note that other software may support additional messages not supported by the reference client, e.g. to serve UTXO data, or to fulfill service-specific light client requests.
FIBRE is a redundant second communication network for relaying newly mined blocks outside of the regular gossip. It used especially by miners and large Bitcoin services.
Mining pools use their own protocols (getblocktemplate, stratum, stratumv2) to coordinate contributions of their contributors.
The LN uses a whole separate stack of protocols to announce channels and nodes, manage peers, channels, and facilitate payments.
I am not sure whether the following strictly fulfill the definition of "protocols", but there are various coordination processes to facilitate multiparty payments such as PSBT, statechains, MuSig, JoinMarket, PayJoin, …

Hope that's sort of what you were looking for, but note that the list is not meant to be exhaustive. Please feel free to amend your question to further narrow down what you are looking for, if I am off target.


text:
How often does temporary fork occur and how long does it last?
I was wondering, how often does temporary forks occur? They appear when there are two different blocks mined based on the same previous block (parent block), but what are chances for that? And if fork occurs, how long does it last (on average)? What is the moment in a chain when side branch gets discarded by the network, or when is the node certain that the branch he continues to mine on is really the longest one (following the longest chain rule)?
Thank you guys!!

Blockchain forks occur when two blocks are found at the same height. Only one of the two chaintips can become part of the best chain. Each full node will consider the first block it saw to be the best block for that height, until proven otherwise by another chaintip accumulating a greater total difficulty (i.e. adding another block). When another chaintip pulls ahead, the node will reorganize to the best chain. The node reverts its current chaintip back to the last shared block and then applies the blocks from the best chain. A blockchain fork is generally resolved whenever a block for the next height is found. The "best chain tip" is always a probabilistic determination, but the confidence quickly rises as more blocks get added (hence the recommendation in the white paper to wait for six confirmations). Nothing prevents a miner to continue mining on a stale chaintip. However, a miner cannot spend the block reward if the block does not become part of the best chain, so in most cases, it is unreasonable to mine on a stale chaintip. A miner with a large portion of the hashrate may try to extend a stale chaintip if they authored the stale block in a selfish-mining attack.
Earlier in Bitcoin's history there were some two dozen cases in which blockchain forks consisted of multiple blocks before a best chain emerged. You can read more about that in What is the longest blockchain fork that has been orphaned to date?. As far as I'm aware, we have not had a multi-block chainfork for multiple years.
If you have access to a Bitcoin Core instance that has been running for a long time, you can get all stale blocks it registered by calling the getchaintips rpc. Obviously, your node might not have seen all stale blocks that have occurred. Any node syncing later, will only download the best chain, and not acquire these stale chain tips.
Stale blocks were a fairly common occurrence in 2013-2015. IIRC, there would usually be one or more per day.
Headers-first sync introduced with Bitcoin Core 0.10.0 significantly reduced that. In 2016 the Fast Internet Bitcoin Relay Engine (fibre) replaced a previous effort (the "Bitcoin Relay Network") to provide a supplementary relay network connecting especially mining entities that directly pushed new blocks to other participants.
The rate of stale blocks further dropped around the time that segwit got activated. Some people surmised back then that some miners had been running old versions of Bitcoin Core, and when segwit activation forced them to update to a segwit-compatible client, they leapfrogged a number of block relay improvements that had been added over the years. Another rumor was that some mining outlets (spending millions on mining hardware!) used micro-computers as their mining controllers which would take a while to validate new blocks, delaying their switch to the latest chaintip.
These days, it's common that the network goes weeks without any stale blocks. BitMEX Research runs a forkmonitor which offers an RSS feed to alert users when stale blocks (and other block related events) occur. Unfortunately, it seems to me that the RSS feeds item list was reset and I was unable to find a list of their history of fork alerts. In lieu of that, let me note that BitMEX Research tweeted on 2020-01-26 that they had seen a stale block at height 614,732 and that this was the first stale block they had registered since 2019-10-16. Searching BitMEX Research's tweets for "stale", since 2020-01-26, they also tweeted about stale blocks on 2020-07-10, 2020-06-09, 2020-03-03, 2020-02-27, and 2020-02-22. Assuming BitMEX research tweeted about each, they have recorded seven stale blocks since 2019-10-16.
Note that the "orphan block chart" provided by blockchain.com appears to be broken.

Does this mean that sometimes nodes who provided PoW,  do not get a  reward for mining a block because it's not part of the best chain?

Yes, when two blocks are found at the same height, one of them will go stale, as the best blockchain can only have one block at every height.—Since the block reward can only be spent after a 100 block maturation period, generally only the one in the best chain ever produces a spendable output.


text:
Why is my mempool count so much lower than that of block explorers?
I have been running a full node for about two days.  I wanted to get a list of all mempool txs (using getrawmempool false), and found that it only came back with around 3,000 even though all the block explorers are currently showing around 12,000.  I understand that mempools will differ between nodes, but this seems like a very big difference.  Can I do anything about this?
My getmempoolinfo:
"size": 1985,
"bytes": 3458091,
"usage": 10785216,
"maxmempool": 300000000,
"mempoolminfee": 0.00001000,
"minrelaytxfee": 0.00001000

How long has your node been running? It may take hours or days for your mempool to fill up.

About 2 straight days now.  Seems to be bouncing between 2000 and 4000.  How can I remove all restrictions on what is accepted/stays in mempool?

What does bitcoin-cli getmempoolinfo spit out?
You may want to increase the maxmempool config value.

TL;DR:
Unconfirmed transactions are relayed only once. If you were not online, you will only learn about the missing transactions when they are included in a block.

As you may know, Bitcoin employs a gossip protocol to relay transaction and block information. When a new transaction gets submitted to the network, the spender wallet will announce it to its peer nodes. Each peer node will check whether it has heard about the transaction before and will request the full transaction if it does not have it. The peer nodes then proceed to validate the transaction and gossip it to its peers in turn. The transaction spreads through the network until all online nodes have received the transaction. The nodes will then hold the transaction in their mempools until it is included in a block or expires. Note that each unconfirmed transaction is announced only once on the network.
When a new node joins the network, the new node starts participating in the gossiping and will hear about any new transactions that get submitted to the network. The new node will not hear about unconfirmed transactions that were broadcast earlier as the other nodes do not rebroadcast transactions they hold in their mempool (although there is a proposal to change that). However, when a block is announced, each node will retrieve all missing transactions from its peers to be able to validate the block. This guarantees that all relevant transaction get propagated eventually.

I retrieved a screenshot of a mempool visualizer for the period of time at which you were asking your question (via jochen-hoenicke.de).
You mention that your node was running about two days at the point when you retrieved the mempool count. If you look at the graph at May 27, you'll see that there is a large count of transactions in the 1-2 satoshi/byte feerate range (the lowest blue band). If you look closely, you see that most of these transactions had been submitted to the network more than two days prior, i.e. before your node was online. Therefore, your node would not have known about the majority of the transactions that were known to nodes with a longer uptime.


text:
Accidentally sent BCH to BTC address... I tried to use the private keys in a BCH wallet to recover, and there's no coins showing
I've read many other threads like this and it seems to be the common consensus that to recover BCH sent to a BTC address, just use the private key inside a BCH compatible wallet. Well, I did that, and there are no coins showing, nor the address that I originally sent the BCH to (which has 100+ confirmations already).
Not really sure what to do in this case. The wallet which I originally sent the BCH to was a Bitcoin wallet in the Copay app.

Is it a segwit address?

@RaghavSood, it was legacy I believe, but I don't see how that's relevant, because there are no filled addresses at all in my BCH or BTC wallets related to this private key. I know the private key is valid because I've used it for BTC many times before, and usually keep it empty. It's just, when I load this private key under both BCH and BTC wallets, they're all totally empty. Yet, the address itself, which was generated by Copay from this private key, is showing a received BCH transaction.

Segwit matters because it does not exist on the BCH network. If it is a segwit address, you need to reach out to a miner such as BTC.com to get the coins back safely. Do you have a txid?

To recover Bitcoin Cash (BCH) from a Bitpay/Copay BTC wallet, please follow the steps below:
1. Within the Bitpay/Copay app, navigate to Settings
2. Select the desired Bitcoin wallet then tap on More Options
3. Tap on the Duplicate ( Bitcoin Cash ) option
Duplicating the BTC wallet will create a BCH wallet in your BitPay or Copay app with the BCH balance.
The option above to duplicate is not available for multi-sig BTC wallets, and you will need to use the recovery tool to recover BCH funds sent to a multi-sig BTC wallet.
Then, please clear your history cache. To do so, please open up your BitPay app and do the following steps:

Settings > Wallet > More Options > Transaction History > Clear cache

And finally, scan for addresses.

Settings > Wallet > More Options > Wallet Addresses > Scan addresses for funds


text:
Rationale behind accepting btc as a mode of payment?
Tesla has said they "expect to begin accepting Bitcoin as a form of payment for our products in the near future."
But Bitcoin doesn't scale. It achieves about roughly 6 transactions per second, paling in comparison to the likes of Visa, which facilitates around 1,700 transactions per second.
What's the rationale behind their decision?

Have you heard of the Lightning network?

@JivanPal They could accept LN only.

@MCCS, sorry, not sure what point you're trying to make; OP seems to not be aware that LN exists if they're focusing on the fact that the BTC blockchain is capped at 6 tx/s.

Oh ok I interpreted it differently. I "autocorrect" the question to why a business would accept BTC directly.

Sending a Bitcoin payment incurs a fee relative to the weight of the transaction. Every transaction must have at least one input and one output. Assuming a minimal transaction weight for either, it costs the same to send 1 mBTC or 100 BTC.
The cost per transaction weight is one reason why on-chain transactions are ill-suited for micropayments, but it also means that larger payments can come at a significantly lower relative cost than other payment forms.
A new Tesla 3 costs about 0.9 BTC today. At a feerate of 150 sats/vB (next block confirmation even at high demand) and a transaction weighing 250 vB, the transaction fee of 37,500 sats (0.375 mBTC) translates to a relative fee of 0.0417%. I believe that you will find many other payment forms to incur a larger fee, especially for the merchant.
On the other hand, payments on the Lightning Network incur a cost relative to the paid amount, so I expect smaller payments to shift to Lightning Network and similar solutions more and more.

What does "weight of transaction" mean? I'm not sure I understand how it's any different than the actual "paid amount"

Ok, I've just googled. It's the number of blocks needed to capture the transaction. Not sure I understand how this could be the same for 1 million btc and 100 btc though

The weight of a transaction corresponds to the length of its witness data and the byte length of its serialized form. More inputs or outputs increase a transaction's weight. Bitcoin blocks are limited to 4,000,000 weight units. I've added a couple links to corresponding topics to better explain.

Great answer. It seems like the fee structure essentially incentivizes large tx's, so it solves the scalability issue on a monetary level. However, I'm not sure how it addresses the issue on a physical level -- specifically one where there are many large tx's happening at a global scale. Does the network have the kind of bandwidth to handle the volume?

Did you mean "high value" with large?—I'd say my main point is that there are generally fewer high-value payments, and high value payments will remain competitive longer per the fee structure. On the other hand, there is a viable escape valve for low value payments.

Yep, I meant large monetary transactions. If tesla adopts it, I'd imagine its competitors/partners might potentially too; this would be mean there are many high value payments happening on a global level. Was just curious if the network had the capability to handle this volume.

"Large" is a bit ambiguous in this context, because "large" first makes me think of "transaction size" (the predecessor of transaction weight). This is why I distinguish between "bigger weight" and "higher value". :)

Let us continue this discussion in chat.

Cutting the middlemen: No bankers, no SWIFT, no account fees, no manual approval, easy intercontinental transactions.
And Musk likes (sometimes too much) to take risk. Perhaps, it's because he believes that the BTC they store would increase in value in the long term.
If everyone adopted SegWit addresses, especially Bech32, then the tx rate is higher than 7 TPS, although TPS may not matter since larger transactions are forced to weigh equally as smaller transactions.


text:
Getting salary in BTC in Germany
Am I allowed to ask my employer (large IT multinational) if I can receive my salary in BTC instead of EUR according to german law? Would I have to pay income tax if I do not exchange them for a year (tax exemption in place) and would I have to pay VAT for purchases made using BTC?

Someone with personal experience may be able to comment on the matter, but in general I think this is a question best left to a qualified accountant (lawyer?) who is familiar with German law :)

When working in a neighbor country and living in Germany, taxes are to be paid - e.g. you work in Switzerland, and live in Germany. German tax authorities asks for the taxes on all salaries, no matter where or in which currency they are received. This is „income tax“. And then there is speculation tax on investments. If you hold special investments, you might be excepted from tax, but currently this does not hold true for bitcoin. This forum here may not be the best to find the right answer, there is a German forum (coinforum.de) with a special section on taxes (obviously in German).

Am I allowed to ask my employer (large IT multinational) if I can receive my salary in BTC instead of EUR according to german law?

There appears to be an obstacle in law:

German labour law sets out certain rules when it comes to the payment of employees. An important regulation is § 107 GewO, which states a simple principle: “Wages shall be calculated and paid out in Euro”.

From Salary Payment in Tokens: German Labour Law Considerations

Would I have to pay income tax if I do not exchange them for a year

Salary is subject to income tax. Paying a salary is not the same as making an investment.

would I have to pay VAT for purchases made using BTC?

Yes.

Germany will regard bitcoin as the equivalent to legal tender for tax purposes when used as a means of payment,

...

When a buyer of goods pays with bitcoin, an article of the EU's VAT Directive will be applied to the price of bitcoin at the time of the transaction, as documented by the seller

From Germany Won't Tax You for Buying Coffee With Bitcoin
(the title may be confusing -- it is contrasting the rules in Germany with those in the US where using BTC to buy coffee means the buyer pays capital gains tax in addition to any applicable sales tax.)


text:
How is the current hashing power of the entire network measured in real time?

Does hash power refers to mining nodes only ?

We don't know how many nodes there are on the Bitcoin network, correct?
How do we count them?

Would we need to know [2] in order to figure out what the actual hashing power of the network is?

What are the units of hashing power?

Does hash power refers to mining nodes only?

Exactly. Other nodes just make sure everything's OK, or they don't relay it.

We don't know how many nodes there are on the bitcoin network, correct? How do we count them?

We can only count public nodes, but still, there are nonlistening nodes, nodes on the same IP, etc. So it not 100% accurate.

Would we need to know [2] in order to figure out what the actual hashing power of the network is?

Nope. We can calculate the total hashpower in two ways:

Visit each pool's website and add the hashing power. This method requires trust. On the contrary, it's accurate in practice.

Make an estimation using the network difficulty and the time between blocks. It's not very accurate.

What are the units of hashing power?

1: Hash/second: H/s <--- Not even Hand-scale
1000000: Megahash/second: MH/s
1000000000: Gigahash/second: GH/s
1000000000000: Terahash/second: TH/s <---ASIC-scale
1000000000000000: Petahash/second: PH/s
1000000000000000000: Exahash/second: EH/s <---World-scale

how do we count the listening nodes practically ? What if we have nodes that are asleep and suddenly wake up for a massive attack ?

By sending them requests. They can't do anything bad, they are not miners and have limited capabilities.

Shouldn't Megahash/second be 1000000?

@BoltonBailey Sorry, updated it.


text:
What is the correct use of the term "validating"?
First, in the Bitcoin context what does validating mean?
Second, is it incorrect to say something like

" the average time it takes to validate a block by the network is 10 minutes."

The way, I understand it,  validating is a split second procedure. Or am I confusing things. What is incorrect?

A bitcoin transaction is valid if it conforms to all of the bitcoin protocol rules. Likewise, a block is valid if it conforms to all of the bitcoin protocol rules (including: all of the transactions it contains are valid).
‘Validation’ of a block or transaction happens at the level of each individual node (miners and regular nodes alike). Validating a transaction or block is not that computationally expensive, in fact the protocol is designed so that fairly inexpensive hardware is capable of being a node (ie, your average computer can validate hundreds, or thousands of transactions per second).
Upon hearing about a new transaction or block, each node will quickly validate that it conforms to the network’s rules. If it is valid, that node may relay the transaction/block to its peers. If it is not valid, the node will reject that transaction/block, and not add it to the node’s mempool/blockchain.

the average time it takes to validate a block by the network is 10 minutes.

This is not quite technically correct, I would rewrite it to say:

the average time it takes for miners to find a new block on the network is ten minutes. Each block ‘confirms’ all transactions it contains. As the new block is transmitted across the network, each node will check it (and all of its transactions) to ensure they are valid according to the protocol’s rules.

someone emailed me that the correct way would be: finding the solution to the pow for the network takes approximately 10 minutes. that is better ? @chytrik

I think that is better, but in a nit-picky technical sense I think the language it is still a tiny bit off. I would amend it slightly: ”finding a valid POW solution for the network takes 10 mins, on average”. Note the difference from your original quote: it is not that ”it takes 10 minutes to validate, on average”, instead it is ”a valid solution takes 10 minutes to find, on average”. A solution is either valid, or not. Validity is not something that is ‘worked towards’. Hope that makes sense :)

thank you for correcting but i feel there is no such thing as a "finding a valid" solution. Solution solves a problem. Validity is key to that. It's too much to say valid.

Right, I can agree that ‘solution’ does presuppose validity. My nitpick was more over saying ‘finding the solution’, as opposed to ‘finding a solution. On an even nitpickier level, saying ‘10 mins, on average’ is more accurate than ‘approx 10 mins’. But I think we’re on the same page, the crux of the answer was that miners are not validating transactions by mining; transaction are either valid or not, independent of mining. Mining simply confirms them into the blockchain :)


text:
terminology and conceptual question about progress of PoW
what is wrong about thinking

prbobability of attacker increases with time t that goes into PoW since they have more time to secretly mine their alternate blockchain ?

This refer to double spending. Can one think in these terms or is progress of finding a solution to pow to related to it.
Please enlighten.

update:also, how is probabilty and hash hashpower related

Time only helps the attacker if they have more hashpower than all other miners together. That scenario is called a majority-attack and discussed on numerous questions on this site. Such an attacker can essentially rewrite arbitrary lengths of history.
However, if the attacker only has minority hashrate, time works against them. The more time passes, the more likely is it that other miners advance the blockchain further than the attacker in the same time. Once the attacker falls behind, nobody will consider their chaintip when it is broadcast and the attack is failed.

thank you ok . but in white paper p=probility that an honest node finds the next block ... does that mean that p is also hash power ? What is the probability ? it links to hashpower also ?

The probability of being the author of the next block corresponds to the relative portion of the total hashpower one contributes. With 10% of the hashpower, you should expect to find 1 out of 10 blocks.


text:
Could Taproot or Graftroot enable the execution of complex scripts?
From my understanding, Taproot uses a Merkle Tree structure whose root represents the outcome of a script. That representation is in the form of a signature that may unlock the inputs associated with its public key counterpart, which is shared by all participants.
I have two questions related to this:
First, how is the script structured in the tree? Does each path represent a different execution outcome? If so, how are the potential outcomes defined?
Second, if it follows a Merkle Tree structure, is there a limit in terms of the size of the script? I'm inclined to say no, given that this occurs off-chain, but I might be wrong.

First, how is the script structured in the tree? Does each path represent a different execution outcome? If so, how are the potential outcomes defined?

The taproot email doesn't specify how the script is placed into the merkle tree.  It can be that each leaf node in the tree is a different script (BIP114-style) or it can be that a parameter can be passed that allows extracting multiple leaves so that parts of the script can be reused (BIP116-style).
The reason this detail is not in the taproot email is because that email was about rearranging the previous ideas about merklized scripts (MAST) so that the expected default condition (everybody signs) was the easiest and cheapest option to use with no need to actually handle the merkle tree in the expected case.  The ideas about how to organize and use the tree are a separate discussion.

Second, if it follows a Merkle Tree structure, is there a limit in terms of the size of the script? I'm inclined to say no, given that this occurs off-chain, but I might be wrong.

The merkle root / public key for taproot consumes a fixed number of bytes (say 64), which is trivial, but the spending transaction will have to provide the spending script as well as a merkle proof providing a list of hashes (and a few bits of path information) proving that the provided script connects to the taproot's merkle root.
This information will be subject to the fundamental block size limit of 4 million weight units and, depending on how it is implemented, may also be subject to Bitcoin's current limits on witness size (10,000 weight units for segwit v0).  The good news is that it's impossible for an honest person to create a merkle tree that requires more than about 8,000 bytes to create the merkle proof (not counting the script) even if they had at their disposal all the energy in the universe.  (Assuming we use Bitcoin's SHA256d hash function.)

The above is an illustration from my article about MAST showing how the encoding of alternative scripts (subscripts) into a MAST grows at log2 whereas it grows linearly with the existing mechanism.
For a script with a million possible outcomes (tree depth equals 20) would require about 643 bytes (20 * 32 + ceil(20 / 8)), allowing actual witness script and witness data to be up to about 9,300 bytes.  Of course, if everyone signs, you don't need to provide any of that data---you just push a single signature.

Very helpful, thanks David. So what is the relationship between taproot and MAST? It seems like taproot is a proposed implementation of MAST, but with the added benefits of a consolidated pubKey?

That's correct, Taproot is a form of MAST where the merkle root is combined with a public key to create a secondary public key that can be spent by the private key corresponding to the primary public key.  Basically, if you take an ECDSA public key and add an integer to it to create a secondary public key, you can create the corresponding secondary private key by adding the name integer to it.  Revealing the number later doesn't reduce the security of the primary keypair, so if you need to publicize the merkle root to use MAST, you can---but otherwise you can just sign.


text:
Why is there sometimes no output that sends funds back to the sender's address?
'A' has one bitcoin.
'A' tries to send a 0.5 bit coin to 'B'.
Two utxo are created.
First, "utxo" sends "B" 0.5 bitcoin.
Second, "utxo" where "A" remits remaining bitcoins to "A" except for 0.5 bitcoins and fees.
utxo 1) A-->B
utxo 2) A-->A
The url below is the URL to see how UTXO is reflected in the Bitcoin block detector.
https://www.blockchain.com/ko/btc/address/1JK1MAseF6TRjBidxz45T1VnYVFummCTBZ?offset=5250&filter=6
https://www.blockchain.com/ko/btc/address/17YVBuR8oCaC78xQtWbx1gkfmhjt52UMK7
https://www.blockchain.com/ko/btc/address/1HpyyzMwq1QZqS43guyy9GvLdc6jMWoy8z
Sometimes when you look at a block detector, there's some TX information that you don't understand.
For the following URL, the coin in the wallet is used to transfer the same bitcoin from several wallets to another.
There is also a "TX" that displays only the amount of coins received from one wallet.
In the case of the url below, I transfer Coin from my wallet "13E3dBUWUHV8XpgJib795yqRTmyX47jWMk" and there is no utxo sent to my wallet.
utxo 1) A---->B
utxo 2) A---->C
If this is how the money is transferred, can we know why this is happening?
https://www.blockchain.com/ko/btc/address/13E3dBUWUHV8XpgJib795yqRTmYX47jWMk

related: https://bitcoin.stackexchange.com/q/736/5406

You are confusing addresses and UTXOs. What you are talking about are addresses, not UTXOs.
The inputs of a transaction have no effect on the outputs. There is no requirement that a transaction must have an output that corresponds to an address that is an input. In fact, what you described first is known as address reuse which is highly discouraged. The behavior you see in the address you have a question about is exactly the kind of behavior that is encouraged: the change is sent to a newly generated address.


text:
How does the Litecoin difficulty get calculated?
Bitcoin creates 2016 blocks, and if the average time of 2016 blocks is less than 10 minutes, the difficulty increases. If it is more than 10 minutes, the difficulty decreases.
How does the Litecoin mining difficulty get adjusted?

It is actually 2016 blocks in Bitcoin per difficulty retargeting. (The first block is not accounted for due to an off-by-one error)

Litecoin is a fork of Bitcoin Core, and uses the same difficulty adjustment period (2016 blocks), which on Litecoin is 3.5 days because the block time is 2.5 minutes instead of 10.  See chainparams.cppL#85:
consensus.nPowTargetTimespan = 3.5 * 24 * 60 * 60; // 3.5 days
consensus.nPowTargetSpacing = 2.5 * 60;


text:
How can forks coexist even though only one of the is the longest chain?
We know Bitcoin has some forks like Bitcoin Cash and Litecoin. They make a new branch on chain, so how can they coexist without the shorter branches being discarded, and just the longest chain staying around?
In the Satoshi paper, we read that just the longest chain is valid. So, if each of them has a longest chain, why doesn't one override another, for example assuming Litecoin has longest chain, why are Bitcoin or Bitcoin Cash still working?

For one, Litecoin is not a fork of Bitcoin. It relies on the same base code, but it is a separate network, and they do not share the genesis block.
Bitcoin Cash is a true fork of Bitcoin, in the sense that they can be traced back to the same genesis block.
Both chains continue to exist as they follow different consensus rules. Blocks on the bitcoin Cash chain are considered invalid by the nodes on the Bitcoin chain, and vice-versa. Since they have conflicting consensus rules, they are each the longest valid chains for their own set of the consensus rules.
Edit:
To include some additional information based on the comments, we can look at why cross communication doesn't happen (in most cases).
For litecoin, the genesis block, network magic bytes (a set of 4 fixed numbers that identify protocol messages for a network), proof of work algorithm, and a number of other things have been different from day one. This would prevent ltc nodes from communicating with btc ones since they would disagree on just about everything.
Things are a little more blurry with Bitcoin Cash. On August 1st, 2017 (almost exactly one year ago!), Bitcoin Cash altered the consensus rules of Bitcoin at that time. They did so by increasing the maximum allowed block size to 8MB, the difficulty adjustment algorithm, and the tx signing method (to prevent replay attacks).
These changes went into affect at block #478558. For all blocks mined after that, Bitcoin and Bitcoin Cash were following different rules. Even if a Bitcoin Cash node was to broadcast a new block to the Bitcoin chain, it would be rejected as:

It may have exceeded 1 MB
The transactions were signed in an incompatible way to Bitcoin's signatures
The difficulty would be vastly lower than the Bitcoin network's difficulty (it was lowered quickly using the new EDA algorithm in Bitcoin Cash). This means that even if the BTC chain received 10 BCH blocks for each BTC block, the total work done would still be higher on the BTC chain since it has a higher difficulty.

Based on the above, Bitcoin nodes would reject the Bitcoin Cash blocks. Moreover, as MCCCS mentioned in the comments, Bitcoin Cash also eventually changed their network bytes, which would prevent a broadcast from accidentally being accepted to begin with, stopping the new block before it even reached consensus validation checks.
Now, lastly, if someone were to manually take the BCH, LTC, Doge, or any other BTC-like chain's data and attempt to broadcast it over Bitcoin's network, they would all still fail various consensus checks.

Long after Bitcoin Cash was born, perhaps October/November, BCH moved to a new network magic thus they don't communicate with BTC nodes.

@MCCCS That's what I suspected, but I had a vague recollection of reading that right after the fork block, the nodes were still communicating. Makes sense if they switched later. Thank you!

@RedGrittyBrick I've updated the answer with some more details based on this comment chain!

Small nitpick: years ago, litecoin would have been called a 'fork of bitcoin', it is only more recently that 'fork' started meaning 'hardfork of the network, using the same genesis block (etc)'. Maybe it would be useful to edit this slightly to mention the difference between a fork of the codebase, vs a fork of the chain itself? This Q/A is largely aimed at reducing confusion of terms, so I think this is a worthy comment


text:
How do you get Sibling Hashed Values in a Merkle Proof?
Merkle Proofs are one of the main reasons that people attribute Bitcoin's use of Merkle Trees. But I'm struggling to understand how these work in practice. Please explain theoretically as well as practically.
Given that Lightweight Nodes only store Block Headers to limit the storage needed for their copies of the BlockChain, Nodes don't have access to the transactions in a Block; by definition of a Block Header, the only info they have about transactions is the Merkle Root.
But the Merkle Root is not enough to prove a transaction is in a block. All the sibling-values up the Merkle Tree are needed. Where do these values come from if they aren't already stored?
Example. Node 1 has a Block on its Blockchain with Merkle Root = H_ABC...P. It wishes to see if H_K is in the block. To do so, it needs the values H_L; H_IJK; H_MNOP; H_ABC..H. Where and how does it get these?

Given that Nodes only store Block Headers to limit the storage needed for their copies of the BlockChain This is incorrect. Nodes store the entire block.

Corrected the question to specify Lightweight Nodes

They will ask a full node

But the Merkle Root is not enough to prove a transaction is in a block. All the sibling-values up the Merkle Tree are needed. Where do these values come from if they aren't already stored?

Any full node that has a complete copy of the block can construct a merkle proof that proves a requested transaction identifier (txid) connects to the merkle root in a block header.  Here's an animated graphic showing how Bitcoin Core constructs a merkle proof:

For the txid (H5) for transaction 5, a list of hashes necessary to make the proof plus is created along with a list of flags telling the software evaluating the proof which side of each branch the would find the hash.
The lightweight client evaluating the proof uses those flags and hashes to prove the txid connects to the merkle root like this:

For more information, you may wish to read about the peer-to-peer network protocol message merkleblock in the BtcInformation.org Developer Reference, which includes these illustrations.