Selectively choosing transactions to be included in a block

[donch]

Hi,

can anyone tell me if the current bitcoind RPC interface allows for selectively culling transactions from the memory pool to allow a pool operator to choose which transactions to include in a block they want to solve? As miners face a potential shortfall in the return on their ASIC investments and perhaps felt inclined to only process transactions with fees, thereby coaxing Bitcoin users to be a bit more generous with their fees, how would you actually do this using the current default implementation?

I can see that getblocktemplate discusses being more transparent about the work that a miner does, but I can't quite fathom how you select transactions. Any help much appreciated!

https://en.bitcoin.it/wiki/BIP_0023

Cheers,
Donovan.

[jgarzik]

getblocktemplate provides a set of candidate transactions.  You are able to supplement or cull that set, before passing a block header template to miners.

[Peter Todd]

Hi,

can anyone tell me if the current bitcoind RPC interface allows for selectively culling transactions from the memory pool to allow a pool operator to choose which transactions to include in a block they want to solve? As miners face a potential shortfall in the return on their ASIC investments and perhaps felt inclined to only process transactions with fees, thereby coaxing Bitcoin users to be a bit more generous with their fees, how would you actually do this using the current default implementation?

bitcoind already supports this actually, in ~/.bitcoin/bitcoin.conf set blockprioritysize=0 tells Bitcoin to include only fee paying transactions, and then set mintxfee=0.001 to set the minimum fee per KB for transactions you're willing to mine. (I made some estimates, and IIRC 0.001 is roughly break even in terms of increased orphan risk; you probably want to set it even higher)

[gmaxwell]

FWIW, I hope no one that had to learn this from reading this thread is running a large pool…  

I also don't think that twiddling up your minimum fee levels is likely to increase the fees that most transactions pay… at least not in any way proportional to the confusion and irritation users suffer if they found their transactions taking unexpectedly long to confirm (and the danger to the value of the coins you're mining created by scaring users away with fee policy that feels like terrorism to someone who doesn't understand it).

A first step in driving up transaction fees would be helping to improve network behavior and wallet software so that replacing a transaction with a too low fee is painless and doesn't leave users feeling like they've been assaulted by an invisible force.

[donch]

Thanks for the answers, much appreciated! I'm not a pool operator, but am interested in the mechanics of generating blocks. It's also interesting to watch the development of btcd, which is written in Go, which happens to be my favourite programming language :-)

I agree that no one wants to stop newcomer's transactions from going through, but it doesn't seem unreasonable that a pool could process transactions with fees above a threshold in every piece of work that they distribute while limiting fee-less transactions to perhaps every other block. This way a gentle transition to actually expecting fees from users and wallet developers could be accelerated.

I suppose the main question is what is an acceptable transaction fee. Can anyone tell me how they would go about quickly accessing the trend in fee as a proportion of block transaction volume or output total for all blocks over time? Anyone have any thoughts on what they would consider an acceptable threshold?

Just playing devil's advocate really. Lots of people are going to lose money in the ASIC game from being too dependent on the block reward and hoping for a good BTC exchange rate if they bought with fiat. Transaction fees could be a small light at the end of the tunnel :-)

[donch]

bitcoind already supports this actually, in ~/.bitcoin/bitcoin.conf set blockprioritysize=0 tells Bitcoin to include only fee paying transactions, and then set mintxfee=0.001 to set the minimum fee per KB for transactions you're willing to mine. (I made some estimates, and IIRC 0.001 is roughly break even in terms of increased orphan risk; you probably want to set it even higher)

Can you explain why there is an increased orphan risk due to the mintxfee setting? I though orphans were dependent on the timing of the block hash being found..

[Peter Todd]

Can you explain why there is an increased orphan risk due to the mintxfee setting? I though orphans were dependent on the timing of the block hash being found..

Larger blocks take longer to propagate around the network, thus increasing the window in which someone else could have find another block that got to the majority of hashing power faster.

mintxfee doesn't directly reduce the orphan risk, but it can be used to increase profitability by only accepting transactions for which the fees are sufficient to outweigh the increased chance of the 25BTC block reward being orphaned.