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

Add libbitcoinconsensus to the project as resource #13

Open
dexX7 opened this issue Sep 24, 2015 · 5 comments
Open

Add libbitcoinconsensus to the project as resource #13

dexX7 opened this issue Sep 24, 2015 · 5 comments
Labels

Comments

@dexX7
Copy link
Owner

dexX7 commented Sep 24, 2015

The library should be added to the project in one way or another.

Ideally there were some safe guards, to ensure the file was not tempered with.

This may include:

  • comparing file hashes against known references (how? as test?)
  • a lot more tests

The library should be build via Gitian, or extracted from the official release.

@dexX7 dexX7 added the release label Sep 24, 2015
@msgilligan
Copy link
Collaborator

I see this PR as being about two things, but we can create a separate PR if you want to split it up.

#1 - Automating the process of loading in the library binaries
#2- Adding the binaries to the distribution

I'm actually more interested in #1 at the present because I want to use this project to test various binaries. I was thinking the next step would be to replace the download and verify code you have in the .travis.yml file with roughly equivalent code in build.gradle. That will allow people to easily configure the test to use different builds of libbitcoinconsensus. Does that sound like a reasonable approach?

@msgilligan
Copy link
Collaborator

It would also be nice to be able to download the test JSON files that match the version of the lib we're testing.

@dexX7
Copy link
Owner Author

dexX7 commented Sep 22, 2016

Automating the process of loading in the library binaries

Sorry, can you please clarify? If the library is locally installed, then it should be available without providing an explicit path. But I assume you were referring to something else?

It would also be nice to be able to download the test JSON files that match the version of the lib we're testing.

I agree! It looks like there are different sets of tests for different versions, and for example the current test set fails with 0.13 libbitcoinconsensus, as far as I can see.

@msgilligan
Copy link
Collaborator

Sorry, can you please clarify?

My idea is to add the rough equivalent of what your .travis.yml file does to download the libraries to the Gradle file. That way a user can change some variables (properties file) to run the test against different versions of bitcoin. We may also want (need) to pull different versions of the JSON test files.

the current test set fails with 0.13 libbitcoinconsensus

I'm wondering if we should update the default (checked-in) tests to match the latest (released?) version of Bitcoin Core...

@dexX7
Copy link
Owner Author

dexX7 commented Sep 26, 2016

My idea is to add the rough equivalent of what your .travis.yml file does to download the libraries to the Gradle file.

Ah gotcha, so you want to download the library files via Gradle. Sounds good to me as a start. We might provide different versions (e.g. libs from 0.10-0.13).

I'm wondering if we should update the default (checked-in) tests to match the latest (released?) version of Bitcoin Core...

Generally I'd say yes. However, I'm not sure how to deal with changes in the interface. There is a new bitcoinconsensus_verify_script_with_amount since 0.13, which isn't available in earlier versions. If we are going to provide support for the older libs, this could be an issue?

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

No branches or pull requests

2 participants