Topic: Moving forward with Armory - page 9. (Read 18528 times)
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.
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.
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.
Many thanks to both @etotheipi and @goatpig for all you've done,
please any chance to keep Armory alive and include Trezor support?
please any chance to keep Armory alive and include Trezor support?
Carlton Banks sums it all up in this thread: https://bitcointalksearch.org/topic/are-there-serious-plans-to-support-hardware-wallets-1350328
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.
Best of luck.
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.
Thanks armory is all I use
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.
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.
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.
Many thanks to both @etotheipi and @goatpig for all you've done,
please any chance to keep Armory alive and include Trezor support?
please any chance to keep Armory alive and include Trezor support?
Carlton Banks sums it all up in this thread: https://bitcointalksearch.org/topic/are-there-serious-plans-to-support-hardware-wallets-1350328
TLDR: need BIP32/44 first before implementing hardware wallets support.
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.
Quote
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.
Many thanks to both @etotheipi and @goatpig for all you've done,
please any chance to keep Armory alive and include Trezor support?
please any chance to keep Armory alive and include Trezor support?
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
Thank you etotheipi for everything! Sorry it didn't work out and good luck in your future ventures!
Thank you very much goatpig (and all the contributors) for your effort!
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!
What about lockboxes that were created?
Can funds be retrieved from lockboxes without using armory, with addresses, public keys, and private keys?
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).
What about lockboxes that were created?
Can funds be retrieved from lockboxes without using armory, with addresses, public keys, and private keys?
Can funds be retrieved from lockboxes without using armory, with addresses, public keys, and private keys?
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.
Quote
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.
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?
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.
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.
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.
Quote
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.
Quote
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).
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?
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.
Jump to: