BitShares Forum
Main => Technical Support => Topic started by: monsterer on December 09, 2014, 11:18:46 am
-
I'm trying to find the best way to determine whether a given transaction is a deposit.
Using wallet_account_transaction_history, we have a structure returned which contains multiple ledger entries and I'm not sure if you could have both a deposit and a withdraw inside that array?
Using blockchain_get_transaction we have an array of 'operations' inside the 'trx' field which typically contains both withdraw_op_type and deposit_op_type.
Is there an easy way to tell whether a given transaction is a deposit? Just some clarity on the subject would be great :)
Cheers, Paul.
-
I'm trying to find the best way to determine whether a given transaction is a deposit.
Using wallet_account_transaction_history, we have a structure returned which contains multiple ledger entries and I'm not sure if you could have both a deposit and a withdraw inside that array?
Using blockchain_get_transaction we have an array of 'operations' inside the 'trx' field which typically contains both withdraw_op_type and deposit_op_type.
Is there an easy way to tell whether a given transaction is a deposit? Just some clarity on the subject would be great :)
Cheers, Paul.
It is of course a matter of perspective, for one user it is a deposit the other it is a withdraw. For what you are doing it is probably safe to simply check the owner address of the claim_with_signature deposit operation belongs to your account:
wallet_account_list_public_keys ACCOUNT_NAME
wallet_dump_private_key BTS_ADDRESS
-
Isnt there a call like
wallet_verify_titan_tx .. or so?
-
the toaccount of wallet_account_transaction_history will tell you it was sent to you (thus deposit). This list will only update if wallet is unlocked.
-
the toaccount of wallet_account_transaction_history will tell you it was sent to you (thus deposit). This list will only update if wallet is unlocked.
If you register your own account the to and from are both you inside the transaction, so this rule doesn't quite work :)
-
Depends what you mean by deposit?
The individual operations you see from something like blockchain_get_transaction represent exactly what happened to the DAC.
-
Depends what you mean by deposit?
The individual operations you see from something like blockchain_get_transaction represent exactly what happened to the DAC.
My difficulty was in understanding which was a deposit to my account (deposit from their account) and which was a withdraw from my account (withdraw from their account).
-
the toaccount of wallet_account_transaction_history will tell you it was sent to you (thus deposit). This list will only update if wallet is unlocked.
+5% I must not understand the problem, because this^ seems to answer it as far as I can tell.
the toaccount of wallet_account_transaction_history will tell you it was sent to you (thus deposit). This list will only update if wallet is unlocked.
If you register your own account the to and from are both you inside the transaction, so this rule doesn't quite work :)
I think you could say this still applies, the registration is a fee, and is burned. The transaction is all fees and zero is deposited in the to_account
-
Inside the array of ledger_entries returned from wallet_account_transaction_history for 1 single transaction, can there be multiple different deposits?
-
Inside the array of ledger_entries returned from wallet_account_transaction_history for 1 single transaction, can there be multiple different deposits?
This is my php code for the ecommerce plugins which will get the accumulated deposit amount based on a desired account (your account name):
foreach($response['result'] as $txinfo)
{
// make sure the order was placed before it was paid on the blockchain, sanity check incase hash's match but tx is for wrong order.
// also make sure this tx is confirmed on the blockchain before processing it
if($txinfo['is_confirmed'] == true)
{
$timeStamp = $txinfo['timestamp'];
$trxId = $txinfo['trx_id'];
foreach($txinfo['ledger_entries'] as $tx) {
$toaccount = $tx['to_account'];
// could we get the asset by name aswell here? Another RPC call to get name
$txSymbol = btsGetAssetNameById($tx['amount']['asset_id'], $rpcUser, $rpcPass, $rpcPort);
$memo = $tx['memo'];
if($txSymbol != $asset && !$demoMode)
{
continue;
}
// sanity check, tx to account should match your configured account in admin settings
if($toaccount != $account)
{
continue;
}
// if this TX doesn't have the hash of the open order we are checking, skip this order
if(strpos($memo, $orderEHASH) == FALSE)
{
continue;
}
$accumulatedAmountPaid += ($tx['amount']['amount']/100000);
}
}
}
It will also check the asset you are looking for aswell as an order hash.. but that isn't important. I just iterate over all transactions... so each tx will have a toaccount etc... there is only one entry per tx I believe.
-
foreach($response['result'] as $txinfo)
{
// make sure the order was placed before it was paid on the blockchain, sanity check incase hash's match but tx is for wrong order.
// also make sure this tx is confirmed on the blockchain before processing it
if($txinfo['is_confirmed'] == true)
{
$timeStamp = $txinfo['timestamp'];
$trxId = $txinfo['trx_id'];
foreach($txinfo['ledger_entries'] as $tx) {
$toaccount = $tx['to_account'];
// could we get the asset by name aswell here? Another RPC call to get name
$txSymbol = btsGetAssetNameById($tx['amount']['asset_id'], $rpcUser, $rpcPass, $rpcPort);
$memo = $tx['memo'];
if($txSymbol != $asset && !$demoMode)
{
continue;
}
// sanity check, tx to account should match your configured account in admin settings
if($toaccount != $account)
{
continue;
}
// if this TX doesn't have the hash of the open order we are checking, skip this order
if(strpos($memo, $orderEHASH) == FALSE)
{
continue;
}
$accumulatedAmountPaid += ($tx['amount']['amount']/100000);
}
}
}
There's a bug there - you're dividing by a magic number (100000) when you should be dividing by the precision of the asset.
:)
edit: I see you're assuming that all ledger entries have the same 'from_account', is that a safe assumption?
-
Thanks... this should run against the server wallet so from account shouldnt matter... the hash makes sure i got the right tx.
-
Thanks... this should run against the server wallet so from account shouldnt matter... the hash makes sure i got the right tx.
But 'from_account' is the customer who's paying you, right? I'm just wondering if it's possible to have two different 'from_account's inside the ledger array?
-
Thanks... this should run against the server wallet so from account shouldnt matter... the hash makes sure i got the right tx.
But 'from_account' is the customer who's paying you, right? I'm just wondering if it's possible to have two different 'from_account's inside the ledger array?
There will be many diff from accounts.. U mean two different ppl paying for same thing? Well there is a hash too for that reason but if they know the hash then yes you can have someone else pay for you if you really want. The customer is not reequired to validate which account they are paying from when paying an order.
-
Thanks... this should run against the server wallet so from account shouldnt matter... the hash makes sure i got the right tx.
But 'from_account' is the customer who's paying you, right? I'm just wondering if it's possible to have two different 'from_account's inside the ledger array?
There will be many diff from accounts.. U mean two different ppl paying for same thing? Well there is a hash too for that reason but if they know the hash then yes you can have someone else pay for you if you really want. The customer is not reequired to validate which account they are paying from when paying an order.
No, I mean within 1 transaction there is a ledger_entries array. Inside that array each entry has a 'from_account' field. That suggests to me that inside 1 transaction it might be possible to have several different people sending you assets. I just want clarity on whether this is possible or not.
-
Thanks... this should run against the server wallet so from account shouldnt matter... the hash makes sure i got the right tx.
But 'from_account' is the customer who's paying you, right? I'm just wondering if it's possible to have two different 'from_account's inside the ledger array?
There will be many diff from accounts.. U mean two different ppl paying for same thing? Well there is a hash too for that reason but if they know the hash then yes you can have someone else pay for you if you really want. The customer is not reequired to validate which account they are paying from when paying an order.
No, I mean within 1 transaction there is a ledger_entries array. Inside that array each entry has a 'from_account' field. That suggests to me that inside 1 transaction it might be possible to have several different people sending you assets. I just want clarity on whether this is possible or not.
Yea I see.. if this is true we will have to loop through each tx to ensure we got all of the received coins we are looking for. I havent' seen this in my tests.. even sending multiple tx's within 10s so I can tentatively say that its 1 and not N inputs.
-
Yea I see.. if this is true we will have to loop through each tx to ensure we got all of the received coins we are looking for. I havent' seen this in my tests.. even sending multiple tx's within 10s so I can tentatively say that its 1 and not N inputs.
I don't know about you, but I wouldn't be comfortable with releasing software dealing with money without knowing answers like this *for certain* :)
-
Yea I see.. if this is true we will have to loop through each tx to ensure we got all of the received coins we are looking for. I havent' seen this in my tests.. even sending multiple tx's within 10s so I can tentatively say that its 1 and not N inputs.
I don't know about you, but I wouldn't be comfortable with releasing software dealing with money without knowing answers like this *for certain* :)
Since there is no spec this is why we have to do codereviews with someone who can tell us right away aka bm.. i can look at the code too but cant be bothered to because im not at the release and testing phase yet. You should come up with a verification test that will cover these cases to ensure its good.. thats my plan anyway.
-
Thanks... this should run against the server wallet so from account shouldnt matter... the hash makes sure i got the right tx.
But 'from_account' is the customer who's paying you, right? I'm just wondering if it's possible to have two different 'from_account's inside the ledger array?
There will be many diff from accounts.. U mean two different ppl paying for same thing? Well there is a hash too for that reason but if they know the hash then yes you can have someone else pay for you if you really want. The customer is not reequired to validate which account they are paying from when paying an order.
No, I mean within 1 transaction there is a ledger_entries array. Inside that array each entry has a 'from_account' field. That suggests to me that inside 1 transaction it might be possible to have several different people sending you assets. I just want clarity on whether this is possible or not.
This is very possible, but does not happen in practice yet since there are no good tools to do so. A transaction can pretty much have any arbitrary set of operations--this is why the transaction scanning (and thus history) is currently being rewritten (see https://github.com/BitShares/bitshares/issues/845) to treat transfers effectively as inputs and outputs--like in bitcoin.
-
This is very possible, but does not happen in practice yet since there are no good tools to do so. A transaction can pretty much have any arbitrary set of operations--this is why the transaction scanning (and thus history) is currently being rewritten (see https://github.com/BitShares/bitshares/issues/845) to treat transfers effectively as inputs and outputs--like in bitcoin.
Thanks vikram, that's good to know. For safety, do you suggest we parse every ledger entry inside each transaction as it's own 'micro' transaction with potential unique sender and receiver?
-
This is very possible, but does not happen in practice yet since there are no good tools to do so. A transaction can pretty much have any arbitrary set of operations--this is why the transaction scanning (and thus history) is currently being rewritten (see https://github.com/BitShares/bitshares/issues/845) to treat transfers effectively as inputs and outputs--like in bitcoin.
Thanks vikram, that's good to know. For safety, do you suggest we parse every ledger entry inside each transaction as it's own 'micro' transaction with potential unique sender and receiver?
Yes. Please be careful regardless, however. The current scanning and ledger construction code is honestly pretty bad (hence the rewrite), and the ledger entries may be inaccurate for certain types of transactions.
-
Yes. Please be careful regardless, however. The current scanning and ledger construction code is honestly pretty bad (hence the rewrite), and the ledger entries may be inaccurate for certain types of transactions.
Can we have detail on exactly where the problems lie?
-
Yes. Please be careful regardless, however. The current scanning and ledger construction code is honestly pretty bad (hence the rewrite), and the ledger entries may be inaccurate for certain types of transactions.
Can we have detail on exactly where the problems lie?
Can't really say; the current code is too complex to analyze. I would just manually test the particular types of transactions you are interested in; e.g.: TITAN transfers, BitAsset transfers with yield, etc.