Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some refactoring to make possible transactions checking client-side #728

Closed
wants to merge 7 commits into from

Conversation

ouziel-slama
Copy link
Contributor

Move sub functions outside get_tx_info2() because counterpary-cli needs the function decode_output() to check transactions generated by a server.

Add raw_unpack_data() method. This method don't use the database or the backend.
It is used by counterparty-client/gui to check transactions generated by counterparty-server.

see: CounterpartyXCP/counterparty-cli#34

param_name = message_module.FORMAT_DESCRIPTION[p]
params[param_name] = unpacked[p]
return params
except Exception as e:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is no good.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why? here I want to catch all possible errors. No matter what type of error, if there is one, that means that the data is incorrect.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there's a filesystem read error, e.g., that's not a problem with the unpacking, and it doesn't mean that the data is invalid.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah you are right! I will fix that.

@ouziel-slama
Copy link
Contributor Author

I moved transaction checking from counterparty-cli to counterparty-lib. After several attempts I have not managed to use the same functions at the end of transactions.construct(). Checks are too different in the two cases, and IMO wanting to absolutely use the same functions sounds like a solution in search of a problem.

Edit: however we can use the same checking functions in the API: https://github.com/CounterpartyXCP/counterpartyd/pull/728/files#diff-b4466fbb7c2afb413c8537b30b2d4bc7R285

@ouziel-slama ouziel-slama force-pushed the checktx branch 2 times, most recently from 5aef8a3 to cfa69bd Compare March 9, 2015 12:03
asset_id = data.pop(asset_param)
param_name = asset_param_list[asset_param]
try:
data[param_name] = util.generate_asset_name(asset_id, block_index=333501)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to try both ways? Shouldn't all newly created transactions use the new asset ids?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hum.. I don't think, for instance we can have a send transaction for an "old" asset.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, right. (I made that mistake before.)

@ouziel-slama
Copy link
Contributor Author

@adamkrellenstein, there is a problem to check btcpay transaction without database: it's impossible to get the address and amount corresponding to the order hash without querying the database.
To enable full client side validation, maybe we should add two mandatories parameters for btcpay: destination and amount.
Or we can show for confirmation to the user, these 2 parameters when the transaction is generated.
thought?

params['destination'] = params['feed_address']

# No destination
if asked_message_type in ['order', 'dividend', 'broadcast', 'cancel', 'destroy', 'execute', 'publish', 'rps', 'rpsresolve']:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Create new variables parsed_destinations = tx_info['destinations'].keys() and desired_destination = params[destination'], I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hum.. seems difficult.. I need yet to well test each transaction.. when done I will give a try.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EDIT: I think the code changed since you message, not sure if I understood well your remark.

'callable_': False,
'divisible': True
}
for param in data:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This block could be clearer, I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I broke the block in several checks.

@adamkrellenstein
Copy link
Member

You mean mandatory parameters to the create_btcpay call? Yes, I'm fine with adding those.

@ouziel-slama
Copy link
Contributor Author

yep! OK.

@ouziel-slama ouziel-slama force-pushed the checktx branch 2 times, most recently from 1eb272d to b61f3ca Compare March 9, 2015 15:49
@adamkrellenstein
Copy link
Member

@ouziel-slama, what's the status of this?

@ouziel-slama
Copy link
Contributor Author

@adamkrellenstein, the codebase is finished, but I need to add unit test for every RPC call.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.48%) to 69.34% when pulling 88079ec on checktx into 9c0e0f2 on develop.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.48%) to 69.34% when pulling 9e6ddea on checktx into 9c0e0f2 on develop.

@ouziel-slama
Copy link
Contributor Author

@adamkrellenstein, there is now enough tests for RPC calls... however the kickstart failed, not sure it's linked with this PR, but I will check that tonight.

ouziel-slama added 3 commits April 1, 2015 23:26
`counterpary-cli` needs the function `decode_output()` to check transactions generated by a server.
This method don't use the database or the backend.
It used by `counterparty-client/gui` to check generated transaction generated by `counterparty-server`.
@coveralls
Copy link

Coverage Status

Coverage increased (+0.58%) to 65.93% when pulling 38c5946 on checktx into 7076bc0 on develop.

@ouziel-slama
Copy link
Contributor Author

OK, I rebased the branch and the kickstart works well.. don't know what happen the last time I tried..

@adamkrellenstein
Copy link
Member

@ouziel-slama, why/how did the kickstart fail? Are we sure it won't be an intermittent problem?

@ouziel-slama
Copy link
Contributor Author

@adamkrellenstein: the parsing didn't stop at BLOCK_START, he continued until block 1.. I don't understand how it's happened (that mean that the kickstart just skip the first block, see here: https://github.com/CounterpartyXCP/counterpartyd/blob/master/counterpartylib/lib/blocks.py#L835)
I ran two kickstarts without problems.. I will launch more to be sure.

@adamkrellenstein
Copy link
Member

Created this issue #749.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.54%) to 64.85% when pulling 38c5946 on checktx into a4225b0 on develop.

@chiguireitor
Copy link
Contributor

This Pr although useful, has diverged too much from the codebase, closing this and saving on branch pr728

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants