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.

[1715280349]

1715280349

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