Will look at it.

That's a way to look at the security of the fragment. There is no code allowing to go from 1 fragment to your secret atm, and doing this off of the second version of the SSS scheme is non trivial, just so we are clear.

The "Fragment:" field is not the wallet ID field. Are they mismatching in you restore attempt? Are you testing this with a pre or post fix backup?

I'd rather you don't confuse the 2 for the sake of convenience, but that's a way to look at it.

To allow for the use of segwit and compressed key in p2sh scripts, I developed a whole new wallet code. This stuff is in C++ and operates as companion code to the python stuff. The goal was to no disrupt the existing, time tested code, while providing new features for those willing to run new code.

This flashing dialog is for the operation the mirrors the python wallet containers into their new, C++ implemented counterparts. These wallets are WO only, as they only need the data necessary to register the scripts with the DB and construct unsigned transactions. And no, there's nothing to click on, it is just there for report progress on the mirroring, and closes on its own. I figured I'd rather let people see something progress than silently mirror wallets, which can take up to a couple minutes on large wallets.

You will see that dialog every run because you use an imported address, and the mirroring code goes through every import each run, since there is no deterministic way to verify the mirrored wallet is still in sync with the python counterpart.

I'm not sure where to take that part of the GUI atm (if letting the dialog flash is ok, or requiring user interaction to close it is gonna piss off people real quick).


Yep, I borked that when I fixed comments resolution in the main ledger.


And apparently I borked that too... fml.

Thanks for the reports, will go over that stuff .4

I think you're reading too much into gmax's words. His general concern with SSS implementations is that they are basically all done over prime fields, which the easier implementation, but introduces side channel attacks cause it relies on bignum operations.

A GF(256) implementation would be in constant time, but that's harder to pull and therefor brings in question whether it's worth the effort at all, considering multisig covers a lot of what SSS does. I argued that SSS still has an edge over multisig scripts (plausible deniability), therefor I'll consider implementing SSS over GF(256) for the new wallets.

Hmm there may be some misconceptions here. Fragments have always carried 2 IDs: the wallet ID, and the fragment ID. The new fragment ID is random instead of derived from the secret, but there always was these 2 IDs on the paper fragments to begin with. Are you saying the fragment ID from old backups is off now?

When restoring fragments, the code presents you with the fragment ID to check against your fragments at first. Once enough fragments are provided and the secret is reconstructed, it then asks you to compare the resulting wallet ID with the wallet ID on the fragments, which they also carry. This is a 2 step verification that should make sense on its own.

Let me know if you there are specifics in the GUI that you believe are off.

I'm don't know what you are referring to.

You mean it tells you to check the fragment ID vs wallet ID? I thought I got rid of that stuff ugh. Can you pinpoint where that happens?

From the changelog: https://github.com/goatpig/BitcoinArmory/blob/master/changelog.txt#L17


The IDs are different because the fragments are different. You cannot mix and match fragments from within different sets. The randomized ID is by design, so that users don't end up mixing them.

Only if you have not moved coins on the prefork chain past that point.

The logic is as follows: your last set of valid utxos pre fork is still valid on the Bcash chain (up until the point you move your bcash). If you roll back the BTC blockchain to a point in time where it stands past your last valid utxo set state and before you moved coins post fork on the BTC chain, these utxos are also valid on the Bcash chain.

Graphically, it would look like this:


Any chain tip between V and M has the utxo set state you need to move coins on the Bcash side of the fork (as there is no divergence in utxo sets yet in between the 2 sides of the fork).

So what you want to do is to feed Armory a copy of the chain with the tip belonging to [V, M[

rev files shouldn't matter at all, they're only relevant for Core's reorgs. What you need to nuke as well is your ArmoryDB (if you're not going to use a fresh folder).

Also, there's no guarantee file 949 will do it for you. Core does not download files sequentially, there's a chance post fork blocks are embedded somewhere deeper down your blk files. This file # is only relevant if your node was running at the time of the fork. If you caught up for more than a day of blocks after the fork, chances are you have post fork blocks all over the place. Granted, the only thing you are actually after is the blk file with the first post fork block. If that one is taken out, Armory can't compute the chain past the fork point and you should be good.

You can choose any x as long as the coefficients are random. I don't quite see how randomizing x achieves anything, as you have to provide entire points (x, f(x)) as fragments, therefor x is public information. Maybe you were trying to say that the x values should be chosen at random, instead of say, as part of a sequence? I don't think that's relevant at all for SSS, since all operation are performed on a finite field.



The coefficients are 32bytes, therefor your backup would have 5 lines (1 header line + 4 * (16bytes of data + 2bytes of checksum) lines) per fragment. If the fragment only has 1 header and 2 data lines, it's using implicit [1,...,N] for x.


It's far worse than that. Look at how the coefficients are constructed, they're hashes of the previous coefficient. Whatever fragment the attacker gets access to, he will be able to compute all following coefficients just by hashing x once.

Read this again and look at the code again. In the first scheme, anyone with access to a fragment that carries the first coefficient can compute *ALL* all of the coefficients. The single point he has with the fragment is then enough to reveal the secret.

This is slightly worsened by the fact that since there are more fragments than coefficients, certain coefficients reoccur on several fragments. Now people being people, when they distribute fragments they tend keep the first few for themselves, by happenstance. If the coefficients were distributed in order with fragments, this very human yet entirely irrelevant quirk would actually save these users from total disaster. Again, the order of coefficients matter since they are derived consecutively from one another

It's scanning two address sets independently for whatever reason. Do a rebuild & rescan.

Read the "Tricks" section

Hmm that sounds unlikely but I will definitely test it out.


This parameter controls the write queue depth for scan threads. It's only one element that controls total RAM footprint for scans, which would be broken down to these items:

- size of batches (hardcoded here: https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockchainScanner.h#L24)
- batch queue depth
- constant overhead from the container objects
- speed at which your system goes through the batches

After a substantial rework of the scanning queu mechanism, this parameter doesn't have much effect on full node scans as they're leaner, nor is it really necessary anymore. It is very significant for supernode however.

Use pastebin, my browser blocks that domain.

Something is off with how you pass your custom arguments. The cookie arg is not mandatory, if you start an instance of the DB and give that arg to your client you should be fine. Are you using something else than 127.0.0.1? Is localhost resolved to some other IP? You need to list out all parts of you setup that deviate from default settings and isolate them one after another.

It should find the DB instance by default.

ArmoryQt will first look for a DB on the given IP:port. If it can't find one, it will spawn a DB. If you are running a DB but ArmoryQt can't find it, you aren't giving it the proper IP:port to look at.