Bitcoin Forum
November 17, 2019, 10:52:06 AM *
News: Latest Bitcoin Core release: 0.18.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Best practices for sending BTC and dealing with fees  (Read 492 times)
randomuser543
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.


1573987926
Hero Member
*
Offline Offline

Posts: 1573987926

View Profile Personal Message (Offline)

Ignore
1573987926
Reply with quote  #2

1573987926
Report to moderator
1573987926
Hero Member
*
Offline Offline

Posts: 1573987926

View Profile Personal Message (Offline)

Ignore
1573987926
Reply with quote  #2

1573987926
Report to moderator
1573987926
Hero Member
*
Offline Offline

Posts: 1573987926

View Profile Personal Message (Offline)

Ignore
1573987926
Reply with quote  #2

1573987926
Report to moderator
The Bitcoin Forum is turning 10 years old! Join the community in sharing and exploring the notable posts made over the years.
1573987926
Hero Member
*
Offline Offline

Posts: 1573987926

View Profile Personal Message (Offline)

Ignore
1573987926
Reply with quote  #2

1573987926
Report to moderator
1573987926
Hero Member
*
Offline Offline

Posts: 1573987926

View Profile Personal Message (Offline)

Ignore
1573987926
Reply with quote  #2

1573987926
Report to moderator
cloverme
Legendary
*
Offline Offline

Activity: 1498
Merit: 1041


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:  

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!