Yes... Bitcoin uses Merkle Trees... but not for storing UTXOs (at least as far as Bitcoin Core is concerned). As noted above, it uses them for mapping transactions in a block... thus arriving at the Merkle Root stored in the Block header. But it doesn't use a Merkle Tree for storing/holding UTXOs... which is what the original point you were trying to make was:

So, that just isn't correct with regards to a full node like Bitcoin Core... it has the UTXO set stored in the chain state db... this is not a Merkle Tree.


So, it seems that perhaps there is some confusion to what you're actually referring to... when you asked:

Any UTXO, regardless of whether or not it is associated with a "burn" address, will continue to live in the chainstate db of a Bitcoin Core full node, until such time that it is successfully spent in a transaction.


Whether or not a UTXO exists in any "Merkle Tree" would be wholly dependent on the exact implementation being used by whatever node software you happen to be referencing...

That is indeed a puzzle... I am honestly all out of ideas for why this seems to be happening to you. I don't imagine you're the only Bitcoin Core user receiving payouts from Nicehash, so I'm surprised there are not more reports of this issue.

Hopefully the Bitcoin Core devs are able to investigate, identify the issue and fix it in a future version. For now, unless you absolutely require features in v0.21.1, I can only suggest running v0.20.1 until a new version is released and see if that fixes it.

Basically they are a low power black and white screen like the ones used by Kindle and Kobo and other eBook readers etc... sometimes also referred to as e-Ink.

I suspect it was chosen due to the slim form factor of the device.

Why do you need to manually run Bitcoin Core, wait for it to sync, then shut it down... only to have it start up again automatically again when you launch Armory?

That seems like a bit of a convoluted method to get it up and running... why not just start Armory and just let it sync bitcoind in the background if that is how you're going to run it?

Honestly, aesthetics wise, it looks a bit like the BitHD-Razor: https://bithd.com/BITHD-Razor.html

Although it seems like it has an "ePaper" display instead of OLED like the Razor. And is super thin at just "0.8mm"... Not sure I'd be keen on the proprietary charging dock... and this just frightens me:





If it wasn't quite so expensive, it would probably be a neat little "portable" wallet you could take with you on the go, so you could have your mobile "hot" wallet with extra security... But then the economics of it don't really make sense

You're missing the simple fact that Hardware Wallets, while some of them might have the appearance of one, are not just a plain USB stick. They have custom hardware/software/firmware that prevents external devices from accessing the data stored within in.

Essentially they provide a limited "API" that external devices/software have to use to communicate with the device, such that the sensitive information stored within it (ie. seed/private keys) cannot be extracted using that API... at least, in theory

That video appears to be talking about a proposal for stateless nodes... as far as I'm aware, they're not actually 'fully' implemented outside of the research project nor are they in common use.

In fact, the video even describes how Bitcoin is currently working... with the "chainstate" that is the "set of UTXOs" that is stored by a Full Node... and how "lite nodes" work.

Sure, all the transactions are available on the public blockchain... but can you tell which ones are mine?

As it currently stands, even with an SPV client like Electrum, I can go someway to maintaining my privacy because I can connect my Electrum client to my Electrum Server that is connected to my Bitcoin Core node. Thus, I can be 100% sure that none of the Electrum client addresses are being "leaked"... because I know for a fact that the Electrum server is not logging them... and they're not being linked to any IP addresses or user accounts


Right... you're just proving my point. You're not participating in Bitcoin cryptocurrency for any sort of reason other than "to get paid"... you obviously don't care about your privacy. Your over-riding motivation is "making money".

And that's fine... but it doesn't change the fact that other people do care about their privacy and are indeed willing to run nodes as the trade off is worth it to them. I'm not sure why that upsets you so much? As you've stated, there are plenty of other options available if you want to be paid to run a node. ¯\_(ツ)_/¯

For one... a vast portion of the "community at large" seem happy to use Exchange and web wallets etc due to either laziness and/or ignorance They simply want to "cash in" on the huge gains they have seen over the last few years and want to participate using the "path of least resistence".

The tools (wallets and information) are freely available and there if people want to use them to maintain their "self sovereignty"... but as they saying goes... "you can lead a horse to water, but you can't make it drink".


And I'm not quite sure how you equate peoples laziness and/or ignorance as "a coordinated attack"??!?

How much do you value your privacy and the ability to operate on the Bitcoin network without leaking your information to "random" servers/third parties?

If the "cost" of running a node, which is actually pretty negligible in the grand scheme of things, is too much for you, then I'd say that you don't value your privacy very much... otherwise you would simply write that minimal cost off as the cost of improving your privacy (along with some of the other benefits of running a full node)

Because people are blindly following instructions without actually understanding exactly what it is they are doing... or why they are doing it.

This often leads to people copy/pasting commands verbatim, ignoring "hints" like YOUR_PASSPHRASE_GOES_HERE etc... or leaving default values in web forms etc.

Because you want to do this offline, it might be difficult to identify exactly which addresses you need to dump the private keys for... so you might need to use the dumpwallet command to dump all the private keys from your wallet.dat instead of using dumpprivkey:

The dump_filename can include the full path if you want.

NOTE: if you're using Windows 10... it can sometimes be a bit "fussy" about letting you output the dump file onto C: drive due to various folder permissions etc. So, in that instance, make sure you either create a temp folder that you can write permissions to, or that you specify the full path to a folder that you have write permissions for.

Several options:

- 2x individual private keys (paper wallets) generated using dice/coin flips etc
or
- 2 wallets generated from 1 seed phrase and 2x BIP39 passphrases (addresses from each wallet cannot be linked to each other unless you specifically include UTXOs from different wallets in one transaction)
or
- 2 wallets generated from 2 different seed phrases (optionally protected with BIP39 passphrases).
or
- 1 hardware wallet device and use 2 different "Accounts" (in Ledger Live/Trezor Suite etc. this uses different derivation paths for each "Account")
or
- 1 hardware wallet device and use 2 different passphrases to generate 2 different wallets.


You will need to decide which option satisfies your requirements for "easy to manage" and "minimum number of seeds/keys/phrases" etc... and as long as you're careful with your coin control etc and don't spend coins from both stacks in the same transaction, then there really isn't anyway to "link" the stacks.

Note that if you just tried to use 2 different addresses generated from the same seed/passphrase/account combination and relied solely on "coin control" to prevent linking the addresses... in the situation where your XPUB "leaked", it would be possible to identify that the 2 addresses were indeed part of the same wallet, even if they had never been used in the same transaction.

Sorry, just to clarify... you're saying that line 109 in that debug output is the transaction arriving from an exchange... correct? And that your Bitcoin Core kept running just fine after receiving that transaction?

What's interesting is that going back and looking at your previous debug... the AddToWallet output is actually quite a long way from the debug that indicates that Bitcoin Core is shutting down, it seems to be syncing a lot of blocks after it sees that transaction.

Indeed the 2nd lot of debug here: https://pastebin.com/sWZwFZV0 near the very end, it doesn't even seem to be receiving any new wallet transaction at all, it is just syncing blocks and then shuts down (line 920 onwards)

Armory won't be online if you have closed Bitcoin Core.

Bitcoin Core (or bitcoind) needs to be running for Armory to be "online". It can still scan the block files and transaction if Bitcoin Core is not running, but it won't be "online" as there is no local node to connect to... and it won't get any new block/transaction information as your node is not running and therefore can't receive them

When you initially ran pywallet to get dump the keys out... did you use the otherversion option to specify that the wallet was a DOGEcoin wallet? If not, it will have read the file as a Bitcoin wallet and will have output the private keys in Bitcoin format.

I suspect you have not used otherversion as you're saying the addresses start with a "1"... whereas Dogecoin addresses start with a "D" and the "WIF" format private keys for a dogecoin wallet should start with a "6" (uncompressed) or "Q" (compressed)

I believe that the otherversion value for Dogecoin is 30... so your command should look something like:

When you do that, you should see the addresses output start with a "D"... and the "sec" values should start with a "6" or "Q"... they should then import into Dogecoin wallet.

The "sec" records should start with a "K", an "L" or a "5"... these are "WIF" formatted private keys... you should be able to import those into a wallet of your choice (that allows importing of private keys).

What wallet are you attempting to import the keys into?

Is your Bitcoin Core fully synced? If you look in the "Window -> Information" menu... what is the "current block height" value?

If that value is not at least 685072, then your Bitcoin Core is not synced. Also, is your Bitcoin Core without pruning enabled? How much free disk space do you have on your PC?

Note that without Bitcoin Core being fully synced without pruning enabled, then Armory will not be able to work properly.


in any case, for us to really understand exactly what is going wrong with your setup, you'll need to post your armory log files... to do this, locate the armorylog.txt (and dbLog.txt) file in your Armory data directory... copy/paste the contents to https://pastebin.com/ then click "Create new paste" and then copy/paste the unique URL that it generates into a message here.

Assuming that you are unable to sign a message from the address in the profile... and that you didn't make any deposits to freebitco.in... and that you have explained this to their support and they are unwilling to provide any other assistance... then it would seem that, unfortunately, you're out of luck.

Unfortunately, this is one of the huge problems with custodial services... when things go sideways, it can be awfully difficult to recover access.

I really wish that some of these services would make their "account backup & recovery" options more obvious from the start, so that users could take the necessary precautions before they lose access to their accounts.

Telling a user 6-12 months later "sign a message from a staked btc address" isn't helpful... they should make users stake an address to start with and verify that address to show that their account is "backed up" or something.


I hope you didn't lose too much

But we're supposed to "trust" the word of an internet rando who has provided no proof of their claims or cited any sources to backup the quite serious allegations they're making regarding the integrity of software wallets, hardware wallets and exchanges??!?

#irony