Topic: Negative Account Balances and Static Addresses (Read 1213 times)

Hi Gmaxwell,
     Never mind - I was thinking aloud based on end user requests we receive.   As I think more, this request feels more like feature creep rather than a core feature.  Updating the original message to reflect this.

Thank you,
      Keyur

This is all well and good, and also completely meaningless.  If thats what you want to do, then just do it. You don't need any support from the software.

Perhaps you're under the impression that bitcoin will forget about older addresses that it has given you after it gives you a new one? That isn't the case. (I'm just guessing wildly, because I can't figure out what you're thinking). All addresses your client generates will be remembered forever, any other behavior would lose money.

Gavin,
      Thank you - this explanation really helps me understand the design intent.


RE Static Addresses:  Customers have two different sets of needs.  They can choose to use disposable addresses used for transfers / trades, and opt for a "static" address to plug into mining services or merchant solutions, where deposits can be made over extended periods of time.  As Bitcoin matures like other financial system, this deposit period may extend well into years.

Thank you,
      Keyur

I think by static addresses he means when the wallet is created generate 100,000 addresses or something crazy like that, then make no more.

Then a wallet backup is good for the (now limited) lifetime of the wallet.

RE: negative account balances:

There is (was?) a patch proposed with an RPC call to prepare a send transaction, which would lock the inputs involved and return the transaction fee and a transaction id.  And commit/reject RPC calls, which take the transaction id and either commit it or rejects it.  That's the only really right way to estimate transaction fees before sending. I haven't reviewed the patch, and I don't think it has been thoroughly tested; there might be denial-of-service attacks possible or odd edge cases (e.g. could one customer who decides to go to lunch while the "this transaction will cost you 0.0005 BTC, OK/Cancel?" dialog is open tie up the entire wallet's balance, making sends fail for everybody?)

There's also an estimatetxfee patch, but the problem is that between the time you estimate the tx fee and the time the send happens the state of the wallet might change, making the estimate wrong.

The real question is why should customer A pay a transaction fee just because customer B funded their account with tons of tiny transactions? If customer A puts 1,000 bitcoins in their account and pays 0 fee, they're going to be pretty upset at you if you charge them to withdraw THEIR money from the account.

For ClearCoin, I just treated transaction fees as a cost of doing business, and refunded customer accounts when a send resulted in a transaction fee (via the RPC move method from a special FEES account that I pre-funded to cover transaction fees).

So sends look like:
  sendfrom "account"
    ... return txid
  gettransaction
    ... return txinfo
  if txinfo says a fee was paid:
    move "FEES" "account"


RE: static addresses

I don't follow.  You mean have one address per account?  You could call getaddressesbyaccount and the return the first address or (if empty array) return getaccountaddress?  Or if you create an account when a user signs up for your service, call getaccountaddress and then you KNOW that getaddressesbyaccount will return at least one address.

Hi Everyone,
       Had two questions about the current implementation:


1) Negative account balances:

Quote
 - The check for sufficient funds is done before paying transaction fees (if any); if a
   transaction fee is needed, and there are sufficient funds in the wallet, then the
   transaction fee will be paid and debited from the account.  For example, if account
   'foo' contains 10 bitcoins, you sendfrom foo 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC 10,
   and the transaction costs 0.01, 'foo's balance will be -0.01 bitcoins.
End Quote

What was the rational for implementing fee management this way?  In most of the business scenarios, negative balances can confuse improperly designed algorithms, and halt the properly designed ones.  A user account should be also responsible for fees on their transactions from a logical standpoint.

I haven't reviewed the fee-calculation code yet, but is it possible to calculate fees beforehand and incorporate them in the NSF check?


2) Static Addresses:
      There is a lot of demand for static addresses from Bitcoin users, but most of the current implementations simulate this through a very large key-pool value.  It may be better to offer this feature natively by adding a true/false flag to Berkeley DB storing the addresses.  

Two API calls can be added to offer this feature:
makestatic

removestatic

To set and unset these static flags for addresses.


Eager to hear your thoughts on these,
       Keyur