text:
Do the channel balances get publicly announced in real-time on Lightning Network?
In Lightning Network, is the balance publicly announced in real-time?
On the one hand, it should be public as it is crucial to the routing mechanism.
But, in case that the balance might reveal some private information to the network..
I didn't find the answer in the BOLT documentation.
Thanks.

Channels do not publicly announce their balance for several obvious reasons

It would be a huge privacy concern if balances could be viewed
live on the network. People could monitor large parts of the network and
aggregate data about how balances change over time, which could then
be used to trace payments through the network and deanonymize users.
If every transaction by every node required a broadcast of the new
channel balance, then bandwidth usage would become extremely large.
The network would not scale for the same reasons Bitcoin can't have
massive blocks. It would make running a node impossible on a
commodity computer and internet connection.
Broadcasting channel balance would really be quite useless because
the concept of "real-time" does not exist in a distributed network. A
node could advertize its channel balances to its peers, but before
any peer has chance to act on that data, those balances could have
changed if they route a payment for another peer. The system is in
constant change, and there is no way to atomically check a channel
balance and then send a payment over that channel. It would be a bad
idea to attempt to add such locks because there is no central
coordinator of them, and it would result in all kinds of race
conditions happening, like livelocks and deadlocks.

Channels only advertize their capacities, features, fees, minimum and maximum (optional) transaction values. There is no guarantee that a payment will route successfully even if you've provided a valid amount between the minimum and maximum with the correct fees.

The channel balance is not a public information. If you look at the channel_announcement-message in BOLT7 you see that the following information of the channel is public:
[64:node_signature_1]
[64:node_signature_2]
[64:bitcoin_signature_1]
[64:bitcoin_signature_2]
[2:len]
[len:features]
[32:chain_hash]
[8:short_channel_id]
[33:node_id_1]
[33:node_id_2]
[33:bitcoin_key_1]
[33:bitcoin_key_2]

There you can see neither capacity nor balance however the short_channel_id consists of the blockheight of the funding transaction and the index of the transaction and the index of the output within the transaction as described here.
Also from BOLT7 you can take the following quote about the channel_update_message:

Note that the htlc_maximum_msat field is static in the current protocol over the life of the channel: it is not designed to be indicative of real-time channel capacity in each direction, which would be both a massive data leak and uselessly spam the network (it takes an average of 30 seconds for gossip to propagate each hop).

I hope both points give you a definite answer (:


text:
Basic questions about lightning network HTLC
I'm reading about lightning and I have a few questions:

The HTLC contract seems to be different at each new path payment channel is opened (due to a different Hash value that needs to be provided), but from my understatement, the channel opens in an independent and in advance to the payments in that channels, between two parties.
How is it possible? Does the HTLC is not written on the blockchain?
This part confuses me.
Are there are known ways to extend the time of a channel before the predefined period time is over? (without closing and opening a new channel)?

Thanks.

I've downvoted this question because it is asking about multiple unrelated topics, the questions are unfocused and hard to understand, and I'm even having a hard time to come up with a decent title that gives potential readers a good idea of what it's about. In its current form, this is not useful content for the site. I would recommend that this question's content should be split up into several narrower topics and the original removed.

How is it possible? Does the HTLC is not written on the blockchain?

In the Lightning Network, HTLCs are part of the commitment transactions which are not broadcast to the network. This means that the HTLCs do not go onto the blockchain unless some fraud has occurred or someone is unresponsive.
None of the conditions of a commitment transaction (all of the punishment, timelock, HTLC, etc. stuff) ever go onto the blockchain unless fraud has occurred or one party is unresponsive. In a typical Lightning Channel, the only things that go onto the blockchain are the funding transaction which just pays a standard 2-of-2 multisig address, and the closing transaction, which just spends from a standard 2-of-2 multisig.

Are there are known ways to extend the time of a channel before the predefined period time is over?

Channels do not have a predefined period of time.
Only HTLCs have a predefined timeout time and this cannot be changed without revoking the HTLC and creating a new one.

HTLCs can also be published onchain for submarine swaps - not purely for fraud

source: Stack Exchange

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

sort: votes


text:
Will the size of a Bitcoin Core full node be too big to run on a normal computer?
I am a Bitcoin enthusiast, with no background knowledge in computer science and cryptography. I once ran Bitcoin Core on my laptop but realized that it occupied too much space on my computer.
I understand the idea that Bitcoin network is secure as long as any individual can run the full node of Bitcoin Core. However, what concerns me is that one day the full node may become too large to run on a normal computer. Do Bitcoin developers have any solutions to this problem? Or is it really a problem?
I would like to hear some responses from cryptocurrency developers or specialists in computer science.

I've removed several comments discussing a pseudo-answer to the question. Please post answers as answer posts.

Bitcoin has to maintain some balance to be able to retain the ability to be decentralized. As you've correctly established, this is partly down to making sure that the resource requirements of fully validating the block chain are not unreasonable. There's a push form the consumer side of things to constantly increase the resource usage of Bitcoin for convenience or lower transaction fees, but this comes at the cost of decentralization. What the limits for this are is debatable to some extent, but there are clearly hard limits to avoid.
Most notably it's difficult to undo mistakes in this area of the system design, going too far with resource usage is effectively a permanent decision so you will find that choices have been made as conservative as reasonable.
We have the following limitations to contend with:

Size of the block chain. It is often advantageous to store previously validated information, even if it is not immediately required for the operation of the system. It makes wallet management easier and allows for easy re-synchronization if required. The limit of this can not be above reasonable cost or the size of volumes available to the mass-market.
Growth of the block chain size on dish currently is bounded by the block size limit. Knowing that 6 blocks happen on average per hour, and they can be a maximum of 4MiB when fully saturated with Segwit transactions, we have a bounded growth of 210 GiB per year.

Nodes can disgard these blocks once validated to avoid storing them, but the entire set must be transmitted to them in some form, typically over the internet but could be done via Bluray, Fedex, or carrier pigeon if this was cheaper or required. This is a limit for the size of the growth, as it must not exceed the ability of users to obtain the data needed to validate.

Size of the UTXO. The Unspent Transaction Outputs database is the storage of units of Bitcoin that have not been spent. This is consensus critical and must be stored by all nodes in the network who are fully validating. This database has looser restrictions on its growth, and is effectively bounded by the block size as well, as it implicitly limits the number of entries which can be added to the database. Unfortunately there is not much to be done to reduce the impact of this 4 GiB storage on disk without much larger economic changes to Bitcoin to allow for entries to be "archived".

Validation complexity. The transactions within the chain have a cost associated with their validation. ECDSA is used in Bitcoin due to it being extremely space efficient and suitable for the task, but it is not particularly fast even with completely optimized implementations. Synchronizing the Bitcoin chain involves billions of individual SHA256 and ECDSA operations which puts a hard limit on the number which can be performed by a consumer processor in a reasonable amount of time. The growth of the chain should not exceed the ability for reasonable, consumer hardware to complete validation.

My view would be that it isn't currently possible to run a fully validating node on a "normal" computer and that it will be less so in future. However, the stretch from a "normal" computer to a capable system won't necessarily be out of reach either.
Bitcoin has to maintain a "sweet spot" which means nodes don't have to be hugely widespread but do have to be within reach of enough people to establish sufficient decentralisation.
My own peculiar philosophy is that Bitcoin's "limitations" actually underpin it's longevity. On the one hand, its blockchain "limitations" have allowed for continued decentralisation, but have also spawned higher transaction layers that were always going to be necessary for widespread adoption.
The higher "off chain" layers are obviously less secure, but we tolerate lower security for lower value transactions in our current exchange systems, so there's no reason to see this as a limitation.

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


text:
How do more leading zeroes make it more difficult to find a block?
A couple of articles describing the process of mining do say that the more miners are in the network, the more 0 numbers are included in the encoded hash of the particular block. I cannot find an answer to the following question:
why does adding more zeros at the beginning of the hash make it more difficult to calculate?

Adding more zeroes (more precisely as a prefix) to the required block hash (which is the hash of block header) makes it more difficult because you need to keep hashing the block header until you find a hash value that is less than the required maximum numeric hash value (you update the block header everytime by incrementing the nonce in it which changes the block header. Presently because of ASICs this field is too small, so the extra nonce is stored in unused locking script of Coinbase transaction, which as a result changes Merkle root which is part of the block header). Here is a documentation of what goes into block header:
https://en.bitcoin.it/wiki/Block_hashing_algorithm
Mathematically to make sense of it, think of it this way, if I ask you find a number at random from 0 to 100 less than 90, how many times do you have to try before you get a number for sure less than equal to 90? It is exactly 10 times. This same principle applies to SHA-256 of the block header.

I've got the answer http://www.righto.com/2014/02/bitcoin-mining-hard-way-algorithms.html:
The key point is that each nonce generates a basically-random hash value.
To get a lot of zeroes, you need to try an exponentially large number of nonces.


text:
Does total size of the transaction affect confirmation time?
Suppose one pays 1 satoshi/byte for their transactions.
Will the confirmation of the two transaction below be different?
A) a transaction of 1 inputs and 1 output (~192 bytes)
B) a transaction of 1000 inputs and 1 output (~148044 bytes)

Yes, but for a different reason than you think. ;)
Transactions bigger than 100,000 bytes are considered non-standard and won't be relayed by most nodes and probably not included by most miners in their block candidates.
Besides that, especially for a transaction paying a thrifty fee, a larger transaction might take longer to confirm. Block templates are by default populated by highest fee rate first as this maximizes revenue. It's more likely to have 192 bytes of block space left than 148,044 bytes after all transactions with higher fee rates have been considered. It's thus more likely for a bigger transaction to be delayed from inclusion in a block due to taking up more space.

The optimal transactions for miners to include in block is those with high fee and low volume. Transaction size is the major limit. In terms of lots of inputs, it should not be expensive since verifying signature is very easy and all the inputs are already in the pool of UTXO.
So it really depends on miners' algorithm and other transactions. For example if the block has a very small size left and your transaction A is the best option then tx A gets lucky.

What I am trying to know is if I set 1 satoshi/byte for transaction fee, will my 10000 input transactions still be confirmed in about 48 blocks which is claimed here: https://estimatefee.com/

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


text:
Electrum Gap Limit from CLI
Is there any way to change wallet gap limit in Electrum from command line? If yes, how? If not, could it be bypassed using some kind of external script? I really need to avoid GUI. Thank you in advance.

Does this no longer work?

@RaghavSood console there means the python console in the QT gui.

The only way is to edit the json code in the wallet file and add the gap limit into it. You can do that using the command line tool jq:
jq ". + {gap_limit:100}" wallet_file

Is necessary to run the daemon to refresh addresses?

@MichalVales yes you'll likely have to restart electrum to get it to generate the new addresses and sync.

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


text:
Why does the value range of outputs need to be restricted?
In the 'tx messages' section for protocol rules we have

Each output value, as well as the total, must be in legal money range

For each input, if the referenced output does not exist (e.g. never existed or has already been spent), reject this transaction

If my understanding is correct, rule 4 will confirm 0 <= output, sum of outputs <= 21,000,000, and rule 12 is checking that each input is in the UTXO set. I am having a hard time seeing why rule 4 is necessary, it seems like other rules - such as rule 12 - would already invalidate a transaction that was not in legal range. No one could ever have > 21,000,000 bitcoin so there could never be utxos for more 21,000,000.
Also, where can I find the code for these checks in the source code.

There's no real reason for the rule to exist, other than that there had been an integer overflow incident in the past.

If the output value was only constrained by their sum being smaller than that of the inputs, you could e.g. set one output to a negative value and create new money in a second output.
You can also do more creative stuff:
I think the rule might have been introduced as a response to the value overflow incident on 2010-08-15. A transaction in a (now invalid) block at height 74638 created outputs that were so large that their sum overflowed into the permitted range. The transaction created 2×92.2 billion bitcoins.
The code fix for the value overflow incident can be found in this commit. The code for this rule can be found in src/consensus/tx_check.cpp. The CheckTransaction() function checks consensus rules that don't require any knowledge of the current chainstate.


text:
Value of cryptocurrencies: Why does noone make Bitcoin2, 3, 4,...?
Cryptocurrency disciplee sometimes say that cryptocurrencies have just as much inherent value and potential as storage of value as fist currencies. One argument specific to the Bitcoin is that its value is guaramteed by the limited number of Bitcoins. However, I am very skeptical about this and similar arguments because of the following reasoning:
Why does noone use the exact same technology of the Bitcoin and create Bitcoin 2?  If they did, why would a Bitcoin2 be worth less than a Bitcoin? If it isn't, how can there be any worth in a Bitcoin, if there is the possibility that in five years there are a thousand different Bitcoin like system all guaranteeing the same anonymity, reliability, decentralized storage, and ease of use as the original Bitcoin? To me this is a significant difference to classical currencies which are linked to real governments and guaranteed by the fact that these governments work, pay and are paid with their respective currencies.

Why does noone use the exact same technology of the Bitcoin and create Bitcoin 2?

They have, there are hundreds of copies of bitcoin known as "altcoins", one prime example is bcash.

If they did, why would a Bitcoin2 be worth less than a Bitcoin?

Because there is no demand for a bitcoin2. No one wants one because its not a real bitcoin. The only value bitcoin has is in the demand people have for it - how much someone is willing to pay for it.

So Bitcoins are a pure investment bubble then? It sounds as if Bitcoins are a better investment than Bitcoin2s in the same way that tulips used to be a better investment than roses, except that tulips and roses actually make people happy and thus will always have at least some value

Cryptocurrency systems have utility, so I would not say they are 'pure investment bubble' (thought certainly the value of a bitcoin has a speculative aspect built into it). Since cryptocurrencies have utility, they will have some value, and the cryptocurrency system which has the most usage and demand (ie bitcoin) will have the highest value.

It is wrong to suggest there is "no demand" for altcoins like ethereum and ripple. There may be less demand or even much less demand but there can be significant demand. @Bananach is probably right to infer that the overwhelming majority of bitcoin transactions are currently speculative rather than associated with the purchase of legitimate retail goods.

Anyone can create their own cryptocurrency, this is a fundamental aspect of such systems: they are open and permission-less, so anyone can participate, whether that be using an already-existing cryptocurrency, or creating a new one of your own.

how can there be any worth in a Bitcoin, if there is the possibility that in five years there are a thousand different Bitcoin like system

As a thought experiment, consider this: instead of talking about cryptocurrency, lets talk about metal. Imagine a society where money comes only in the form of metal coins, and the majority of coins are made from a type of metal called 'coinium'. A lot of people use coinium coins to purchase their daily goods, so there is a great deal of economic activity conducted using the coins, giving them great value.
Now, eventually someone realizes that there is another metal, called 'altium', that can also be used to create coins, and it is extremely similar to coinium in many ways, except for the colour is different, so they are still obviously distinct. Just a couple people start to use altium to conduct their business, but the vast majority still use coinium.
What is the difference between coinium coins, and altium coins? They both accomplish the same goal, are equally as easy to make, but still are distinct since they are obviously different colours. This distinction allows people to differentiate between the two types of coins, and each has its own value.
Likewise, there are already hundreds, if not thousands of 'altcoins', many of which are copies of the bitcoin code base. But just because they are all cryptocurrencies, does not mean they are all absolutely equal. Each network is distinct and separate from the rest, so you cannot send a bitcoin to the litecoin network, or vice versa.
So we can see that there is a distinction between a bitcoin, a litecoin, or any other coin. Each one has it's own network, and price, whereas if every cryptocurrency was equal, than we would expect no difference in price between them. So in practice, we see that there is a discernible difference.

the difference in price despite equality in everything else perfectly matches my belief that cryptocurrencies are a pure speculative bubble. Also, your metal analogy ignores the very important fact that metals have inherent value because they can be turned into consumer goods (machines, electronics, jewellery)   and thus have inherent value and because they are truly limited (no one cannot break this limitation by inventing a new metal, and certainly not a million new metals by means of a mouse click)

Gold, much like cryptocurrency, has a large amount of ‘speculative’ value. The price of gold is driven more by this than by its usefulness as a jewelry material. But either way, bitcoin (cryptocurrency) has properties and functions that no other financial asset has, and I believe some of these functions and properties are important, and valuable. Yes, value is created & maintained through consensus of users agreeing that ‘bitcoin is more valuable than bitcoin2’, but I don’t believe this makes the value any less ‘real’.


text:
How do BIP8 and BIP9 differ, how are they alike?
With Taproot on everyone's lips, people have started discussing activation approaches. The debate currently seems to favor BIP8. Previous soft forks used BIP9. How are the two related and what are the differences between the two?

Early soft forks each had their own activation method included in the proposal which relied on flagdays or block version signaling. The latter only allowed a single proposal to be considered concurrently as it relied on incrementing the block version.
BIP9 proposed an activation standard which allowed multiple proposals to be considered at the same time. Soft forks that were activated using BIP9 were coordinated by having a supermajority of hash power signal readiness for the upgrade (traditionally 95%). Miners are tasked to assess the network's uptake of the proposal and signal readiness by setting specific bits in the version field of their blocks. The miners readiness signal is measured over the last difficulty period at each retargeting height. For example, the segwit soft fork and the CHECKSEQUENCEVERIFY soft fork that activated BIP68, BIP112, and BIP113 used BIP9-based activation.
BIP8 is a variant and the successor of BIP9. BIP8 uses block heights rather than timestamps to bound the signaling window, and gives the option to either fail or lock-in the upgrade at the end of the signaling window. When lockinontimeout: true is set, nodes running the activation code only accept blocks that signal readiness in the last difficulty period before the timeoutheight. This forces the upgrade to lock-in to the end of the signaling window. In contrast, BIP9 would always fail after the signaling window passed without activation, so BIP9 worked equivalently to BIP8 with lockinontimeout: false.

via BIP8
Per BIP8, a proposal would get activated via the following steps:

The signaling period commences at start_height by switching from DEFINED to STARTED. The start_height would be set at least a month after release of the activation code. Note that the timeout_height must be the end of a difficulty epoch.

At each difficulty retargeting, every node running the activation code independently checks whether the signaling threshold was met in the concluded difficulty period. There are three possible state transactions from STARTED:

If the threshold is not met at timeout_height, the
proposal settles in the final FAILED state at the end of the signaling period.
If the signaling threshold was met, the proposal transitions to the
LOCKED_IN state.
If the proposal forces activation via lockinontimeout: true and
the last difficulty epoch of the signaling period is reached with
the proposal in STARTED state, the proposal transitions to MUST_SIGNAL. This causes upgraded nodes to reject any blocks that don't signal readiness.

The proposal remains in LOCKED_IN
state for one difficulty period and then transitions to the final ACTIVE state. Upgraded nodes now enforce the soft fork rules on the network.

An activation threshold of 90% in BIP8 differs from 95% in BIP9. I think BIP8 is more likely to get activated than BIP9 because of this threshold. Do you know why and where this threshold numbers come from?

@ogw_yuya: They're picked as parameters for an activation attempt, either BIP8 or BIP9 could use a threshold of 90% or 95%.


text:
What is "Link-Level Multiplexing"?
In a discussion about private channels, Conner Fromknecht mentioned a concept called Link-Level Multiplexing. What is this and what is it useful for? How does it work?

It means that one peer can decide what is the best way of reaching another when forwarding a HTLC.
Let Alice and Bob having 2 channels between then, each one with 0.5 on each side, so looks like this:

Now, assume Bob gets a HTLC of 0.7 bitcoins going from him to Alice through channel A. Clearly, A cannot forward 0.7 bitcoins, since Bob's capacity there is just 0.5. But Bob can break this HTLC in two different ones, but with the same payment hash, so he forwards e.g 0.4 through A and 0.3 through B.
Alice may forward to the next hop using only one HTLC, or split even more. But this is local and only Alice and Bob knows about this split, hence, link-level.
Notice that this is not MPP. In MPP, the node who is paying breaks the payment, and it should be forward in parts through different peers. This one is inside a path itself, and doesn't reflect in what others see.


text:
What restrictions does the version field in the block header have?
We are seeing a lot of funky values in the block version since blocks are getting mined using the version field for additional entropy. This made me wonder, what range of values are permitted in the version field?

nVersion is a 4-byte little-endian signed integer. Little-endianness means that the least significant byte is first. The order of bits in a byte remains the same.
I’m aware of the following restrictions:

BIP65 requires blocks to have at least version 4.
Since nVersion is a signed integer, setting the top bit would turn it negative.

Therefore, any bit pattern that does not set the top bit and sets at least one bit among positions 2…30 will be permitted.
Note that in the context of BIP-9-style deployments, the top three bits must be set to 001 and only in that case the remaining bits are interpreted as a bit vector where each position may signal readiness for a softfork proposal’s activation.
Let’s look at some examples in hexadecimal and binary:
Sign (topbit):
0b 00000000 00000000 00000000 ±0000000
                              ^
                              Sign (topbit)

Version 0, least and most significant bytes:
0x 00       00       00       00
0b 00000000 00000000 00000000 00000000
   ^______^                   ^______^
     LSB                        MSB

Version 1:
0x 01       00       00       00
0b 00000001 00000000 00000000 00000000

Version 4:
0x 04       00       00       00
0b 00000100 00000000 00000000 00000000

BIP-9 (not signaling):
0x 00       00       00       20
0b 00000000 00000000 00000000 00100000

Signaling for Taproot on bit 2:
0x 04       00       00       20
0b 00000100 00000000 00000000 00100000

Version of Block 779,960 (version field used for additional entropy):
0x 32       47       40       00
0b 00110010 01000111 01000000 00000000

The final example here is a block in which the version field is used as an additional source of randomness in the block header: it’s faster to change the version field instead of changing the extra nonce in the coinbase transaction because changing the version field will not require recalculating the left flank of the Merkle tree to update the Merkle root.

What is the purpose of the "Overt ASICBOOST" changing version numbers?

Changing the version field is quicker than changing the coinbase transaction and rehashing the left flank of the merkle tree, thus it’s a quicker way to generate more variants from a block template.

So as long as they don't add the BIP-9 style 001 on the most significant bits, these different / random version bytes have no other consensus level implication?

Yes, as I write in my answer, blocks simply have to have a version greater than 3.


text:
Which transaction gets picked when ancestor scores tie?
Bitcoin Core greedily picks the ancestor sets with the highest ancestor score into its block template. When two transactions have the same ancestor score (e.g. two transactions without unconfirmed ancestors that have the same feerate) during block building, does Bitcoin Core randomly pick one, or does one get preferred per some criteria?

As of Bitcoin Core v24.0rc1, and probably since ancestor-aware mining has been included, the txid is used as tie-breaker:
https://github.com/bitcoin/bitcoin/blob/v24.0rc1/src/txmempool.h#L293


text:
How would faster blocks cause mining centralization?
I've heard that faster blocks would cause mining to become more centralized. How do these things fit together?

Why faster blocks?
This conversation often starts with someone pointing out that shortening the block interval would allow for a quicker first confirmation, reduce variance in mining revenue, and could provide more blockspace.
Beyond the fatal argument that such a change would require a hard fork, the responses usually point out that confirmations would still be too slow for point-of-sale scenarios even at feasible shorter block intervals, thin clients would be more expensive due to the larger blockheader count, and it would cause more frequent chaintip reorganizations. I want to explore the last argument further.
How do reorgs happen?
Bitcoin is a distributed system. Propagating a new block in the network takes time. Even if every node could message every other node directly that a new block was found, the limited speed of light would still result in a notable delay until every other node would receive this message. After nodes hear about a new block, they still need to validate the block before forwarding it to their peers (although nodes may permit their peers to forward before validation in the high-bandwidth compact blocks relay mode). Miners can only build a new block template after validating the block, and then it may take some more time to update all devices to the new instructions. So, while the successful miner can immediately switch over, the other miners continue to work on a competing block for a short time window. If another miner finds a competing block before hearing about the other, they'll announce it as well. From the point-of-view of each miner, their own block was seen first and they are on the best chaintip.
 via DSN Research Group, Kastel, KIT
Over the years, improvements in block propagation and validation have lowered this latency. The number of chainsplits and stale blocks got reduced from about once or twice every day to once every two weeks.
Why are reorgs bad?
Hashrate working on a competing chaintip does not go towards the proof-of-work securing the best chain. Frequent reorganizations make the first confirmation less reliable.
While mining itself is progress-free (every hash is an independent event with a chance to find a block), the author of the latest block has the advantage that they can immediately start mining the next block.
How much does the propagation latency benefit larger miners?
Let's assume it takes 6s for a block to reach other miners and compare 60s vs 600s block intervals for miners with 5% vs 30% of the hashrate. 6s is a very rough estimate for the time until most nodes have received a block after Compact Blocks.
The propagation delay is both an advantage and disadvantage: it gives the author a headstart for the next block, but also gives time for a competing block to emerge which may oust the author's block. Let's assume that each author works on their own chain, and the remaining hashrate is split half-half on each competing chaintip.
Finding blocks is a Poisson process that we can model such:

We can calculate the chance of finding one or more blocks in a time interval by starting with a probability of 100% and deducting the chance of finding 0 blocks. The chance to find 0 blocks in a time frame where we'd expect λ blocks is p(0|λ) = exp(-λ)*(λ^0)/(0!) = exp(-λ)*1/1 = exp(-λ).
600s block interval
Given a 600s block interval, we'd expect 0.01 blocks to be found in 6s by 100% of the hashrate, 0.05×0.01 = 0.0005 blocks to be found by the 5% miner, and 0.0030 blocks by the 30% miner.
As noted above, we'll simplify to expect half the remaining hashrate to work on a competing block whenever one is found. In case of the 5% miner the split is therefore 52.5% to 47.5% of the hashrate, and it's 65% to 35% for the 30% miner.
The author wins either when they find another block during the headstart or when their collaborators find the next block, and loses when both a competing block is found and it sires the successor: P_loss = (1-e^(-λ_comp))×comp/2×e^(-λ_self)
(That's a simplification, because we don't cover the case where both sides find at least one block in the headstart time window, but the competitors find more blocks.–I think we can get away with it.)
Small miner:
P_loss = (1−e^(−0,0095))×0,475×e^(−0,0005) = 0.0045. I.e. the 5% miner mines at a handicap of 0.45% and has an effective hashrate of 5%×(1-0.0045)=4.98%.
Big miner:
P_loss = (1−e^(−0,007))×0,35×e^(−0,003) = 0.0024.
I.e. the 30%-miner mines at a handicap of 0.24% and has an effective HR of 30%×(1-0.0024)=29.93%.
60s block interval
Given a 60s block interval, we'd expect 0.1 blocks to be found in 6s by 100% of the hashrate, 0.05×0.1 = 0.005 blocks to be found by the 5% miner, and 0.030 blocks by the 30% miner.
At 60s blocks for the small miner:
P_loss = (1−e^(−0,095))×0,475×e^(−0,005) = 0.043.
I.e. the small 5%-miner mines at a handicap of 4.3% and has an effective hashrate of 5%×(1-0.043)=4.79%.
At 60s blocks for the big miner:
P_loss = (1−e^(−0,07))×0,35×e^(−0,03) = 0.023.
I.e. the bigger 30%-miner mines at a handicap of just 2.3% and has an effective hashrate of 30%×(1-0.023)=29.3%. At the same handicap as the smaller miner, the big miner would only have an effective hashrate of 28.7%!
Conclusion
We see that going from 600s blocks to 60s blocks, a 5%-miner goes from a 0.45% handicap to a 4.3% handicap, but a 30%-miner goes from a 0.24% handicap to a 2.3% handicap.
Also, the stale block rate would increase from one every ~100 blocks to about one in every ~10 blocks; increasing the portion of hashrate not contributing to security, the chance of multi-block reorgs, and easing majority and selfish mining attacks.¹
In effect, an individual miner contributing to a 5%-pool would make about 0.2% more money by joining a 30%-pool at 600s blocks, but the same move would gain 2.1% more money at 60s blocks.
However, when mining hardware is abundantly available and the exchange rate becomes less capricious, it would be expected that miners continue to invest in building out their hashrate as long as there is more money to be made. Eventually, an equilibrium would be reached where miner margins would be pretty tight, and less efficient miners would get pushed out of the market. Then, profit might be a small portion of the revenue. If profit were e.g. only 10% of the revenue, 2.1% more revenue would translate to a profit increase of 21%.
Note on assumptions
• 6s propagation is a bit long¹
• Remaining hashrate would not be split 50:50
• Headstart is not explicitly modeled

¹ Note that miners actually have a lower latency to each other than 6 seconds or we would actually see a stale block every day, but we actually only see them a few times per month.

A by-product of faster block times is larger storage requirements to store the chain data, also faster disks and faster network to propagate and sync these updates.
Based on this assertion, the cost of hosting the infrastructure of a mining pool goes up. A single copy of the chain is not too bad to think about in terms of costs, but when considering multi-site, multi redundant nodes.
Fast blocks also require faster disks and faster network. 10 minute blocks vs 1 minute blocks vs 6 second blocks and lower.
The miners themselves may be scattered geo-politically around the world, however, if they are getting their jobs from a central mining pool, or 2 or 3 of them, then this is where the centralization argument becomes relevant.

Faster blocks would not necessarily mean larger storage requirements. One minute blocks of 400,000 wu would have almost the same storage as 4,000,000 wu blocks every ten minutes. Smaller blocks would also propagate a tiny bit faster, but not to the same degree, so latency would remain an issue even when storage wouldn't change much.

I'm not understanding your comparison.
1 minute blocks after 1 year > 10 minute blocks after one year.
The storage requirements at the end of year 1 are higher for 1 minute blocks, because there are more of them.
Am i missing something?

If you have 10 1-minute blocks with a tenth of the current block weight, that would not significantly increase the storage requirement over having one 1 10-minute block with the current block weight. However, the minimum latency (speed of light) remains the same even when you have smaller blocks.

What do you mean by "weight"?
Block with no transaction size is: 2kB for example, header data etc.
In 10 hours:
1 min blocks = 600 blocks = 600 x 2kB = 1.2MB
10 min blocks = 60 blocks = 60 x 2kB = 120kB
Mining pools may only be sending out "jobs" or "shares" but they still need to maintain low-latency high speed networks to remain competitive. Connecting to 100s of peers to receive the latest block, to send the new block's jobs to miners.
The storage is 10x for empty blocks.
Network bandwidth & data are also higher with more blocks than less blocks.
Leads to higher costs.

The segwit softfork replaced the 1,000,000 byte blocksize limit with a 4,000,000 weightunit blockweight limit: https://bitcoin.stackexchange.com/a/53626/5406. The header data on a block is exactly 80 B, which would translate to about 38 MB more data per year for the additional blockheaders when going from 10 minute blocks to 1 minute blocks.

That is useful, but complicated info to grok in one hit. Sorry for the delay & thank you for persevering with the explanation.
I see where I have been led astray - I have been looking at equihash blocks, which have 2kB of header info, and the blocks I have been basing my case for contain regular multi-sig transactions >1kB.
Given the 80 B header & 128 B transaction for a coinbase, my argument of additional storage doesn't hold at all on those numbers, regardless of a decade long collection of data on either 10min or 1 min blocks.


text:
single mnemonic to create private key with different networks
I have both 12 and 24 words, but i can't remember which coin it has.
so shall i try all wallets to find out which has a coin or is there anything i can do practical?
with a 24 words can i create a wallet for most of blockchain networks?
example:
24 words mnemonic-to

bitcoin wallet
doge wallet
ethereum wallet

if there is a library i can also use that then try finding my coins.
Regards.

Hi Septimus, this site only covers questions about Bitcoin. Someone might help you with the Bitcoin portion of this, but our users might not know about multicoin wallets or care to answer that portion of your question. You might want to ask on a different platform.

Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.


text:
How to convert the results of point doubling (Rx1 and Ry1) to point addition (Rx2 and Ry2) without knowledge of (Qx, Qy) in secp256k1 elliptic curve
I'm working with the secp256k1 elliptic curve and have point doubling and point addition formulas for this curve. Given the following formulas:
Point Addition Formula in Python3:
s = (Qy - Gy) * pow(Qx - Gx, -1, p) % p
Rx = (s**2 - Qx - Gx) % p
Ry = (s * (Qx - Rx) - Qy) % p

Point Doubling Formula in Python3:
s = (3 * Qx**2) * pow(Qy*2, -1, p) % p
Rx = (s**2 - Qx*2) % p
Ry = (s * (Qx - Rx) - Qy) % p

If a point is given Qx and Qy
Qx = 112711660439710606056748659173929673102114977341539408544630613555209775888121
Qy = 25583027980570883691656905877401976406448868254816295069919888960541586679410

performing point doubling on the given points (Qx, Qy) will get the below output
Rx1 = 115780575977492633039504758427830329241728645270042306223540962614150928364886
Ry1 = 78735063515800386211891312544505775871260717697865196436804966483607426560663

Performing point addition on the given points (Qx, Qy) will get
Rx2 = 103388573995635080359749164254216598308788835304023601477803095234286494993683
Ry2 = 37057141145242123013015316630864329550140216928701153669873286428255828810018

Now, I'm looking for a way to convert (Rx1, Ry1) to (Rx2, Ry2) without knowing the original given values (Qx, Qy). Is there a method or algorithm to achieve this conversion?

Hello Aviril, this question has already an answer, so please refrain from heavily editing your question at this point. If you want to ask something different, please start a new topic.

@Murch  the answer provide below does not answer my question. I already gotten the answer somewhere else so if you don't mind stop editing the question back, I tried deleting it but since some already tried answering the question I can't.

It is not clear to me how your edit improves the question except that it removes context relevant to the answer below. I’ve already requested once that you stop removing content. I’ve locked this question to edits.

I’m voting to close this question because it was crossposted to Crypto SE, where someone figured out that the asker meant to ask how to get from R_1 = 2Q to R_2 = Q + G which lead to a better answer.

Yes, but it's pretty silly.
If you use your addition formula for Qx = Gx, the intermediary s will be 0. From this, it follows that Rx = -2Qx = -2Gx and Ry = -Qy.
So if you instead wanted doubling (all you need to do is take the Rx and Ry values, compute Qx and Qy from those, and substitute those expressions in the correct doubling formula.


text:
Why is my manually calculated public key different than libsecp?
I'm teaching myself ECC using the secp256k1 curve. Ultimately I'm interested in learning about Schnorr signature aggregation and MuSig protocols, but I'm starting from the ground up.
I've attempted to calculate the public key given a private key, but the public key that I calculate is different than the one that libsecp returns. Maybe I'm getting byte ordering wrong somewhere, or I am misunderstanding when to use modulus. Can someone point out where my logical error is?
use num_bigint::BigUint;
use rand::Fill;
use secp256k1::{Secp256k1, SecretKey};

fn main() {
    let secp = Secp256k1::new();
    let sk = private_key();
    let sk = SecretKey::from_slice(&sk.to_bytes_be()).unwrap();
    let pk = sk.public_key(&secp);
    println!("Public Key: {}", hex::encode(pk.serialize_uncompressed()));
}

fn private_key() -> BigUint {
    // Generate a random 32-byte private key
    let mut private_key_bytes: [u8; 32] = [0; 32];
    private_key_bytes.try_fill(&mut rand::thread_rng()).unwrap();

    // Convert the private key bytes to a BigUint
    let private_key = num_bigint::BigUint::from_bytes_be(&private_key_bytes);

    // Curve parameters for secp256k1
    let p = BigUint::from_bytes_be(&secp256k1::constants::FIELD_SIZE);
    let n = BigUint::from_bytes_be(&secp256k1::constants::CURVE_ORDER);
    let g_x = BigUint::from_bytes_be(&secp256k1::constants::GENERATOR_X);
    let g_y = BigUint::from_bytes_be(&secp256k1::constants::GENERATOR_Y);

    // Ensure the private key is within the valid range
    let private_key = private_key % &n;

    // Compute the corresponding public key using scalar multiplication
    let public_key_x = (g_x * &private_key) % &p;
    let public_key_y = (g_y * &private_key) % &p;

    // Encode the public key
    let public_key_encoding = format!(
        "04{:064}{:064}",
        hex::encode(public_key_x.to_bytes_be()),
        hex::encode(public_key_y.to_bytes_be())
    );

    println!("Private key: {:?}", private_key);
    println!("Public key: {}", public_key_encoding);

    private_key
}

The multiplication between the generator G and the private key which you use to obtain the public key is not normal (modular) multiplication, but https://en.m.wikipedia.org/wiki/Elliptic_curve_point_multiplication. It's a far more complex algorithm than what you're doing here (yours would be trivial to revert too).

Thanks. I will attempt to implement the double-and-add algorithm described there.

You'll also need point addition and point doubling, which are a lot more involved than the double-and-add done on top. Good luck!


text:
How can I raise the fee of a transaction in Bitcoin Wallet App?
I am using the Bitcoin wallet app from bitcoinj.org. I sent a payment with a low fee so it's been pending for 8 days. I wrote the developers and they only replied with auto. Beneath is what I got:

Q: An outgoing payment doesn't get confirmed for a longer time.
A:
The reason is the same as for the previous question: The Bitcoin
network is running at its capacity limit. As a sender, if you have
time critical payments you should use Send coins > Options > Fee >
Priority to pay a higher fee. The fee can also be increased after
sending (Transaction > Options > Raise fee). Just be aware about how
much you spend on fee; it's sometimes more than expected.

Now I can't find a place to do that. When I click on any sent transaction nothing happens.


text:
How to create off-chain transaction, the one that exchanges uses
How to create off-chain transaction, the one that exchanges uses. I know that exchanges just update their databases when transaction between customers occur. But how this affect blockchain? How to build such kind of transaction and I am not asking about lighting network because I already have lighting network node and that's not what I am searching for. What tools to use for crafting off-chain transaction? Can someone guide me how to create it?

I know that exchanges just update their databases when transaction between customers occur.But how this affect blockchain?

It has no effect on the Bitcoin blockchain. None.

At midnight on Monday, John asks the exchange to transfer ₿3 to Mary. Both are customers of the same exchange.
Here's how that changes the spreadsheet in the laptop of rich Eddy, the exchange owner:

Day
I owe John
I owe Mary

Monday
₿10
₿10

Tuesday
₿7
₿13

Heres how that affects the blockchain²

Day
John has¹
Mary has¹
Eddy has¹

Monday
0
0
₿100

Tuesday
0
0
₿100

Note that the number in Eddy's column could as easily be 0. Eddy might have long ago spent it all.

When you give money to a trusted third party, such as an exchange, you give them control of that money
The Bitcoin blockchain records changes in control of money. The Blockchain does not record debts
When an exchange deletes their IOU to John and creates an IOU to Mary, there is no change in control over Bitcoin money. It is still the exchange in control.
Remember, Bitcoin was invented so that one party could pay a second party without involving any trusted third party. There's no good reason to hold money in an exchange unless you are some kind of day trader.

How to create off chain transaction the one that exchanges uses.

Use whatever methods your particular exchange provides. Every exchange is different. Ask them. Maybe they have an API, maybe not.

¹ control over.
² in the UTXO set derived from it - if you know the public keys etc of each.

Some exchanges enable their customers to send funds to each other by using an email address. The recipient then receives an email informing them of the pending payment offer. The recipient must log in (or create an account) to accept the transfer, at which point the exchange updates their accounting. This does not case any on-chain transaction, the funds are still in custody of the exchange. These sort of service features generally only work among customers of the same exchange, and not all exchanges offer it.
If you cannot find any such feature on the exchange you are using, you should contact the exchange’s customer service to inquire whether it is available and how to use it.
Most exchanges only permit withdrawing to yourself for KYC/AML reasons. If an exchange offers payments to others directly from your account, they may offer on-chain or Lightning as payment methods. Possibly some exchanges might use Liquid. I’m not aware of any exchanges facilitating off-chain payments to customers of other exchanges that are completely off-chain and not settled in some other blockchain based token or via Lightning.


text:
Is it actually possible to pay ONE fee but make many transactions?
I heard that apparently, exchanges and similar "load up" and then "batch-send" many Bitcoin transactions at once, with just one fee, instead of sending each one with a separate fee.
Is this actually possible? Is it easy to do? Should I be doing it for all my "withdrawals"? Will it save me lots of money versus making separate Bitcoin transactions for each customer? (I'm not running or planning on running an exchange, but a Bitcoin-based service where people will get sent Bitcoin.)

Is this actually possible?

Yes. Transactions may have arbitrarily many inputs and outputs (subject to them fitting inside a block, of course). The inputs must be UTXOs that you can provide signatures for (coins you own), and the outputs will be new UTXOs, each of which can be associated with any address(es) you like (that is, the coins you own can be distributed amongst as many addresses as you like).

Is it easy to do?

The reference implementation (Bitcoin Core / bitcoind) allows you to do this on the command line (that is, with bitcoin-cli) using its sendmany command. You can see an example usage of that command in this answer to a similar question.
I'm not aware of any wallets or solutions that make this easy to do via a GUI. Bitcoin Core and Samourai have easy ways to do batch spends. In Bitcoin Core, there is an [Add Recipient] button at the bottom of the "Send" tab. In Samourai, when at the "Send" screen where you would enter the destination address and amount, you can tap the three dots in the upper-right, and then tap [Batch spend].
There must be automated business solutions out there that companies such as exchanges and large merchants are using, though I'm not aware of any specific ones. Perhaps this functionality is present in BTCPay Server, but if so, I'm not familiar with it.

Will it save me lots of money versus making separate Bitcoin transactions for each customer?

That depends on the frequency at which you receive orders and the frequency at which you wish to fulfill those orders. If, say, you're receiving 10 orders per minute, then you could batch 50 orders into one transaction, allowing you to fulfill orders within 5 minutes. If you're only receiving 1 order per minute, then you could only batch 5 orders into one trasaction whilst still fulfilling orders within 5 minutes; to batch 50 transactions, you'd have to wait until you'd received 50 orders, meaning your customers would have to wait up to 50 minutes before you fulfill their particular order.
The average BTC transaction that contains one input (your funds) and two P2PKH outputs (recipient and change) is around 250 bytes. Each additional P2PKH output requires 34 bytes. In this way, assuming a transaction fee of 90 sats/byte:

50 individual transactions with 1 recipient (2 outputs) each would in total cost 1,125,000 sats ≈ 0.011 BTC (≈ 486 USD at time of writing).

1 batch transaction with 50 recipients (51 outputs) would only cost 172,440 sats ≈ 0.0017 BTC (≈ 74.50 USD at time of writing).

You can see how this becomes very economical at scale!

Having said all that, in practice this is much less of an issue nowadays because of Layer 2 networks like the Lightning Network. With Lightning, fees average no more than 20 sats per off-chain transaction, and then the resulting balance after many, many Lightning transactions will ultimately be settled on-chain by paying a single BTC transaction fee. Let's say you fund a Lightning channel, perform 50 transactions, and then settle the channel. That's:

One on-chain transaction of 250 bytes, paying 90 sats/byte, so 22,500 sats.
50 Lightning transactions at no more than 20 sats each, so no more than 1,000 sats.
Another on-chain transaction with another 22,500 sat fee.

So in total, that's 46,000 sats = 0.00046 BTC (≈ 20 USD at time of writing).
In practice, you can expect to perform many more than just 50 transactions with a single Lightning channel, further reducing the effective cost per transaction.

@Prayank — I have been using Samourai for a while now but never noticed the "Batch spend" option in the [...] menu, so thanks for that! However, I just took a look at Bitcoin Core for macOS, and Mycelium, Schildbach's Bitcoin Wallet, and Phoenix for Android in case they changed since I last used them, and it seems that they still do not support batch spending. Do you know of any other GUI wallets that do?

The Bitcoin Core GUI lets you enter multiple amounts/destinations.

@PieterWuille, d'oh! I have just now seen the [Add Recipient] button... I must be blind! Had to search "bitcoin core multiple destinations" to realise that, was searching "bitcoin core batch spend" before and not finding out anything. Thanks


text:
How do I compute the coinbase in for a stratum pool?
I searched around Google and didn't get a correct answer, some one says I should use:
hashed_coinbase_ = coinbase1 + extranonce + extranonce2 + coinbase2;

And some other pages says:
hashed_coinbase_ = coinbase1 + extranonce2 + coinbase2;

Which one is correct?

If the first one is correct, is the coinbase1, coinbase2, extranonce are all hex represent values that I received from the stratum server? for extranonce2, should I also use its hex and concat all these hex strings together, and the hash it to get the hashed_coinbase?

Seems all received hex values are big-endian, should I change them into little-endian before computing the coinbase?

Is there any existing test case (values) that I can test my algorithm to make sure everything works fine?


text:
What does the error “wallet files should not be reused across chains” mean?
I downloaded Bitcoin Core 25.0. When I try to open my wallet I get this error:

Wallet loading failed. Wallet files should not be reused across chains. Restart bitcoind with -walletcrosschain to override.

Why am I getting that error, how can I stop getting it?

As the error says, wallet files cannot be reused across chains. This means that the wallet was created with one of the testing chains such as testnet or signet, or created for an entirely different coin. Either way, as the error says, you should not be using the same wallet with different chains as it can lead to errors in the wallet state.
You should instead try to identify which chain the wallet was used with and open it with the software set to that chain or the proper altcoin software.


text:
How does the BTC protocol guarantee that a "main" blockchain emerges?
I'm reading up on the bitcoin/blockchain technology.
Usually, the part about proof of work and how to create a block is well explained.
However, what is never explained is how/why the communication of blocks over the network allows for a 'blockchain' to converge.
Let me explain:
what if two miners create a new block at the same time, and broadcast it at the same time ? Roughly 50% of the nodes would have each one a new (different) block, and build on it. Now, imagine this happens again etc. Then, there is not a single blockchain that is worked on, as now miners all work on several forks. The bitcoin proposal addresses this by saying that the longest chain must be used but:

at a given time there could be two forked chains with the same size, and growing roughly at the same pace
knowing which chain is the longest requires to "backtrack" possibly to the beginning, which means that no transaction on any chain can be "validated" as we are not sure to be on the correct chain

Are these issues addressed by the bitcoin protocol? Basically, it seems that there is no proof that adding blocks in a distributed fashion over the network converges cleanly into a single chain.

You say, "at a given time there could be 2 forked chains with the same size, and growing at roughly the same pace". But "roughly" is not "exactly" -- on average, if the chain difficulty is set well and a block takes about ten minutes to mine, two parallel chains will have about five minutes between their two next-block discoveries. That is ages in computer time -- easily enough for the longer chain to communicate itself to the whole network and have four minutes to spare.

@DanielWagner why would they necessarily be 5 minutes apart. It could be milliseconds apart, and then a 10 minute wait?

@Tim It isn't necessarily 5 minutes apart. It is five minutes apart on average, as I said.

Bitcoin nodes consider the chain with the most accumulated proof-of-work the best chain. Whenever one chain tip pulls ahead by adding another block, all nodes will reorganize to that chaintip as soon as they learn about it.
Another reason for the network to quickly converge on one best chain follows from how Bitcoin miners get paid. When miners construct their block templates, each includes a unique coinbase transaction which pays the block reward to themselves. This means that finding a valid block results in the block author paying themselves the block reward via the coinbase transaction they included. However, the outputs of coinbase transactions are subject to a maturation period of 100 confirmations. This means that only blocks that spawn at least 99 successors can be spent. This essentially means that a block reward only gets paid out when a block becomes part of the best chain. As mining operations incur large hardware and power expenses regardless of success, miners bleed money when they work on blocks that do not end up in the best chain. Therefore, even when occasionally two miners find blocks at the same time and produce two competing chaintips, even the "losing" miner usually reorganizes quickly to the best chaintip and works on extending that as soon as one pulls ahead, because the stale block that has fallen behind is highly disadvantaged in its bid to become part of the best chain.
While the individual mining efforts are not centrally coordinated, it is uncommon for two competing blocks to be found at the same height: it only happens about once per month. Bitcoin mining is a Poisson process which aims to produce about one block every ten minutes. The cadence is regulated by difficulty adjustments that occur every 2016 blocks, which reset the difficulty target such that the next 2016 blocks are expected to take 14 days under the assumption that the network continues to produce the same amount of hashrate as observed for the previous epoch.

Thanks, I think I understand. But it feels like this basically assume that there will be a 'main' branch and like 2 subchains with each 1 or 2 oustanding blocks. In this setup, indeed it's simple to identify which chain should be the "main" one by checking the longest.
My initial question was more about the (theoretical) possibility that new blocks are mined so fast in a chaotic way such that no one can really agree where the main chain is. Basically if, from the initial block, there are always 10 different next nodes mines and it keep branching out in all directions

If blocks are found very quickly, the difficulty increases until the cadence returns to about one block per ten minutes. A scenario where numerous competing chaintips are found is therefore unlikely to happen by chance and it would be very expensive for miners to bring about on purpose.

@lezebulon In general 10 minutes is substantailly longer than it takes to announce a new block, so the chaotic period is short compared to the steady state period where no new blocks are suddenly appearing.  However, in infant blockchains, there are real concerns about what happens when a malicious actor suddenly buys a lot of AWS time and makes a bunch of blocks really fast (because they had a large fraction of the total mining CPU time).  Bitcoin is large, with lots of miners so that is unlikely to happen... but theoretically possible.

It can be left to the individual bitcoin user to decide whether the risk of such a successful attack is sufficient to bring the bitcoin system into question.

Now image this happens again etc.

For the two chains to remain even, the new blocks would have to be found repeatedly at exactly the same time. It gets less and less likely that this will happen repeatedly.
The probability depends on block interval, which is regulated at 10 minutes, and how fast the new block announcements propagate on the network.
Currently bitcoin network sees stale blocks about once in 10 000 blocks. Two miners getting a block at the same time is a random and independent event, so we can calculate that having two chaintips with 2 unique blocks each would be 1 in 100 million chance. With block interval of 10 minutes this would occur on average once in 2 000 years.
Before Bitcoin Core 0.10.0 of 2015 it used to be that network propagation was slower and the stale block rate was closer to 1 in 100. But even then, getting a stale chain of 3 blocks would only occur once in 20 years. It is in miner's best interest to speed up block propagation, and as such stale blocks are a much less common occurrence.

ok I get that, thanks. What I'm more worried about in this situation is it the network itself starts to fail or incorrectly deliver blocks. It feels like, this relies on the assumption that the HTTP transport layer is properly working and that info always end up propagating fast enough

@lezebulon You can suppose a situation where the network splits completely due to some major internet traffic issue. In that case a fork is unpreventable because there is no communication between the halves.

We had a two block fork in November and it was not the first. I think once every 2000 years sounds a bit optimistic. :)


text:
What happens to your assets if Coinbase (or an equivalent site) closes down?
If a bank institution closes down, there is an amount of money insured.
What happens if Coinbase or Crypto.com which are actually just websites shuts down?

There is a saying: "Not your keys, not your bitcoin".
If you don't put your own money in your own personal non-custodial wallet and look after it yourself then you are relying on the honesty and competence of a large number of other people.
You can hope that the closed business didn't close because it lacked solvency to pay its creditors (including you) or that it had some kind of insurance that will cover your loss.
Many businesses claim to be regulated but those claims are mainly to reassure customers. The truth is that in most jurisdictions, this kind of business is far less regulated than retail banks are and they are typically not required to contribute to industry compensation schemes for customers of failed businesses.
Personally I think customers of these businesses take an overly optimistic view based on almost no supporting evidence. Many such businesses have closed and their customers have often lost all or most of their money. That's just my opinion though.
Consider the fate of customers of businesses that were industry-leading and highly regarded, such as MtGox, Quadriga-Cx and many others.


text:
How are derivation paths stored and regenerated for HD wallets?
HD wallets create derivation paths for generated keys. But if you need to regenerate these keys with your seed or master key, where do you get the derivation paths? I don't see how they can be stored in the seed somehow. Does a wallet bruteforce derivation paths to find UTXOs with balances?

I'm not a wallet developer but this is how I imagine the process of discovering funds in a seeded HD wallet works:
Start generating addresses for Account #0 and check if they appear in the blockchain history. After you see a long run of addresses with no history (say a few hundred), you can assume that's all the addresses that were used on this account. Do the above for Account #1, Account #2... until you start seeing accounts with no used addresses at all (again choose some cutoff point), then assume that's all the accounts.
If your seeded wallet supports multiple address types (Legacy, P2SH SegWit, Native SegWit), do the above for all of them.


text:
Bitnodes check on .onion addr returns 403 Forbidden
Question on inbound connections. I am running via tor proxy and getting outbound connections. Node is running in pruned mode and is up to date. I manually created hidden service via torrc config file. When checking the node via bitnodes i am seeing HTTP403 forbidden. In earlier tests I was getting unreachable so seems like some sort of progress. Tor and btc core are running in the same docker container. Any thoughts on the cause of the 403? I have no port changes in my router as I am under the impression for tor and onion i dont need to do port forwarding. Thanks.
bitcoin.conf
prune=5000
proxy=127.0.0.1:9050
torcontrol=none
onlynet=onion
maxuploadtarget=2000
listen=1
listenonion=1
bind=127.0.0.1
externalip=XXXXX.onion
debug=tor
debug=http
debug=proxy
shrinkdebugfile=1

torrc changes:
HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8334

The Bitcoin P2P protocol is not HTTP based; 403 is an HTTP error. Whatever you're seeing, I doubt it has anything to do with your node.

Thanks. I refreshed the bitnodes website and the node was reachable again. Guess I had timed out on bitnodes...ugh


text:
Securing Digital Heritage
I would like to bequeath my digital assets in a secure way. I am the sole custodian of my bitcoins. I would like to release or pass custody conditionally, like upon death. This has to happen in a secure way.
Obviously, I can pass down my wallets' seed phrases. The unclear part is how to do it conditionally, for instance upon death, at the same time as doing it securely.
Initial thoughts:

Put the information in a cloud password manager that allows for a digital heir. One example is the Emergency Contact functionality of Last Pass.
Store the information in a deposit box, in a bank.

Both of these seem to achieve the goals. Any inheritance will be passed down upon death. Also the information is kept with some security.
The Last Pass Scenario is shakier. Possibly, the Emergency contact already needs to have your master password. It's easier for Last Pass to get hacked than for bank deposit box to be broken into. Possibly, LastPass will not exist when I am dead.
Both of these options are not without cost.
Question:
What other options exist for passing down information securely and conditionally, for instance upon death? Has anyone deployed a smart contract to this end? How would this work?

No worries, your question is on-topic here. Please also check out other questions on the tag [tag:bequesting-bitcoin]. I think these might be related: https://bitcoin.stackexchange.com/q/38692/5406, https://bitcoin.stackexchange.com/q/44426/5406, https://bitcoin.stackexchange.com/q/61705/5406. OTOH, I think there has been significant innovation related to your question, so a refresher is definitely in order.


text:
Why can't a 51% attack change past blocks on the blockchain?
I have read that it is not possible to reverse transactions already added to the blockchain but I do not understand why that is not possible in a 51% attack.
If an attacker was to change the information of a past transaction, the hash of that transaction would change. This would result in a different Merkle root for that specific block. Since the attacker controls 51% of the hash rate, he would have enough computational power to find the new Merkle Root and the nonce this new block in order to produce a valid proof of work. Then the minder could broadcast the proof of work and approve it himself since he controls the majority of the network. In that way he could change the contents of a past block.
My logic above is definitely flawed somehow. Could someone please explain why a 51% attack cannot change past transactions?
Does the digital signature somehow play a role in this? If yes how?

It could! An attacker could replace a block at arbitrary depth given that they can maintain majority hashrate sufficiently long.
Every block in the Bitcoin blockchain commits to its predecessor by including the previous block's hash in the header. Therefore, each block inductively commits to all previous blocks. This prevents a block from being swapped out, because all blocks at a greater height would appear be invalid on a chaintip including the new block.
An attacker with majority hashrate would have to replace an old block and then build a competing alternative chaintip from that point until they achieve a greater total proof-of-work than the rest of the network. Since the attacker has majority hashrate per the premise, they are bound to produce more blocks than the rest of the network and will eventually pull ahead.
The difficulty in performing this attack in practice lies in the logistic challenge of acquiring hardware to achieve majority hashrate and the economic cost of maintaining the majority hashrate for such a period of time. Additionally, such an attack could potentially be rebuffed on the social layer by users coordinating to reject the attacker's chain, even then, such an attack would probably destroy the confidence of Bitcoin users in the stability of the network and would likely cause the price to tank, severely reducing the expected gains from such an attack.

Lets say the block height is currently 700000 and you computed a different version of block 699990 and broadcast it.
The old block 699991 cannot be considered a successor to the new 699990 because it references the hash of the old 699990, so the new 699990 is the top of a new fork of the blockchain.
Each node would consider the two forks, one has a block height of 699990 and the other has a block height of 700000 with ten more blocks worth of work in it, the nodes would choose the fork with 700000 blocks. Note that it isn't the length that matters but the amount of accumulated work.
So you can't just change one block, in this case you'd also have to compute successor blocks with a combined amount of work greater than the existing chain up to 700000. You'd have to do this faster then other miners are adding blocks on top of block 700000. So you'd probably have less than 10 minutes to do something that normally takes the best mining pools around 100 minutes.

If you have >51% of the hashrate for an extended period of time you can rewrite arbitrarily deep - bounded only by how long much time they can keep it up. The answer to OPs question is "yes, they can", I think.


text:
Is it possible for the `size` and `vsize` to be the same for a valid segwit (bech32) transaction?
I'm aware that for non-segwit transactions, vsize is always the same as size. But is it possible for a valid transaction to include size=vsize when involving segwit inputs/outputs?
This particular query is motivated by a need to debug an 'invalid signature' error associated with a raw transaction.

With segwit outputs, yes. Segwit outputs do not have a witness that could get discounted.
With segwit inputs, in theory possibly, but in practice no. Every standard segwit input today has a non-empty witness, and thus will get a discount.


text:
Criteria for Bitcoin protocol consolidation/freezing at the network level (full nodes)
In the Bitcoin development process, there exists the following high-level structure of control:

Anyone can submit a BIP that aims to change Bitcoin Core
The BIP must be approved by an editor
The BIP must be voted in with 95% confidence from the miners
The community must upgrade to the new software version

As a full node community member, I have always updated my node to the latest version of Bitcoin Core. A good answer would make me dispel my doubts regarding the next questions:

What should I consider or be aware of when updating to the latest software version?
What are the criteria for the Bitcoin protocol to consolidate at community/network level in comparison to TCP/IP protocol for example?
Are there any kind of changes which require additional caution from the network participants (full nodes)?

Thank you.

I think you have a sense of the general idea, but I want to first address a few misunderstandings point by point first.

Anyone can submit a BIP that aims to change Bitcoin Core

Bitcoin Improvement Proposals (BIPs) are used to provide globally relevant information or propose changes to the Bitcoin protocol. Changes to single implementations such as Bitcoin Core are made via that project's repository.

The BIP must be approved by an editor

The BIP editors only ensure that a BIP fulfills certain minimum criteria, like being viable, on-topic, and complete.

The BIP must be voted in with 95% confidence from the miners
The community must upgrade to the new software version

BIPs that propose consensus changes must define an activation mechanism. For example Taproot used the Speedy Trial activation, which included miners signaling for readiness. Miners do not vote on proposed changes, they are asked to gauge whether they perceive the network to be supportive of the change and signal readiness to enforce a consensus change. Full nodes upgrade to signal support and to enforce the consensus change once it is activated. If there is serious disagreement among developers, community, and miners  whether something should be activated, this should be sufficiently visible in the public debate, so that a Speedy Trial activation attempt would fail.

What should I consider or be aware of when updating to the latest software version?

Node operators define what they consider to be Bitcoin per the software they run. If you want to support adoption of a consensus change, you should run software that facilitates the new rules. If you disagree with a consensus change, you should run software that expresses this disagreement either passively by not supporting the change or actively by counteracting it in some manner. If it's all the same, you should probably run somewhat recent software, to get access to the latest bug fixes, features and improvements. For example, Bitcoin Core's life cycle provides maintenance for the current and previous major version, older versions receive critical security fixes a bit longer, but are considered end-of-life shortly after that. Other projects have their own modus operandi.

What are the criteria for the Bitcoin protocol to consolidate at community/network level in comparison to TCP/IP protocol for example?

TCP/IP is maintained by the IETF, an open standards organization. From what I understand the IETF standards track's RFCs  inspired the BIP process. I assume that slight divergence in adoption of protocol changes in TCP/IP would mostly cause participants to downgrade to shared mechanisms for compatibility. On Bitcoin however, consensus changes must be broadly adopted by the network to come into effect, so there is an emergent property to the process on the network level. If e.g. users run node software enforcing rules conflicting with rules enforced by other nodes, it may cause the network to split for good which can lead to the spin-off of a fork-coin.

Are there any kind of changes which require additional caution from the network participants (full nodes)?

Unless a new version introduces consensus changes, not usually. If you're a power user, you should glance at the release notes to see if there were any changes to RPCs you use. If any existing features get removed, this usually happens in steps over multiple major releases.


text:
What is the format of the coinbase transaction?
I'm trying to understand the format of the coinbase transaction. I've read that it is arbitrary and not specified. I'm wondering because I need to generate mining work and create an internal pool. As I've found out, you can change the ntime, nonce and extranonce fields. The last one should be suited in the coinbase parameter, right? So, can anyone help me analyze the content of the coinbase transaction and how am I supposed to build one, so all miners in my pool could have different headers for hashing? A step-by-step guide on an existing block would be much appreciated, links and other stuff too.

A coinbase transaction follows the same format as a normal transaction, except:

It has exactly one txin
This txin's prevout hash is 0000...0000.
This txin's prevout index is 0xFFFFFFFF
The txin's prevout script is an arbitrary byte array (it doesn't have to be a valid script, though this is commonly done anyway) of 2 to 100 bytes. It has to start with a correct push of the block height (see BIP34).
The sum of the txout's values cannot exceed the subsidy (25 BTC for now, halves every 210000 blocks) plus the fees of the non-coinbase transactions in the same block.

About the scriptSig being an arbitrary byte array, there is one caveat: the checksig operations in it are counted towards the block sigop limit (20000), so you probably don't want to accidentally trigger this. Making it a list of just push operations (including of the extranonce) avoids that.

Look at block #280963. Look at coinbase transaction d1c6b8...fd08. You can see CoinBase data:
038349040d00456c69676975730052d8f72ffabe6d6dd991088decd13e658bbecc0b2b4c87306f637828917838c02a5d95d0e1bdff9b0400000000000000002f73733331312f00906b570400000000e4050000

This is a script. Look at wiki for details. In coinbase transaction this script can contain any data. If you change this data, merkle root will change as well, and diffirent miners can start changing nonce/timestamp for merlke root, that you provides for them. Look at wiki for more information about merkle tree.
Coinbase transaction contains single input. This is input is not used, and it contains 32 bytes zeros as previous tx. Look at wiki for more information about what data transaction contains. I provide as example of decoding raw coinbase transaction.
> getrawtransaction d1c6b8140246950475735394b0ac68f9ada60d313d2b5308afbc569c84f7fd08
< 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff53038349040d00456c69676975730052d8f72ffabe6d6dd991088decd13e658bbecc0b2b4c87306f637828917838c02a5d95d0e1bdff9b0400000000000000002f73733331312f00906b570400000000e4050000ffffffff01bf208795000000001976a9145399c3093d31e4b0af4be1215d59b857b861ad5d88ac00000000

01000000 - version
01 - input count
0000000000000000000000000000000000000000000000000000000000000000 - prev tx
ffffffff - prev out n
53 - length of coinbase script
038349040d00456c69676975730052d8f72ffabe6d6dd991088decd13e658bbecc0b2b4c87306f637828917838c02a5d95d0e1bdff9b0400000000000000002f73733331312f00906b570400000000e4050000 - coinbase script
ffffffff - sequence
01 - output count
bf20879500000000 - 2508660927, satoshi count, or 25.08660927 BTC
19 - script length
76a9145399c3093d31e4b0af4be1215d59b857b861ad5d88ac - script
00000000 - locktime


text:
Is there any relation between the block version field and the one of the transaction?
I am struggling to validate my custom miner against the testnet network and I can't seem to add a block of mine to the chain. I've noticed that all the other miners are appending version 2 blocks, so I decided to do the same. As I've read the block height should be included in the coinbase transaction script. So my question is if there is any relation between block version and transaction version because that's the only thing (in my opinion), that I could be doing wrong. I would appreciate an example of how should my block look like as byte array so it would be accepted by the network (testnet).

Have you seen the Bitcoin Protocol Specifications?

I would send your solved block to a core node of your own and then check the debug.log file to see why it wasn't accepted.
But, no, in general there is no necessary relationship between the version of the block and the version of transactions. Version numbers just give a signal to other nodes if there is any special way to handle new blocks/transactions.
As per BIP34, version 2 blocks now have the block height put into the scriptSig of the coinbase input so that no one can make a transaction with a duplicate transaction id (hash).


text:
How do pre-segwit clients evaluate segwit spends true?
Quoting Bitcoin wiki:

A transaction is valid if nothing in the combined script triggers
failure and the top stack item is true (non-zero).

However, P2WPKH and P2WSH scriptPubkeys are two data pushes of witness versions and witness programs with empty scriptsigs spending them. From a pre-segwit client perspective, stack is ending with data pushes which are non-true? If so how do legacy clients evaluate segwit spends true?

In the Bitcoin scripting system, anything that is not explicitly OP_FALSE (0) is implicitly true. Because the top stack elements is not 0, it will be evaluated as true.

"The top stack item true" is just a relay policy then?

No, it is a consensus rule.


text:
How are fees specified in a TX?
I know that the way miners claim their fees are by factoring them in the BTC amount specified in the coinbase, which the protocol forces the max selectable value to be the current block reward + the total fees included from TXs in the block.
But how do people themselves specify what amount of the BTC should be spent on fees in their transactions? Is there a special output area that says to pay it to the miner, or how is it structured?
My question is, in literal concept, how are the fees chosen in a TX when constructing a tx manually.

The miners fee is sum of inputs minus sum of outputs.
When you construct a transaction you make sure there is a difference between those two sums

Here's a made up example, I want to buy a cup of coffee and I only have the Bitcoin equivalent of a million dollar bill (banknote) in my trouser pocket.
Transaction:

Inputs
Outputs

60.00000
(to coffee shop)         0.00018

(change returned to me)  59.99981

Sums:

Inputs
Outputs
Difference

60.00000
59.99999
(fee for miner to collect) 0.00001

”The miners fee is sum of inputs minus sum of outputs. When you construct a transaction you make sure there is a difference between those two sums“ ⇒ So what happens if the sender only has really large inputs? Is the miner to assume they are allowed to take a large fee from their transactions if they make small transactions with big inputs? How is something like fee-per-byte determined if you might not have the right input to limit your input-output difference? Is there a limit on how big of a fee can be taken?

You would create a change output back to your wallet - just like in real life. This is very common and done automatically by your wallet software. You might want to take a closer look at the bitcoin transaction model and the concept of UTXO (unspent transaction outputs).

@Poseidon: Check out https://bitcoin.stackexchange.com/q/736/5406

I added an example to clarify


text:
Why does bitcoin limit the difficulty adjustment to a factor of four?
from here: https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp
 // Limit adjustment step
 int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;
 if (nActualTimespan < params.nPowTargetTimespan/4)
     nActualTimespan = params.nPowTargetTimespan/4;
 if (nActualTimespan > params.nPowTargetTimespan*4)
     nActualTimespan = params.nPowTargetTimespan*4;

I know that the code used to control the network difficulty adjustment limits it to at least one quarter of the target and at most four times the target. But why was the factor 4 chosen? Why not 2, or 3, or 5?

At least some of these important constants were either chosen arbitrarily or for reasons that have not been disclosed by the people who chose them. See Why 21 million and duplicate for examples. Any answer here may therefore be speculation rather than historically factual.

I'm voting to keep this open. It may be technically opinion based, assuming there is no rationale known by Satoshi about the choice of this constants, but there are still potentially useful technical answers about what downsides/upsides other constants could have.


text:
Is it better to have multiple connections with stratum protocol or a single one for the entire proxy to the pool?
I'm currently trying to code my own BTC proxy mining pool that need to handle at least 20k workers but I'm still in need of information to build it correctly.
My main inquiry is about the TCP connection between my proxy pool and the pool.
Should I need to open a connection between the proxy and the pool for each worker or should I create a single connection for all worker in my proxy?
I think the best option in my case is the second one (open 20k connections with the same ip may result as ban?) but it implies more work to do and understanding.
In that case how should I manage the high difficulty of the pool and the vardiff?
Thanks you for you answer and don't hesitate to share me all interesting links you have about it!

Holding one connection per worker is highly inefficient and will cause a lot of traffic going through your network. The preferred way to do this is to condense all your work behind some proxy. You don't need to have only one proxy. Multiple proxies with dozens or hundreds of devices per proxy is fine too.
As for the diff, the proxy may set a high enough diff that you'll generate a few shares per minute in all machines, to reduce network traffic.

Like if I have 1000 workers, I make 10 proxies with 100 workers each ?
And these 10 proxies with one connection for each worker to the pool or only one for the proxy (100 workers) ?
If single connection for one proxy how do I share the job to the workers ? Do I give each worker the job gived by the pool or I create sub job of my own ?
Thanks you for your time I really apreciate it

Like if I have 1000 workers, I make 10 proxies with 100 workers each ? exactly. Ideally, you'd give different jobs to each worker. One way you can do that by assigning different extra-nonce spaces to each work. So you get a job from the pool with e.g. 32-bit extra-nonce space and you break that down into multiple, per proxy spaces.

Thanks you for your precious advices, are you available somewhere I can contact you to go deeper in technical things? (@ByFishh on twitter)


text:
How does one interpret mempool.space’s address view?
What does the total received, total send and balance represent in mempool.space below the address? It says they received a larger amount than sent leaving a balance

TL;DR: They include debits and credits from historical transactions in the blockchain, not just unconfirmed mempool transactions.

The "Total Received" includes not only the amount received in unconfirmed transactions in the mempool but also historical amounts previously received in past transactions that are already confirmed and therefore no longer in the mempool but in the blockchain.
The "Total Sent" also includes amounts in confirmed transactions that spent (consumed as inputs) amounts that had been associated with this address.
The balance is the difference between the two. All amounts ever received at that address minus all amounts ever spent from that address.


text:
Does the probability of false positives with BIP157-8 depend on the number of TXs in the block?
If a block has much fewer transactions than average, let’s say 63 like 4MB block 774628, will keys have less probability to falsely match against its BIP157-8 compact filter?

No, BIP158 basic filters have a fixed false positive rate of exactly 1/784931, regardless of how many elements they contain.

Just ftr. The 1/784931 fpr is for bitcoin core and compatible. Wasabi filter's parameters are different because Wasabi wallets are expected to have more keys than average bitcoin core wallets given coinjoins and remixes.

Wasabi doesn't use BIP158 filters.

@PieterWuille Wasabi does use BIP158 filters AFAIU.
https://docs.wasabiwallet.io/FAQ/FAQ-UseWasabi.html#what-are-bip-158-block-filters
https://docs.wasabiwallet.io/using-wasabi/BIPs.html

Well BIP158 specifies the parameters for the filter, including the 1/784931 false positive rate. It's possible it uses a (very) similar design, but IIRC at least the filter contents is different, and the parameters are different.

Thank you for clarifying this.


text:
Do miners have an incentive to confirm various transactions from same address?
Mempool is really clogged those days. I tried to make a transaction from one of my address to a friend. As we didn't care about confirmation time, I put a 5 sats/bit fee.
2 weeks later, transaction still wasn't confirmed. But, from same address, I had to send another transaction of all remaining funds on the address. I was in a hurry so I put next-block estimate fee.
My second transaction has been confirmed as planned in next block but, interestingly, my first transaction was also confirmed in that block, even if mempool was still clogged.
I want to understand what was the incentive for the miner to confirm my first transaction, and if I can use this mecanism.  For example, if I have to send 2 transactions with confirmation in next block, can I be confident to put high fees in only one of them?

It sounds like you have rediscovered a mechanism called child pays for parent.
Generally, no, two independent transactions could get included in any order even when they were sent from the same wallet or involve the same address.  There is no efficiency benefit to reusing addresses, in fact it has significant downsides especially for privacy.—Miners will simply pick the transactions that maximize the transaction fees collected by their block. In effect, transactions with higher fee rates get prioritized.
However, I don't think the transactions were independent in this case! Usually, when you make a payment from a wallet, the wallet will not have exactly the amount you're trying to pay available in a distinct UTXO. In that case, when you send the payment, the inputs make up more funds than the payment amount and your wallet creates an additional change output to assign the remaining funds to itself. When your second transaction spent the wallet's complete balance, it would have also spent the first transaction's change output. I'm confident that this is how the two transactions became dependent.
When one transaction pays another transaction's output, they can only appear in topological order in the blockchain. Obviously, funds that don't exist cannot be spent. So, when a transaction spends the output of an unconfirmed parent transaction, the child is invalid unless the parent precedes it.
Now, you say that your second transaction paid a large transaction fee. This incentivized the miners to include the child transaction, but to be able to include the child, they first had to include the lower feerate parent. It turns out that the fee bid by the child was sufficient to make the whole transaction chain attractive for inclusion: the child paid for the parent.

Ohh ok I see! So miner wanted to collect fee of my second transaction, but to do so UTXO of first one had to be used, so first transaction had to be confirmed, so miner calculated that it was worth it to confirm both. Thanks a lot for detailed and clear answer

Yep, you got it. :)

Hey @Murch, I’m not sure I follow here. It seems like what you are describing in the $child pays for parents$ scenario is when one address is associated with two transactions, one in which it is receiving funds, and one in which it is sending funds. It seems like what OP is saying is their address is associated to two transactions, both in which they are sending funds. Is OP’s scenario an example of $child pays for parent$?

@PrinceM Scenario is further described here. I was exactly in this configuration. The key thing is that I sent in 2nd transaction UTXO from first one. Miners saw my second transac, but saw it needed first one's UTXO (I guess you can see an UTXO as what you are calling a "receiving transaction"),and computed that fee paid by first + second transac was worth the blockspace of both.

@PrinceM: I extended my answer to better explain how I got from Turbolay's description to diagnose child pays for parent.

Got it! The change was needed. Thanks @Murch


text:
When do miners add a new block to blockchain?
I'm a bit new to blockchain and I am trying to understand.
As I understand when a new transaction happens it's added to a mining pool and miners prioritize these transactions (for example by amount of fee) and select some transactions to add them to block (max 1MB).
But it's also possible for some block to be empty (without transactions).
So, if some blocks are empty, does this mean that new block creation starts at certain times? (Does it have some schedule like every 5 min or something like that?)
Or does something trigger miners to create a new block?

There hasn't been a 1MB block size limit for many years now. Since Segwit activated blocks have been bigger on average.

The flow of a transaction is like this:

Users create and submit transactions
Nodes gossip the transaction in the network, validating them, adding them to their mempools and forwarding them
Miners select transactions from their mempools to build block templates
A new block is found that includes the submitted transaction and the transaction is confirmed

Miners mine continuously—each of them is always trying to find a new block. A block is found when a block header hashes to something that is lower than the difficulty target. There is no way to know whether a block header candidate is a valid block until it is hashed. Since every miner is trying to pay themselves the mining reward, they all have unique block templates (as their transactions don't match, the Merkle root of the transactions differs). This means that every miner is searching previously unseen block candidates and finding a new block essentially comes down to an independent random event with a minuscule chance for every block template. Sometimes it only takes seconds for a new block to be found, and sometimes it takes more than an hour. The difficulty retargets automatically to keep the expected block interval to about 10 minutes.
Miners continuously update their block templates whenever they hear about new transactions. As you said, they pick the transactions with the highest feerates, to build the block template that will collect the most fees.
When miners hear about new blocks, they briefly use an empty block template that doesn't include any transactions. The miners do this to avoid including a transaction that the previous block already included which would make their new block be in conflict and invalid. As soon as the miners have processed the previous block, they build a new block template with transactions again and use that. So, we usually only see empty blocks if a new block is found seconds after a previous block, or if there are actually no transactions waiting to be confirmed.

Nice answer which changed my perspective :) But just a small question for clarification. U said, "miners do this to avoid including a transaction that the previous block already included which would make their new block be in conflict and invalid."
But why there are instead of just stopping the creation process and look new transactions there are creating new empty blocks? (For earn award?)

And U said "or if there are actually no transactions waiting to be confirmed". if there are see new transactions not exist why instead of stoping there are creating an empty block? So let's say if in some blockchain not any transaction exist mining process will continue?

The reward for mining a block is composed of two parts: the transaction fees, and an amount of new bitcoins to be created. The miners can still collect the new coins even if they do not include any transactions. Since the transaction fees are only a small part of the block reward right now, mining empty blocks is still very profitable.

The miners don't know if they only saw a transaction after it was included in the previous block, therefore it just being new to them is insufficient for putting it in their block template. They have to finish processing the previous block to know which transactions can be safely included.