Is that all on the first line? It can't be on any other line...

Is there a space between the "#" and the "--" ? There can't be a space there... (actually I just now uploaded a fixed version that no longer minds extra spaces there so that nobody else gets tripped up with this).

Hi.

Could you show exactly what command you're typing in, and also exactly what the error message is please?

Oops, silly mistake on my part, thanks....

TierNolan isn't wrong, but his answers are limited to BIPs which cause hard forks (on everyone's mind these days w.r.t. the blocksize limit...).

BIPs which don't cause hard soft forks do not need 95% miner support. BIPs don't need to be suggestions for Bitcoin Core or even the Bitcoin network. They can be purely informational in nature, e.g. BIP-32.

(Just some additional perspective....)

Do you know if your wallet was created with version 4.0 or higher (Released Oct 3, 2014)? If so, there may be an easier alternative....

If your wallet was generated by Electrum 2.x, an alternative to dealing with individual private keys would be export your one master private key ("xprv"), and import it into another wallet.

Unfortunately, you're limited in your other wallet options. The only one I'm aware of that this would work with is Mycelium for Android.

(How to export your xprv from Electrum: http://bitcoin.stackexchange.com/questions/36839/electrum-2-0-non-bip39-32-standardisation-complicates-matters-immensely-why/36945#36945)

Not trying to start an o/t flame war here, but Google and Apple (and even Ubuntu to some extent with their search provider deals) don't have the best privacy/security track records either.... I see no reason MS phones are much if any worse.

You cannot (easily anyways) create a new wallet in Electrum 2.x that uses a 128-character mpk. You could, if you needed to, temporarily run an earlier version of Electrum to generate an old-style wallet though. Full instructions (for Windows) can be found here: http://bitcoin.stackexchange.com/questions/37386/error-in-checkout-while-using-bitcoin-payments-by-bitcoinway-with-woocommerce/37388#37388

Take a look at the spreadsheet listed in this post: https://bitcointalk.org/index.php?topic=1000544.msg10862297#msg10862297

The second tab, labeled "mnemonic-compatible", lists wallets which use seeds compatible with one another. Specifically, you'll want one of the wallets listed in column L. If you used more than one account in Mycelium, you'll need to choose a wallet listed as "Yes", otherwise you can choose one listed as either "Yes" or "Partial".

I would never suggest that a newbie try to directly handle private keys, there is far too much danger involved in messing something up. If physical loss of a phone is a concern (and I agree it should be), usage of a deterministic wallet plus properly backing up the seed is much better advice IMO.


Aside from physical loss (which I addressed above), losses from malware are a real threat, and they are much smaller threat on mobiles than they are on desktops (at least for the time being...). IMO newbies should be steered towards mobile wallets, especially deterministic ones, not away from them.

(I certainly agree with you that large amounts shouldn't be stored in any hot wallet though.)

Why? And as opposed to what?


Why?


Why? Malware which targets mobile devices is considerably less common than PC-based malware, and some mobile devices are currently invulnerable to bitcoin-stealing malware (those which cannot yet be easily rooted such as iOS 8.3, most boot-locked android phones running 5.0.2, etc.).

Oops, you're completely correct there, my bad... but thank you for seeing past my technical failures

Maybe....

This doesn't address all of your questions, but for a partial answer take a look at this thread: https://bitcointalk.org/index.php?topic=1000544.0

Agreed.

It's rather ironic that ATI couldn't, as things currently stand, host an armoryd-based service off of their own website at https://bitcoinarmory.com/.

https://bitcoinarmory.com/ is (currently) hosted with the help of CloudFlare's anti-DDOS service. Although CloudFlare (as a for-profit company) has chosen to open-source some of their software (good for them!), their platform is not completely open source.

Although I don't have a problem in general with "copyleft" licenses (and have used them myself), I find (just IHMO) the AGPL license to be far too restrictive for my taste (edited to add: especially ATI's interpretation of the AGPL license)....

Having said all that, if that's how the Armory devs would like to see their code used, I can/will respect those wishes.

You misunderstand what I was trying to say (or rather I wasn't being very clear).

When you hit the "give me a new receive address" button, some wallets will [try to^*] always generate a new address. Other wallets will choose a currently unused address, although it may be an address that's been displayed to the user previously. Electrum is of the latter type—it's easy to mistakenly give the same address to multiple people as long as the address has no current transactions associated with it.


(I don't mean to pick on Electrum... it just happens to be a wallet I know which does this, there may be others as well.)

* It'd be reasonable for a wallet to avoid generating new addresses that would violate the wallet's gap limit, however a privacy-conscious wallet should at least warn the user if it presents the same receive address a second time.

The collection of factual data is nice, as are some of their ideas where existing wallets can improve privacy.


Not IMO... the score weighting is completely arbitrary. It's not unreasonable, but it'd be easy to reach very different conclusions with equally reasonable but different choices in the weighting.

Of course, people like to see a bottom line and generally can't be bothered to take the time to draw their own conclusions, so it's not surprising that the authors decided to create such a bottom line score (useless though it may be IMO)....

I'm also noticing at least two points which they did not consider, but perhaps should have.

1. Armory is I believe unique among popular wallets in that it still uses uncompressed public keys. This makes it possible to identify likely Armory-created transactions, and perhaps easier to correlate transactions to particular wallets.

2. Some wallets, e.g. Electrum, do not consider an address as "used" until it is associated with a transaction with a certain number of confirmations. If a wallet user asks for a new receive address, they will be presented with the same address as previously displayed until it is considered "used" by the above criterion. (In the Electrum case, they can manually choose an address which they believe has not yet been given out, but they must keep track of this themselves.)

I'm sure you're sick of hearing this , but any dev who developed a system like this in lieu of a signature scheme probably doesn't know what they're doing... I'd be very wary.



Make sure you click the BIP44 tab. If you have multiple Accounts in your Mycelium wallet, you'll need to modify the account # on that page as well (the number 0 corresponds to what Mycelium calls "Account 1", the number 1 corresponds to "Account 2", etc.).



Do you have the public key, or the address? A Mycelium address starts with a 1 (as I'm sure you know). A Bitcoin public key typically starts with a 02, 03, or 04, but it depends on the encoding used.

If you have the address, simply find it in the displayed list. The WIF-encoded private key is to its right.

Unless you choose to use, say, an armoryd instance to power your blockchain explorer or web store (these are not my words...).

Was there ever a 0.91.2 release?

There was a 0.91.2-rc1 release (available here: https://s3.amazonaws.com/bitcoinarmory-releases/armory_0.91.2-rc1_winAll.exe).

I think following releases were all 0.92 testing (alpha) releases and then 0.92.0.

Out of curiosity, why would you need it?

On my Windows box, MultiBit (Classic) works perfectly fine with the most recent Java SE8.


Agreed. The vulnerabilities you often hear about relate to the Java sandbox, not to Java itself. The sandbox is responsible for enforcing security rules on untrusted applications, typically run from inside a web browser. (Yes, the Java sandbox is infamous for its security bugs, and deservedly so).

MultiBit does not run inside a sandbox because it is not an untrusted app (you do trust it, don't you?). It has just as much access to your PC as any other normal Win32 app.

Also, if you have a need to, nothing prevents you from installing multiple versions of Java, in which case browser-based Java apps requiring the sandbox will use the most recent version by default.