There is for RPi. Otherwise, no. The master plan, seen via some PRs up on the old Github, was to introduce Gitian and move towards a Core-like cross-build system once the Py3/Qt5 upgrade occurred.

Are we allowed to (from a licensing/legal standpoint) take those PRs from the old one and use them in the new one? Or would it be better to ask the users who submitted those PRs to resubmit them to the new one. (e.g. this one: https://github.com/etotheipi/BitcoinArmory/pull/312)

There is for RPi. Otherwise, no. The master plan, seen via some PRs up on the old Github, was to introduce Gitian and move towards a Core-like cross-build system once the Py3/Qt5 upgrade occurred.

Are we allowed to (from a licensing/legal standpoint) take those PRs from the old one and use them in the new one? Or would it be better to ask the users who submitted those PRs to resubmit them to the new one. (e.g. this one: https://github.com/etotheipi/BitcoinArmory/pull/312)

They were submitted by a former Armory intern. My personal guess is that, if it came down to a court case, the PRs would be acceptable. IANAL, obviously, and all attempts I've made to get any sort of answers haven't gotten anywhere. So, I don't think the code would be accepted if you tried to port it. If you want to be absolutely safe, you'll have to do a "clean room" implementation. You might be best off reading the PRs and going through the Core codebase. (Alas, Autotools is impossible to fully understand. You basically make it work by failing 'til you're no longer failing.) Cory Fields might be willing to answer some questions, although it sometimes took him weeks to answer any questions we had.

There is for RPi. Otherwise, no. The master plan, seen via some PRs up on the old Github, was to introduce Gitian and move towards a Core-like cross-build system once the Py3/Qt5 upgrade occurred.

Are we allowed to (from a licensing/legal standpoint) take those PRs from the old one and use them in the new one? Or would it be better to ask the users who submitted those PRs to resubmit them to the new one. (e.g. this one: https://github.com/etotheipi/BitcoinArmory/pull/312)

They were submitted by a former Armory intern. My personal guess is that, if it came down to a court case, the PRs would be acceptable. IANAL, obviously, and all attempts I've made to get any sort of answers haven't gotten anywhere. So, I don't think the code would be accepted if you tried to port it. If you want to be absolutely safe, you'll have to do a "clean room" implementation. You might be best off reading the PRs and going through the Core codebase. (Alas, Autotools is impossible to fully understand. You basically make it work by failing 'til you're no longer failing.) Cory Fields might be willing to answer some questions, although it sometimes took him weeks to answer any questions we had.

There is for RPi. Otherwise, no. The master plan, seen via some PRs up on the old Github, was to introduce Gitian and move towards a Core-like cross-build system once the Py3/Qt5 upgrade occurred.

Are we allowed to (from a licensing/legal standpoint) take those PRs from the old one and use them in the new one? Or would it be better to ask the users who submitted those PRs to resubmit them to the new one. (e.g. this one: https://github.com/etotheipi/BitcoinArmory/pull/312)

They were submitted by a former Armory intern. My personal guess is that, if it came down to a court case, the PRs would be acceptable. IANAL, obviously, and all attempts I've made to get any sort of answers haven't gotten anywhere. So, I don't think the code would be accepted if you tried to port it. If you want to be absolutely safe, you'll have to do a "clean room" implementation. You might be best off reading the PRs and going through the Core codebase. (Alas, Autotools is impossible to fully understand. You basically make it work by failing 'til you're no longer failing.) Cory Fields might be willing to answer some questions, although it sometimes took him weeks to answer any questions we had.

Again, my understanding is that using the code as-is may not be safe from a legal standpoint. Who knows, maybe that branch would be safe since it apparently never got pulled. If others want to merge it in and goatpig wants to accept the merge, go for it. I'm not doing it. I'm happy to contribute elsewhere but I'm not touching this stuff until there's more clarity regarding the situation.

I won't accept a PR that has anything to do with Joseph's work for ATI until I can clear that with the shareholders first. Do not keep your hopes up. Use Joseph's work as reference as much as you'd like though.

For people interested in adding deterministic build support for Armory, please focus on a single Linux distro at first (ideally Debian 7 or 8 ).

Honestly, while the PRs look pretty large, the code isn't that difficult to port over. A lot of the files are taken from elsewhere and can basically be reused as-is. It's the files Joseph & I (mostly Joseph, granted) wrote where you need to be careful. Keep in mind that a lot of the complexity comes from trying to do this stuff in a robust manner. My goal was to have a first delivery that wasn't necessarily perfect but was robust enough that cross-compiling and such, including Windows/MinGW, would be reasonably easy. To that end, we actually had some internal test builds made to prove that everything worked. It was a lot of work but it was worthwhile, IMO. I'd recommend that anybody who starts from scratch use the notes in the PRs as guides and go from there. Even if you don't necessarily support anything other than specific Linux builds out the door, try not to hard-code anything that'll make it difficult to support other builds later.

Just my $.02. Do as you please. I'm just saying that a little pain upfront will save you lots of pain later.

You should update to Core 0.12 (I believe they update the block checkpoints) and download the chain straight from that. Once it is sync'd, back up a copy of yours bitcoin datadir folder for the good measure.

You should update to Core 0.12 (I believe they update the block checkpoints) and download the chain straight from that. Once it is sync'd, back up a copy of yours bitcoin datadir folder for the good measure.

They did not update the checkpoints because apparently the checkpoints don't actually help. Those checkpoints haven't been updated since 2011.

We should also probably remove the bootstrap torrent stuff. I don't think it actually helps with the new versions of Bitcoin Core.

It was Alan's intention to remove that feature once sipa's EC library was turned on for sig verification. Now is the time then.

Strictly speaking, it's probably best to wait for an officially tagged version of libsecp256k1. That being said, I suppose a reasonable workaround would be to create a link on Git (can't remember how offhand but I should have it written down) that lets you do a symlink of sorts to code posted elsewhere. The code in 0.12 could be used and manually updated as needed.

We should also probably remove the bootstrap torrent stuff. I don't think it actually helps with the new versions of Bitcoin Core.

It was Alan's intention to remove that feature once sipa's EC library was turned on for sig verification. Now is the time then.

Strictly speaking, it's probably best to wait for an officially tagged version of libsecp256k1. That being said, I suppose a reasonable workaround would be to create a link on Git (can't remember how offhand but I should have it written down) that lets you do a symlink of sorts to code posted elsewhere. The code in 0.12 could be used and manually updated as needed.

Why do we need ilbsecp256k1 and what does that have to do with the bootstrap.dat?