Bitcoin Forum
December 13, 2024, 02:38:07 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: What reason does a miner have not to choose as many unconfirmed transactions?  (Read 427 times)
szangvil (OP)
Newbie
*
Offline Offline

Activity: 35
Merit: 0


View Profile
April 25, 2013, 03:25:20 PM
 #1

When mining for a new block, the miner choses unconfirmed transactions to include in his block (should he find one before another miner).
Why a miner will not choose ALL unconfirmed transactions (until reach the maximum block size)? What are the considerations when choosing transactions (other than the highest fee)?
DannyHamilton
Legendary
*
Online Online

Activity: 3514
Merit: 4894



View Profile
April 25, 2013, 03:48:46 PM
 #2

When mining for a new block, the miner choses unconfirmed transactions to include in his block (should he find one before another miner).
Why a miner will not choose ALL unconfirmed transactions (until reach the maximum block size)? What are the considerations when choosing transactions (other than the highest fee)?

It is entirely voluntary.  Each miner (or pool) can use any criteria they like for deciding which valid unconfirmed transactions they'll add to their block.

I think most miners just use the criteria built in to the bitcoind client.  I don't remember the rules on that, but I know I've seen them in the forum.  If you do enough searching, I'm sure you'll stumble across them eventually.
szangvil (OP)
Newbie
*
Offline Offline

Activity: 35
Merit: 0


View Profile
April 25, 2013, 04:11:21 PM
 #3

Isn't it in the best interest of the network that each block will contain as many transactions as possible? Why make transactions wait? If it takes the same effort to create a block with 10 transactions or 1000 transactions, why the system does not enforce choosing the the latter?

Theoretically, a node which has considerably more computing power vs the rest of the network, can choose to include 1 transaction with each block, deliberately delaying confirmations (or controlling them)  since it has the biggest chances of finding a new block...
DannyHamilton
Legendary
*
Online Online

Activity: 3514
Merit: 4894



View Profile
April 25, 2013, 04:22:34 PM
 #4

Isn't it in the best interest of the network that each block will contain as many transactions as possible?

Perhaps.  But is it in the best interest of the miner?

Why make transactions wait? If it takes the same effort to create a block with 10 transactions or 1000 transactions, why the system does not enforce choosing the the latter?

Good question.  I'm not sure if there are technical reasons why this isn't enforced, but from a ideological standpoint, most of Bitcoin is voluntary.

When creating transactions you are not "required" to include a fee.  You are welcome to create transactions without a fee if you like.

When acting as a peer, you are not "required" to relay transactions.  You are welcome to use any criteria you like for refusing to relay a transaction.  In most cases, people run the reference client.  As such, they refuse to relay transactions that seem too much like spam unless they include a fee.

When mining, you are not required to include any transactions at all in your block (except for the coinbase transaction that pays out the block reward).  You can use any criteria you like for choosing transactions.

Theoretically, a node which has considerably more computing power vs the rest of the network, can choose to include 1 transaction with each block, deliberately delaying confirmations (or controlling them)  since it has the biggest chances of finding a new block...

Yes.  This is true.  This is the nature of the design of Bitcoin, and it is why a ">50% attack" works.
szangvil (OP)
Newbie
*
Offline Offline

Activity: 35
Merit: 0


View Profile
April 28, 2013, 07:06:57 AM
 #5

Thanks for the answers.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!