This is 'a python geeks coin control.'
Should be both useful and also a good demonstration of using the raw transactions API.
This is 'a python geeks coin control.'
Should be both useful and also a good demonstration of using the raw transactions API.
Should be both useful and also a pretty good demonstration of
using the raw transactions API.
In my own python scripts I've never been clear about this— and hand't bothered to try to test it— can the cast from Decimal to float and then transmission to bitcoind result in turning 1e-8 BTC to fees due to rounding?
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/72bb8e1b3498a79702e47c2e64895f3b29f9ee45 for binaries and test log.
Cast from Decimal to float will be safe as long as floats are 64 bits. Checking for that is a good idea: "information about the precision and internal representation of floating point numbers for the machine on which your program is running is available in sys.float_info."
... or maybe more straightforward (and more easily portable to other languages) would be a check routine that takes Decimal("20000000.00000003"), converts it to float, json encode/decode, and makes sure precision is not lost in the round-trip.
mmm, yeah, json encode/decode definitely better, because the json float encoder might decide to round/truncate...
Closing this for now; I found a nasty bug doing more testing (on testnet-- using same address as input and output could lose coins to fees).
I'm going to rework to sanity-check fees on the final transaction and write a test plan.