search

dexX7 / java-libbitcoinconsensus

JNA binding and Java wrapper for libbitcoinconsensus
Other
9 stars 3 forks source link

Add libbitcoinconsensus to the project as resource #13

Open dexX7 opened 9 years ago

dexX7 commented 9 years ago

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:

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

msgilligan commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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?