Bitcoin Forum
December 07, 2016, 10:47:08 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Negative Account Balances and Static Addresses  (Read 1044 times)
Keyur @ Camp BX
Sr. Member
****
Offline Offline

Activity: 300



View Profile WWW
August 14, 2011, 09:26:46 PM
 #1

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 <address>
removestatic <address>

To set and unset these static flags for addresses.



Eager to hear your thoughts on these,
       Keyur







Please stay tuned to our news and announcements feeds at:
Twitter: https://twitter.com/CampBX
Facebook: https://facebook.com/CampBX
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481107628
Hero Member
*
Offline Offline

Posts: 1481107628

View Profile Personal Message (Offline)

Ignore
1481107628
Reply with quote  #2

1481107628
Report to moderator
1481107628
Hero Member
*
Offline Offline

Posts: 1481107628

View Profile Personal Message (Offline)

Ignore
1481107628
Reply with quote  #2

1481107628
Report to moderator
1481107628
Hero Member
*
Offline Offline

Posts: 1481107628

View Profile Personal Message (Offline)

Ignore
1481107628
Reply with quote  #2

1481107628
Report to moderator
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
August 14, 2011, 11:36:56 PM
 #2

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" <to> <amount>
    ... return txid
  gettransaction <txid>
    ... return txinfo
  if txinfo says a fee was paid:
    move "FEES" "account" <amount-of-fee-paid>


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.

How often do you get the chance to work on a potentially world-changing project?
zellfaze
Full Member
***
Offline Offline

Activity: 142


Security Enthusiast


View Profile WWW
August 15, 2011, 10:10:57 AM
 #3

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.

A+, CCENT, CCNA
Security Enthusiast
PHP Coder

Not that I expect anyone to, but should you like my post, please donate:
Donate: 1BRbfqii6Sm9tEUE8A16H7QeDmYFjyBZ7V
Keyur @ Camp BX
Sr. Member
****
Offline Offline

Activity: 300



View Profile WWW
August 16, 2011, 03:59:01 AM
 #4

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.

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




Please stay tuned to our news and announcements feeds at:
Twitter: https://twitter.com/CampBX
Facebook: https://facebook.com/CampBX
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
August 17, 2011, 01:03:59 AM
 #5

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.

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.

Keyur @ Camp BX
Sr. Member
****
Offline Offline

Activity: 300



View Profile WWW
August 17, 2011, 01:27:07 AM
 #6

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.

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




Please stay tuned to our news and announcements feeds at:
Twitter: https://twitter.com/CampBX
Facebook: https://facebook.com/CampBX
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!