Pulled into git integration repository.
Topic: [PULL REQUEST] add address to listtransactions output (Read 1922 times)
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...
sendfrom 1Ed... 1Ed....
If he loses:
move 1Ed... BANK
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.
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...
sendfrom 1Ed... 1Ed....
If he loses:
move 1Ed... BANK
listtransactions is for showing Ed a detailed list of what happened to his account.
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.
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
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.
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.
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
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).
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.
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
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
Normal send; this one was:
sendfrom Test1 mytzSq1rkXzPidP9tHvfhDuzXqDSSvvaCg 100
And a wicked-crazy multisend:
sendfrom Test1 to:
mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX 3.0 AND
mo5JUdFcaHQdT6VbWxee9q7Y7U8GZta4QX 3.3 AND
msVM67gJZ4EKMRVdMjMFzwWEU32VzBUnqu 2.0
Again, multi-sends are non-standard transactions. And no, I won't give you the hacked code I wrote to generate multisend test cases...
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...
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 ?
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 ?
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.
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.
Jump to: