Topic: getting the input addresses of a transaction. (Read 953 times)
once more tks for the explanation, and Gavin, tks for the batch tip.
So I'm wondering, is there any better way to get the input addresses on a transaction?
As was pointed out, getrawtransaction
If your JSON-RPC library supports it, you could also use a 'batch' request to get all of the inputs in one round-trip. See http://www.jsonrpc.org/specification#batch
ok, tk you guys for the information. for now I'm just trying to figure things out.
what I wanna understand is, I see that this is a problem if someone send bitcoins through mtgox wallet or if someone make the payment for you (which seems like a exceptional case, but can't be discarded). but I read that the bitcoin client could become very slow if there's a lot of address in the wallet.
is this true? if so, how much addresses will the qt client supports before becoming slow?
what I wanna understand is, I see that this is a problem if someone send bitcoins through mtgox wallet or if someone make the payment for you (which seems like a exceptional case, but can't be discarded). but I read that the bitcoin client could become very slow if there's a lot of address in the wallet.
is this true? if so, how much addresses will the qt client supports before becoming slow?
Most people don't have to worry about getting too many addresses in their wallet. There is no number that is "too many", because it depends on your computer.
Basically, for each transactions that comes in (whether by protocol or by block), your node needs to compare the inputs and outputs with all of your keys, looking for matches. The good news is that modern computers are pretty fast. The better news is that we can probably switch to bloom filters or something similar if it gets to be a widespread problem in the future.
People usually only get this problem if they accept tons and tons of incoming payments, like mtgox or other big names, and they understand that they have to find their own solution (for now).
As to your first question about the transaction tracking, looking backward is the only way to find out where coins were in the past, and what you are doing is about the best you can do. There are no features in the system to make this step easier, because it is dangerous, not useful. If you want to follow transactions around the network as an academic or intellectual exercise, feel free. But please be careful that you do not delude yourself into thinking that you have found "the sender", as the concept does not exist in bitcoin. If you need to collect state information about an incoming transaction, you must collect that information in advance and associate it with the payment address that you provide.
ok, tk you guys for the information. for now I'm just trying to figure things out.
what I wanna understand is, I see that this is a problem if someone send bitcoins through mtgox wallet or if someone make the payment for you (which seems like a exceptional case, but can't be discarded). but I read that the bitcoin client could become very slow if there's a lot of address in the wallet.
is this true? if so, how much addresses will the qt client supports before becoming slow?
what I wanna understand is, I see that this is a problem if someone send bitcoins through mtgox wallet or if someone make the payment for you (which seems like a exceptional case, but can't be discarded). but I read that the bitcoin client could become very slow if there's a lot of address in the wallet.
is this true? if so, how much addresses will the qt client supports before becoming slow?
If you add the option 1 after the transaction hash in your getrawtransaction call it'll automatically decode the hex for you, saving that second call and some latency. At least that's how it works on the command line; I'm pretty sure the actual HTTP-json RPC interface is identical.
The latter transaction is taking longer because it's bigger. To be exact it's 26 times bigger, (5122 bytes vs 193) and it's taking 50 times longer, so pretty much exactly how much longer you'd expect it to take.
That said, Danny is right. Depending on the input address is almost always a bad idea.
The latter transaction is taking longer because it's bigger. To be exact it's 26 times bigger, (5122 bytes vs 193) and it's taking 50 times longer, so pretty much exactly how much longer you'd expect it to take.
That said, Danny is right. Depending on the input address is almost always a bad idea.
This is generally a bad idea. People need to stop trying to find input addresses, they aren't typically good for the things people try to use them for. It would be far easier and better to simply ask users to supply a payout address.
I suspect that kjj or DeathAndTaxes will be here in a bit to share their opinions on how you shouldn't be doing this as well.
For explanations (about how this is a bad idea) given to a few others who have asked a similar question see:
https://bitcointalksearch.org/topic/m.1435502
https://bitcointalksearch.org/topic/m.1429404
https://bitcointalksearch.org/topic/m.498915
I suspect that kjj or DeathAndTaxes will be here in a bit to share their opinions on how you shouldn't be doing this as well.
For explanations (about how this is a bad idea) given to a few others who have asked a similar question see:
https://bitcointalksearch.org/topic/m.1435502
https://bitcointalksearch.org/topic/m.1429404
https://bitcointalksearch.org/topic/m.498915
What I'm doing is (using the bitcoin rpc):
having the transaction id, I'm using the function getRawTransaction to get the hex and after this I'm using the decoderawtransaction to get the json. So, I'm navigating through all inputs and using the getRawTransaction and decoderawtransaction on each input to find the address.
When doing this on the transaction dcf2af38cebd8abf3a34897b7ef908033fedba825e2ba86a7f7079705e8b2376
it is taking something like 15 milliseconds, but doing this in the transaction: 49a26581cf176de5c13452e773dd7fcae6721acaf0bca5b71a26059da190baa4 it's taking about 781 milliseconds.
So I'm wondering, is there any better way to get the input addresses on a transaction?
tks in advance
having the transaction id, I'm using the function getRawTransaction to get the hex and after this I'm using the decoderawtransaction to get the json. So, I'm navigating through all inputs and using the getRawTransaction and decoderawtransaction on each input to find the address.
When doing this on the transaction dcf2af38cebd8abf3a34897b7ef908033fedba825e2ba86a7f7079705e8b2376
it is taking something like 15 milliseconds, but doing this in the transaction: 49a26581cf176de5c13452e773dd7fcae6721acaf0bca5b71a26059da190baa4 it's taking about 781 milliseconds.
So I'm wondering, is there any better way to get the input addresses on a transaction?
tks in advance
Jump to: