Can't I use my 0.96.3 offline signer with 0.96.4 ?

I finally got around to try the RC build on my Macbook (macOS Sierra 10.12.6).  Unfortunately, it cannot broadcast transactions.

When I load a transaction that I signed offline, I cannot broadcast it.  The usual dialog comes up, I load the transaction from file, the usual gibberish appear in the window, but Broadcast and Copy Raw Tx (Hex) buttons remain gray.  And the green text "All Signatures Valid" does not appear.  Instead, a number of exceptions appear in the log: https://pastebin.com/7pv6U5iE

I have now reverted to the previous version and have broadcasted my transaction, but I am ready to try again (and to patch the Python code to test solutions).

EDIT: It is a BCH transaction, signed with the BCH signer.

There is now a 0.96.3, you probably want that one, at least if you ever plan on creating a fragmented backup.

Have you moved the app after you unpacked it? 

Some fancy security measure in OS X kicks in when an app is unpacked from a tar file or a zip file.  Most apps are not harmed by this, but it prevents armory from starting.  Once you move the app using the Finder, this security measure is disabled, and Armory should work again.

For me, an important feature of any wallet is that if the wallet disappears, then I can always get an old version running in a VM and then export my keys to another wallet.

I assume that if I use any of the new P2SH-based addresses in Armory, I no longer have that option; i.e. I can get my private keys out of Armory but I cannot make the corresponding scripts in another wallet, and therefore cannot (easily) spend the funds.

I assume that for segwit a standard will emerge solving this problem.  But until then, I guess I better stay away from both the segwit and the wrapped compressed key features.  Or am I overlooking something?


EDIT: I don't think the risk is vanishing.  If goatpig had not picked it up, Armory development would have stopped after etotheipi stopped working on the open source version.  And at least once did the Bitcoin network implement a soft fork that required an Armory update before it could sign transactions again.

I doubt that side-channel attacks are at all relevant for paper backups.  That normally requires statistical data on the timing or the amount of power it takes to do the operation.  It might be a worry that a compromized computer can gain information from a hardware wallet through side channels, but not when restoring a wallet.

My guess is that the main problem with SSS is that it is one of the few cryptographic operations that are simple enough that people implement it themselves, instead of getting it from a peer-reviewed and well-debugged library.


SSS does not just have a plausible deniability edge over multisig scripts (I am sure it does, although I cannot see how).  It solves a different problem: that of safely keeping backups.  Multisig of course gives the same security to your backup, but it also makes spending from the wallet on a day-to-day basis significantly more cumbersome.  And in times with high pressure on the blockchain, it also adds to the fee.

Are you looking at the new website: btcarmory.com ?

I think that part of the code is long gone.  Also, there is an error in the webpage you are quoting, it is on the *online* computer that you can download the signed packages, there is no way you can do that on the offline computer.  But I do not think that is supported any more at all.  Download from github, and check goatpig's GPG signature.

It is a common problem: Do you want to display a progress box, if you don't know how long the operation is going to take?  Some programs delay popping up the dialog until a few seconds have passed.  It can still pop up a fraction of a second before it closes, but now it is a lot less likely.

Or you could put a 1-sec delay on closing it.  But please don't require an extra click

Ah!  I must have been half asleep reading the Armory instructions to miss this

Will try it out.

I had misunderstood your post.  My bad.


Mine has a header line, and two data lines.  I am not completely pwned then, but only has a slightly reduced security.  Ah, well.



Oh my god!  It must be one of the worst security f*ckups in a bitcoin wallet!

This is even worse than I first thought.  In an N-of-M backup, each of the M sheets encodes a linear equation (linear in the unknown coefficients, not in x).  Together, they can be solved to find the N coefficients of a polynomial.  It requires N equations to find the N unknowns, this is where the most of the security comes from.  In addition, you want to avoid leaking information that could potentially reduce the search space for the unknowns, hence the random x values.

But if each sheet reveals a coefficient, then there are TWO equations on each sheet!  (y = c_0 + c_1 * x + c_2 * x^2 + ...  and c_i = x)

Thus you only need N/2 sheets to recover the key !!!.  The seed can be recovered from a single sheet of what was supposed to be a 2-of-M backup, or from two sheets of a 3-of-M or 4-of-M backup, etc etc.  

At least only the oldest Armory backups have this awful flaw.  The newer ones potentially leak some information that makes finding the key a little less impossible if you already have N-1 sheets.

NB: This is of course assuming that I have not misunderstood goatpig's undoubtedly slightly simplified explanation of the flawed algorithm.

Good point.  But since building with an older cross-compiler that I successfully used to build an older version of Armory still results in the "Illegal instruction" stuff, that could indicate that it is assembler code in the crypto library that causes the failure.  That the failure occurs at startup provides some evidence that the problem is not in said library, though.

I hope to get the new RPi today or tomorrow, but I will try a rebuild with the official cross-compiler if I get the time today.


EDIT:
The official cross compiler contains no installation instructions, no normal github releases, and no hints about how to use it.  I could perhaps work it out myself in a day or two, but I think I will just wait for the newer RPi.

Various web pages let me to believe that it could very well be the compiler, apparently the RPi 1 contains an older ARM cpu that the normal cross compiler does not support.

There are two things should be random in SSS.  The coefficients of the polynomial.  And the x-values where the polynomial is evaluated.

Non-random x values is probably relatively benign, since all information about the polynomial is in the f(x) values.  Wikipedia does not even mention that the x values should be random.

Pseudo-random coefficients is certainly a bad idea.  And printing the coefficients of the polynomial by using them as x-values is a horrendous mistake, I can hardly believe that it has been done!

Is there any way I can see on my 3-of-5 backup if it was made before or after that update was made?  I am of course going to move my funds, but doing so before a new 3-of-5 backup is in place is also a risk.



EDIT: Could not spell 'pseudo'

I can now confirm that it is a question of the age of the RPi (mine is a model 1 B).  I borrowed a model 3 B, and moved the SD card over in it; Armory then started perfectly.  I have ordered my own 3B now.


Yes: I was not aware of it

But the gcc cross compiler has been working previously for me.

I followed these instructions: https://github.com/goatpig/BitcoinArmory/tree/master/r-pi
with the exception that I broke up the line
into two, and added a --prefix.

I installed the cross-compiler using

Note that I do not think my Pi is a model 2, as I remember I bought it shortly before model 2 was released.
Maybe there is a difference.  Or maybe it is because I cross-compiled on a brand new virtual lubuntu.  I have just built it on the same old vm I think I used for the previous version, will try it out tonight.

Armory will not give you a wrong address.  Most likely, your Bitcoin Core installation is not yet synced with the blockchain.

Thanks, I'll try.  Unfortunately, 0.95.1 is not useful to me since it cannot sign BCH.  But if that is the case, I'll get a newer R-Pi (unless the problem is i686 assembler code!)

Hi,

I have previously built Armory for the Raspberry Pi using the instructions on the git.  I think it was version 0.93.3.  Now I need 0.96.2 so I can get my BCH out of the wallet, and I would prefer not to export private keys as I plan on keeping by BTC there (making a new Armory wallet is easy - getting the 3-of-5 backup distributed requires some logistics. )

Anyway, I compiled on an up-to-date lubuntu with the RPi cross compiler (comes as a package).  Moved it to a newly installed RPi.  If I use a Raspbian based on Debian Jessie then there is a GLIBC version mismatch, using the just released Raspbian based on Stretch does not have this problem.  But as Armory starts up, it crashes (before the splash screen) with an "Illegal instruction".

My RPi is really old, it was the first (or maybe second) model, and has a version 7 ARM cpu.  I tried recompiling with -march=armv7, but that did not help.  Does Armory contain some assembler code or the like that depends on a newer ARM CPU, or does a modern GCC just generate too new code?

I guess I could buy a new RPi.  Or does anyone else have a suggestion.

It is far from synced.  The last block is 485188 (see https://tradeblock.com/bitcoin), you are at block 217855.  You are missing a couple of years worth of blockchain data.  The full blockchain will be aroung 150 GB.

Googling "fedora qt4-linguist-tools" indicate that the package may be called qt4-dev-tools, although that answer was not for Fedora.

http://lalescu.ro/liviu/fet/forum/index.php?topic=703.0

EDIT:
This answer https://ask.fedoraproject.org/en/question/36411/how-to-install-qt-in-fedora-no-valid-kit-fund-when-create-project/
suggests running to see what packages are available, and states that as a minumum you should install qt-devel qt-doc and qt-creator