The following workaround seems to be giving me some success:

If you get the "unexpected magic characters" error, make sure you have a non-hardware wallet window open in Electrum (create a dummy wallet for this purpose if you don't already have one) and then close your hardware wallet window (or all your hardware wallet windows if you have multiple open - although IME having multiple HW wallets open in Electrum tends not to work well).  Then re-open the offending hardware wallet using Electrum's  "Open" menu.  This seems to work for me quite well (on OS X).  YMMV...

(EDITED because the above seems to work better than my first suggestion.  For the record, my previous suggestion was: "It seems to be that the "unexpected magic characters" message is, at least sometimes, not fatal.  Try doing something that requires authentication with the Trezor (such as signing a message) and Electrum might recover....")

I've been seeing the same since updateing my Mac from 10.11.4 to 10.12.4.

I'm guessing it's an issue with some recent update to OS X.

Yeah, it's a bit broken, isn't it.  It's been like that since forever - don't know why they haven't fixed it yet.  EDIT: I've reported it to them.  We'll see if it  does any good.

Still, bitcoin.org and bitcoin.com are on opposite sides of the block size debate.  Since Armory is blocksize-agnostic (AFAIK) it would be good to aim for a listing in both places.

Well, assuming that's true in some jurisdiction then if, hypothetically, Monero had been designed without a view key - so that the only way you could view your transactions was with your private key - then in that scenario a court could almost certainly just order you to release the private key instead.  Better to give the court just the ability to view, rather than the ability to view and spend.

It's much the same as (one of) the more general arguments for not using the same keys for encrypting and signing messages.  In many jurisdictions courts can demand keys to decrypt your messages, but there's rarely if ever a valid reason for them to demand to be able to forge your signature on messages.  So again, it's useful to be able to give them just the key they need, rather than the only way of complying with the order being to give them far more than they need.

roy

Maybe also try getting listed on bitcoin.com?

There definitely is a lack of appreciation outside of this forum that open-source Armory is still going strong.  And also a lack of knowledge outside this forum as to who goatpig is and why they should trust the new releases.

I don't really know what we can do to help get the word out, though.

Unfortunately those who buy from illegal online pharmacies are often digging their own graves, too - that's part of the reason governments are cracking down on them.  The incidence of customers receiving medication that is at best ineffective and at worst actively dangerous seems to be quite high.

Are you talking about the issue with repeated k-values in ECDSA signatures?  In principle EdDSA (as used with Ed25519) has the same problem.  However, DJB's reference implementation uses deterministic k-values (as, I suspect, do all implementations of Ed25519) to avoid the need for a crytographically strong random number generator during signing (you still need a cryptographically strong random number generator for key generation, though!)

This solution isn't unique to EdDSA, though - deterministic k-values can and are used with conventional ECDSA, too.  RFC6979 defines one such  implemention, and I believe that some Bitcoin wallets actually use this.  The difference is that ECDSA (like DSA) is conventially defined and implemented with random k-values (like DSA) meaning that most implementations have an unnecessary vulnerability in the event of a poorly-seeded PRNG.

Also, more generally than just choice of curve, the CryptoNote coins (of which Monero is one) are rare amongst cryptocurrencies in sharing very little of the cryptographic design of Bitcoin.  So in the event that a flaw is found in Bitcoin's cryptographic design, there's a reasonable chance it might not affect Monero (or vice versa).

The one obvious advantage that Bitcoin does currently have over CryptoNote is that its design (which has remained fundamentally unchanged since it's initial launch) has been very widely studied over the years since then.  Generally this kind of widespread review is the only way to gain assurance that there are no flaws in a cryptographic protocol, and Monero has inevitably had fewer cryptographic eyes on it.

Of course, in the very near future Bitcoin is likely to deploy segwit.  Although segwit doesn't change the underlying cryptography, a significant change to cryptographic protocol always carries a risk of unintended consequences - so it becomes harder to argue that Bitcoin, in its post-segwit future form - will have had the same number of eyes on it.

I agree that Wikipedia article isn't as clear as it could be - in that the context of the Bruce Schneier quote isn't particularly clear to readers not familliar with the history of the curves being discussed here.  But I assure you that Bruce was not talking about Curve25519 there.

The reason for the inclusion of that particular quote in the article is to explain why Curve25519 has become popular in recent years:  there are concerns about the choice of constants in other curves, which has resulted in many more people using Curve25519 precisely because there are no such concerns with Curve25519.

Curve25519 is generally considered to be safe.  That said, there are those who worry (Bruce Schneier included) that the NSA may have made advances in the cryptanalysis of ECC in general - but if that's the case then any attacks might affect all curves - or at least, we have no way of knowing which curves are vulnerable.  If that were to be the case, it would be a concern for pretty much all cyrptocurrencies, though - potentially necessitating a move to larger keys (depending on how bad the attack is).

Actually, using a different curve to the one used by Bitcoin and most other coins is a good thing because it gives the market an opportunity to hedge the risk by holding coins that use different curves.  If an attack on ECC is found (by the NSA or someone else) it's quite possible (although by no means a given) that the attack might work better against some curves than others - although there's no real way to know which curves are safer in advance of the attack being found.

EDIT: Actually, looks like I was wrong - Monero uses Ed25519 and EdDSA (not Curve25519 and ECDSA).  So it shares even less crypto with most other coins that I had thought.

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.

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.

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.

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.

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.

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

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?

More out of curiosity than anything else, but is the secure downloader actually working at the moment?  For me, it complains that it hasn't seen an update in months, and won't show me anything recent.  But I self-built, so maybe something broke.

Is 0.93.3 going to be put up on the website?  Currently the downloads link still seems to point to 0.93.2.

roy

A product can be source-available, without being under a FOSS license.  This allows the community to review (without the need for an NDA) but only to run under a restrictive license (or possibly not legally to run at all without paying a fee).  Of course, not everyone will respect the license, but you have recourse to the courts if someone builds a business on your software illegally.  Recourse to the courts does rely on you finding out that the business is illegally using Armory, of course.  It's not perfect, but broadly speaking big financial institutions are likely to care about compliance.

Another compromise would be a closed source online component with an open source offline signer.  That's not perfect, either, but at least it gives a high degree of assurance for cold storage applications - which I presume are the main draw of Armory.  It's still far from ideal, though, since there's a very real risk that the government could require ATI to put a backdoor into the code.  Even though I'm not doing anything that would make me a target for government action, the very presence of such a backdoor would still increase the attack surface of my online system.