Bitcoin Forum
May 13, 2024, 04:16:57 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Best practices for sending BTC and dealing with fees  (Read 559 times)
randomuser543 (OP)
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
May 10, 2016, 03:55:42 PM
 #1

I've got a fully functioning web service working with my bitcoin daemon, which I'm pretty happy with. When a withdrawal is requested, I'm doing the following -

settxfee =  16 satoshis / per byte (this seems pretty safe, however I may switch to using 'estimatefee 6')
sendtoaddress (I'm terrified about attempting rawtransactions)

I'm now thinking how to best handle fees so that they won't eat in to any potential profits. Sending to many isn't an option at this point. Withdrawals will come from warm storage.

  • Would it make more sense to utilize sendFrom, and then specify a minimum confirmation of ~6? I believe this should reduce fees.
  • Is there anything I can do with my warm storage funds, in terms of organising unspent outputs, that will help increase their priority etc and therefore reduce fees?
  • In the client it's possible to deduct the transaction fee from the sending amount, is this possible through the daemon?
  • Are there any other practices or recommendations I'm missing?

I'm still thinking how to best handle things. Should I eat the tx fees or pass them on. Should I deduct a static fee from all withdrawals or a tiny percentage.


1715573817
Hero Member
*
Offline Offline

Posts: 1715573817

View Profile Personal Message (Offline)

Ignore
1715573817
Reply with quote  #2

1715573817
Report to moderator
BitcoinCleanup.com: Learn why Bitcoin isn't bad for the environment
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715573817
Hero Member
*
Offline Offline

Posts: 1715573817

View Profile Personal Message (Offline)

Ignore
1715573817
Reply with quote  #2

1715573817
Report to moderator
1715573817
Hero Member
*
Offline Offline

Posts: 1715573817

View Profile Personal Message (Offline)

Ignore
1715573817
Reply with quote  #2

1715573817
Report to moderator
cloverme
Legendary
*
Offline Offline

Activity: 1512
Merit: 1057


SpacePirate.io


View Profile WWW
May 11, 2016, 03:37:28 AM
 #2

I've got a fully functioning web service working with my bitcoin daemon, which I'm pretty happy with. When a withdrawal is requested, I'm doing the following -

settxfee =  16 satoshis / per byte (this seems pretty safe, however I may switch to using 'estimatefee 6')
sendtoaddress (I'm terrified about attempting rawtransactions)

I'm now thinking how to best handle fees so that they won't eat in to any potential profits. Sending to many isn't an option at this point. Withdrawals will come from warm storage.

  • Would it make more sense to utilize sendFrom, and then specify a minimum confirmation of ~6? I believe this should reduce fees.
  • Is there anything I can do with my warm storage funds, in terms of organising unspent outputs, that will help increase their priority etc and therefore reduce fees?
  • In the client it's possible to deduct the transaction fee from the sending amount, is this possible through the daemon?
  • Are there any other practices or recommendations I'm missing?

I'm still thinking how to best handle things. Should I eat the tx fees or pass them on. Should I deduct a static fee from all withdrawals or a tiny percentage.





All things considered, fees are pretty low. Calculate the transaction size before sending, calculate the txfee, then deduct total fee from the amount your sending before you send it.
Check out this post: http://bitcoin.stackexchange.com/questions/22313/fees-for-bitcoind-sendmany-limits-for-number-of-end-addresses



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!