Topic: Bitcoin Consensus. Posibility that a transaction will never be validated? (Read 231 times)

can be - probably yeah, should (or even must) be - a solid nope. It's better to revive the original meaning of concepts, otherwise it will be hard to cope with topic. I prefer to distinguish between the networking "consensus" and the rules for Bitcoin. There are plenty of serious research papers on that, and Google is the best hand in this case.

Nope, that article in the wiki  you refer to is misleading in some way as network  consensus  (defined by Satoshi and referenced in my above post) differs from rules of Bitcoin  as to the transaction validation. Those rules to validate transaction are the the set of rules to ensure that transactions in the block follow  correct protocol to build them (all scripts are valid and so on) and the record of those transaction included into the block is correct.

the rules you refer to (following the chain with the most proof of work) can be categorized under the same category of consensus rules. as i said they include block and transaction validation. there are more rules under block verification that include verifying the proof of work of that block, finding chain splits and following the longest chain,...

To give you a better picture: Transactions aren't being picked up and deleted from the mempool. (This must be where your confusion came from)
Mining Pools, Solo Miners, anything with Full Node (eg. Bitcoin Core) have their individual mempool and it's constantly being updated based from their own/default rules and new transactions from their peers' mempool;
it will only be deleted or rejected if it was "mined", didn't follow their set or default rules, input(s) were double-spent or transaction expired.
So each node's mempool shouldn't be too different than each other's.

that is exactly what consensus is all about! consensus or consensus rules are the set of rules that are enforced by any bitcoin full node client and it includes validation of blocks and their transactions. https://en.bitcoin.it/wiki/Consensus

thank you again... you are a very nice person

There used to be other criteria, but nowadays it 99,9% ecomic... The transactions with the highest fee per vbyte of transaction data usually end up in the next block. The biggest exepctions are transactions from pool operators, or people that payed pool operators to include their transactions into the next block.

The other caveat is that pools usually look at the unconfirmed parents of a transaction aswell... For example
Transaction 1 is unconfirmed, you cheaped out on the fee... But you used the output of transaction 1 to create transaction 2. Transaction 2 pays a fee high enough so the fee of transaction 1 + transaction 2 is in the top of the mempool for the combined vsize of transaction 1 + transaction 2. In this case, the miner will usually put transaction 1 and transaction 2 in the block he's trying to solve (cause it makes economic sense: he wants to add the fee of transaction 2 to his coinbase transaction, but he can only do so if he also adds transaction 1 to his block). But a general bystander will just see a transaction with a low fee/vbyte included in the block (transaction 1). This is called a CPFP

wow. Thank you for the explanation. I did some research to understand what are you saying, because I am new in this and now I have thanks to you a much cleaner image, how it is supposed to work.

one more question: are the transactions picked up by chance from the mempool? Are there any criteria besides the econmic ones?

Your transaction does not end in the mempool of the node of one miner... It is broadcasted troughout the network and ends up in the mempool of the nodes of allmost all miners (if the transaction is valid and the fee is high enough to pass the minimum relay fee). This means that if your transaction had a sufficiently high fee and was valid, it should have been in the mempool of the node of whatever miner mines the next block...

It IS possible your transaction never ends up in a block if you were messing with your transaction and it's double-spending unspent outputs that are already used in another (potentially unconfirmed) transaction (unless the rbf flag is set) or if you cheap out on the fee and give no incentive to the miners to add your transaction into the block they're trying to solve (tx's get pruned from the mempool of most nodes after x days, or if the mempool size gets bigger than x mb... Each node can set these variables themselfs) or if it's invalid because of other (not so common) reasons.

That being said, your transaction not getting confirmed is not really the basic defenition of consensus rules... Unless your transaction is rejected BECAUSE it violated the consensus rules offcourse (but this is very uncommon, usually a transaction remains unconfirmed because the fee was to low, or because it was using an unspent output that has been double spent).

Firstly let me tell you (very abstractly), how I understood the consenous. If I am wrong, please correct me.

Out there are many miners and each one receive a lot of different transactions, that have to be validated. The one who is faster put all his by others verified transactions into a block.

What if for example my transaction lands by a miner, whose computing power very low is and he will be never able to put my transaction into a block?

Thanks abd best regards