Bitcoin Forum
October 21, 2017, 11:30:13 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Selectively choosing transactions to be included in a block  (Read 1902 times)
donch
Member
**
Offline Offline

Activity: 84


Updated ironic image.


View Profile
October 12, 2013, 05:29:47 PM
 #1

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.

"How are you justifying these as fair use?  They are clearly and unequivocally a copyright violation."
"I really want to know how you justify that under the fair use doctrine?  It does not conform to a single point of fair use."
Josh whining about people reusing his studio portrait shot on this forum. Can you copyright a copyright complaint? All Paypal refunds are final.
1508628613
Hero Member
*
Offline Offline

Posts: 1508628613

View Profile Personal Message (Offline)

Ignore
1508628613
Reply with quote  #2

1508628613
Report to moderator
1508628613
Hero Member
*
Offline Offline

Posts: 1508628613

View Profile Personal Message (Offline)

Ignore
1508628613
Reply with quote  #2

1508628613
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508628613
Hero Member
*
Offline Offline

Posts: 1508628613

View Profile Personal Message (Offline)

Ignore
1508628613
Reply with quote  #2

1508628613
Report to moderator
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
October 13, 2013, 01:22:17 AM
 #2

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



Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
October 13, 2013, 03:10:41 AM
 #3

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
Moderator
Legendary
*
qt
Offline Offline

Activity: 2324



View Profile
October 13, 2013, 04:09:33 AM
 #4

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

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. Smiley

Bitcoin will not be compromised
donch
Member
**
Offline Offline

Activity: 84


Updated ironic image.


View Profile
October 13, 2013, 01:46:46 PM
 #5

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 :-)

"How are you justifying these as fair use?  They are clearly and unequivocally a copyright violation."
"I really want to know how you justify that under the fair use doctrine?  It does not conform to a single point of fair use."
Josh whining about people reusing his studio portrait shot on this forum. Can you copyright a copyright complaint? All Paypal refunds are final.
donch
Member
**
Offline Offline

Activity: 84


Updated ironic image.


View Profile
October 13, 2013, 01:49:06 PM
 #6

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..

"How are you justifying these as fair use?  They are clearly and unequivocally a copyright violation."
"I really want to know how you justify that under the fair use doctrine?  It does not conform to a single point of fair use."
Josh whining about people reusing his studio portrait shot on this forum. Can you copyright a copyright complaint? All Paypal refunds are final.
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
October 13, 2013, 03:04:50 PM
 #7

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.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!