Wallet: list all transactions

[GoogleCodeExporter]

It would be useful if a wallet can be asked for all transactions that affect 
the balance at all, not only the 'unspent' ones.

Original issue reported on code.google.com by andreas....@gmail.com on 11 Mar 2011 at 1:53

[GoogleCodeExporter]

Is this for a transactions list like the official client has?

If so will you want them sorted by time?

Original comment by hearn@google.com on 12 Mar 2011 at 6:04

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Yes, this is so the user can understand how the balance develops.

I'd be happy to sort in the client, as long as I have a timestamp for each 
transaction. So yes, ultimately I want to present this sorted by time.

Original comment by andreas....@gmail.com on 13 Mar 2011 at 10:38

[GoogleCodeExporter]

Ah, and I guess for the transaction list a "onNewTransaction" event would be 
handy. I understand that this is something different than the existing 
"onCoinsReceived" event, because coins are not received until some confirmation 
has happened. I'd like to display transactions immediately, even if they are 
not confirmed yet.

Original comment by andreas....@gmail.com on 13 Mar 2011 at 2:40

[GoogleCodeExporter]

Displaying 0/unconfirmed transactions on a phone is a bit involved because most 
of the time, the phone will be sleeping and disconnected from the network. The 
C2DM infrastructure on Android can be used to solve that. See the mobile design 
ideas thread.

Let's make handling of unconfirmed transactions a separate bug.

Original comment by hearn@google.com on 14 Mar 2011 at 9:26

[GoogleCodeExporter]

The implementation of this issue becomes kind of pressing. I just had the issue 
of all my Bitcoins being cleared from the Wallet after a "Send coins" failed. 
This is exactly something that one of my users were reporting, so I don't 
believe in a typing mistake.

However, if I had this method, I could look up how the balance of 0 BTC is 
calculated.

Original comment by andreas....@gmail.com on 13 Jun 2011 at 8:38

[GoogleCodeExporter]

I just added issue 28 for the 'loss of coins' problem.

Original comment by andreas....@gmail.com on 13 Jun 2011 at 8:44

[GoogleCodeExporter]

For now you can just make the lists public in your copy of the library, then 
dump them all out. 

What do you mean by "send coins failed"? Failed in what way?

Original comment by hearn@google.com on 13 Jun 2011 at 10:33

[GoogleCodeExporter]

See r214, r215. Are these sort of what you need?

I think there's still some way to go - you want to be able to find out whether 
a transaction is confirmed/dead/pending or not. I think an "int 
Wallet.getConfirmations(Transaction tx)" method would do the trick there.

Original comment by hearn@google.com on 18 Sep 2011 at 7:55

[GoogleCodeExporter]

Looks good. Two comments:

I think you should filter out duplicates (the same tx can be in multiple pools)

Why don't you include dead transactions in the transaction list getters? I need 
to display them to the user. Currently, dead transactions are printed in red 
and struck thru. For this, I also need a boolean Wallet.isDead(Transaction tx).

Original comment by andreas....@gmail.com on 18 Sep 2011 at 8:41

[GoogleCodeExporter]

One more thing: Currently, I sort pending transactions to the top, regardless 
of their updatedAt.

I'm not sure this is something that the framework is responsible for. Maybe 
return transactions unsorted and leave sorting (and result set limiting) to the 
client?

Original comment by andreas....@gmail.com on 18 Sep 2011 at 8:57

[GoogleCodeExporter]

Your transaction sorting might raise NullPointerExceptions, if getUpdateTime() 
returns null.

Original comment by andreas....@gmail.com on 18 Sep 2011 at 9:07

[GoogleCodeExporter]

I added a getTransactions() method that returns a set, optionally including 
dead/inactive. Does that work for you?

I'm not sure a method that returns a sorted list should give unstable results. 
I think the API user would expect pending transactions to sort with other types 
- heck I think end users would expect that too. The pending state of a 
transaction can be shown by its font, I'm not sure floating them to the top is 
that helpful (in most cases it won't make much difference). But you could 
certainly keep that style if you wanted.

You can't sort transactions that have no associated time. This should only 
occur with wallets that have old pending  (outbound) transactions stored in 
them. However I think your code has already been setting a field with an 
identical name for a while (that's why I chose this name), so in practice after 
merging you shouldn't encounter any crashes. People who didn't use this patch 
but are upgrading old wallets might do. Those wallets will get flushed out with 
time I guess ....

Original comment by hearn@google.com on 18 Sep 2011 at 9:14

[GoogleCodeExporter]

The new getTransactions() works perfectly for me, thanks for that.

I think the Satoshi client also always keeps pending tx at the top.

Original comment by andreas....@gmail.com on 18 Sep 2011 at 10:19

[GoogleCodeExporter]

I think in future pending transactions will become a lot more common, which is 
why I'm reluctant to sort them in a special way. For instance, if I send some 
coins to you, we shouldn't really have to pay a fee. You know I'm not going to 
rip you off. 

Currently, Bitcoin might force me to pay for the privilege of sending you 
money, but that doesn't make much conceptual sense - it's the receiver who 
cares about tx reversal risk not the sender. So I think in future it may be 
common to send transactions around outside the network (eg via email or sms) 
and then the recipient just keeps them unconfirmed. When you eventually receive 
some money from somebody you aren't sure you really trust, you can respend the 
coins to your own address but this time including a fee. All the transactions 
get bundled up together when transmitted. Miners see 5 transactions, 1 of which 
includes a fee, and include all 5 (it's required to claim the fee on the last 
one).

For this to work there needs to be a lot of work done:
- building these out-of-band payment protocols that move txns around
- allowing pending transactions to depend on each other within the wallet
- being able to resolve the dependencies of within a transaction set back to 
the block chain, to confirm there have been no double spends (the tx chain 
still holds)

etc. But it makes more sense in the long run.

Original comment by hearn@google.com on 19 Sep 2011 at 8:43

[GoogleCodeExporter]

Original comment by mi...@google.com on 23 Sep 2011 at 8:37

• Added labels: Component-Persistence

[GoogleCodeExporter]

This is a bit of a tangent.  But how about support for listing all transactions 
associated with a certain key?  I don't see any easy way to do this with the 
library the way it is now - other than using a separate wallet for each ECKey - 
then each wallet would obviously only have transactions from that key.  But 
that brings up other problems like having to roll my own spending allocation 
process.

Original comment by MarcHa...@gmail.com on 25 Jan 2012 at 2:26

[GoogleCodeExporter]

Well, the wallet keeps all transactions in memory. It's a fairly simply for 
loop to get that data. The trick is when you want to do it efficiently. 

BitCoinJ lacks a lot of obvious low hanging fruit like this, because almost all 
the dev work goes into supporting the basic needs of mobile wallets. The moment 
you venture outside this use case, you'll find missing functionality. So please 
feel free to submit patches :-)

Original comment by hearn@google.com on 25 Jan 2012 at 4:13

[GoogleCodeExporter]

Original comment by hearn@google.com on 2 Feb 2012 at 3:18

• Changed state: Fixed