1. 22 Aug, 2013 1 commit
    • Gavin Andresen's avatar
      Refactor: CAddressBookData for mapAddressBook · 4329730e
      Gavin Andresen authored
      Straight refactor, so mapAddressBook stores a CAddressBookData
      (which just contains a std::string) instead of a std::string.
      
      Preparation for payment protocol work, which will add the notion
      of refund addresses to the address book.
      4329730e
  2. 31 Jul, 2013 1 commit
  3. 17 Jul, 2013 1 commit
  4. 25 Jun, 2013 1 commit
  5. 24 Jun, 2013 1 commit
  6. 22 Jun, 2013 1 commit
    • Pieter Wuille's avatar
      Add GetKeyBirthTimes to wallet · 313752bb
      Pieter Wuille authored
      Compute safe lower bounds on the birth times of all wallet keys. For
      pool keys or keys with metadata, the actually stored birth time is
      used. For all others, the birth times are inferred from the wallet
      transactions.
      313752bb
  7. 19 Jun, 2013 1 commit
    • Pieter Wuille's avatar
      Refactor keytime/metadata and wallet encryption bugfix · 14f3fed0
      Pieter Wuille authored
      Refactor keytime:
      * Key metadata is kept in a CWallet::mapKeyMetadata (std::map<CKeyId,CKeyMetadata>).
      * When generating a new key, time is put in that map, and new key is written.
      * AddKeyPubKey and AddCryptedKey do not take a creation time argument, but instead
        pull it from that map, if it exists there.
      
      Bugfix:
      * AddKeyPubKey and AddCryptedKey in CWallet didn't override the CKeyStore
        definition anymore. This is fixed, as they no longed need the nCreationTime
        argument now.
      
      Also a few related other changes:
      * Metadata can be overwritten.
      * Only GenerateNewKey calls GetTime(), as it's the only place where we know for
        sure a key was not constructed earlier.
      * When the nTimeFirstKey is known to be inaccurate, it is set to the value 1
        (instead of 0, which would mean unknown).
      * Use CPubKey instead of std::vector<unsigned char> where possible.
      14f3fed0
  8. 14 Jun, 2013 1 commit
    • Matt Corallo's avatar
      Refactor fee rules to make them actually readable. · 18e9f7d2
      Matt Corallo authored
      This (nearly) doesn't change fee rules at all:
       * To make it into the fee transaction area, the dPriority comparison
         changed from < to <=
       * We now just ignore transactions > MAX_BLOCK_SIZE/4 instead of
         doing some calculations to require increasingly large fees as
         size increases.
      18e9f7d2
  9. 13 Jun, 2013 1 commit
  10. 10 Jun, 2013 2 commits
  11. 06 Jun, 2013 2 commits
  12. 04 Jun, 2013 2 commits
  13. 30 May, 2013 1 commit
  14. 12 May, 2013 1 commit
    • Pieter Wuille's avatar
      Make FindBlockByHeight constant-time. · 3db02fb8
      Pieter Wuille authored
      Remove the pnext pointer in CBlockIndex, and replace it with a
      vBlockIndexByHeight vector (no effect on memory usage). pnext can
      now be replaced by vBlockIndexByHeight[nHeight+1], but
      FindBlockByHeight becomes constant-time.
      
      This also means the entire mapBlockIndex structure and the block
      index entries in it become purely blocktree-related data, and
      independent from the currently active chain, potentially allowing
      them to be protected by separate mutexes in the future.
      3db02fb8
  15. 07 May, 2013 1 commit
    • Gavin Andresen's avatar
      Use boost::asio::deadline_timer for walletpassphrase timeout · e7c715e9
      Gavin Andresen authored
      New method in bitcoinrpc:  RunLater, that uses a map of deadline
      timers to run a function later.
      
      Behavior of walletpassphrase is changed; before, calling
      walletpassphrase again before the lock timeout passed
      would result in: Error: Wallet is already unlocked.
      
      You would have to call lockwallet before walletpassphrase.
      
      Now: the last walletpassphrase with correct password
      wins, and overrides any previous timeout.
      
      Fixes issue# 1961 which was caused by spawning too many threads.
      
      Test plan:
      
      Start with encrypted wallet, password 'foo'
      NOTE:
       python -c 'import time; print("%d"%time.time())'
      ... will tell you current unix timestamp.
      
      Try:
      
      walletpassphrase foo 600
      getinfo
      EXPECT: unlocked_until is about 10 minutes in the future
      
      walletpassphrase foo 1
      sleep 2
      sendtoaddress mun74Bvba3B1PF2YkrF4NsgcJwHXXh12LF 11
      EXPECT: Error: Please enter the wallet passphrase with walletpassphrase first.
      
      walletpassphrase foo 600
      walletpassphrase foo 0
      getinfo
      EXPECT: wallet is locked (unlocked_until is 0)
      
      walletpassphrase foo 10
      walletpassphrase foo 600
      getinfo
      EXPECT: wallet is unlocked until 10 minutes in future
      
      walletpassphrase foo 60
      walletpassphrase bar 600
      EXPECT: Error, incorrect passphrase
      getinfo
      EXPECT: wallet still scheduled to lock 60 seconds from first (successful) walletpassphrase
      e7c715e9
  16. 03 May, 2013 3 commits
  17. 02 May, 2013 1 commit
    • Gavin Andresen's avatar
      Do not write to wallet during LoadWallet · 2e935d11
      Gavin Andresen authored
      When debugging another issue, I found a hang-during-startup race condition due to
      LoadWallet calling SetMinVersion (via LoadCryptedKey).
      
      Writing to the file that you're in the process of reading is a bad idea.
      2e935d11
  18. 25 Apr, 2013 1 commit
  19. 07 Apr, 2013 1 commit
  20. 03 Apr, 2013 1 commit
  21. 18 Feb, 2013 1 commit
    • Gregory Maxwell's avatar
      Internal RNG for approximateBestSubset to prevent degenerate behavior. · 4bf3ef0c
      Gregory Maxwell authored
      This fixes test_bitcoin failures on openbsd reported by dhill on IRC.
      
        On some systems rand() is a simple LCG over 2^31 and so it produces
      an even-odd sequence.  ApproximateBestSubset was only using the least
      significant bit and so every run of the iterative solver would be the
      same for some inputs, resulting in some pretty dumb decisions.
      
      Using something other than the least significant bit would paper over
      the issue but who knows what other way a system's rand() might get us
      here.  Instead we use an internal RNG with a period of something like
      2^60 which is well behaved.  This also makes it possible to make the
      selection deterministic for the tests, if we wanted to implement that.
      4bf3ef0c
  22. 05 Feb, 2013 1 commit
    • Gavin Andresen's avatar
      Make transactions larger than 100K non-standard · e9b5fc22
      Gavin Andresen authored
      Extremely large transactions with lots of inputs can cost the network
      almost as much to process as they cost the sender in fees.
      
      We would never create transactions larger than 100K big; this change
      makes transactions larger than 100K non-standard, so they are not
      relayed/mined by default. This is most important for miners that might
      create blocks larger than 250K big, who could be vulnerable to a
      make-your-blocks-so-expensive-to-verify-they-get-orphaned attack.
      e9b5fc22
  23. 04 Feb, 2013 1 commit
    • Gavin Andresen's avatar
      Fix getbalance discrepency · 5536482d
      Gavin Andresen authored
      Two changes:
      
      Use IsConfirmed() instead of IsFinal(), so 'getbalance "*" 0' uses the same
      'is this output spendable' criteria as 'getbalance'. Fixes issue #172.
      
      And a tiny refactor to CWallet::GetBalance() (redundant call to IsFinal -- IsConfirmed
      calls IsFinal).
      getbalance with no arguments and 'getbalance "*" 0' could return different different results,
      5536482d
  24. 30 Jan, 2013 1 commit
  25. 16 Jan, 2013 1 commit
  26. 15 Jan, 2013 1 commit
    • Gavin Andresen's avatar
      Remove IsFromMe() check in CTxMemPool::accept() · 08bee8fb
      Gavin Andresen authored
      Fixes issue #2178 : attacker could penny-flood with invalid-signature
      transactions to deduce which addresses belonged to your node.
      
      I'm committing this early for code review; I still need to write up
      a test plan.
      
      Executive summary of fix: check all transactions received from the network
      for penny-flood rate-limiting before adding to the memory pool. But do NOT
      ratelimit transactions added to the memory pool:
        - because of blockchain reorgs
        - stored in the wallet and added at startup
        - sent from the GUI or one of the send* RPC commands (CWallet::CommitTransaction)
      
      The limit-free-transactions code really should be a method on CNode, with
      counters per-peer. But that is a bigger change for another day.
      08bee8fb
  27. 26 Dec, 2012 1 commit
    • Gregory Maxwell's avatar
      If the prio. will be enough after the next block don't force fees. · 5d5e6833
      Gregory Maxwell authored
        If the user was really after the fastest possible confirmation times
      they would be manually setting a fee. In cases where the wallet builds
      a transaction with a priority that is too low to qualify as free until
      the next block, go ahead without a fee.  Confirmation frequently takes
      multiple blocks even when a minimum fee is provided.
      5d5e6833
  28. 14 Dec, 2012 1 commit
  29. 04 Dec, 2012 1 commit
  30. 16 Nov, 2012 1 commit
  31. 15 Nov, 2012 1 commit
  32. 13 Nov, 2012 2 commits
  33. 03 Nov, 2012 1 commit
  34. 01 Nov, 2012 1 commit
    • Pieter Wuille's avatar
      Bugfix: do not keep relaying spent wallet transactions · ce5d0d47
      Pieter Wuille authored
      The original test (checking whether the transaction occurs in the
      txindex) is not usable anymore, as it will miss anything already
      fully spent. However, as merkle transactions (and by extension,
      wallet transactions) track which block they were last seen being
      included in, we can use that to determine the need for
      rebroadcasting.
      ce5d0d47