Apologies for not replying sooner... work+real life etc etc

No, I meant the wallet itself is too thin to contain a standard USB port (and by "standard" I meant microUSB or USB-C)

The device really is quite thin:



It uses an adapter called the "blade", which you plug a MicroUSB cable into... it's just a bit fiddly and annoying.

---

Good question... I would probably side with the Nano S, only because of the security flaw in the Trezor which absolutely requires that you use the passphrase functionality. But it's still very very close, like 51% Ledger S, 49% Trezor One... they really are very similar in performance and features.

I'm liking the new native Trezor Suite though.

The hdseed in a wallet.dat can be extracted in WIF, which is easily convertible to hex, which is easily convertible to binary... which is easily converted into a BIP39 seed. Can't say that I would recommend this as a way to back up your wallet though.

Additionally, the issue with this method of only storing the "seed", is that Bitcoin Core allows you to import private keys which are not covered by the seed... so there is potential for the user to import a private key, and then attempt to recover only to find that the private key is missing. This is why Bitcoin Core recommends that the entire wallet.dat file is backed up.

It is also the reason that Electrum explicitly refuses to allow importing of individual private keys into seed-based wallets, to prevent a scenario where a user believes all their funds are covered by the seed, when in fact they are not.


Are you related to jerry0??!?    

It's not very useful though. A confirmed transaction is confirmed, so it makes zero difference at that point whether it was replaceable... as once it is confirmed, it can't be replaced.

I can't really think of a useful purpose for a "was-yes/was-no" indicator outside of possibly testing that the flag was being set correctly... but it should be easy enough to simply generate a transaction and not broadcast it to see if the flag is being set as intended.

This.

If the wallet has loaded "OK" (ie. Bitcoin Core didn't output any obvious errors with the wallet being corrupt) and there are transactions displayed, then I would also guess that the previous balance that was shown was either outdated, or there have been transactions since the last time the wallet was used.

Either way, I would expect that the current balance showing now with the wallet file fully synchronized is correct.


I would also suggest that the OP should run an audit on all the displayed transactions and make sure they tally up with what they expect... hopefully it is just a case of a forgotten transaction, and not loss of funds due to the wallet being compromised.

Can you take a screenshot of the sync screen. I would like to check exactly where this "2 weeks" is quoted... that is to say, is it "2 weeks behind" or is the ETA showing 2 weeks?


Generally speaking tho, as others have mentioned... actual internet download speed is not usually the main determinant of sync speed. It is generally hardware related (disk speed, amount of RAM, Processing power etc)

+1 on this advice... it'll help provide confidence that your setup is working as intended.

I would also recommend trying the --listpass option that just generates a list of password candidates. This way you can quickly double check to see that it is actually constructing password candidates in the format you expect it to.

When you say "the position of unknown characters are not 100% known"... do you mean that some are known and some aren't? or that their positions are completely unknown?


Are these 2 special characters included in the 11 characters? or are they in addition to them?


In either case, I would tend to concur with ETFbitcoin that btcrecover is a very good option. It gives you quite a lot of flexibility in defining the "structure" of a password, and how to construct password candidates from wildcards etc.

Honestly not sure there is such a thing as a dictionary of "common patterns"... I had never really even considered it until I started digging into the keyboard walking while reading this thread. Although, given human nature, it would not surprise me in the least that someone has thought of things like this:
- Characters in a single keyboard row
- Characters in a single keyboard row, backwards
- Alternating characters from 2 rows
- Alternating characters from 2 rows, backwards
etc etc.

I'm just not sure anyone will have actually created/published these maps. Do let us know if you find anything!

Unfortunately, it doesn't look like the code supports having multiple backreferences in a row... Logically, something like this should work:

which should generate the 4 characters at the front... then copy them to the end in reverse order... for example:

Unfortunately, it seems that the tokens parser is prioritising the ";filename;" parsing... and treating ;9b%; as a filename for a keyboard walking map pattern and spits out an IOError


I'm not sure of a workaround for this, that doesn't involve a massive pre-generated token file that has the 4 characters matched with their reverse 4 characters etc.

You need to create a pattern.txt file that maps how the keyboard "walking" goes. In the example provided, they say that the typist only moves up-right, or down-right (note that this is not the only pattern that can be defined)... which results in a pattern.txt that looks like this:

Starting from "q" the only keys (up-right or down-right) on a standard qwerty keyboard are "2" or "a" (red arrows below)... from "a" you have "w" or "z" (blue arrows)... from "z" you only have "s" (orange arrow) etc.

Hopefully this pic explains that a little more clearly:



so given:

What it is doing is selecting "a single ASCII lowercase letter"... the %a... this is then followed by selecting an additional 3-5 characters ( the %3,5)... which are defined by following the instructions in ";pattern.txt;"

The "b" at the end is the backreference, which instructs the program to place the characters derived from pattern.txt into the (%3,5) part.

So, if the program starts with "a" as the first "%a" character, it would then look in the pattern.txt and find that "a" is followed by "w" or "z"... so:

"w" is followed by "3" or "s"... "z" is followed by "s"... so that leads to:

"3" can be followed by "e"... "s" can be followed by "e" or "x":

And that is how it will start to build up the list of possible passwords. Hopefully that makes things a little bit clearer as to how the keyboard walking works.

---

In any case, you need to create the pattern.txt file to match the pattern that you think you may have used when creating your password.

Well... firstly, thanks for posting all the updates, so we could see what you got up to.

It seems you have managed to get everything up and running, so a good result... but to answer this specific question from earlier:
No, you don't necessarily need to run Bitcoin Core every time before you start Armory, it is possible to configure Armory to launch Bitcoin Core in the background... I have just found that letting Armory run Bitcoin Core in the background (it launches bitcoind) has the potential to cause issues because you can't "see" what Bitcoin Core is actually doing and whether it is actually running properly unless you're familiar with bitcoind/bitcoin-cli and the various commands required to see what it is doing.


Personally, I have Bitcoin Core (the actual GUI application, not bitcoind) running pretty much 24/7 anyway... when I want to use Armory, I just start it up and it uses the already running Bitcoin Core instance without problem. In the several years I have been using Armory, I have just always found it to be much more reliable to run Bitcoin Core manually, let it fully sync up, then launch Armory.

Nice try Mr. Hacker/IRS/FBI/CIA/NSA/<insert bad person trying to steal my precious!>!!?!

---

Seriously tho, I have a Ledger Nano S, Trezor ONE and a BitHD Razor (that I got sent as a review unit):


NOTES:
- Trezor ONE and Nano S both purchased around the same time (mid 2017).
- I vaguely remember that I ordered the Nano S first, but there were manufacturing/shipping delays at the time, so I ordered the Trezor ONE because I really wanted a HW wallet. They were then delivered only 2 days apart! 
- The Trezor ONE looks filthy because it still has the factory fitted plastic protective film on it (what y'all seem to be calling a "foil").
- I once "bricked" my Nano S back in the old days of the firmware and bootloader updates... frantic plugging/unplugging while holding various buttons eventually got it back (after a very panicky 20-30mins) to the point I could re-flash the firmware I was attempting to load and it has worked pretty much flawlessly since.
- My Trezor and Nano S have been on international holidays
- I don't really use the BitHD Razor due to the somewhat annoying custom cable adapter (it's too thin for a standard USB port) and having to use Bitpie wallet app.


If I were forced to choose a new hardware wallet today... I'd probably pick the coldcard. Not sure why... it just looks like it would fit all my requirements.

Or... if you're in a super hurry, it looks like it has also been ported to Metamask: https://github.com/MetaMask/metamask-extension/pull/12935

You'd just have to compile and run the "RC"


Or hope that they release Metamask version 10.8.0 soon™

People say a lot of things on reddit... yes, the device is space limited, this is not new information... but the largest app is Cardano (ADA) at 86kb... so, if you had that installed, you'd be quite limited as to what else you could put on, as you'd only have 52kb of space left... certainly not enough for BTC, but you could put ETH on at (48kb) or any number of the other apps that are 52kb or less.

It really comes down to what apps you're attempting to load as to "how many" (as it has for about the last 4 years)... in any case, you can freely uninstall and reinstall as you like... yes, it's annoying, no it's not the end of the world.

---

I think by the time I realised there was a firmware update and/or it rolled out to my region/account... I had missed the whole Fido U2F issues... it was already there in the list of apps when I went to do my update, as I remember being confused as to why people were complaining that it was missing.

The suggested fees might be OK, but they need to update their whatever API they were using for the price of BTC... it is just a tad bit out of date:



vs. coinmarketcap:

Like 99,999 times out of 100,000... simply installing the new version of Bitcoin Core over the top of the previous version will work without causing any issues. But it can depend on your setup and which Operating System you are using... you haven't specified, so it's difficult to be 100% sure. I know with my Windows 10 setup, I just shutdown Bitcoin Core, then run the new installer.exe and then start Bitcoin Core and it all "just works" to update the node without affecting anything.


If you're at all worried, then I would definitely recommend using the "File -> Backup wallet" option... or manually backing up the wallet.dat as recommended by the users above.

That can be a bit hit and miss... sometimes it will recover "gracefully" and simply continue from the "missing" file, other times it will just freak out and start downloading and syncing from the genesis block again. I've never quite been able to figure out exactly why, and haven't tried it recently so it may not currently be an issue... but I've certainly had it do both in the past.

You're about 10 years too late... according to this story, the claim form was here: https://www.mybitcoin.com/claim.php but that no longer exists.

And if you never had a mybitcoin.com account... and it was just used by someone who stole your money, then you wouldn't be eligible to any of it anyway.

I still don't quite get how you don't understand (or simply refuse to accept) that you were conned out of $56 and it's gone.


Pretty much yes... it would have been spent on "hookers and blackjack"... like most money that gets stolen and subsequently spent, it's unrecoverable... like your $56.

Armory isn't 100k blocks behind... your bitcoind database is.

ArmoryDB reads your bitcoin block files directly... and these lines of debug from ArmoryDB show that ArmoryDB is only able to see 626760 blocks in your bitcoin block files.


If you're not running Bitcoin Core GUI, you might want to find the bitcoin "debug.log" file... and check in that to make sure that bitcoind is actually syncing properly... you should see "update tip" messages in debug.log if it is.... like this:

Otherwise, it might also show errors as to why it isn't syncing properly.

So creating a 2-of-3 Multisig using "Seed" + hardware device + hardware device == incorrect wallet... but 2-of-3 Multisig using "seed" + "master public key" + "master public key" does work? If so, then it very much sounds like a "derivation" path and/or "Script Type" issue.

Having said that, it depends on how you try and set up the wallet as to what options Electrum will give you. If you put the "seed" in first, it should automatically detect if it is a "legacy" seed, or if it is a native segwit seed etc... and only prompt for derivation path:

"Legacy" seed used:



"Native Segwit" seed used:



If however, you try and use the "hardware key" first... it will give you the full "script type" and "derivation path" prompt:



So, when you are creating the wallet... what is the "seed type" that shows when you enter it?