Commits on Jun 27, 2011

1. CWalletTx::GetAmounts(): Move address divination to CTxOut::GetAddress()

   

   pasky committed Jun 27, 2011
   Configuration menu

   • View commit details
   • Copy full SHA for ddc1695
   • Browse repository at this point

   Copy the full SHA

   ddc1695 View commit details

   Browse the repository at this point in the history

2. RPC sendmany(): Move address-amount list parsing to AddressAmountList()

   

   pasky committed Jun 27, 2011
   Configuration menu

   • View commit details
   • Copy full SHA for c591baf
   • Browse repository at this point

   Copy the full SHA

   c591baf View commit details

   Browse the repository at this point in the history

3. Support for "exact send" with manual coin selection …

   This patch introduces CWallet::CreateExactTransaction() function that
   works like CWallet::CreateTransaction(), but takes explicit list of
   prev_out transactions for sourcing the new transaction and fixed value
   of transaction fee.
   
   Furthermore, new RPC call 'sendexact' is introduced; it works like
   'sendmany', but takes explicit list of transactions to use as coin
   sources, and explicit value of transaction fee.
   
   All outputs of the listed transactions that the account can claim are
   used to source coins; the output of the new transaction must be exactly
   the same amount, the user is responsible for dealing with any change.
   The user is also responsible for setting the transaction fee to such
   a value that other nodes will relay the transaction.
   
   The point is to provide a low-level interface for making transactions
   without all the auto-guessing implicitly done by the client. My primary
   motivation is that I am a control freak and I want to have precise
   control over the addresses used as "sources" of my transactions.
   
   There are other applications too - even if more specific interfaces
   might be more suited to them, this interface makes them possible at all
   as the lowest common denominator. E.g. people who wish to be sure no
   transaction fees will be paid for their transaction can use this
   interface. Or people wishing to try out different coin selection
   algorithms (or when coin selection makes sense at the moment of
   transaction setup, e.g. in case of anonymizers).
   
   Q: Why use explicit transactions instead of addresses?
   A: In reality, you do not quite transfer money "from" an address.
   Address is just a token that proves you are authorized to claim
   a particular amount of bitcoins listed as one of outputs of some
   transaction. Specific use-cases might be simplified, but you would
   still be in hands of a fixed coin selection algorithm.  You can use
   (somewhat laborously) listtransactions or external service to discover
   transactions that send money to a given address.
   
   Q: Why use account instead of explicit addresses?
   A: First, it is more consistent with the other "send" interfaces
   and the wallet organization. Second, I believe account is the right
   abstraction - as mentioned, address is just a token for claiming some
   bitcoins, but different kind of claim proofs might be used (e.g. the
   now-deprecated "send to IP address", or it could be possible to also
   specify password-protected coins). In the future, you could associate
   further methods of authentication with accounts, but addresses are
   limited. If you require a specific set of addresses to be used, you can
   set up an ad-hoc account.
   
   Q: What does that bit about "change" mean?
   A: If transaction input claims some output of a previous transaction,
   it must claim all the coins in the output. If you need to transfer
   smaller amount than that, you must specify what to do with the
   remaining amount (change). The built-in coin selection algorithm
   either sends them to a new address (for better anonymity) or returns
   them to the source address. Here, you are responsible for manually
   specifying the destiny of your remaining amount.
   
   Q: Can I be finally sure I pay only the TX fee I specify?
   A: Yes, the TX fee you specify is final. However, please note that
   if the new transaction is large (i.e. has many inputs and outputs)
   or transfers too small amount and you do not offer any TX fee, it
   may not be accepted by any other nodes. Note that this is more
   serious than not being included in a block - you could just wait
   longer for a benevolent miner. In these circumstances, your
   transaction is not likely to even *reach* a mining node because
   the P2P network will not relay it.

   

   pasky committed Jun 27, 2011
   Configuration menu

   • View commit details
   • Copy full SHA for 34fd79f
   • Browse repository at this point

   Copy the full SHA

   34fd79f View commit details

   Browse the repository at this point in the history