[PULL REQUEST] add address to listtransactions output

[Gavin Andresen]

  https://github.com/bitcoin/bitcoin/pull/10

Three changes to listtransactions:

Add address to listtransactions output.

"multisends" (non-standard, use one transaction to send to multiple addresses) generate N "category":"send" lines.

Bug fix: listtransactions wasn't reporting pay-by-IP-connection receive transactions.

[1714775664]

1714775664

[1714775664]

1714775664

[1714775664]

1714775664

[1714775664]

1714775664

[1714775664]

1714775664

[1714775664]

1714775664

[davout]

That's nice !
So, what is the output going to be like if the transaction is sent to one address and if it is sent to multiple addresses ?

[Gavin Andresen]

Normal send; this one was:

sendfrom Test1 mytzSq1rkXzPidP9tHvfhDuzXqDSSvvaCg 100

Code:

    {
        "account" : "Test3",
        "address" : "mytzSq1rkXzPidP9tHvfhDuzXqDSSvvaCg",
        "category" : "receive",
        "amount" : 100.00000000,
        "confirmations" : 344,
        "txid" : "210ea061bd3664c34349dfa4849b9f33889cfe2117bf02d62fd765cb0ee5b5b0",
        "time" : 1292527858,
        "comment" : "Test1 to Test3, 100"
    },
    {
        "account" : "Test1",
        "address" : "mytzSq1rkXzPidP9tHvfhDuzXqDSSvvaCg",
        "category" : "send",
        "amount" : -100.00000000,
        "fee" : 0.00000000,
        "confirmations" : 344,
        "txid" : "210ea061bd3664c34349dfa4849b9f33889cfe2117bf02d62fd765cb0ee5b5b0",
        "time" : 1292527858,
        "comment" : "Test1 to Test3, 100"
    },

And a wicked-crazy multisend:

sendfrom Test1 to:
   mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX 3.0  AND
   mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX 3.3  AND
   msVM67gJZ4EKMRVdMjMFzwWEU32VzBUnqu 2.0

Code:

    {
        "account" : "Test3",
        "address" : "mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX",
        "category" : "receive",
        "amount" : 3.03000000,
        "confirmations" : 342,
        "txid" : "ed9d338586c0893b2469cd9e3af4d074654d807329a5a789e066f03063a08136",
        "time" : 1292531730,
        "comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
    },
    {
        "account" : "Test3",
        "address" : "mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX",
        "category" : "receive",
        "amount" : 3.00000000,
        "confirmations" : 342,
        "txid" : "ed9d338586c0893b2469cd9e3af4d074654d807329a5a789e066f03063a08136",
        "time" : 1292531730,
        "comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
    },
    {
        "account" : "Test2",
        "address" : "msVM67gJZ4EKMRVdMjMFzwWEU32VzBUnqu",
        "category" : "receive",
        "amount" : 2.00000000,
        "confirmations" : 342,
        "txid" : "ed9d338586c0893b2469cd9e3af4d074654d807329a5a789e066f03063a08136",
        "time" : 1292531730,
        "comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
    },
    {
        "account" : "Test1",
        "address" : "mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX",
        "category" : "send",
        "amount" : -3.03000000,
        "fee" : 0.00000000,
        "confirmations" : 342,
        "txid" : "ed9d338586c0893b2469cd9e3af4d074654d807329a5a789e066f03063a08136",
        "time" : 1292531730,
        "comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
    },
    {
        "account" : "Test1",
        "address" : "mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX",
        "category" : "send",
        "amount" : -3.00000000,
        "fee" : 0.00000000,
        "confirmations" : 342,
        "txid" : "ed9d338586c0893b2469cd9e3af4d074654d807329a5a789e066f03063a08136",
        "time" : 1292531730,
        "comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
    },
    {
        "account" : "Test1",
        "address" : "msVM67gJZ4EKMRVdMjMFzwWEU32VzBUnqu",
        "category" : "send",
        "amount" : -2.00000000,
        "fee" : 0.00000000,
        "confirmations" : 342,
        "txid" : "ed9d338586c0893b2469cd9e3af4d074654d807329a5a789e066f03063a08136",
        "time" : 1292531730,
        "comment" : "multisend, Test1 to Test2 and Test3 twice (same addr)"
    },

Again, multi-sends are non-standard transactions.  And no, I won't give you the hacked code I wrote to generate multisend test cases...

[bitcoinex]

How would look multitransaction with several entries of identical addresses with identical amounts? How they will be different for JSON client?

The question is not idle, it is necessary for services like http://bitcoindarts.movoda.net/ but who can accept payments several times at the same address

[Gavin Andresen]

How would look multitransaction with several entries of identical addresses with identical amounts? How they will be different for JSON client?

They won't be different-- you will get two entries that are identical.

Bitcoin will sum them up for you if you use the getbalance or getreceivedby* RPC commands.

[theymos]

How would look multitransaction with several entries of identical addresses with identical amounts? How they will be different for JSON client?

The question is not idle, it is necessary for services like http://bitcoindarts.movoda.net/ but who can accept payments several times at the same address

Two different transactions to the same address will have different txids (and possibly other info).

[Gavin Andresen]

Two different transactions to the same address will have different txids (and possibly other info).

I thought bitcoinex was asking about the weird multisend case, where there is one Transaction (so one txid), but two or more TxOuts with the same amount to the same address.

[bitcoinex]

How would look multitransaction with several entries of identical addresses with identical amounts? How they will be different for JSON client?

They won't be different-- you will get two entries that are identical.

Bitcoin will sum them up for you if you use the getbalance or getreceivedby* RPC commands.

But if I want use a single address to receive payments many times? For a casino it is very convenient: user sends money, the system takes money and shows the result of the game. Then again and again, without registration on casino site and without browser at all - enough to save the address to the address book to play from time to time.

In this case, multi-transaction for whatever reason, contains twice the same address will cause an error of reception of part of the amount.

[davout]

But if I want use a single address to receive payments many times? For a casino it is very convenient: user sends money, the system takes money and shows the result of the game. Then again and again, without registration on casino site and without browser at all - enough to save the address to the address book to play from time to time.

In this case, multi-transaction for whatever reason, contains twice the same address will cause an error of reception of part of the amount.

Yea, that particular edge case makes it pretty hard to track payments and map the transactions to database records

[Gavin Andresen]

Yea, that particular edge case makes it pretty hard to track payments and map the transactions to database records

If you expect a one-to-one relationship between transactions and bitcoin addresses, then yes, a multisend will be a problem for you.

If I were implementing the anonymous fund-with-a-bitcoin-address system, I would do something like:

Customer "Ed" gives a "send winnings to address"-- lets say it just happens to be   1Ed....
Casino gives a funding address -- lets call that address   1fundEd...

Casino creates an account named "1Ed..." and associates it with address 1fundEd.
So any coins Ed sends to 1fundEd....  go into the 1Ed... account.

When Ed wants to place a bet, casino checks to see if he has money:   getbalance 1Ed....
If he does, he can place a bet.
If he wins, casino sends money:
  move BANK 1Ed...  <amount Ed won above his bet>
  sendfrom 1Ed... 1Ed.... <amount Ed won>   # Account name and cash-out address are the same.
If he loses:
  move 1Ed... BANK <amount Ed lost>

listtransactions is for showing Ed a detailed list of what happened to his account.

[bitcoinex]

Yea, that particular edge case makes it pretty hard to track payments and map the transactions to database records

If you expect a one-to-one relationship between transactions and bitcoin addresses, then yes, a multisend will be a problem for you.

If I were implementing the anonymous fund-with-a-bitcoin-address system, I would do something like:

Customer "Ed" gives a "send winnings to address"-- lets say it just happens to be   1Ed....
Casino gives a funding address -- lets call that address   1fundEd...

Casino creates an account named "1Ed..." and associates it with address 1fundEd.
So any coins Ed sends to 1fundEd....  go into the 1Ed... account.

When Ed wants to place a bet, casino checks to see if he has money:   getbalance 1Ed....
If he does, he can place a bet.
If he wins, casino sends money:
  move BANK 1Ed...  <amount Ed won above his bet>
  sendfrom 1Ed... 1Ed.... <amount Ed won>   # Account name and cash-out address are the same.
If he loses:
  move 1Ed... BANK <amount Ed lost>

listtransactions is for showing Ed a detailed list of what happened to his account.

In fact, it is possible to work without registration - multitransactions amounts occur at the same time, just sent it directly to the database and have more transactions with this txid will not be.

[Gavin Andresen]

Pulled into git integration repository.