For fear of being "dogpiled" (excuse the pun)... why invest so much effort into developing a wallet for what is really just another "pump and dump"?

Sure the price spiked to an ATH... and now it is slowly decaying back down to it's "regular" levels.

You seem to be misunderstanding what "block 269" is...


It isn't stopping on block# 269... it is stopping on the block file that Bitcoin Core is storing on disk... as you can see, that file actually has 133 blocks stored in it... from Block# 356495 through to Block# 356719



And zooming in on your very small screenshot, it's possible to see that Bitcoin Core is indeed getting a lot of "updateTip", so is in fact syncing "OK" (at least, up until it gets killed! )

As the others have said, the limited RAM on the Pi is likely your issue... especially with the dbcache setting you have used. dbcache should never really be more than half of your total system RAM (as a maximum!)... and you should only really increase it about the default value when you have a fairly substantial amount of system RAM.

Remove the dbcache setting... and you'll find your Pi should happily (but somewhat slowly) sync without being killed

Given the OPs location and comments, it is possibly related to the use of non-Latin characters (ie. Chinese) in the passphrase... and the way that the system is parsing it... TBH, I'm not surprised it might be something as simple as using ' instead of "...

I've had a bugger of a time with Bitcoin Core parsing JSON because of similar ' vs " issues

Theoretically, yes... it can be brute-forced... but that comes with some big caveats...

- You need a good idea of the password length
- You need a good idea of the "structure" of the password (ie. word+word+2digits, or 6 characters+4 digits etc)
- You need to know what characters were used in the password (ie. lowercase, UPPERCASE, numb3r5, Speci@! Symbols etc)

If you know these things... and the password isn't too long (like < 12 chars)... then there is a very good chance it could be bruteforced. There are all manner of scripts available to achieve this... or you could try: https://www.walletrecoveryservices.com/

They have a good reputation and have helped a number of users over the years recovery their wallet passwords etc.

Why do companies do things like this? The only explanation I can think of is "vendor lock in"... as there is simply no good reason for:

1. Using a custom derivation path
2. Not telling anyone what that custom derivation path is

That 12 word seed is effectively useless as a recovery tool without Abra... and what happens when they cease to exist?

Why did you "restore" the node?

All you had to do was do a rescanblockchain command on the console... or start with -rescan commandline argument... it would have found the "original" transaction and you'd still be fully synced. You wouldn't need to wait for anything (except the rescan command to complete) unless you are using a "pruned" node.


Sync speed is a function of:

- Storage type (SDD > HDD)
- CPU speed
- RAM (more == better, if you increase dbcache value)
- Internet Bandwidth

If any of these is "sub-optimal"... it'll slow things down

Not technically a "custodial" wallet tho... it's a somewhat complicated multisig with some "timelock" stuff thrown in for good measure...

The real issue is that they don't really place enough emphasis on the wallet recovery procedure and the information you absolutely must retain etc... how many users would realise that you need to make permanent records of the other parties XPUB for wallet recover?

Added to this, it is a rather technical process to actually recover the wallet should you need to.

Granted the "security" that the wallet offers is quite good... possibly too good as it would appear in this case

Oh wow... how did I not even notice that? LOL You're quite right... it would indeed be correct.

iq_armando necro'd this thread so that it showed up on the "first page" as having a recent reply (and subsequently deleted their post)... and I didn't even check the OP post date... #whoops!      

Time to let this thread go back to "sleep"

I'm kinda tempted to say "If it ain't broke, don't fix it"... If everything is currently "fine and smooth"... then you might be better off just leaving it "as is"... there haven't been any "breaking changes" to Bitcoin Core... so 0.18 will quite happily continue to work with the network (as things currently stand).


You'd need to read the release notes of the versions after 0.18.0 up to 0.21.0 and see what changes have been made and what vulnerabilities have been addressed and assess whether or not they offer any benefit to you.

There have been a number of changes and additions... but that doesn't necessarily mean "better" for your particular use case.

This is no one "perfect" wallet... everyone's use case is different... for some people, hardware wallets are the ideal solution as the afford a good combination of security and convenience (ie. being able to transact "easily" while maintaining high levels of security)... for some people, paper wallets (securely generated offline) are the way to go if they just want to HODL and aren't transacting often... air-gapped setups are great for those who value security above all else and can live with the "hassle" of setting up and maintaining the system and aren't bothered about convenience etc... and for "some", a web wallet is probably the best tool (ie. small amounts, no personal hardware/need to use public computers etc).

Then we get to you and your theoretical $500... given the cost of a hardware wallet (or a 2nd pc for air-gapped setup)... that is going to cut into your holdings by a fair amount... in this situation, a software wallet like Electrum, that has been downloaded, verified and setup properly on a PC that isn't used for "dodgy" purposes (torrents/free porn/cracked software etc) is likely to work perfectly fine... as long as you pay attention to what you're doing.

However, you must then balance what that $500 means to you... What would the loss of that $500 mean to you? is that like a weeks wages? a months wages? your life savings? depending on your answer to that question, you can begin to assess what level of security you need to protect that asset.

A couple of things to check:

1. Are you using a [2fa] wallet? Does it show [2fa] in the title bar like this:


or does it say [standard]?:



2. Is your wallet configured to show BTC or mBTC? Goto "Tools -> Preferences -> General" and check the "Base Unit" setting:

Correct... by using the AppImage, you shouldn't need to worry about dependencies, as they are all included in the AppImage... that's the entire purpose of the AppImage... download (verify) and run!


Correct, running from sources is a bit more involved... as you may not necessarily have all the required dependencies... and getting them onto an "air gapped" machine can be a bit fiddly (and adds a possible attack vector to the air-gapped machine... ie. compromised libraries etc).


Seems like you have a fairly good handle on things... any standards compliant camera should suffice... you shouldn't need anything too special to make it work. Even a laptop camera would probably work "OK" but could possibly be a bit fiddly trying to scan QR codes on the "online" machine by holding up a laptop to the screen!

It's a "dust attack"... they've obviously identified some addresses with "high balance"... and dropped in a small dust amount hoping that they'll be able to trace/track the ones actively being used and possibly identify the owners through chain analysis etc.

refer: https://www.google.com/search?q=bitcoin+dust+attack

If this is "too harsh", then using a full node client like Bitcoin Core is not for you. You need to stop and ask yourself why you are wanting to use Bitcoin Core?

If you don't have the time/patience and resources to be able to sync the full blockchain, then Bitcoin Core (or any other full node client) is probably not the solution you need/want and you'd be far better off using an SPV (aka "light") client that "syncs" quickly and doesn't require as many resources.

Definitely not "new"... and it seemed to hold up fairly well in the torture test: https://jlopp.github.io/metal-bitcoin-storage-reviews/reviews/cryptosteel-capsule/

Heat and acid didn't seem to bother it much... and only a "slight" bend during the crush test. Interesting to note that the "information" inside is effectively in an unknown state (Schrödinger's Seed? ) due to the reviewers inability to open the capsule after it deformed during the crush test... still you'd think a hacksaw/angle grinder and a bit of time/patience should enable you to remove the cap and hopefully extract the contents.

Perhaps you would need to cut along the tube to extract the discs if they're really jammed in after the tube was deformed like that?


Also, they're cheaper on the cryptosteel store https://cryptosteel.com/product/cryptosteel-capsule-solo/?v=8e3eb2c69a18

How many transactions before the coins ended up in Binance?

Unless it was 1, you've no real clue as to whether or not it was the actual thieves who sent the coins into Binance. They may have sent it to a gambling site... who then paid it out to another completely different user... or they may have put it into a mixer etc.

What exactly did this entail? Did you upload a wallet file or did you backup a 12/24 word "recovery phrase" to your email? Also, what email provider were you using?

Shut everything down, delete armorylog.txt, dbLog.txt and then reboot the PC... then once it has resstarted. Give it another try. If you're still getting the hashtags in the file instead of proper output, then shut everything down again, delete the logs and then try starting Bitcoin Core manually, let it sync... then run ArmoryDB.exe manually from the command line...

It should be in: C:\program files (x86)\Armory\

Note, because you have Bitcoin datadir set to a custom path, you'll need to use the --satoshi-datadir argument:

See if you get any weird errors displayed on the terminal window... if not, check dbLog.txt again.

Is your wallet a "2FA" wallet? Does it say [2fa] in the title like this:


Or does it just say [standard]?

If it's [2fa], its probably reserving as much as possible to pre-pay for your TrustedCoin "credits" as 2FA Electrum wallets come with a service charge from TrustedCoin in addition to the normal Bitcoin Transaction fee... it is usually charged on the first send (and when you have 0 credits left), refer: https://api.trustedcoin.com/#/electrum-help

If it says [standard], it's possibly an issue with the default "fee calculation algorithm" in the desktop version... given that fees have increased dramatically again over the last 12 hours, it might have decided that you needed to be paying a HUGE fee and so there was nothing left to send so you could only send 0.

Given the current "bull run"... and the increased network traffic, fees have shot up again... currently you're looking at somewhere around 100 sats/byte to get into a block. If your transaction is paying less than this, it could take quite a while. Given you've been waiting a week, I'm guessing your fee rate was under 5 sats/byte...

As for "recovery"... you'll need the transaction to drop out of the mempool... the default time for this for the majority of nodes is 14 days.

For "acceleration", it depends on your fee rate, if it was actually above 10 sats/byte, you could try the ViaBTC accelerator for free (extremely limited and difficult to actually get into)... or you're looking at paying $$$$ to the commercial accelerators like BTC.com etc.

Otherwise, if RBF was enabled, you could try increasing the fee... but as the current fee levels are massive, that is likely to cost quite a bit.