Moving forward with Armory

[goatpig]

For Linux packages, run this python script:

https://github.com/goatpig/BitcoinArmory/blob/master/dpkgfiles/make_deb_package.py

For Windows, run this .bat:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BitcoinArmory_SwigDLL/build_installer_64.bat

For OSX, it's one of these here:

https://github.com/goatpig/BitcoinArmory/tree/master/osxbuild

[achow101]

For Linux packages, run this python script:

https://github.com/goatpig/BitcoinArmory/blob/master/dpkgfiles/make_deb_package.py

For Windows, run this .bat:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BitcoinArmory_SwigDLL/build_installer_64.bat

For OSX, it's one of these here:

https://github.com/goatpig/BitcoinArmory/tree/master/osxbuild

Is there no cross compiling?

[droark]

For Linux packages, run this python script:

https://github.com/goatpig/BitcoinArmory/blob/master/dpkgfiles/make_deb_package.py

For Windows, run this .bat:

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BitcoinArmory_SwigDLL/build_installer_64.bat

For OSX, it's one of these here:

https://github.com/goatpig/BitcoinArmory/tree/master/osxbuild

Is there no cross compiling?

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.

[achow101]

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)

[droark]

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.

[achow101]

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.

What about merging in this branch: https://github.com/etotheipi/BitcoinArmory/tree/autotools-gitian from the original repo? Needs rebase obviously.

[droark]

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.

What about merging in this branch: https://github.com/etotheipi/BitcoinArmory/tree/autotools-gitian from the original repo? Needs rebase obviously.

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.

[goatpig]

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 ).

[droark]

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.

[roterdam]

how it's the most easy way to install armory to recover my btc?
i cannot access to bitcoinarmory.com
thanks

[achow101]

how it's the most easy way to install armory to recover my btc?
i cannot access to bitcoinarmory.com
thanks

Get the downloads from https://github.com/goatpig/BitcoinArmory/releases

[goatpig]

Should I add those files in too or leave as is?

I'll compare yours to what is in there already and take a decision. Only need one instruction file per OS, the rest I'll delete.

[CoinCidental]

is there a link for the last stable version i can download ?

the main site seems to be still down .....

[goatpig]

https://github.com/goatpig/BitcoinArmory/releases

[bitprospector]

   I know you have a lot on your mind at present.

   For the last month, I've been trying to update my
blockchain with no luck. I'm on a slow DSL connection
of around 34-35kb.

   Armory has hung at 65-70% blockchain download
3 different times. I've had to go under the hood each
time to delete everything except my wallet.

   The newly updated Armory/Bitcoin will not make
a connection using torrent...which would probably
shorten the download days...so have had to switch
back to bitcoin-qt.

   Any idea why kept hanging at 65-70% download,
and why torrent won't connect ?

   Is there any way to speed up complete update ?

   Any suggestions will be appreciated.

   bitprospector
   

[goatpig]

ATI shutdown their website, torrents seedboxes included.

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.

[achow101]

ATI shutdown their website, torrents seedboxes included.

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

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.

   I know you have a lot on your mind at present.

   For the last month, I've been trying to update my
blockchain with no luck. I'm on a slow DSL connection
of around 34-35kb.

   Armory has hung at 65-70% blockchain download
3 different times. I've had to go under the hood each
time to delete everything except my wallet.

   The newly updated Armory/Bitcoin will not make
a connection using torrent...which would probably
shorten the download days...so have had to switch
back to bitcoin-qt.

   Any idea why kept hanging at 65-70% download,
and why torrent won't connect ?

   Is there any way to speed up complete update ?

   Any suggestions will be appreciated.

   bitprospector
   

It looks like your main problem is slow internet speed, and there really is nothing that can be done to speed it up except get better internet.

[goatpig]

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.

[droark]

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.

[achow101]

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?