Topic: I didn't get something (Read 281 times)

They do not.

Every block must have exactly one coinbase transaction, and that coinbase transaction must be the first transaction in the block. The coinbase transaction may collect the block subsidy and the block fees, or any portion thereof, but it doesn't have to. The coinbase transaction must also contain the block height as the first entry in its scriptsig (4 bytes) with a further 96 bytes of arbitrary data, which is how pools tag blocks as being found by them.

It's supposed to be, but it isn't, because the miner clearly messed up. If you pull the hex script from that output, you'll get the following:

The start of that - 52534b424c4f434b - decodes to RSKBLOCK. If you look at any other recent block which has an RSKBLOCK OP_RETURN output, you'll see the same string in its coinbase transaction. However, in this case, the miner has neglected to include the necessary OP_RETURN bytes at the start of the script (0x6a29).

Great ! Thank you everyone. Everything is "clear" now 

I can't find other examples, I thought they exist.

Blockchair makes it look like an OP_RETURN transaction.

I doubt we can have a block without any transaction.
Take a look at the block number 501726. The miner hasn't claimed the block reward, but the block still includes 1 transaction.

No it doesn't. Some miners have forgotten to claim their block reward, that's possible.

Your transaction will be included in the next block if you pay enough fee for that.
As each block has a size limit and can't include any number of transactions, miners prioritize transactions based on their fee rate.

As I said in my previous post, each of miners has a candidate block. Miners can add new transactions or remove the exisiting transactions from the candidate block when they are trying to solve the block. So, whenever you broadcast your transaction, it can be included in the next block, assuming the fee rate you set for it is high enough.

Each block must contain at least one transaction. The first transaction in the block is called a coinbase transaction. It is a unique type of transaction that contains a block reward for the miners.


As I understand it, the moment one block is mined (confirmed and included in the blockchain) all miners start searching for the hash of the next block. So yes, you could say that they are adding new transactions to the block they are currently "working" on.

But I think it is wrong to imagine that miners solve some kind of complex operations on the block (calculating the hash is actually a simple process, and you can even calculate it manually), but they actually compete with each other to find a hash that meets specific conditions (the one that is under the current target). So it makes sense for them to start calculating the hash of the next block as soon as possible because it gives them a better chance of finding it first.

No.

Nothing. We wait.

No.

It's basically a Poisson distribution: there's no minimum, and there's no maximum. The average is 10 minutes by design, although it has been less than 10 minutes (on average) because of the (more or less) continuous increase in mining power.

@mocacinno, you said: "sometimes it can take an hour before a valid block is found". Is one hour the maximum time between two blocks? What happens if no miner finds a valid hash in that time? If not, is there a maximum time that can elapse between two confirmed blocks?

A block may or may not contain users' transactions. But even if miners choose to not add users' transactions they will normally still include the transaction that pays them ( = to the miners) the block reward (called the coinbase tx). And since 2 miners will most probably have different addresses to send to that money, the headers will be never identical.

From what I understand, they can only include the transactions they know about while mining the transaction. But I also assume mining pools continuously look for more profit, so they continuously adjust which transactions are included in the block they're mining.

I didn't understand this...

You unlocked something in my head.

Still something I don't understand. If I send a bitcoin now. The transaction will be accepted in the next block because the miners are already working on the block at the moment, right ? Or can they add unconfirmed transactions while they are solving the block ?

More or less... It's actually your transaction going into the mempool of each node that choses to accept it (some nodes might reject transactions that have, for example, a low feerate). Each miner (or mining pool) has one or more nodes in the network, and they have access to the unconfirmed transactions in the mempool of their own nodes.


1) that's incorrect. All miners in the world can try to solve a block containing exactly the same transaction. Miners don't have to communicate with eachother. You can run a node at home and setup a solo mining operation without telling anybody. You'd be getting the header of the latest valid block straight from your node, and you'd get the transactions from the mempool of your own node. If you'd ever solve a block, you'd just broadcast said block to the peers you are connected to and nobody would ever know you were the miner that solved the block in the first place.

2) well, they're all trying to find a header whose sha256d hash is under the current target. The thing is: if 2 miners would pick 100% exactly the same set of unconfirmed transactions, they'd still have to add the coinbase transaction which is paying the miners themselves to the merkle tree (which ends up in the header of the candidate block). And since 2 different miners won't fund the same address with the coinbase transaction, the headers those 2 miners are working on will never be 100% identical.
EDIT: on a sidenote to question2 => miners are not looking for "the" hash... There's looking for "a" hash that's under the current target... There are billions of valid hashes that are under a certain target. The thing is: eventough there are billions of valid hashes, it's still extremely hard to find one of those hashes since the number of possible hashes is waaaaaaaaaaaaaay bigger.
It's like filling a big swimmingpool with blue marbles and adding 100 red ones, then dive in wearing a blindfold and picking a single marble: eventough there are100 red ones, the odds of picking one is slim to none since there's are several million blue marbles in there.

I think I begin to understand

So, when I send a bitcoin to somebody, the transaction goes to the mempool. The mempool is like a big pool where the transactions wait to be picked up. All the miners have access to the mempool to choose the transactions they want to put in their block.

1) When a miner pick up a transaction in the mempool, the others miners can't take it ?
2) If all the miners can choose what they put in the block, they are all searching for a different hash to solve the block, right ? I'm saying this because with this simulator (https://blockchaindemo.io/) The "Data" input represent the different transactions in it, no ?

It may worth adding that sometimes the mempool just doesn't have enough transactions to fill an entire block, hence no matter the block is not full and the miners would want to add more, they can't; the block will not wait for new transactions to come.


Again, I'll add that it depends on fee rate vs how full the mempool is.
Plus, the fee cannot really be under the default minimum of 1 sat/vByte (but long ago in the past even 0 satoshi was sometimes OK as transaction fee).

Just to be more accurate:
If you use the same or higher fee rate for the second transaction, both transactions will be probably confirmed in the same block.

No. You can use your unconfirmed outputs for a new transaction. If you use the same fee rate, they'll probably confirm in the same block.
It is however cheaper (in terms of transaction fee) to make one transaction with multiple outputs.

A small, simplified explanation:

You create a new transaction and broadcast it over the network. Miners have nodes running on said network. Each miner can have or multiple nodes, and i don't think two seperate solo miners (or pools) share a node (at least, this isn't something that i have ever seen... theoretically they can.. but they're competing against eachother, so it wouldn't make any sense).
The miner (and the other nodes for that matter) receive the transaction you broadcasted and they store it in their mempool.

The mempool of the nodes is filled with unconfirmed transactions, but each node can have it's own rule as to how many transactions it keeps in its mempool, for how low, the minimum fee to accept a transaction in it's mempool,... So the mempool of most nodes will differ.


When a miner starts mining, he takes the sha256d  hash of the header of the last block known to him/her, he creates a merkle tree of transactions it picked from it's mempool and adds a nonce (basically, a piece of random data) and some other data that isn't important for this explanation. The combination of this data is the header of the new block the miner is trying to solve. Then he creates a sha256d hash of this new header and sees if it's under the current target. If this is the case, the block he created is valid. If not, he increments the nonce and tries again.

What is important is that each miner is working independantly. He has his own node and his own set of transactions in the mempool. When generating a block, he can add a maximum of 1Mb of transaction data (not including the signatures), so odds are the transactions picked by 2 miners at a certain point in time differ.

Every 2016 blocks, a new difficulty is set in such a way that the average time between 2 blocks is ~10 minutes. But since hashing outcome cannot be predicted, sometimes it can take an hour before a valid block is found, and sometimes it takes mere seconds.
Some pools start mining with an "empty" block, only containing the coinbase reward whilst they are still creating a transaction set witch gives them the most income (due to the transaction fees) whilst still fitting in 1Mb (excluding signatures). That's why you sometimes see empty blocks... Other times blocks aren't full because the miner just doesn't have enough unconfirmed transactions in the mempool of his node.

All miners are trying to solve the blocks at the same time and each of them can have their own candidate block.
Once you make a transaction, it goes to mempool of the nodes. Miners can pick any of the transactions they want from the mempool and put them in their candidate block. There is nothing forcing them to include or not include a certain transaction.

Thank you !


They are all working together, right ? So they all choose the number of transactions in the next block, and then they ALL work to find the hash ?