Moving forward with Armory

[goatpig]

As Alan stated in his thread (https://bitcointalk.org/index.php?topic=1351792.0), Armory as a business is essentially in limbo for the time being. That thread is locked on purpose, if you'd like to discuss it, please do so here instead.

The reality is that Armory's IP is in a state of pseudo deadlock. There was an attempt to have it acquired by another company in order to keep funding development, but the time cost of such an acquisition got the best us. Simply put it takes too long to get things right and resume operations in a way that satisfies all parties involved. In the mean time, people aren't getting paid and they eventually run out of resources.

There is a financial reality that every one has to deal with, and unfortunately it has caught up with us. It pains me to see so many talented developers leave this space, even more so knowing how long they stuck around on their own dime. It was an honor and a pleasure to work with these people and I would like to thank them for their effort, passion and dedication.

-----------------------

Now, moving forward, I appear to be the deranged hippie of the band, for I still believe I have a few punches left in me. As such, I will be resuming open source development of Armory. It will take place on my own public github repo, forked from the last state of Alan's own repo. This means 2 things:

1) Development has to resume from 0.93.3 due to the IP entanglement. It means I'll be spending my first few weeks as lead reimplementing the DB changes behind version 0.94.

2) All the IP up to 0.93.3 is property of Armory Technologies Inc. (ATI), under GNU Affero General Public License, Version 3.

3) All new code I submit to my fork will be my property, under the MIT license.

-----------------------

My current plans for development are as follow (in descending priority):
1) 0.94 DB changes
2) BIP32/44 support
3) SegWit and RBF support (hopefully Im done with the new wallets before SegWit goes live on the mainnet)
4) Everything else

EDIT: for the sake of speed and simplicity, I will not redevelop supernode along the 0.94 DB changes. I am phasing that feature out for the moment, until I got time to enjoy redeveloping it.

-----------------------

As for funding, this all done on my own resources. I have no job currently, as I want to catch up with all that Armory is missing. However, as an Armory user and a member of this community, you should expect the following: at some point it is likely I will ask for development to be crowd funded. That day isn't here yet and it isn't guaranteed that it will ever come. If it does come, here is what will happen:

I will ask the community to pay me for further development. I'll list a set of features to develop, let users discuss them, modify them, propose new ones, change the priority around, all the good stuff. With that said I will lay out a time estimate for each task, and a hourly fee. That part will be discussed with the community too. Once we get to an agreement, these figures will used for a crowd funding campaign. If the targets are met, I will continue to work Armory full time. If they are not, I will have to get a job and work on Armory on my free time. I'm fine with either possibilities but I'd rather work on Armory full time if I had a choice.

[1715300326]

1715300326

[1715300326]

1715300326

[1715300326]

1715300326

[1715300326]

1715300326

[Roy Badami]

First off, many thanks to both @etotheipi and @goatpig for all you've done, and continue to do, for the Bitcoin community.

Two quick questions for goatpig:

1. Any chance of setting up a download location for the open source project, with 0.93.3 builds?  This will at least make Armory useable again to a wider community.

2. Will your open source project continue to use the Armory name, or is that a trademark of ATI?

[achow101]

I hope to be able to help with armory development in the future, I just need to brush up on my python and c++.

Just a couple of questions
IIRC the announcements tab got its announcements from Armory's servers. Now that the company is no longer a thing, where will the announcements come from or will that be removed due to the cost of maintaining a server?
How come previous code for 0.94 cannot be used? Didn't you say that you also had a copy of that branch before it was removed? If it is because of licensing, can't you just ask Alan for permission to use it, or is there some legal issue with the company that prevents this?

[goatpig]

First off, many thanks to both @etotheipi and @goatpig for all you've done, and continue to do, for the Bitcoin community.

Two quick questions for goatpig:

1. Any chance of setting up a download location for the open source project, with 0.93.3 builds?  This will at least make Armory useable again to a wider community.

2. Will your open source project continue to use the Armory name, or is that a trademark of ATI?

1) I will have to figure things out on this front. I have no access to the current website and I expect it to be off limit (maybe I'm wrong?). If the community wishes to participate on that front, I'll be happy to provide signed builds, but no 0.93 builds. I expect to get into a testing phase for the redone 0.94 soon enough.

2) No idea. My current expectation is that ATI will graciously let me use that name. Otherwise, I'll consult with the community on what the new name should be.

[goatpig]

I hope to be able to help with armory development in the future, I just need to brush up on my python and c++.

Pull requests are welcomed. It's preferable if you consult with me on what you intent to develop. It all needs to be MIT licensed.

IIRC the announcements tab got its announcements from Armory's servers. Now that the company is no longer a thing, where will the announcements come from or will that be removed due to the cost of maintaining a server?

Afaik the announcement system is down to begin with as it was not updated in a while and the URL changed anyways. This is again something to be discussed with the community. I can't push updates to old clients as the the URL for announcements is hard coded to ATI servers, so I wonder if it's worth modifying that URL in the fork at all, as opposed to just disabling the feature for now.

How come previous code for 0.94 cannot be used? Didn't you say that you also had a copy of that branch before it was removed? If it is because of licensing, can't you just ask Alan for permission to use it, or is there some legal issue with the company that prevents this?

Alan doesn't legally own the code. He is a share holder in a company that owns the code. Simply put it isn't his decision to make.

I have access to much more than just 0.94, but releasing that would and basing an open source fork of Armory off of that would create a legal burden. I don't want to jeopardize the project to jump some hoops. 99% of what's in 0.94 is my work, I know how to redo it (the new stuff will actually be faster and more robust).

[Carlton Banks]

Concur with Roy, massive thanks to etotheipi, goatpig, Doug, and at least 2 other guys I forgot the name of.

Might also be an idea might to try to get Armory onto the debian/arch/gentoo/red hat etc repo, to take some traffic pressure off your new server. Torrent published either here or on the new website would be a further idea (but you could argue pretty much anyone here on this forum can do that themselves). Bitcoin.org publicly seeds all the new bitcoin releases with bittorrent over http, that's a way to go also.

[achow101]

Pull requests are welcomed. It's preferable if you consult with me on what you intent to develop. It all needs to be MIT licensed.

I was thinking about working on RBF.

Afaik the announcement system is down to begin with as it was not updated in a while and the URL changed anyways. This is again something to be discussed with the community. I can't push updates to old clients as the the URL for announcements is hard coded to ATI servers, so I wonder if it's worth modifying that URL in the fork at all, as opposed to just disabling the feature for now.

I think it would be best to disable that feature for now.

Also, what about work on gitian/deterministic builds?

[goatpig]

I was thinking about working on RBF.

To detect or create RBF transactions? For both you would need the C++ side to feed you some sort of RBF flag for each UTXOs. I created a branch on my fork called RBF_PR. It is based off of master. Feel free to fork that repo and work in that branch. Assume you are getting an RBF flag from ZC UTXOs, I'll add that extra bit of information once I'm done with the new DB. Please keep it all on the Python to simplify the merge.

Also, what about work on gitian/deterministic builds?

I can't use any of that, will have to go at it from scratch too. Not sure about the priority on this, although I value that feature a lot.

[Patel]

What about lockboxes that were created?

Can funds be retrieved from lockboxes without using armory, with addresses, public keys, and private keys?

[goatpig]

What about lockboxes that were created?

Can funds be retrieved from lockboxes without using armory, with addresses, public keys, and private keys?

The lockbox feature isn't going away. These are multisig transactions, you can extract the data and recreate the script to spend the coins without Armory (with some effort, mind you).

[RoadStress]

Thank you etotheipi for everything! Sorry it didn't work out and good luck in your future ventures!

Now, moving forward, I appear to be the deranged hippie of the band, for I still believe I have a few punches left me. As such, I will be resuming open source development of Armory. It will take place on my own public github repo, forked from the last state of Alan's own repo.

Thank you very much goatpig (and all the contributors) for your effort!

[Roy Badami]

For both you would need the C++ side to feed you some sort of RBF flag for each UTXOs.

Core 0.12 has an RPC call to tell you whether a tx opts in to RBF (which AIUI also checks whether an unconfirmed parent tx opts in).

EDIT: Although perhaps it's only useable if the tx pays to an address in the Core wallet - I haven't looked at what it does so I don't know.

EDIT: See https://github.com/bitcoin/bitcoin/pull/7222

[Bitcoinorama]

Many thanks to both @etotheipi and @goatpig for all you've done,

please any chance to keep Armory alive and include Trezor support?

[goatpig]

Core 0.12 has an RPC call to tell you whether a tx opts in to RBF (which AIUI also checks whether an unconfirmed parent tx opts in).

Armory only sets up an RPC connection to Core when running the auto bitcoind management. I'd prefer a solution that covers ever case.

EDIT: Although perhaps it's only useable if the tx pays to an address in the Core wallet - I haven't looked at what it does so I don't know.

Core keeps track of all ZC tx (otherwise Armory would not be able to see them). I expect the RPC would let you get the RBF flag by tx hash, regardless of the relevance to Core's own wallet.

[goatpig]

Many thanks to both @etotheipi and @goatpig for all you've done,

please any chance to keep Armory alive and include Trezor support?

Carlton Banks sums it all up in this thread: https://bitcointalk.org/index.php?topic=1350328.0

TLDR: need BIP32/44 first before implementing hardware wallets support.

[TraderTimm]

Thanks etothepi and goatpig, Armory is a high-octane wallet that has many features power users love.

As time winds on, please update this thread when you can. I understand that living comes first, then the things you love, then perhaps coding (they could overlap, possibly).

I'll be watching this space to see what evolves. I understand legalities can complicate things, just very glad you're willing to take it under your wing and continue.

[Roy Badami]

Armory only sets up an RPC connection to Core when running the auto bitcoind management. I'd prefer a solution that covers ever case.

I believe that 0.12 also includes some code that generates a temporary random RPC password if none is configured - and writes it to a file - to make it easier for local clients to use the RPC interface without requiring prior configuration.

EDIT: Don't know if this functionality is enabled in GUI mode, though, or only for bitcoind.

P.S. Out of curiosity, what does Armory currently use the RPC connection for?  Just wondering what I'm missing out on, given I don't have Armory managing my Core instance.

[bitpop]

Thanks armory is all I use

[goatpig]

P.S. Out of curiosity, what does Armory currently use the RPC connection for?  Just wondering what I'm missing out on, given I don't have Armory managing my Core instance.

Not that much really. Originally it was to retrieve blockchain download progress data from bitcoind. Now it's also used to query bitcoind for the proper fee on unsigned transactions.

[coins101]

Best of luck.

[Bitcoinorama]

Many thanks to both @etotheipi and @goatpig for all you've done,

please any chance to keep Armory alive and include Trezor support?

Carlton Banks sums it all up in this thread: https://bitcointalk.org/index.php?topic=1350328.0

TLDR: need BIP32/44 first before implementing hardware wallets support.

Thanks bro for the consideration and the swift response. I think I as many Trezors owners bought it with the hope Armory would support it as Armory has always been the goto cold storage and Trezor bridges the middle ground between cold storage and a safe hot wallet environment online.

Alan Reiner and Slush have long been heros in the eyes of most here and I think we all would like to see your respective open source technologies work with eachother.

It's prob worth firing a message to Slush as i'm sure he'd be willing to support any Trezor integration if you need it.

[BCB]

Alan's announcement thread is lock so I'll post here.  

Alan has always been one of the true good guys in Bitcoin.  Your contribution and documentation has been invaluable to the understanding and development of the protocol.  I hope you will someday be able to share the lessons learned in your journey to turn your passion for bitcoin in to a profitable business.  Looking forward to see where you will be applying your considerable talents next.

goatpig good luck with the further development of Armory.

[goatpig]

The lack of Trezor integration is an issue on our side. Trezor as an organization have made themselves available the few times we thought we could move forward with the integration and reached out to them.

[Blazed]

I have used only Armory for years now and will defenetly contribute once you ask for some funds. Thanks for all of the hard work and making by far the most secure/best software wallet around.  

[PRab]

I'm sorry to hear that Alan will no longer be working on Armory. Goatpig, I'm glad that you will be continuing the work. Armory has been my go-to wallet for many years. I appreciate all the hard work that you both put in.

[Ente]

This isn't the news I hoped for, but at least the situation is clear now.
Alan, you are an inspiration, even for non-developing folks. One of the few good guys I trust. Thank you for all you did, and please stick around Bitcoin for your next endeavour! :-)
Goatpig, I am super happy to have you here, the lone hippie of the bunch. Please don't rush things, but have enough pleasant non-computer time as well. Try to delegate things, ask us, the community, for what we might help you with.

I like the idea of a crowdfunded interactive featurewishlist. Nothing wrong with starting that earlier than later, it's been some time that you actually received financial compensation, eh?

One detail question: as I understand it, there was a 0.94 branch on github, which was removed again. Isn't all the code which was published automatically under GPL as well? What's the difference between .93 and .94?

Oh well, Rough times, but Armory simply is without alternatives. Let's do this!


Ente

[goatpig]

One detail question: as I understand it, there was a 0.94 branch on github, which was removed again. Isn't all the code which was published automatically under GPL as well? What's the difference between .93 and .94?

I am not versed in IP law so I can't give you a reason why. The only thing I have been told and that I know is that anything but 0.93.3 as it stands in Alan's public repo is off limit. This whole endeavor has made me a bit paranoid with IP tainting. I would rather be safe than sorry, and I won't try to go for more than what is perceived as a perfectly safe state to start from.

Try to delegate things, ask us, the community, for what we might help you with.

On that front, if anyone has advice on how to properly deal with code licensing (I'm adding MIT code a GPL3 codebase), particularly in how to do it without making a mess, I'm all ears.

[droark]

One detail question: as I understand it, there was a 0.94 branch on github, which was removed again. Isn't all the code which was published automatically under GPL as well? What's the difference between .93 and .94?

I am not versed in IP law so I can't give you a reason why. The only thing I have been told and that I know is that anything but 0.93.3 as it stands in Alan's public repo is off limit. This whole endeavor has made me a bit paranoid with IP tainting. I would rather be safe than sorry, and I won't try to go for more than what is perceived as a perfectly safe state to start from.

One thing I'd like to know - and I doubt Farhod knows, for understandable reasons - is if this includes failed pull requests. As I mentioned over on Reddit, there's some Autotools/Gitian code that would be great to add. It was aimed at 0.94 but never officially made it into the repo. Does that mean it's safe? I'd like to think so, as starting from scratch would suck. IANAL, unfortunately.

[solitude]

Does this mean Armory is on life support and will meet its demise within a year or so?

What does this mean for people with a fair number of bitcoins held in Armory?  Should we look for a new client for our bitcoins?

[achow101]

Does this mean Armory is on life support and will meet its demise within a year or so?

No, goatpig will continue development and the project will remain open source so people can still contribute and keep armory alive.

What does this mean for people with a fair number of bitcoins held in Armory?  Should we look for a new client for our bitcoins?

Nothing will happen. Your Bitcoin will be safe, you just won't get updated wallets if Armory does stop being developed. When new features come out, it would be a good idea to get a new client of course.

[solitude]

Does this mean Armory is on life support and will meet its demise within a year or so?

No, goatpig will continue development and the project will remain open source so people can still contribute and keep armory alive.

What does this mean for people with a fair number of bitcoins held in Armory?  Should we look for a new client for our bitcoins?

Nothing will happen. Your Bitcoin will be safe, you just won't get updated wallets if Armory does stop being developed. When new features come out, it would be a good idea to get a new client of course.

So let's say I go to prison for ten years, and Armory had stopped being developed one year into my prison sentence.

Would I be able to get out of prison nine years after Armory had stopped being developed, find my paper wallet, and get access to my bitcoins?

[achow101]

Does this mean Armory is on life support and will meet its demise within a year or so?

No, goatpig will continue development and the project will remain open source so people can still contribute and keep armory alive.

What does this mean for people with a fair number of bitcoins held in Armory?  Should we look for a new client for our bitcoins?

Nothing will happen. Your Bitcoin will be safe, you just won't get updated wallets if Armory does stop being developed. When new features come out, it would be a good idea to get a new client of course.

So let's say I go to prison for ten years, and Armory had stopped being developed one year into my prison sentence.

Would I be able to get out of prison nine years after Armory had stopped being developed, find my paper wallet, and get access to my bitcoins?

If you could find a working install of armory, yes. Hopefully there will be further development to make it compatible with other wallets and current standards, in which case, you would not need to have armory at all and the paper wallet would still be compatible with other wallets.

[Blazed]

Does this mean Armory is on life support and will meet its demise within a year or so?

No, goatpig will continue development and the project will remain open source so people can still contribute and keep armory alive.

What does this mean for people with a fair number of bitcoins held in Armory?  Should we look for a new client for our bitcoins?

Nothing will happen. Your Bitcoin will be safe, you just won't get updated wallets if Armory does stop being developed. When new features come out, it would be a good idea to get a new client of course.

So let's say I go to prison for ten years, and Armory had stopped being developed one year into my prison sentence.

Would I be able to get out of prison nine years after Armory had stopped being developed, find my paper wallet, and get access to my bitcoins?

I am sure finding a version would be easy even if it can not send coins. Once you imported the wallets just dump the keys and import into something else. I have a feeling that Armory will continue on for a while. I hope when he asks for dev funds people help out.

[achow101]

Just a thought:

Couldn't you just host the releases on Github using the release function? Just tag the releases and then upload the corresponding binaries for that release and tell people to download the binaries from there.

Also, github pages could be utilized to set up a website for the open source project. A project site could be set up using github pages and it would all be hosted by github for free. In announcements text file could be kept there and armory could pull the announcement from there.

If we go with that option, I could help as I have experience with setting up all of that stuff for github, although when it comes to web design and development you will need to get other people to help. Thankfully the github pages thing actually makes making a website there really easy.

[tss]

thank you for making an effort to maintain armory in open source.. it is a great product.  so sad that the company was not able to monetize the project to cover expenses.  i wish you luck in all the updates coming forward and would def send a few satoshi for donation to continue development.

[sandal]

Looking forward to the next iteration!  Thanks for continuing to support!!

[goatpig]

Just a thought:

Couldn't you just host the releases on Github using the release function? Just tag the releases and then upload the corresponding binaries for that release and tell people to download the binaries from there.

Also, github pages could be utilized to set up a website for the open source project. A project site could be set up using github pages and it would all be hosted by github for free. In announcements text file could be kept there and armory could pull the announcement from there.

If we go with that option, I could help as I have experience with setting up all of that stuff for github, although when it comes to web design and development you will need to get other people to help. Thankfully the github pages thing actually makes making a website there really easy.

That's a good suggestion. I like keeping the releases on github directly, makes my life easier (and everybody else's I suppose?). For the website I have to think about it. Apparently I could get access to armory.org through a friend and ex-Armory employee. It's a valid option to consider.

[btcsql]

Thank you for your continued work on this, goatpig. I'd be happy to pledge some support in the future when the time arises.

[coins101]

Happy to take a look at the IP issue and give you some informal feedback / personal view.

[STRML]

Just a thought:

Couldn't you just host the releases on Github using the release function? Just tag the releases and then upload the corresponding binaries for that release and tell people to download the binaries from there.

Also, github pages could be utilized to set up a website for the open source project. A project site could be set up using github pages and it would all be hosted by github for free. In announcements text file could be kept there and armory could pull the announcement from there.

If we go with that option, I could help as I have experience with setting up all of that stuff for github, although when it comes to web design and development you will need to get other people to help. Thankfully the github pages thing actually makes making a website there really easy.

That's a good suggestion. I like keeping the releases on github directly, makes my life easier (and everybody else's I suppose?). For the website I have to think about it. Apparently I could get access to armory.org through a friend and ex-Armory employee. It's a valid option to consider.

We at BitMEX would be happy to help with resources and hosting. Please email us at support at bitmex dot com if you would like any help. We have plenty of extra capacity.

As for releases and documentation I heartily recommend doing releases on GitHub itself, and creating a gh-pages branch of the repository (or another repo) for docs/public website. That way we all benefit from open development of the docs site. I find in practice that if the repo is discoverable (e.g. there should be links to the GitHub page all over it), the community will submit PRs regularly. This makes keeping documentation helpful and up to date far easier.

Very sorry to hear how 0.94 went. As a team we're happy to help any way we can. Thank you for taking the lead on getting the work started to create a libre 0.94.

[goatpig]

Happy to take a look at the IP issue and give you some informal feedback / personal view.

Thanks for the help =). This is my current situation:

I'm mostly concerned about how to properly deal with license headers and wording on the repo, to make it clear the new code is MIT and mine and the old code is GPL3 and ATI's.

This is the original license: https://github.com/etotheipi/BitcoinArmory/blob/master/LICENSE

This is the modified one on my fork: https://github.com/goatpig/BitcoinArmory/blob/dev/LICENSE

Is this acceptable?

Also, this is what the license header looks like on the original code: https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/BlockUtils.cpp#L1

I have modified some of that code already by did not modify the license text on any of the original code files.

This is the header on all new code files: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/BlockDataMap.cpp#L1

Those files are 90~95% new code, I've copied some of the original utility code into the new class.

Did I mess up anything?

We at BitMEX would be happy to help with resources and hosting. Please email us at support at bitmex dot com if you would like any help. We have plenty of extra capacity.

As for releases and documentation I heartily recommend doing releases on GitHub itself, and creating a gh-pages branch of the repository (or another repo) for docs/public website. That way we all benefit from open development of the docs site. I find in practice that if the repo is discoverable (e.g. there should be links to the GitHub page all over it), the community will submit PRs regularly. This makes keeping documentation helpful and up to date far easier.

Very sorry to hear how 0.94 went. As a team we're happy to help any way we can. Thank you for taking the lead on getting the work started to create a libre 0.94.

That's a kind offer and I appreciate it. While this is an important matter, I'd like to get back to it once I actually have code ready for a release. I will have an easier time doing things properly once I have a new version ready.

I am open to suggestions on this matter, although I think the GitHub release is a seller.

The gh-pages approach sounds really good too. I'll try to figure something out, I'm looking forward to the community submitting PRs.

[Acejam]

This is unfortunate - Armory is one of the best wallets out there in my experience.

Not sure if this helps, but if anyone is looking for inspiration: https://github.com/acejam/BitcoinArmory/tree/ffreeze

[coins101]

Happy to take a look at the IP issue and give you some informal feedback / personal view.

Thanks for the help =). This is my current situation:

I'm mostly concerned about how to properly deal with license headers and wording on the repo, to make it clear the new code is MIT and mine and the old code is GPL3 and ATI's.

This is the original license: https://github.com/etotheipi/BitcoinArmory/blob/master/LICENSE

This is the modified one on my fork: https://github.com/goatpig/BitcoinArmory/blob/dev/LICENSE

Is this acceptable?

Also, this is what the license header looks like on the original code: https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/BlockUtils.cpp#L1

I have modified some of that code already by did not modify the license text on any of the original code files.

This is the header on all new code files: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/BlockDataMap.cpp#L1

Those files are 90~95% new code, I've copied some of the original utility code into the new class.

Did I mess up anything?
....

First, I'm not a lawyer. But, unfortunately, I have spent many years in dark rooms with lawyers talking about IP on software.

I think what you have done looks ok. I've read through the Armory GNU licence and basically you need to add this to the source code that was created by Armory:

Code:

<one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU Affero General Public License as
    published by the Free Software Foundation, either version 3 of the
    License, or (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU Affero General Public License for more details.

    You should have received a copy of the GNU Affero General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.

http://www.gnu.org/licenses/agpl-3.0.en.html

So, you'll have a mixture of code licences that you might want people to compile according to where the code starts:

* Armory code should start with the Armory licence terms

Code:

Copyright (C) 2011-2015, Armory Technologies, Inc.                        //
//  Distributed under the GNU Affero General Public License (AGPL v3)         //
//  See LICENSE or http://www.gnu.org/licenses/agpl.html 

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU Affero General Public License as
    published by the Free Software Foundation, either version 3 of the
    License, or (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU Affero General Public License for more details.

    You should have received a copy of the GNU Affero General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.

* Your new code can then start with:

Code:

//   Copyright (C) 2016,  <copyright holders>         //
//  Distributed under the MIT License                           //
//  See LICENCE or https://opensource.org/licenses/MIT //

I take it there is no other code you'll be using that has come form Armory, that has not been released on the GNU licence?

By using the Armory code now, you should be ok if someone decides to buy the company or its assets and then changes the licence.

I'll keep reading around to see if the above thoughts need modification.

[coins101]

The risk you face, without knowing the details, is this:

Along the way, we accumulated a mess of legal and corporate complexity that has made it difficult to do anything constructive with Armory's intellectual property.  These complexities make it risky for me to continue development, even if the money was there to pay me a salary.  It has also made it difficult to be acquired by another company that shares my vision, that could provide funding to see its execution.  

https://bitcointalk.org/index.php?topic=1351792.0

The CEO / core developer is evidently aware of some legal issues and in particular around IP.

It could be that the GNU licence made if difficult to raise investor money as the company was giving away its core product for free.

What you might want to do is write to Armory stating what you are doing with the Armory source code that is on their github repo. Then also explain that you may modify and add to their source code, but you are doing so under the MIT licence on any new additions. Then give them a period, say 30 days, to respond with any specific objections. The response period is not relevant as they or future owners of the IP have many years to raise legal objections. Asking them to give you feedback is more of a way to get some guidance back to you within a reasonable time period.

* Personally, I would also drop the Armory name or significant references to it, other than in passing or for historical reference. The name could be seen as necessary brand IP the company might want to protect in order to gain value from.

* Trade secrets - I'd also avoid saying things like, 'based on my internal knowledge, Armory were going to do .....xxxxx...., so that's what I'm going to do as part of my new road map.'

[RoadStress]

Many thanks to both @etotheipi and @goatpig for all you've done,

please any chance to keep Armory alive and include Trezor support?

  Look who's back!

Hello hello mister 'Orama. How are you doing?

[goatpig]

I take it there is no other code you'll be using that has come form Armory, that has not been released on the GNU licence?

By using the Armory code now, you should be ok if someone decides to buy the company or its assets and then changes the licence.

I'll keep reading around to see if the above thoughts need modification.

Indeed, I won't touch anything from ATI that hasn't been explicitly released under the GNU license. I also won't touch any of the original 0.94 code (that I have locally, but won't be using because it is mired in the IP entanglement like a lot of our former code). I'm actually approaching the DB design under a different angle entirely, so I won't even look at that stuff for inspiration.

A couple questions:

1) Is it fine if I don't update the license anywhere on original Armory files even though I'm modifying its content (sometimes up to 10~15% I expect)? I don't care if those changes are somehow considered falling under the scope of the GPL license, not like they make any sense without the new MIT licensed code.

2) Do I have to add the GPL license header to my new code files if I recycle some 5~10% of Armory's code there? (copy paste code blocks in new file and modify them there)

----------------------------------

The CEO / core developer is evidently aware of some legal issues and in particular around IP.

What you might want to do is write to Armory stating what you are doing with the Armory source code that is on their github repo. Then also explain that you may modify and add to their source code, but you are doing so under the MIT licence. Then give them a period, say 30 days, to respond with any specific objections. The response period is not relevant as they or future owners of the IP have many years to raise legal objections. Asking them to give you feedback is more of a way to get some guidance back to you within a reasonable time period.

I've worked at Armory for over 2 years, I know the details of the IP snafu. Alan gave me the go ahead to work on top of 0.93.3 (as in it's the legally safe start point). I'm not expecting any legal back fire on that front. I also believe the share holders in general approve that I forward development on my own time under the conditions that I don't go around leaking IP in contention.

What I am mostly concerned about is keeping this whole forking "Kosher": I don't want the new code that will coexist and be intertwined with the old code to somehow fall under the umbrella of the preexisting IP contention because I messed up on my due diligences with license language and what not.

[coins101]

...
What I am mostly concerned about is keeping this whole forking "Kosher": I don't want the new code that will coexist and be intertwined with the old code to somehow fall under the umbrella of the preexisting IP contention because I messed up on my due diligences with license language and what not.

That's an interesting point.

GNU does say you're able to modify and adopt. The intention of the licence is:

Developers that use our General Public Licenses protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License which gives you legal permission to copy, distribute and/or modify the software.

Because you are releasing all new code under the MIT licence, I tend to think you don't have any issues to worry about when mixing/matching code.

[coins101]

..... Alan gave me the go ahead to work on top of 0.93.3 (as in it's the legally safe start point). I'm not expecting any legal back fire on that front. I also believe the share holders in general approve that I forward development on my own time under the conditions that I don't go around leaking IP in contention.

..

Unless you have something in writing, you don't have anything. That's been my experience. Verbal agreements are valid, but hard to prove if someone changes their mind, moves on, etc.

[goatpig]

Unless you have something in writing, you don't have anything. That's been my experience. Verbal agreements are valid, but hard to prove if someone changes their mind, moves on, etc.

Good to know.

[wttbs]

Sad to hear about the end of the road with armony but good to hear development is picked up again.

Maybe a noob question, but I am using Armory 0.93.3, I assume I can keep on using it without any problem?

[goatpig]

Sad to hear about the end of the road with armony but good to hear development is picked up again.

Maybe a noob question, but I am using Armory 0.93.3, I assume I can keep on using it without any problem?

Yes you are fine. I do suggest you upgrade once I'm done with the next version though =).

[Roy Badami]

What I am mostly concerned about is keeping this whole forking "Kosher": I don't want the new code that will coexist and be intertwined with the old code to somehow fall under the umbrella of the preexisting IP contention because I messed up on my due diligences with license language and what not.

CAUTION: I AM NOT A LAWYER.  But I think I can probably steer you in broadly the right direction nonetheless.

You own the copyright to the new code that you write on your own dime.  Nothing can restrict your right to do what you like with your code, short of selling or otherwise assigning the copyright to someone else.  The license you release your code under is your grant of a license to other people; it tells other people what they are allowed to do with your code.  But you are always free to do what you like with your code - including relicense it under different terms - since you own it.

(EDIT: rewritten this para)  The things you have to worry about are that you don't end up using code that ATI owns contrary to any license grant.  And secondly that you don't end up releasing a product that it is effectively impossible for anyone to run without using code that ATI owns contrary to any license grant.  At the moment, the only license grant for the ATI-owned code is the GNU Affero GPL it was publicly released under, but of course you're always free to try to negotiate some more permissive license grant with ATI.

I'm very dubious of your plan to manage copyright at the level of commits - i.e. one copyright and license up to a particular commit, and another for subsequent commits.  This is very unconventional and sounds like a recipe for legal confusion.  You can't meaningfully pick apart the commits to a single file.   Don't try to do this without advice from a lawyer. 0.93.3 files that you modify should instead be treated as derivative works, IMHO.  The way I'd proceed is as follows.

The way I see it, you have three types of files.

1. Files from 0.93.3 which you haven't modified.  Keep the copyright notice and license unchanged on these files.  These files are owned and licensed by ATI.  Obviously over time there will be fewer of these; that's fine.

2. Files from 0.93.3 that you have modified.  These files are derivative works of ATI's work, and both you and ATI have copyright claims on them.  Keep these files under the GNU Affero GPL, but update the copyright notice to include both your copyright claim and ATI's.  You can't relicense these derivative works except in accordance with ATI's license grant.  Fortunately the GNU Affero GPL allows you to create derivative works provided they are licensed on the same terms.

3. New files that are entirely your own work, on your own dime.  You own the copyright on these files, so you are technically free to release these under any other license you choose - but if this license you choose were incompatible with the GNU Affero GPL then it may be impossible for anyone to legally comply with all the licenses.  Any license that is compatible with the GNU Affero GPL is fine here, so a permissive license such as the MIT license should be absolutely fine.  These new files should contain just your copyright notice and the relevant license (and no reference to ATI).

Your LICENSE file should then simply indicate that portions are copyright ATI and portions are copyright you, and that furthermore portions are licensed under the GNU Affero GPL and portions are licensed under the MIT license, and include the text of both licenses for reference.  It should instruct people to refer to individual source files to find out the copyright and license that applies to those files.  EDIT: I'd rename the existing LICENSE file to LICENSE-ATI or LICENSE-0.93.3 or some such, and leave it unchanged except for a some added text at the beginning saying this was the license under which ATI released 0.93.3.  I'd then reference the LICENSE-ATI file from your new LICENSE file, too, and indicate that this was the license under which the ATI-owned code was orignally released.  This is useful for reference, and it also avoids breaking the reference in the ATI copyright messages to see the LICENSE file.

Obviously, you want to aim to modularise things in such a way as to maximise the number of files that fall into category 3 - but of course you have to be careful when refactoring not to accidentally move pieces of ATI-derived code into your category 3 files - or at least, if you do, you should recategorise those files as category 2.

I'm pretty sure what I describe above is safe, and is the most sensible way to proceed, but once again IANAL.  Happy  to answer questions, though, if any of the above is unclear.  EDIT: And of course happy to review and comment on your updated license/copyright notices.

Regards,

roy

EDIT: Significant edits to the above - you may want to reread.
EDIT: Further edits to the advice on LICENSE files.

[wttbs]

Sad to hear about the end of the road with armony but good to hear development is picked up again.

Maybe a noob question, but I am using Armory 0.93.3, I assume I can keep on using it without any problem?

Yes you are fine. I do suggest you upgrade once I'm done with the next version though =).

Thanks for the quick reply. I sure will use your next version. If you (beta)tester just let me know and I will follow this topic of course.

[iwasneverhere]

Hope it all works out. When the time comes I will play my part and donate.

[Roy Badami]

And to follow up, of course for an easy life, you could just release everything under the GNU Affero GPL.  But I applaud your desire to release under a permissive license.  It will only really benefit anyone, though, where there are significant amounts of self-contained new permissively licensed (category 3) code that would be useful to some other project that for what ever reason couldn't (or didn't want to) use any ATI-derived code.

[Roy Badami]

Also to add.  99% of this is about avoiding legal disputes in the first place.  Whether or not you intend to follow my advice, you'd be well advised to run whatever approach you do settle on by any contacts you have at ATI for their opinion.  It ultimately matters not who would win in court, unless you have the inclination and resources to see a lawsuit.  What matters is whether you're doing something that might cause ATI to feel aggrieved and which might incline them to take legal action.

EDIT: But don't worry too much if ATI is effectively defunct and you can't get a formal opinion.  An informal opinion is still better than nothing (particularly given unspecified legal complications with the IP) but I would say it's by no means essential, and I wouldn't worry unduly.

[gangtraet]

goatpig:

I am certainly no expert on copyright law and licenses, but a sound engineering principle is KISS ("Keep It Simple, Stupid").  I can certainly understand that you prefer MIT license over GNU Affero for your own work (I agree with you here), but you should seriously consider if the extra complication of having to keep track of two different licenses is worth the trouble.  In particular, once you start refactor code you will constantly have to worry about not moving code from an Affero file to an MIT file.  Furthermore, the GNU licenses tends to affect the whole work, so the entire Armory will be under that license, even if people can reuse parts of the project that you alone wrote under MIT license.

An alternative might be to keep Armory under the original license, but if you make whole, self-contained modules then release these under the MIT license as well.
It might be less satisfactory, but may keep your life simpler.

[achow101]

goatpig, I think you should grab the tags from etotheipi's repo and then upload the 0.93.3 release to github so that the latest versions are in a place that you have control over so that if ATI goes offline for some reason, the latest release is still available until 0.94 is finished.

[unamis76]

I get away from the forums for a bit of time and this happens... Pretty sad to see so many complications surrounding my favorite desktop and Cold Storage client. I'd like to wish etotheipi all of the best and I hope to see him back to Armory development soon.

I guess the lack of updates predicted something bad was happening at Armory. I guess Armory is a great idea that is turning into reality too soon for the general public/companies.

Anyways, good to see someone taking up development on their own! I'd like to wish goatpig all of the best in developing this, hopefully without too many licensing complications which may unfortunately hinder development... We'll see what the future has in store.

I'd also like to say I am available to contribute with funds for further development, if needed. I don't have much, but if every user contributes a bit, we can make things happen.

Beyond this, I have no help to offer. No code talents, neither a licensing whiz either (Thanks for everyone leaving valuable input, pretty interesting to learn about all these licensing issues). I can however help testing further Armory versions, if needed.

[goatpig]

I'm very dubious of your plan to manage copyright at the level of commits - i.e. one copyright and license up to a particular commit, and another for subsequent commits.  This is very unconventional and sounds like a recipe for legal confusion.  You can't meaningfully pick apart the commits to a single file.   Don't try to do this without advice from a lawyer.

I thought it was proper to indicate where the code starts to diverge, by hash. There is no clearer way to designate a point in the development time line where all code is ATI's property before and anything after is a mix and match. I've removed it from the license.

I've followed your advice and update the licensing language, also added LICENSE-MIT and LICENSE-ATI. Please let me know if that is satisfactory.

And to follow up, of course for an easy life, you could just release everything under the GNU Affero GPL.

My goal in all this is to forward Bitcoin in some way. I believe Armory is the ideal vessel to deliver a complete stack, key in hand professional grade solution that fully embraces Bitcoin's model, in that it allows individuals and organizations to have total control over the code they run and the cryptographic material they own. I believe that kind of tool is necessary for Bitcoin to thrive.

With all due respect, to whom it may concern, if there was good competition in this space, I would not see the need to keep Armory going. I do not believe such competition exists right now, nor in the few years to come, and that is mainly because of the models other people in this space adopt, which do not fully embrace the opportunity of a paradigm shift in finance and business that Bitcoin offers us.

While I commend Armory's competitor on their hard work and passion, I do not believe they will fill the gap Armory would create was it to actually disappear, and I believe that role to be foundational to the good health of the Bitcoin ecosystem.

My vision of Armory is to keep forwarding it as an industry standard, with cutting edge, robust and high performance features to deliver the full Bitcoin experience to power users, financiers and businesses. Don't get me wrong, I love the individual users too, but they aren't encumbered by the legality of intellectual property rights the same way as businesses and organizations are.

Open source code is a full and unalienable property of Bitcoin's model. As such, any tool hoping to achieve what I just described has to be open source as well. On top of that, the particular license should not deter the target, otherwise I would consider the Armory experiment a failure and all my work for naught.

The MIT license (or something as permissive like OpenLDAP license) is a sine qua non condition to my ongoing involvement. If I was unable to develop Armory in such open manner, I would either have to start from scratch or I would try the next best thing I have in mind to forward Bitcoin, i.e. participate directly to Bitcoin's development.

If my memory serves right, Armory became AGPL3 when ATI was created, because it allowed the code to remain publicly available while offering opportunities to charge businesses that looked to integrate with our stack. Instead, here we are. Don't get me wrong, I like money. I believe the people involved with Armory deserve proper compensation for their effort. I believe I deserve proper compensation for my work too, and I do not believe in free lunches. But so far, the only thing I've seen the AGPL license achieve is to complicate the situation and slow down the project to a halt, as well as barring me from code I wrote.

The results do not justify the potential benefits, and there will be no code created under the AGPL3 license while I remain in charge. My long term plan is to phase out all mission critical pieces of code by overhauling them one at a time, while maintaining the new code properly secluded. I will also refrain from copy pasting old Armory code into new code from now on and instead rewrite the functionality fully. There aren't 20 ways of doing certain things correctly though, so there is only so much divergence I can introduce on purpose in certain places.

I am certainly no expert on copyright law and licenses, but a sound engineering principle is KISS ("Keep It Simple, Stupid").  I can certainly understand that you prefer MIT license over GNU Affero for your own work (I agree with you here), but you should seriously consider if the extra complication of having to keep track of two different licenses is worth the trouble.  In particular, once you start refactor code you will constantly have to worry about not moving code from an Affero file to an MIT file.  Furthermore, the GNU licenses tends to affect the whole work, so the entire Armory will be under that license, even if people can reuse parts of the project that you alone wrote under MIT license.

Read above. I appreciate KISS but I AGPL has to go and I don't want to rewrite everything from the ground up. Phasing out the old code will be a long term effort along the course of at least 2016.

you'd be well advised to run whatever approach you do settle on by any contacts you have at ATI for their opinion.

I have Alan's verbal consent.

What matters is whether you're doing something that might cause ATI to feel aggrieved and which might incline them to take legal action.

Hopefully that won't happen. When it comes down to it, my actions benefit ATI in that it keeps the brand alive and the software up to date. It's a win-win if they simply let me do my thing while the IP encumbrance is being worked out.

[goatpig]

goatpig, I think you should grab the tags from etotheipi's repo and then upload the 0.93.3 release to github so that the latest versions are in a place that you have control over so that if ATI goes offline for some reason, the latest release is still available until 0.94 is finished.

Updated the tags. I don't have the patience to figure out the release functionalities of github tonight. I'll look into that sometimes this week.

[achow101]

goatpig, I think you should grab the tags from etotheipi's repo and then upload the 0.93.3 release to github so that the latest versions are in a place that you have control over so that if ATI goes offline for some reason, the latest release is still available until 0.94 is finished.

Updated the tags. I don't have the patience to figure out the release functionalities of github tonight. I'll look into that sometimes this week.

The releases is really easy to use. Click on the Releases tab in the github repo and then click on the tag (the name of the tag is a link) you want (in this case 0.93.3). Then click the button to edit the tag and drag and drop the binaries into the box where it says the binaries are. If you want to add a message that goes with the release, type it into the textbox. When you are done click publish release.

[RoadStress]

Hey goatpig has etotheipi told you anything about the website? If not will you discuss this with him?

[goatpig]

No he hasn't but I expect it is off limit, and he can't do anything about it either.

[Roy Badami]

I'm very dubious of your plan to manage copyright at the level of commits - i.e. one copyright and license up to a particular commit, and another for subsequent commits.  This is very unconventional and sounds like a recipe for legal confusion.  You can't meaningfully pick apart the commits to a single file.   Don't try to do this without advice from a lawyer.

I thought it was proper to indicate where the code starts to diverge, by hash. There is no clearer way to designate a point in the development time line where all code is ATI's property before and anything after is a mix and match. I've removed it from the license.

I don't think it's bad to indicate where they diverge (but it would be more readable to reference the commit by tag, now you've imported them).

My main concern (sorry if I didn't read it carefully enough and misunderstood) was that your original approach seemed to me to be saying that there would be files in your distro that had portions under one license but subsequent changes under another.  I think attempting to apply licenses to an individual file at the commit level is problematic - hence my advice to just accept that modified files are derivative works and will have to be licensed in their entirety under the GNU Affero GPL.

It's late now, I'll try and review your updates soon.

EDIT: Or put another way -  where the development diverges is useful and interesting information, and there's no reason not to include that information.  But I wouldn't personally word the license in such a way that it depends on this; such commentary should be purely informational and clearly not part of the license terms.

[goatpig]

I don't think it's bad to indicate where they diverge (but it would be more readable to reference the commit by tag, now you've imported them).

My main concern (sorry if I didn't read it carefully enough and misunderstood) was that your original approach seemed to me to be saying that there would be files in your distro that had portions under one license but subsequent changes under another.  I think attempting to apply licenses to an individual file at the commit level is problematic - hence my advice to just accept that modified files are derivative works and will have to be licensed in their entirety under the GNU Affero GPL.

You read me correctly but assumed too much. I wanted to have a record in the license file of when the code started to diverge, since I'll be changing code and licenses in a lot of original files. I've amended that by tag in LICENSE.

The releases is really easy to use. Click on the Releases tab in the github repo and then click on the tag (the name of the tag is a link) you want (in this case 0.93.3). Then click the button to edit the tag and drag and drop the binaries into the box where it says the binaries are. If you want to add a message that goes with the release, type it into the textbox. When you are done click publish release.

Done. Was a lot easier than expected =)

[coins101]

You should seriously think about dropping the name Armory or get permission to use it.

Armory is the name of the company, as well as the product.

I know its a pain, but its actually not covered by any open source licence, that I can see.

[opentoe]

All the software I use is free. It is all community developed and have very good support paths. I've donated to all the ones I use and too bad this couldn't be the same with Armory. I have seen some good software ( like this ) go from community type development to being locked down and someone wants to just make money off of it. I don't know anything about IP or the laws, but been good while it lasted.

If you have coins in your wallet and the blockchain/development changes very quickly and/radically couldn't there be a chance you can't send your coins out to another wallet?

[achow101]

Here is a site for the project that I put together using Github Pages: https://achow101.github.io/BitcoinArmory/. It uses Jekyll (which github recommends using) and Github Pages as the hosting. The code is at https://github.com/achow101/BitcoinArmory/tree/gh-pages and if someone can get a domain, that domain can also be pointed to the site so it uses the domain. Let me know what you think about it.

[gangtraet]

I am certainly no expert on copyright law and licenses, but a sound engineering principle is KISS ("Keep It Simple, Stupid").  I can certainly understand that you prefer MIT license over GNU Affero for your own work (I agree with you here), but you should seriously consider if the extra complication of having to keep track of two different licenses is worth the trouble.  In particular, once you start refactor code you will constantly have to worry about not moving code from an Affero file to an MIT file.  Furthermore, the GNU licenses tends to affect the whole work, so the entire Armory will be under that license, even if people can reuse parts of the project that you alone wrote under MIT license.

Read above. I appreciate KISS but I AGPL has to go and I don't want to rewrite everything from the ground up. Phasing out the old code will be a long term effort along the course of at least 2016.

I can certainly see your point.  I doubt that you will ever end with an Armory without AGPL stuff in it, but the new stuff you write will be easier to integrate into other projects with an MIT license.

I have Alan's verbal consent.

"A verbal agreement is not worth the paper it is written on."  

Get a GPG signed email from him.  He seems to be a very trustworthy guy, but still things may change or come out of his control.

[Carlton Banks]

I am certainly no expert on copyright law and licenses, but a sound engineering principle is KISS ("Keep It Simple, Stupid").  I can certainly understand that you prefer MIT license over GNU Affero for your own work (I agree with you here), but you should seriously consider if the extra complication of having to keep track of two different licenses is worth the trouble.  In particular, once you start refactor code you will constantly have to worry about not moving code from an Affero file to an MIT file.  Furthermore, the GNU licenses tends to affect the whole work, so the entire Armory will be under that license, even if people can reuse parts of the project that you alone wrote under MIT license.

Read above. I appreciate KISS but I AGPL has to go and I don't want to rewrite everything from the ground up. Phasing out the old code will be a long term effort along the course of at least 2016.

I can certainly see your point.  I doubt that you will ever end with an Armory without AGPL stuff in it, but the new stuff you write will be easier to integrate into other projects with an MIT license.

I have Alan's verbal consent.

"A verbal agreement is not worth the paper it is written on."  

Get a GPG signed email from him.  He seems to be a very trustworthy guy, but still things may change or come out of his control.

Alan announced the agreement publicly (in this sub), I think that's adequate

[RoadStress]

No he hasn't but I expect it is off limit, and he can't do anything about it either.

What does that mean exactly? Are we able to use the latest builds found on the website or they aren't safe anymore?

[goatpig]

You should seriously think about dropping the name Armory or get permission to use it.

Armory is the name of the company, as well as the product.

I know its a pain, but its actually not covered by any open source licence, that I can see.

I am certainly no expert on copyright law and licenses, but a sound engineering principle is KISS ("Keep It Simple, Stupid").  I can certainly understand that you prefer MIT license over GNU Affero for your own work (I agree with you here), but you should seriously consider if the extra complication of having to keep track of two different licenses is worth the trouble.  In particular, once you start refactor code you will constantly have to worry about not moving code from an Affero file to an MIT file.  Furthermore, the GNU licenses tends to affect the whole work, so the entire Armory will be under that license, even if people can reuse parts of the project that you alone wrote under MIT license.

Read above. I appreciate KISS but I AGPL has to go and I don't want to rewrite everything from the ground up. Phasing out the old code will be a long term effort along the course of at least 2016.

I can certainly see your point.  I doubt that you will ever end with an Armory without AGPL stuff in it, but the new stuff you write will be easier to integrate into other projects with an MIT license.

I have Alan's verbal consent.

"A verbal agreement is not worth the paper it is written on." 

Get a GPG signed email from him.  He seems to be a very trustworthy guy, but still things may change or come out of his control.

I got in touch with the share holders yesterday about the use of their trademark. I'm waiting for their decision before doing anything about that.

No he hasn't but I expect it is off limit, and he can't do anything about it either.

What does that mean exactly? Are we able to use the latest builds found on the website or they aren't safe anymore?

It means I most likely won't have access to the bitcoinarmory.com domain, so unless ATI keeps that up to date, it will decay into obsolescence. As for the builds, it never was a matter of where you downloaded the file, rather if the hash matches the signature and the signature matches Alan's key. This has no changed for now. Once I put out my own builds, I'll make an offline signing key and reveal the public key here for all to check the builds against.

Here is a site for the project that I put together using Github Pages: https://achow101.github.io/BitcoinArmory/. It uses Jekyll (which github recommends using) and Github Pages as the hosting. The code is at https://github.com/achow101/BitcoinArmory/tree/gh-pages and if someone can get a domain, that domain can also be pointed to the site so it uses the domain. Let me know what you think about it.

I'll look into website matters once I have a release.

[RoadStress]

No he hasn't but I expect it is off limit, and he can't do anything about it either.

What does that mean exactly? Are we able to use the latest builds found on the website or they aren't safe anymore?

It means I most likely won't have access to the bitcoinarmory.com domain, so unless ATI keeps that up to date, it will decay into obsolescence. As for the builds, it never was a matter of where you downloaded the file, rather if the hash matches the signature and the signature matches Alan's key. This has no changed for now. Once I put out my own builds, I'll make an offline signing key and reveal the public key here for all to check the builds against.

Much appreciated.

[coins101]

 

[achow101]

You should enable issues on Github, it's in the settings.

Also, I think anything mentioning ATI in the software should be removed, both because ATI is no longer supporting it, and for licensing stuff.

[goatpig]

You should enable issues on Github, it's in the settings.

Also, I think anything mentioning ATI in the software should be removed, both because ATI is no longer supporting it, and for licensing stuff.

Enabled issues.

I can't remove references to ATI, that would break the AGPL licensing terms as well as trademark law (as long as the project uses the Armory name).

[coins101]

You should enable issues on Github, it's in the settings.

Also, I think anything mentioning ATI in the software should be removed, both because ATI is no longer supporting it, and for licensing stuff.

Enabled issues.

I can't remove references to ATI, that would break the AGPL licensing terms as well as trademark law (as long as the project uses the Armory name).

The licensing and trademark are two district issues.  You need to keep the Armory name in the licence, but you need to stop using the name in public to refer to your project, unless the officers of Armory give you written permission to use the name.

Note, there is a difference between shareholders and officers.  The shareholders have no direct say in the day to day running of the Armory business, that's the job and responsibility of the company officers. Getting the permission of shareholders for anything other than buying or selling shares or the whole company is pointless.

[Ente]

I agree to drop the Armory name. This might keep you from bigger problems in the future, and might even give you a slighty better position should all of the old Armory folks come to a round table at a later point. This is a sad moment, with the Armory company structure and dev team being in pieces, so why not take the opportunity to get rid of as much potential ballast as possible.

Another thought: if (all!) the current copyright holders of the code agree, it should be possible to relicense the entire 0.93 code to MIT. Now I don't know the details, but maybe this isn't as impossible as it seems? Maybe they have an (bigger) interest to keep the project and brand alive than to watch the code become obsolete with time..

I read up about GPL vs MIT. Before, I didn't know the details. Goatpig, I applaud you for your strong stance on this topic. "Just" GPL would surely be easier now, but I see your point in being "radically open source" here.
It's an interesting (off topic) discussion point, I personally am unsure what the right way is, generally, on different open source licenses.

Ente

[goatpig]

The licensing and trademark are two district issues.  You need to keep the Armory name in the licence, but you need to stop using the name in public to refer to your project, unless the officers of Armory give you written permission to use the name.

There are talks of giving me a renewable license to use the trademark. I'll be meeting with Alan in person on Monday and go from there.

I agree to drop the Armory name. This might keep you from bigger problems in the future, and might even give you a slighty better position should all of the old Armory folks come to a round table at a later point. This is a sad moment, with the Armory company structure and dev team being in pieces, so why not take the opportunity to get rid of as much potential ballast as possible.

I have several reasons to keep on using the Armory name:

1) Armory has brand name recognition. If I uphold that trademark to the standard it has been so far, the IP retains far more value. This keeps the door open for one day getting a new acquirer, and this could all conclude in reviving Armory as a business and getting the team back together. All devs stuck around with no pay for 6 months, my response to that can't be to just shut down all hope by leaving the trademark to decay.

2) The brand name recognition is beneficial to me too. People on this forum know I've been an active developer of Armory for some 2 years now. They know what I've done and where my skills lie. People outside this forum don't. As an example, while Alan is getting flooded with job offers, I ain't getting snuff. Not that I am complaining. I want to work on Armory anyways, but this is a clear picture of what awaited me had I decided to go job hunting right away instead.

There are several ways for a developer to make a living working on an open source project. It doesn't have to come down to donations. But for the other ways to work, I need my name out there with some achievement behind it if I want these other opportunities to materialize. As far as the Bitcoin business space is concerned, Armory is all Alan. I'll have to change to that if I want to have my cake and eat it to. Doing all that development under the Armory name and demonstrating I can take over where Alan left is beneficial to me as well. I have to look out for myself too.

3) The naming omg... what's the current flavor? Slap some random word on top of wallet and you're done? Or just go with something completely unrelated? What is this, hashtag rap? Who's up for MtnDewWallet? Or what about just Bicycle? If push comes to shove, I will have to change the name, but we aren't there yet. And I dread that time if ever it comes.

4) I don't want someone else to use the name. The share holders benefit from letting me use the trademark. If I was to drop it, they could very well just sell the trademark while the IP entanglement is being dealt with. Then what? Do you want to envision a future where the Armory brand name is bought by a web wallet provider?

5) There are still a lot of individual users and businesses that use and recommend Armory. I don't want to disappoint them, and in the case of businesses, I don't want to harm their image by letting the Armory name they rely upon decay into obsolescence. The image has been harmed enough as it is.

6) I'm a romantic, I don't want to see Armory die, even in name.

7) If I have to change the name, I'd rather do it later, once I have demonstrated my ability to keep the project alive.

[goatpig]

I read up about GPL vs MIT. Before, I didn't know the details. Goatpig, I applaud you for your strong stance on this topic. "Just" GPL would surely be easier now, but I see your point in being "radically open source" here.
It's an interesting (off topic) discussion point, I personally am unsure what the right way is, generally, on different open source licenses.

I'm not all that versed in licenses either. GPL has proved its limits though, and something permissive like MIT or OpenLDAP is the only way forward imo.

[coins101]

The licensing and trademark are two district issues.  You need to keep the Armory name in the licence, but you need to stop using the name in public to refer to your project, unless the officers of Armory give you written permission to use the name.

There are talks of giving me a renewable license to use the trademark. I'll be meeting with Alan in person on Monday and go from there.

I agree to drop the Armory name. This might keep you from bigger problems in the future, and might even give you a slighty better position should all of the old Armory folks come to a round table at a later point. This is a sad moment, with the Armory company structure and dev team being in pieces, so why not take the opportunity to get rid of as much potential ballast as possible.

I have several reasons to keep on using the Armory name:

1) Armory has brand name recognition. If I uphold that trademark to the standard it has been so far, the IP retains far more value. This keeps the door open for one day getting a new acquirer, and this could all conclude in reviving Armory as a business and getting the team back together. All devs stuck around with no pay for 6 months, my response to that can't be to just shut down all hope by leaving the trademark to decay.

2) The brand name recognition is beneficial to me too. People on this forum know I've been an active developer of Armory for some 2 years now. They know what I've done and where my skills lie. People outside this forum don't. As an example, while Alan is getting flooded with job offers, I ain't getting snuff. Not that I am complaining. I want to work on Armory anyways, but this is a clear picture of what awaited me had I decided to go job hunting right away instead.

There are several ways for a developer to make a living working on an open source project. It doesn't have to come down to donations. But for the other ways to work, I need my name out there with some achievement behind it if I want these other opportunities to materialize. As far as the Bitcoin business space is concerned, Armory is all Alan. I'll have to change to that if I want to have my cake and eat it to. Doing all that development under the Armory name and demonstrating I can take over where Alan left is beneficial to me as well. I have to look out for myself too.

3) The naming omg... what's the current flavor? Slap some random word on top of wallet and you're done? Or just go with something completely unrelated? What is this, hashtag rap? Who's up for MtnDewWallet? Or what about just Bicycle? If push comes to shove, I will have to change the name, but we aren't there yet. And I dread that time if ever it comes.

4) I don't want someone else to use the name. The share holders benefit from letting me use the trademark. If I was to drop it, they could very well just sell the trademark while the IP entanglement is being dealt with. Then what? Do you want to envision a future where the Armory brand name is bought by a web wallet provider?

5) There are still a lot of individual users and businesses that use and recommend Armory. I don't want to disappoint them, and in the case of businesses, I don't want to harm their image by letting the Armory name they rely upon decay into obsolescence. The image has been harmed enough as it is.

6) I'm a romantic, I don't want to see Armory die, even in name.

7) If I have to change the name, I'd rather do it later, once I have demonstrated my ability to keep the project alive.

Fuck it. Let's put something together and buy the company, the IP or some variant.  It's currently moribund, with no serious way forward, that I can tell.

[Ente]

Fuck it. Let's put something together and buy the company, the IP or some variant.  It's currently moribund, with no serious way forward, that I can tell.

Funny, I had the same brief thought. Let's just buy what we want. Can't be that expensive, in its current situation? :-)

No, I think that money would be wasted. If we need to spend money, let's pay dev(s) to actually bring Armory forward, instead of paying entities which brought this situation upon us.
Also, there's absolutely no hurry. We have 0.93 as a base to use now and to continue developing, and we have Goatpig. And a whole forum full of fans! That's all we need for this party! :-)

Ente

[achow101]

I can't remove references to ATI, that would break the AGPL licensing terms as well as trademark law (as long as the project uses the Armory name).

Not in the credits or licensing, but places where things to ATI are referenced like where it says to review ATI privacy policy and any links to the ATI website and such should be removed before the next release.

If the Armory name is dropped and another is chosen, the logo will also have to be changed as well.

[goatpig]

Not in the credits or licensing, but places where things to ATI are referenced like where it says to review ATI privacy policy and any links to the ATI website and such should be removed before the next release.

Ugh, right I have to go over that stuff at some point. I made a branch off of master named CleanUpATI. I'll greatly appreciate any PRs to help me clean up the references, links and what not on this branch.

Fuck it. Let's put something together and buy the company, the IP or some variant.  It's currently moribund, with no serious way forward, that I can tell.

Let's take it easy for now. I may just get the right to use the trademark. Let's figure things out after I know where that stands. This is marathon, not a sprint, no need to rush.

Funny, I had the same brief thought. Let's just buy what we want. Can't be that expensive, in its current situation? :-)

I expect you'd be surprised.

---------------------------------

Generally speaking, when it comes down to soliciting the community for money for any purposes, let's not go down that path yet. Give me time to come up with a release and get things settled. This way I can prove myself as a proper successor and build some trust around the project again. Otherwise I could just as well ask for a donation round right now, do not contribute any code, do another round 2 months down the road with whatever good will I have left, to eventually run away with the $$$. Trust takes time to nurture, and again there is no need to rush.

[sandal]

My only real concern:
Will there be a point where the coins I have in armory will be unmoveable?

Do I need to use a different wallet for the time being?

[goatpig]

My only real concern:
Will there be a point where the coins I have in armory will be unmoveable?

Do I need to use a different wallet for the time being?

0.93.3 is fine for at least another couple years.

[gangtraet]

0.93.3 is fine for at least another couple years.

Maybe not fine, but certainly safe.  If unmaintained, it is only a matter of time before it can no longer send money unaided, after some soft or hardfork has made it necessary to update bitcoin core to a version Armory cannot communicate with.  But in that case, you can always export the private keys and import them in another wallet.

Of  course after a few years you may need to dig out an old linux distribution and run it in a VM to even run Armory, but while tedious I cannot see how that could stop working. 

I am not worried yet.  But of course I am considering other options (electrum) if goatpig does not succeed in carrying on the torch.

[goatpig]

0.93.3 is fine for at least another couple years.

Maybe not fine, but certainly safe.  If unmaintained, it is only a matter of time before it can no longer send money unaided, after some soft or hardfork has made it necessary to update bitcoin core to a version Armory cannot communicate with.  But in that case, you can always export the private keys and import them in another wallet.

Of  course after a few years you may need to dig out an old linux distribution and run it in a VM to even run Armory, but while tedious I cannot see how that could stop working. 

I am not worried yet.  But of course I am considering other options (electrum) if goatpig does not succeed in carrying on the torch.

Unless ECC, SHA256 or AES is broken in the future, Armory is safe indeed. And the internet as a whole would be in a lot more trouble than just Armory if that were to happen.

When I said fine I meant fine with regards to Armory's reliance upon a local Bitcoin node. 0.93.3 can't make sense of SegWit transactions, it will just ignore them. It can still spend coins that are not "SW'd". There would an issue in receiving SW transactions, but the idea here is to move coins out, not use the wallet for actual trading.

Generally, if you used Armory in the past for your cold storage, you can expect to be able to spend those coins with Armory as long as no hard fork has been deployed modifying the legacy Bitcoin transaction rules. If the changes are done through a soft fork though, you should be able to spend just fine. I don't personally expect the network will go through a hard fork that would break old style Bitcoin transactions for next 2-3 years. There are plenty talks of hard forks lately, but I don't believe any of those are meant to change on chain transaction structure. I could be wrong though, but again, I expect the network to prefer soft forks whenever possible.

Anti malleability changes like lowS would reduce Armory's usability, but with some persistence, it would eventually create a valid transaction. Block size hard forks are irrelevant to Armory, but changing magic word within the block files would break it. However, fixing that is a matter of changing one hard coded line within 0.93, nothing too dramatic.

Changes to the raw block data saving formats will stop Armory. So far, changes of that category are pruning and obfuscation. Both these features can be disabled and if you find yourself 5 years from now trying to spend old coins with 0.93, you should be disabling that stuff anyways.

As for running the binary, I don't see why you wouldn't be able to build from source on a Debian distro 5 years from now.

[sandal]

My only real concern:
Will there be a point where the coins I have in armory will be unmoveable?

Do I need to use a different wallet for the time being?

0.93.3 is fine for at least another couple years.

Great to hear.

Thank you, goatpig!!

[solitude]

My only real concern:
Will there be a point where the coins I have in armory will be unmoveable?

Do I need to use a different wallet for the time being?

0.93.3 is fine for at least another couple years.

Funny how bitcoinarmory.com lists 0.93.2 as the latest release for ages now.

[achow101]

My only real concern:
Will there be a point where the coins I have in armory will be unmoveable?

Do I need to use a different wallet for the time being?

0.93.3 is fine for at least another couple years.

Funny how bitcoinarmory.com lists 0.93.2 as the latest release for ages now.

Since ATI has been having problems and since ATI is no longer maintaining armory, it is not surprising that that site lists 0.93.2 as the latest. Since goatpig doesn't have access to that site, it is now longer the official site of Armory, we will need to get a new website instead.

[solitude]

How should I go about transferring my bitcoins from Armory to Trezor/Electrum?  Do I have to create a new address and send the bitcoins to that trezor address?

[BitcoinNewsMagazine]

How should I go about transferring my bitcoins from Armory to Trezor/Electrum?  Do I have to create a new address and send the bitcoins to that trezor address?

If you are using Trezor with their online wallet myTrezor.com just send your bitcoin from Armory to a receiving address in myTrezor.com. If you prefer to use Trezor with Electrum you will need to download Electrum-2.5.4. I like to use the portable version because you keep all data confined to one folder. Just make a folder called Electrum and put Electrum-2.5.4 in the folder. Plug in your Trezor and start Electrum, when prompted check create new wallet, hardware wallet then Trezor. Pick a receiving address to send to. Which ever method you choose do a small test transaction first until you are comfortable. If you are completely new to Trezor browse the user manual first. Remember Trezor must be initialized before you can use it with myTrezor.com or Electrum.

[achow101]

For CleanUpATI, what should we be replacing Armory Technologies Inc with? Also, what about links to the armory website? Since Armory's support infrastructure requires sending things to a server, where should those things (e.g. bug reports) go?

[goatpig]

For CleanUpATI, what should we be replacing Armory Technologies Inc with?

For now, nothing. Copyrights are in code files and the license file that should be bundled with every release. I don't believe there is a need to replace anything, just prune stuff out.

Also, what about links to the armory website? Since Armory's support infrastructure requires sending things to a server, where should those things (e.g. bug reports) go?

Nowhere. I'm getting rid of all phone home code in Armory for my upcoming release. I'll reevaluate each of them in a case per case basis once I have time.

[solitude]

Can anyone give me one good reason to stick with Armory?

How can we rely on one single dev (goatpig) to further development?

He's already stated he won't continue development if the money isn't there.  I'm not sure how much he's expecting to receive, but I'm guessing the money (won't) be there with so many free bitcoin client alternatives.

[achow101]

For now, nothing. Copyrights are in code files and the license file that should be bundled with every release. I don't believe there is a need to replace anything, just prune stuff out.

--snip--

Nowhere. I'm getting rid of all phone home code in Armory for my upcoming release. I'll reevaluate each of them in a case per case basis once I have time.

So basically remove/comment out any mention of ATI and the website except in the credits.

Can anyone give me one good reason to stick with Armory?

Armory is still one of the best and most secure clients or there. At this time, there is nothing that makes it obsolete and it still works very well. Just because ATI stopped working on it doesn't mean that the latest version is suddenly not usable.

How can we rely on one single dev (goatpig) to further development?

We can't and won't. Given some time, I'm sure that other developers will come out and help out with the project. Not every project has a team to begin with, the team comes with time.

Besides, he isn't the only developer, I'm also helping out and contributing.

He's already stated he won't continue development if the money isn't there.  I'm not sure how much he's expecting to receive, but I'm guessing the money (won't) be there with so many free bitcoin client alternatives.

He didn't say that development would stop, it would just slow down. It is kind of hard to develop full time on a project of you need to get a real job for money to actually live, and that is what will happen if there isn't money. Currently goatpig is unemployed.

[Bonez0r]

I don't know what form of crowdfunding you want to use, something like kickstarter maybe? An alternative that i don't think was suggested yet is Patreon. Instead of collecting a one-time funding, people can "subscribe" to your patreon and pay an amount either per month or per completed product.

There was an attempt to have it acquired by another company in order to keep funding development, but the time cost of such an acquisition got the best us. Simply put it takes too long to get things right and resume operations in a way that satisfies all parties involved. In the mean time, people aren't getting paid and they eventually run out of resources.

If time is the only problem, could crowdfunding be used to pay you while you make arrangements with said parties? Say $10K-$20K to buy you time?

[goatpig]

How can we rely on one single dev (goatpig) to further development?

Alan has developed Armory alone for the first 2 years of the project.

He's already stated he won't continue development if the money isn't there.  I'm not sure how much he's expecting to receive, but I'm guessing the money (won't) be there with so many free bitcoin client alternatives.

You misread. I'll invite you to go over the post again. My position is no dinero, no full time. I'll have to find a job to eat if the community doesn't pay for my day to day living. But that's some months down the road. My involvement in the project was never in question. And as I said elsewhere, this is up in the air still. There are other ways for open source devs to make a living.

EDIT:

I don't know what form of crowdfunding you want to use, something like kickstarter maybe? An alternative that i don't think was suggested yet is Patreon. Instead of collecting a one-time funding, people can "subscribe" to your patreon and pay an amount either per month or per completed product.

Someone pointed me to gitmoney.io. Looks interesting (get paid per commit) and it opens the room for other devs to get paid to work on the code. I'll review all options if it ever comes down to that.

The community is at liberty to setup something without consulting me to finance development (to pay me or other developers). I won't turn down PRs if they're up to par. If I end up turning the PRs down, you are always welcomed to fork the repo and forward your version there. This the open source world, it's all a matter of how much you want to get involved.

I would suggest you let me come up with 0.94 before exploring anything of that nature.

[goatpig]

If time is the only problem, could crowdfunding be used to pay you while you make arrangements with said parties?

I have nothing to do with the acquisition process. I am not a share holder nor an officer in ATI, these dealings are completely orthogonal to my current activity (whatever it would be for that matter).

Say $10K-$20K to buy you time?

I don't want to talk numbers just yet, but that's an amount I can live on for a year. There is a lot more money to be made than that as a consultant if I manage to carry the Armory torch properly. So again, it may not come down to that.

[Bonez0r]

Can anyone give me one good reason to stick with Armory?
[...]
 I'm not sure how much he's expecting to receive, but I'm guessing the money (won't) be there with so many free bitcoin client alternatives.

How many of them are as secure as Armory? Security is the reason i chose Armory out of all the available software wallets.

The size of the blockchain and the Armory DB is becoming a problem though. Today i had to move the blockchain to another drive because it was using up a sizable chunk of my ssd. Related feature request: moving the blockchain is easy, just move the folder and modify "bitcoin home dir" in Armory settings. It would be awesome if it was the same for Armory, i.e. if it had an "Armory home dir" setting.

[goatpig]

New DB is gonna be sub 250MB.

[sandal]

New DB is gonna be sub 250MB.

YES PLEASE

[jonathgb25]

New DB is gonna be sub 250MB.

That was a huge data man hahahahaha but you can develop a version for windows xp 32-bit because I can't use your client.

[goatpig]

New DB is gonna be sub 250MB.

That was a huge data man hahahahaha but you can develop a version for windows xp 32-bit because I can't use your client.

Microsoft themselves don't support WinXP anymore, why should I?

[sandal]

New DB is gonna be sub 250MB.

That was a huge data man hahahahaha but you can develop a version for windows xp 32-bit because I can't use your client.

Microsoft themselves don't support WinXP anymore, why should I?

Touche.

[unamis76]

I think there should be a sticky thread on this sub-forum redirecting new (and old) users correctly regarding Armory downloads. Can goatpig's GitHub be considered the place to go if one wants to compile Armory and the Releases page the official place to get compiled binaries from?

The sticky thread could later be updated when we find a new definitive home for Armory. The thread could also link to here and the last thread etotheipi made.

[Ente]

I am sure this will be taken care of once Goatpig has a fresh release for us :-)

Ente

[unamis76]

I am sure this will be taken care of once Goatpig has a fresh release for us :-)

Ente

Meanwhile users having issues need to install/reinstall/update Armory and the website is unavailable... I still think there should be a temporary thread with the links combined and easily accessible without searching threads

[goatpig]

I don't have moderator power in this sub forum. Afaik no Armory employee ever had.

[Ente]

Huh? Weird!
Talk to Theymos about it. It looks like there is no mod at all, in this sub?

Ente

[goatpig]

Huh? Weird!
Talk to Theymos about it. It looks like there is no mod at all, in this sub?

Ente

Indeed, no dedicated mods to this sub. I believe that leaves gmax in charge. Alan asked for moderator status some years ago and it never got to anything, so he gave up. Not sure if I want to go down that path too. I'm perfectly fine with an active member of the community getting mod status in this sub.

[pop9119]

Hi goatpig,

I'm concerned about the ability to just simply change the license for the program. I believe that if you still use parts of the old Armory under the AGPL3 that forces you to release your program under the AGPL3.

I'm not a lawyer but what frightens me is that if the "powers that be" of Armory couldn't/wouldn't allow you to use the 0.94 code, I don't have a lot of faith that they might not allow you to continue to work on the program under a different license.

I want Armory to continue, and I would not like to see your work shutdown/removed/destroyed by the copyright holders. Admittedly if they couldn't get the rights to the program for the community before this shut down, they probably wont easily be able to claim a copyright violation.

I don't know how Armory (the company) is structured, but maybe you can see if they will give you the right to license the program differently that doesn't force this AGPL3 upon you.

Its very saddening to hear from Alan about Armory taking this turn. I know the work that Alan, you, knightDK, (and all of the testers and others idk off the top of my head currently) has been fantastic and hope to keep seeing great things from all including the community.

[coins101]

Hi goatpig,

I'm concerned about the ability to just simply change the license for the program. I believe that if you still use parts of the old Armory under the AGPL3 that forces you to release your program under the AGPL3.

I'm not a lawyer but what frightens me is that if the "powers that be" of Armory couldn't/wouldn't allow you to use the 0.94 code, I don't have a lot of faith that they might not allow you to continue to work on the program under a different license.

I want Armory to continue, and I would not like to see your work shutdown/removed/destroyed by the copyright holders. Admittedly if they couldn't get the rights to the program for the community before this shut down, they probably wont easily be able to claim a copyright violation.

I don't know how Armory (the company) is structured, but maybe you can see if they will give you the right to license the program differently that doesn't force this AGPL3 upon you.

Its very saddening to hear from Alan about Armory taking this turn. I know the work that Alan, you, knightDK, (and all of the testers and others idk off the top of my head currently) has been fantastic and hope to keep seeing great things from all including the community.

It's not 100% clear, but....the existing licence allows the original developers / company to retain ownership of what they developed. But, this is the key thing...they gave rights away to their code for no fee.

If someone else builds on top, then what is their loss?  What would the law suit say on the IP case? You added your own code, for which you give it away for free; and it hurt my IP, which I also gave away freely?

Seriously. Who is going to spend $100k on chasing a law suit, without any financial loss that they can show?

Here is your homework: A thought experiment. You are heading to your lawyers office, to discuss making a claim about someone using your open source software, to make more open source software....what exactly are you going to say to your lawyer?

[goatpig]

AGPL3 is still an open source license. You can develop code on top of AGPL3 code, use any license you want that is compatible with AGPL3 (Boost isn't as an example, MIT is), and retain full ownership of your own work.

What you can't do is use AGPL3 licensed code commercially without a license issued from the owner. In the case of Armory, if someone wanted to use my version of Armory for commercial purposes, they need not ask my permission (my additions are MIT), but they will have to seek licensing from ATI (all their code is AGPL3).

ATI can't sue me because I am developing on top of their code base. The MIT license is compatible with AGPL3 after all. ATI can't sue me either if someone was to use my version of Armory commercially. They would have to sue the particular user/business who didn't get a license from them, and I am attaching ATI's AGPL3 text where due in my code (can't blame me for lying about the copyright).

[unamis76]

I don't have moderator power in this sub forum. Afaik no Armory employee ever had.

I suspected that. Anyways, it's you call, fine by me and pretty much anyone else on this thread, we know how to get our source and binaries from... I suggested this after reading about a user having issues with an older version and well... the binaries have to be somewhere visible for people who spend less time here to update. I haven't taken the liberty to create a thread with links and an explanation because it wouldn't be stickied and would probably get lost between all the threads I don't think mods would stick a thread not made by you.

[goatpig]

I don't have moderator power in this sub forum. Afaik no Armory employee ever had.

I suspected that. Anyways, it's you call, fine by me and pretty much anyone else on this thread, we know how to get our source and binaries from... I suggested this after reading about a user having issues with an older version and well... the binaries have to be somewhere visible for people who spend less time here to update. I haven't taken the liberty to create a thread with links and an explanation because it wouldn't be stickied and would probably get lost between all the threads I don't think mods would stick a thread not made by you.

I'll look into getting mod status once I go into the whole release/website dance. For now, I want to focus on coding. At the current rate, I could have a testing phase this week.

[unamis76]

I'll look into getting mod status once I go into the whole release/website dance. For now, I want to focus on coding.

Understandable. Thank you for your effort.

At the current rate, I could have a testing phase this week.

Wasn't expecting this so soon, interesting

[achow101]

If you have time, could you write up instructions on the entire release process for building and packaging releases? I am trying to figure out how to do gitian builds with armory but I can't figure out how releases are currently being built and packaged.

[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?

[droark]

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

Gaaaaaah. I think I misread goatpig's post. Nevermind. That said, there probably should be a switch at some point. Crypto++ is just outgunned for this kind of work. That and there may be certain features (e.g., Schnorr signatures) coming eventually that Crypto++ doesn't support.

On a different note, the latest build fixed my balance issues. Am able to send coins too. Coin control doesn't work, though. Here's what I see when i try to choose specific UTXOs.

Code:

Traceback (most recent call last):
  File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/TxFrames.py", line 785, in createTxAndBroadcast
    ustx = self.validateInputsGetUSTX()
  File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/TxFrames.py", line 602, in validateInputsGetUSTX
    utxoList = self.getUsableTxOutList(totalSend)
  File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/TxFrames.py", line 863, in getUsableTxOutList
    utxos = cppAddr.getSpendableTxOutList(IGNOREZC)
  File "/Users/droark/Projects/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/CppBlockUtils.py", line 1969, in getSpendableTxOutList
    def getSpendableTxOutList(self, ignoreZC=True): return _CppBlockUtils.ScrAddrObj_getSpendableTxOutList(self, ignoreZC)
RuntimeError: not implemented

[goatpig]

ugh ill get on it.

[achow101]

Can we add support for compressed keys to the list of things to do?

[goatpig]

Once I take care of BIP32/44 I'll add that as well

[superbit]

Am I OK to update core to 0.12.0 and keep using armory until you release a new version?

[achow101]

Am I OK to update core to 0.12.0 and keep using armory until you release a new version?

Yes. 0.93.3 works fine with bitcoin core 0.12

[achow101]

Who controls bitcoinarmory.com? It appears that the site is back up and different from the old one. It also has the latest versions posted.

Edit: typos

[goatpig]

Echo controls bitcoinarmory.com? It appears that the site is back up and different from the old one. It also has the latest versions posted.

No idea who's doing what on that front.

[Carlton Banks]

Echo controls bitcoinarmory.com? It appears that the site is back up and different from the old one. It also has the latest versions posted.

No idea who's doing what on that front.

Alan can't be behind it, or at least I would assume he would let you know about it. It seems conciliatory on the surface, but it's best to be cautious nonetheless. This could be the pre-amble to ATI's own fork (riding on your work initially, it seems).

[solitude]

Just to be clear, Armory will be SegWit compatible assuming Core isn't jerking us around and actually soft forks in April?

[goatpig]

Just to be clear, Armory will be SegWit compatible assuming Core isn't jerking us around and actually soft forks in April?

I will support SW, no ETA yet though.

[unamis76]

Who controls bitcoinarmory.com? It appears that the site is back up and different from the old one. It also has the latest versions posted.

Edit: typos

Domain seems to be still controlled by etotheipi... I wouldn't trust it though.

[RoadStress]

Who controls bitcoinarmory.com? It appears that the site is back up and different from the old one. It also has the latest versions posted.

Edit: typos

Domain seems to be still controlled by etotheipi... I wouldn't trust it though.

Does anyone have the sig hashes from the latest version? We can compare them with the ones on the website in order to be sure.

[achow101]

Who controls bitcoinarmory.com? It appears that the site is back up and different from the old one. It also has the latest versions posted.

Edit: typos

Domain seems to be still controlled by etotheipi... I wouldn't trust it though.

Does anyone have the sig hashes from the latest version? We can compare them with the ones on the website in order to be sure.

They're on https://github.com/goatpig/BitcoinArmory/releases/tag/v0.93.3

[achow101]

So a few weeks ago I emailed the people at the Free Software Foundation seeking some help about the licensing issue here, and they finally responded.

This is what I was told:

AGPL is a non-revocable license which allows anybody to keep using the code and build on it as long as they comply with the license requirements. ... If the code was published under the (non-revocable) AGPL, then it can continue to be used. ... Assuming the code was published under the AGPL, developers can continue to use it as long as they comply with the AGPL.

This means that any of the code published under AGPLv3 can be used regardless of whether the original developers pulled the original repository. Anyone who has access to that code is allowed to use it so long as they comply with the terms of the license.

To comply with the terms of the license though, any binaries that are published MUST be published under AGPLv3 since it is using the original AGPLv3 code base. Also, the entire project must be licensed under AGPLv3 because it is using AGPLv3 licensed code.

[droark]

Who controls bitcoinarmory.com? It appears that the site is back up and different from the old one. It also has the latest versions posted.

Edit: typos

It's probably Trace.

[SimonBelmond]

I just quickly want to chime in and also thank all the people that have worked on Armory so far and will do so in the future. I is my favorite wallet and I will follow this new branch closely. What is the best channel to follow about major new features and releases? Is there a donation address for this new OS Armory branch?

[unamis76]

I just quickly want to chime in and also thank all the people that have worked on Armory so far and will do so in the future. I is my favorite wallet and I will follow this new branch closely. What is the best channel to follow about major new features and releases? Is there a donation address for this new OS Armory branch?

The best channel to know more about new releases is here, especially this thread, for now. As said before, no donations accepted by goatpig, at least for now.

[Ente]

So a few weeks ago I emailed the people at the Free Software Foundation seeking some help about the licensing issue here, and they finally responded.

This is what I was told:

AGPL is a non-revocable license which allows anybody to keep using the code and build on it as long as they comply with the license requirements. ... If the code was published under the (non-revocable) AGPL, then it can continue to be used. ... Assuming the code was published under the AGPL, developers can continue to use it as long as they comply with the AGPL.

This means that any of the code published under AGPLv3 can be used regardless of whether the original developers pulled the original repository. Anyone who has access to that code is allowed to use it so long as they comply with the terms of the license.

To comply with the terms of the license though, any binaries that are published MUST be published under AGPLv3 since it is using the original AGPLv3 code base. Also, the entire project must be licensed under AGPLv3 because it is using AGPLv3 licensed code.

Thanks for asking the pros! :-)
I was confused, as to why the removed 0.94 code would be off limits to us. 0.93 and 0.94 were both published under AGPL, the only difference is how long they have been online on a particulary website, github. Which carries no weight here.
Of course we can't force ATI to publish the code again, they can do with their github account as they please.
But if only one copy was saved by anyone out there, he may redistribute and republish under the AGPL again.

It's up to Goatpig to decide if this is a smart move, as ATI might not like that move for whatever reason. But they can't do anything against it except ask us friendly to delete the code.

Ente

[droark]

So a few weeks ago I emailed the people at the Free Software Foundation seeking some help about the licensing issue here, and they finally responded.

This is what I was told:

AGPL is a non-revocable license which allows anybody to keep using the code and build on it as long as they comply with the license requirements. ... If the code was published under the (non-revocable) AGPL, then it can continue to be used. ... Assuming the code was published under the AGPL, developers can continue to use it as long as they comply with the AGPL.

This means that any of the code published under AGPLv3 can be used regardless of whether the original developers pulled the original repository. Anyone who has access to that code is allowed to use it so long as they comply with the terms of the license.

To comply with the terms of the license though, any binaries that are published MUST be published under AGPLv3 since it is using the original AGPLv3 code base. Also, the entire project must be licensed under AGPLv3 because it is using AGPLv3 licensed code.

Thanks for asking the pros! :-)
I was confused, as to why the removed 0.94 code would be off limits to us. 0.93 and 0.94 were both published under AGPL, the only difference is how long they have been online on a particulary website, github. Which carries no weight here.
Of course we can't force ATI to publish the code again, they can do with their github account as they please.
But if only one copy was saved by anyone out there, he may redistribute and republish under the AGPL again.

It's up to Goatpig to decide if this is a smart move, as ATI might not like that move for whatever reason. But they can't do anything against it except ask us friendly to delete the code.

Ente

I've said it before but I'd love to see goatpig allow the inclusion of a few PRs under Alan's repo. They would've gotten the ball rolling on deterministic builds and some other neat stuff. I'd like to think usage of the code is in the clear legally. But, it's not my project. All I can do is ask politely.

[visdude]

My online Armory wallets are 93.3 and my offline wallets are 92.3 (Windows) and 93.2 (Linux). Will these offline wallet versions be compatible with the next release (0.94) and beyond especially with the implementation of SW?

[unamis76]

My online Armory wallets are 93.3 and my offline wallets are 92.3 (Windows) and 93.2 (Linux). Will these offline wallet versions be compatible with the next release (0.94) and beyond especially with the implementation of SW?

Yes, it will be compatible, at least for now

[achow101]

My online Armory wallets are 93.3 and my offline wallets are 92.3 (Windows) and 93.2 (Linux). Will these offline wallet versions be compatible with the next release (0.94) and beyond especially with the implementation of SW?

These versions will still be compatible however you should consider upgrading. 0.94 has a new database structure which reduces the databases by a massive amount (from 60+ Gb to a 300 Mb IIRC).

[visdude]

My online Armory wallets are 93.3 and my offline wallets are 92.3 (Windows) and 93.2 (Linux). Will these offline wallet versions be compatible with the next release (0.94) and beyond especially with the implementation of SW?

Yes, it will be compatible, at least for now

These versions will still be compatible however you should consider upgrading. 0.94 has a new database structure which reduces the databases by a massive amount (from 60+ Gb to a 300 Mb IIRC).

Thanks for the quick replies.

Pardon me as I've not been able to follow this thread for a couple of weeks now but is there already an official release of 0.94? If so, where can I get it?

With Windows, I'm aware that the same executable can be used to install both online and offline wallets. With Linux (I have Mint), I think the offline wallet installation requires a separate "offline package", IIRC. Would it still be the same installation procedures with 0.94?

[achow101]

Thanks for the quick replies.

Pardon me as I've not been able to follow this thread for a couple of weeks now but is there already an official release of 0.94? If so, where can I get it?

Not yet, just a testing release. The latest testing release is available at https://github.com/goatpig/BitcoinArmory/releases/tag/0.93.99.1

With Windows, I'm aware that the same executable can be used to install both online and offline wallets. With Linux (I have Mint), I think the offline wallet installation requires a separate "offline package", IIRC. Would it still be the same installation procedures with 0.94?

When the official release comes out, it should all be the same installation procedure.

[visdude]

Thanks for the quick replies.

Pardon me as I've not been able to follow this thread for a couple of weeks now but is there already an official release of 0.94? If so, where can I get it?

Not yet, just a testing release. The latest testing release is available at https://github.com/goatpig/BitcoinArmory/releases/tag/0.93.99.1

With Windows, I'm aware that the same executable can be used to install both online and offline wallets. With Linux (I have Mint), I think the offline wallet installation requires a separate "offline package", IIRC. Would it still be the same installation procedures with 0.94?

When the official release comes out, it should all be the same installation procedure.

Thanks for the info.

[Dabs]

Compressed keys? (The private ones that begin with K or L instead of 5.)

[achow101]

Compressed keys? (The private ones that begin with K or L instead of 5.)

Not yet. It is on the todo list.

[goatpig]

@goatpig I deleted some torrent code and submitted to the CleanUpATI branch but it seems like it's not up to date with master, so that led to a lot of commits. Am I doing something wrong?

I doesn't matter which branch you push these kind changes to, I merge PRs manually anyways. dev is unstable right now, I'll merge that stuff in once it builds again.

[achow101]

I doesn't matter which branch you push these kind changes to, I merge PRs manually anyways. dev is unstable right now, I'll merge that stuff in once it builds again.

So do I need to resubmit the PR?

You can just reopen it. Go to the PR and you should have a button which allows you to reopen the PR.

[BitcoinNewsMagazine]

Realistically will Armory ever support Trezor within a reasonable time frame (6 months)?

[AussieHash]

Realistically will Armory ever support Trezor within a reasonable time frame (6 months)?

If your rationale is privacy, sync to your own node, slush suggests there will be a solution for that tomorrow.

[goatpig]

I doesn't matter which branch you push these kind changes to, I merge PRs manually anyways. dev is unstable right now, I'll merge that stuff in once it builds again.

So do I need to resubmit the PR?

I merge manually, i.e. I pull all PRs locally and git merge to the branch of my choosing. You can PR to any branch you want, it doesn't make much of a difference from my stand point. What you need to be careful about is basing your work on a commit that won't cause too many merge conflicts. Ideally you want to submit changes that are completely orthogonal to what other me and other contributors are doing, so as to reduce conflicts and overlaps.

[goatpig]

Realistically will Armory ever support Trezor within a reasonable time frame (6 months)?

Getting there.

[maxmint]

Is there any way to download old versions of Armory? I'm looking for the 0.92.3 offline bundle for Ubuntu 12.04 but unfortunately can't find this anywhere. Thanks for any hints.

[achow101]

Is there any way to download old versions of Armory? I'm looking for the 0.92.3 offline bundle for Ubuntu 12.04 but unfortunately can't find this anywhere. Thanks for any hints.

The oldest ones are 0.93.3. If you want older, you will need to build it yourself. But why do you want old software?

[BitMaxz]

Is there any way to download old versions of Armory? I'm looking for the 0.92.3 offline bundle for Ubuntu 12.04 but unfortunately can't find this anywhere. Thanks for any hints.

The oldest ones are 0.93.3. If you want older, you will need to build it yourself. But why do you want old software?

I think old software for now is useless and its better to use the latest version has fixed new blocks headers issue..

[ABISprotocol]

My online Armory wallets are 93.3 and my offline wallets are 92.3 (Windows) and 93.2 (Linux). Will these offline wallet versions be compatible with the next release (0.94) and beyond especially with the implementation of SW?

These versions will still be compatible however you should consider upgrading. 0.94 has a new database structure which reduces the databases by a massive amount (from 60+ Gb to a 300 Mb IIRC).

Goatpig / others, will the next release support offline transactions? (Right now I think you have to offline sign with 0.92 and broadcast with 0.93.3, or am I mistaken? Can any version handle offline transactions?)

see for example:  http://betteroffbitcoin.com/a-protocol-for-offline-bitcoin-over-radio-transactions/ (something which I think is very cool)

[gangtraet]

Any reasonably new version of Armory can handle offline signing for any other reasonably new version of Armory.

What goatpig wrote was that he would not release precompiled offline bundles of the newest version, since there is no need to use the newest version (0.94.X) on an offline computer, 0.93.X is just as good.

[bitpop]

Any reasonably new version of Armory can handle offline signing for any other reasonably new version of Armory.

What goatpig wrote was that he would not release precompiled offline bundles of the newest version, since there is no need to use the newest version (0.94.X) on an offline computer, 0.93.X is just as good.

That's what's confusing. What does offline bundle mean? There's never been an offline version.

[AussieHash]

Any reasonably new version of Armory can handle offline signing for any other reasonably new version of Armory.

What goatpig wrote was that he would not release precompiled offline bundles of the newest version, since there is no need to use the newest version (0.94.X) on an offline computer, 0.93.X is just as good.

That's what's confusing. What does offline bundle mean? There's never been an offline version.

There were offline bundles that one could download built for ARM with the dependency libraries so you would not need to connect your cold offline Pi and `sudo apt-get`.  I believe the ARM builds are no longer part of the official releases.

[bitpop]

Any reasonably new version of Armory can handle offline signing for any other reasonably new version of Armory.

What goatpig wrote was that he would not release precompiled offline bundles of the newest version, since there is no need to use the newest version (0.94.X) on an offline computer, 0.93.X is just as good.

That's what's confusing. What does offline bundle mean? There's never been an offline version.

There were offline bundles that one could download built for ARM with the dependency libraries so you would not need to connect your cold offline Pi and `sudo apt-get`.  I believe the ARM builds are no longer part of the official releases.

Oh never knew that. I just used an offline pc. Now "offline" makes sense.

[goatpig]

That's what's confusing. What does offline bundle mean? There's never been an offline version.

There are offline packages, for Ubuntu and Raspberry Pi. It's a set of bundles with all the packages needed in order to install Armory on fresh OSs without the need to connect to an online package repository.

This doesn't apply to Mac nor Windows because these packages are already plug and play.

There is indeed no difference code wise between offline and online bundles. That may change in the future (lean and mean builds with no connectivity code for offline signers).