Understanding the importance of hashing blocks

[ibba3]

Hello everyone.

A few weeks ago, I became interested in BitCoin and how it works.
There are many videos and articles on the internet but none of them seem to explain the following problem

My understanding so far is that all miners have a copy of the "public ledger" in which all transactions are recorded. New transactions are stored in groups called blocks. New blocks are added by
whichever miner is able to come up with the correct hash for the block.

However,

Say there are two Miners called A and B:

A gets copies of all the transactions made up to now and therefore has a "correct" version of the 'public ledger'.
B on the other hand, due to faulty networks or whatnot does not receive a few transactions. Therefore, B's version of the public ledger is incomplete or wrong.

Now, A and B both begin trying to compute hashes. What would happen if B comes up with a correct hash before A? Wouldn't B's *incorrect* version of the ledger then get added to the block chain, throwing everything out of whack from the on?

Thanks.

[1713253204]

1713253204

[1713253204]

1713253204

[achow101]

The blockchain is the public ledger. The miners who finds the next block for the blockchain is the one who establishes what is going into that ledger.

Miners can choose whatever transactions that they want to include in their block. So long as the block is valid, it will be accepted by everyone else.

There can be multiple valid blocks for a given block height. This happens fairly often. The blocks which are not built upon are called stale blocks.

[ibba3]

The blockchain is the public ledger. The miners who finds the next block for the blockchain is the one who establishes what is going into that ledger.

Miners can choose whatever transactions that they want to include in their block. So long as the block is valid, it will be accepted by everyone else.

There can be multiple valid blocks for a given block height. This happens fairly often. The blocks which are not built upon are called stale blocks.

but what happens to the transactions which aren't included in the last block? (or ones that the miner choses not to include? )

[morantis]

The blockchain is the public ledger. The miners who finds the next block for the blockchain is the one who establishes what is going into that ledger.

Miners can choose whatever transactions that they want to include in their block. So long as the block is valid, it will be accepted by everyone else.

There can be multiple valid blocks for a given block height. This happens fairly often. The blocks which are not built upon are called stale blocks.

but what happens to the transactions which aren't included in the last block? (or ones that the miner choses not to include? )

if i understand you correctly, they would be in the next block.  if it is a fee issue that kept the block out, then it could get ignored for some time.  but keep in mind that there are thousands of tx's every second and if one just "missed" the current block, it will be in the next one, provided that it is a normal and good tx.

[achow101]

but what happens to the transactions which aren't included in the last block? (or ones that the miner choses not to include? )

Before a transaction is included in a block, the transaction is stored in the memory of nodes (including the miner's node) in a place known as the mempool. When a miner goes to choose transactions for a block, he will select transactions from his own mempool. Once the block is broadcast, nodes will then remove the transactions in those blocks from their own mempools.

Transactions in the mempool are unconfirmed. They are not permanent. They are not in the blockchain. Not every node will necessarily know about all of the unconfirmed transactions, nor do they have to.

When a transaction is broadcast, it first goes to the mempools of the nodes. If it remains unconfirmed for a long time, some nodes may choose to drop the transaction from their mempool to free up some memory. Other nodes may choose to rebroadcast the transaction so that it remains in the mempools of as many nodes as possible (i.e. those nodes are reminded of the transaction if they dropped it). Other nodes may simply keep it there until it confirms or the node reboots and the mempool is cleared.

[morantis]

but what happens to the transactions which aren't included in the last block? (or ones that the miner choses not to include? )

Before a transaction is included in a block, the transaction is stored in the memory of nodes (including the miner's node) in a place known as the mempool. When a miner goes to choose transactions for a block, he will select transactions from his own mempool. Once the block is broadcast, nodes will then remove the transactions in those blocks from their own mempools.

Transactions in the mempool are unconfirmed. They are not permanent. They are not in the blockchain. Not every node will necessarily know about all of the unconfirmed transactions, nor do they have to.

When a transaction is broadcast, it first goes to the mempools of the nodes. If it remains unconfirmed for a long time, some nodes may choose to drop the transaction from their mempool to free up some memory. Other nodes may choose to rebroadcast the transaction so that it remains in the mempools of as many nodes as possible (i.e. those nodes are reminded of the transaction if they dropped it). Other nodes may simply keep it there until it confirms or the node reboots and the mempool is cleared.

i believe that the bigger exchanges keep a full node in the background of their server in generate mode to help facilitate their sites own transaction moving into the chain more smoothly, is this correct?

[ranochigo]

but what happens to the transactions which aren't included in the last block? (or ones that the miner choses not to include? )

Before a transaction is included in a block, the transaction is stored in the memory of nodes (including the miner's node) in a place known as the mempool. When a miner goes to choose transactions for a block, he will select transactions from his own mempool. Once the block is broadcast, nodes will then remove the transactions in those blocks from their own mempools.

Transactions in the mempool are unconfirmed. They are not permanent. They are not in the blockchain. Not every node will necessarily know about all of the unconfirmed transactions, nor do they have to.

When a transaction is broadcast, it first goes to the mempools of the nodes. If it remains unconfirmed for a long time, some nodes may choose to drop the transaction from their mempool to free up some memory. Other nodes may choose to rebroadcast the transaction so that it remains in the mempools of as many nodes as possible (i.e. those nodes are reminded of the transaction if they dropped it). Other nodes may simply keep it there until it confirms or the node reboots and the mempool is cleared.

i believe that the bigger exchanges keep a full node in the background of their server in generate mode to help facilitate their sites own transaction moving into the chain more smoothly, is this correct?

If the exchange also operates a mining pool, they can specify which transactions they want to give a priority to. This would help to accelerate the withdrawal/deposit confirmations. This would only work if they have a reasonable hashrate and can generate blocks in a good frequency. Otherwise, it would be useless.

[ibba3]

but what happens to the transactions which aren't included in the last block? (or ones that the miner choses not to include? )

Before a transaction is included in a block, the transaction is stored in the memory of nodes (including the miner's node) in a place known as the mempool. When a miner goes to choose transactions for a block, he will select transactions from his own mempool. Once the block is broadcast, nodes will then remove the transactions in those blocks from their own mempools.

Transactions in the mempool are unconfirmed. They are not permanent. They are not in the blockchain. Not every node will necessarily know about all of the unconfirmed transactions, nor do they have to.

When a transaction is broadcast, it first goes to the mempools of the nodes. If it remains unconfirmed for a long time, some nodes may choose to drop the transaction from their mempool to free up some memory. Other nodes may choose to rebroadcast the transaction so that it remains in the mempools of as many nodes as possible (i.e. those nodes are reminded of the transaction if they dropped it). Other nodes may simply keep it there until it confirms or the node reboots and the mempool is cleared.

But if a miner can just pick and chose which transactions to include in a block, how does the whole thing stay sound in terms of accounting?
What if two transactions depend on each other and one is left out of the block? The other can't be included either

[ranochigo]

But if a miner can just pick and chose which transactions to include in a block, how does the whole thing stay sound in terms of accounting?
What if two transactions depend on each other and one is left out of the block? The other can't be included either

Exactly, thats why the miner has a huge power in terms of including the transactions.

In the protocol, the prior transaction must exist in the blockchain, ie. be included in a block in the valid blockchain. Both transactions can be included in the same block however.

[achow101]

But if a miner can just pick and chose which transactions to include in a block, how does the whole thing stay sound in terms of accounting?
What if two transactions depend on each other and one is left out of the block? The other can't be included either

Two transactions cannot depend on each other. Dependence only works in one direction. There cannot be a circular dependence because such transactions cannot exist. This is because the transaction ids of the outputs being spent from are referenced in the input of the transaction. However the txids cannot be known until after a transaction has been created, but if that transaction also depends on another transaction which depends on it, the txid cannot be known as the transaction cannot be created.

[DannyHamilton]

But if a miner can just pick and chose which transactions to include in a block, how does the whole thing stay sound in terms of accounting?

It stays sound because transactions are not "confirmed" until they are in a block.  Once they are in a block it is very unlikely that the block will be replaced. This is why the hashing is so important. It makes it very difficult for anyone to replace the block. Once there are a few more blocks on top of that block, it becomes practically impossible for that block to be replaced. This is because someone would have to hash more blocks than are on top of the block that confirms the transaction, and they'd have to do it before the legitimate global network of miners solve one more block.  They are effectively stuck chasing the legitimate blockchain, and unless they have more hash power than the entire world combined, they will never catch up.

What if two transactions depend on each other and one is left out of the block? The other can't be included either

As achow101 explained, it is impossible for two transactions to BOTH depend on EACH OTHER.  It is however possible for one transaction to depend on another.

So, for example:

I send you some bitcoins, and then you send those bitcoins to someone else before my transaction has confirmed.

If my transaction is never included in a block, then your transaction can never be included in a block.  Of course, all you have to do to avoid this problem is wait for my transaction to be confirmed.  Once it is confirmed, it is in a block.  Then you can go ahead and spend the bitcoins with confidence that my transaction to you won't vanish.

[ibba3]

Apologies about the phrase "depend on each other".. what I meant was one trasaction depending on another. (One-way).

"i will not stake anything on it, but i would assume that most miners, right out of the box are pretty lenient with allowed tx's and that it takes some tinkering in the settings to get a real biased approach to included transactions, most likely all miners in default state will ignore a zero fee, but the variable is likely only a little above that by default, i will check a couple of them."

I don't understand how that part factors in.

[achow101]

Apologies about the phrase "depend on each other".. what I meant was one trasaction depending on another. (One-way).

So in that case, the order of the transactions is already established, and that is the order in which the transactions must be confirmed. The transaction that depends on another must confirm at the same time or after the transaction that it is spending from.

"i will not stake anything on it, but i would assume that most miners, right out of the box are pretty lenient with allowed tx's and that it takes some tinkering in the settings to get a real biased approach to included transactions, most likely all miners in default state will ignore a zero fee, but the variable is likely only a little above that by default, i will check a couple of them."

I don't understand how that part factors in.

It doesn't. His post seems to just be a post to increase his post count for his signature campaign.

[freemanjackal]

i have asked this question before but i am still have some doubts. how block chain technology can be used for a lot of aplications that has this tech as basis? I have understood that blockchain works a like a database where you can store and retrieve information, is this right? if it is so, is this the same blockchain of bitoins? shouldn't blockchain used for bitcoin just have information related to txs and the blocks containing it??
or the blockchain(not the one used for tbc) tech used with some other info?

[ibba3]

Blockchain is just a method of storing data, as far as I understand. Much like something you would find in a book on "algorithms and data structures". So for differenty applications, you will have different blockchains.
I think you might be better of starting your own thread, though.

Apologies about the phrase "depend on each other".. what I meant was one trasaction depending on another. (One-way).

So in that case, the order of the transactions is already established, and that is the order in which the transactions must be confirmed. The transaction that depends on another must confirm at the same time or after the transaction that it is spending from.

It doesn't. His post seems to just be a post to increase his post count for his signature campaign.
[/quote]

So the second transaction will not get approved until the first one is already in the block chain? That would mean that I would have to wait 10 minutes before I can spend bitCoins that someone sends me, no?

[achow101]

So the second transaction will not get approved until the first one is already in the block chain? That would mean that I would have to wait 10 minutes before I can spend bitCoins that someone sends me, no?

Yes. You can spend from an unconfirmed transaction, just most wallets will not allow you to do so. You should only do that if you absolutely trust that the transaction you are spending from will be confirmed. Your transaction cannot be confirmed before the one it spends from.