Bitcoin Forum
December 04, 2016, 12:35:14 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 116 »
501  Bitcoin / Armory / Re: Moving forward with Armory on: February 14, 2016, 03:24:37 PM
I don't have moderator power in this sub forum. Afaik no Armory employee ever had.
502  Bitcoin / Armory / Re: Armory hangs on "Organizing Blockchain" (>12h). Grateful for any help. on: February 14, 2016, 03:23:08 PM
None of these lines are relevant to your issue. You should start BitcoinQt manually and let it fully sync. In Armory, turn off auto bitcoind management then start it after BitcoinQt. Report what happens here.
503  Bitcoin / Armory / Re: lost transaction on: February 13, 2016, 06:00:36 PM
Kevinjulio, I am not sure what you mean? I am just using Armory's wallet.

The sync finished (it took more than 2 days!), but I am still not seeing the bitcoins in my wallet. My wallet still has the address that I sent the coins to but its still not finding it. :/

The number of blocks shown in the bottom right corner of armory is smaller than the number of blocks of transaction history that bitcoin core has retrieved. ive tried hitting rescan on armory and it did not increase the count at all. Any more ideas?


Your blockchain data is corrupt.
504  Bitcoin / Armory / Re: Moving forward with Armory on: February 09, 2016, 01:47:30 AM
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?
505  Bitcoin / Armory / Re: Moving forward with Armory on: February 09, 2016, 12:18:23 AM
New DB is gonna be sub 250MB.
506  Bitcoin / Armory / Re: Moving forward with Armory on: February 09, 2016, 12:05:46 AM
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.
507  Bitcoin / Armory / Re: Moving forward with Armory on: February 08, 2016, 11:59:24 PM
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.


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 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.
508  Bitcoin / Armory / Re: RBF in Armory on: February 08, 2016, 11:52:44 PM
I haven't had time to review the changes. Been traveling/catching up with Alan all day long.

Even if I was to merge the PR now, it still needs to be merged into dev later to be part of the next release process. I could just merge it now and review later really, since the changes are secluded to a dedicated branch.
509  Bitcoin / Armory / Re: Moving forward with Armory on: February 08, 2016, 04:02:15 AM
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.
510  Bitcoin / Armory / Re: Moving forward with Armory on: February 07, 2016, 06:12:24 PM
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.
511  Bitcoin / Armory / Re: RBF in Armory on: February 07, 2016, 05:50:21 PM
1) Display received RBF at all time. Add some distinctive GUI marker to separate it from non RBF ZC (maybe turn the RBF txn line red in the ledger while it has 0 conf).

2) Allow for the creation of RBF enabled transaction. Add some GUI changes again to separate these non RBF spends ZC too (turn those lines blue in the ledger?)

3) All spends have RBF disabled by default.
Sounds good.

For RBF spends that the user sent, there should be an option somewhere (maybe in the right-click menu) to send a replacement transaction.

I think that should be part of the reworked coin selection feature (to let users pick not only addresses, but individual utxos within an address). With that overhaul, RBF-spent-but-yet-confirmed txouts can be color flagged vs spent without RBF txouts. Most of that work is figuring out a functional GUI flow and then battling Qt.

As much as I'd like to take care of RBF quickly, I don't believe enabling RBF creation makes much sense without the coin selection overhaul.
512  Bitcoin / Armory / Re: RBF in Armory on: February 07, 2016, 07:50:45 AM
I also agree with RBF appearing only in Expert mode:

RBF creation or displaying? There is also the possibility to not display received RBF zero conf unless Armory is set to expert.

So far I'm thinking:

1) Display received RBF at all time. Add some distinctive GUI marker to separate it from non RBF ZC (maybe turn the RBF txn line red in the ledger while it has 0 conf).

2) Allow for the creation of RBF enabled transaction. Add some GUI changes again to separate these non RBF spends ZC too (turn those lines blue in the ledger?)

3) All spends have RBF disabled by default.

I'll give this discussion another couple days. If I don't get more suggestions/objections to these terms, I'll lock these in for 0.94.
513  Bitcoin / Armory / Re: Moving forward with Armory on: February 06, 2016, 11:22:21 PM
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.
514  Bitcoin / Armory / Re: RBF in Armory on: February 06, 2016, 10:20:35 PM
I think RBF support is critical to making confirmations reliable

That would be displaying RBF flagged transactions. That's what the PR covers.

the only reason to send a transaction without opt-in RBF is if the merchant accepts 0-conf.

I wouldn't turn on RBF enabled tx by default, I was rather thinking of extra GUI to turn on RBF at the user's discretion, per spend. Discuss away.
515  Bitcoin / Armory / RBF in Armory on: February 06, 2016, 08:48:49 PM
This thread is for discussing at which level Armory should handle RBF transactions.

knightdk submitted a PR to display RBF enabled ZC transactions in the GUI:

Please read the comment section there. The goal here is to figure out whether Armory should only display RBF transactions, or allow the creation of RBF transactions too. I believe that is something desirable in Armory, but it is a topic that should be discussed first before moving further.

Special thanks to knightdk for the PR and helping with this work in general.
516  Bitcoin / Armory / Re: Moving forward with Armory on: February 06, 2016, 08:10:55 PM
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.
517  Bitcoin / Armory / Re: Moving forward with Armory on: February 06, 2016, 06:55:57 PM
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.
518  Bitcoin / Armory / Re: Moving forward with BitKnox on: February 06, 2016, 06:54:44 PM
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.
519  Bitcoin / Armory / Re: Moving forward with Armory on: February 06, 2016, 01:03:13 AM
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).
520  Bitcoin / Armory / Re: Moving forward with Armory on: February 05, 2016, 06:50:50 PM
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."  Grin

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 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: It uses Jekyll (which github recommends using) and Github Pages as the hosting. The code is at 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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 116 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!