Hach ja, hat ja nicht viel gefehlt zum Club 3k, katsching und deutlich gerissen. Besten Dank an den wohlwollenden Verteiler!

Das hättest du wohl gerne... Kindergarten, Schweinebraten!

On OPs VPS Bitcoin Core seems to run fine with 4GiB RAM. I never had issues running Bitcoin Core on my Raspis which have 8GiB RAM, but more is better, especially to speed up initial blockchain download for which you want to raise dbcache value preferably to around 12 GiB. But if you're patient it works fine with less. Not to mention if you want to run an Electrum server on the same device.

For a non-pruned, full archival node you need more space. Here's what one of my nodes consume as of right now (I've txindex=1 and the blockfilter stuff enabled):

I don't know if you deliberately fuse the hardware wallet part with the necessarily online software wallet part (which as I already wrote is usually watch-only).

With closed-source firmware we don't and can't know what the firmware does and what functionality it provides. As I'm not particularly interested in the Ledger crap, I don't know if and how open-source Ledger Live is. My only perception is that this is crappy software with occasional sync issues and it tracks the shit of its users. Due to Ledger Recovery service subscription, we know Ledger Live contains code that can interact with Ledger hardware capable of this Recovery subscription to exfiltrate encrypted wallet seed shards and transmit them via the internet. No question, I consider this very bad.

Even an air-gapped hardware wallet needs an online software wallet part to transact and broadcast a transaction. Is such an air-gapped hardware wallet by your logic not offline?

Anyway, closed-source Ledger crap is evil and something to avoid based on what this company and its executive morons try to sell as their hottest shit.

I have no issue when a USB connected hardware wallet is not "offline" for you. For me it's offline when I can verify that the firmware code doesn't contain any code for networking and USB related code can't access or transmit main wallet secrets. Same goes for the software wallet part that talks to the hardware wallet. If there's no code to connect wallet secrets with the internet, I consider this as some sort of barrier like an air-gap. No important secrets can be exfiltrated from the hardware wallet. Offline enough for me.

To update firmware you're not always forced to an online scenario. Some wallets allow the download of firmware files, verification by cryptographic hashes and/or signatures and applying the verified firmware on an offline system.

I also observe annoyingly often that the site https://bitcoinexplorer.org/ is either very unresponsive or down like it is now. I just checked myself and the cloudflare.com error page indicates the site is unresponsive for whatever reasons.

But I have my own local instance of bitcoinexplorer, so I don't mind if the real site is down. I just wonder why it's so sloppy maintained.

1. Why did you full quote my post? This is in most cases totally unnecessary.

2. There are enough threads about Ledger crap, it shouldn't be too hard for you to search and find them. You could start with a search for "Ledger" in topic's title. It's also a good exercise for a newbie to learn to search the forum, because a lot of things already have been posted, it's just the matter to search and find them.

3. So, no, I won't explain it here just because you're likely too lazy to search on your own for answers. You can use the forum's search (as newbie you're a bit rate-limited there) or you can search at https://ninjastic.space/search where you're not rate-limited and can easily discard search hits or whole topics that don't fit your needs.

Easy hits if you prefer to be spoon-fed  
Avoid Ledger and their Complies Sanction Crap!
Why I wouldn't buy Ledger Nano S ever again?
Ledger Recovery - Send your (encrypted) recovery phrase to 3rd parties entities

Hardware wallets are usually signing devices and commonly don't work totally on their own. There's commonly a watch-only online software part which "talks" to the hardware wallet (hands over a transaction to be signed; takes the signed transaction from the hardware wallet to broadcast it). There should be no code in both parts to allow access to private keys at the barrier of the online computer/device and the hardware wallet.

When the firmware of the hardware wallet is open-source and preferably allows reproducible builds, you can check that there's usually no network stack, code or hardware components (smart chips) that can talk to the internet. Therefore I consider such signing devices as offline and basically cold storage,  YMMV, limited to devices that have no Bluetooth stack (often too complex and rarely bug-free) and where the private keys or similar main secrets of the wallet are not reachable from the connected computer/device (the latter e.g. doesn't really apply anymore to modern Ledger crap that allows their infamous Recovery service subscription).

Non air-gapped signing devices use mostly USB as hardware connection layer. The firmware of the signing device has to limit clearly what data can travel and what else is allowed to happen via  such a USB connection.

The internet can't talk directly to the signing device and vice-versa.

Malware on an online computer with the watch-only wallet can manipulate and compromise the software wallet part. A compromised software wallet can submit manipulated transactions to be signed by the signing device. That's why the signing device needs an independent own display where the user can easily check ALL transaction details before they allow the transaction to be signed. That's also why everybody has always to verify ALL transaction details, no exception whatsoever, unless they want to be reckless.

Vom Aufwand her ist es für mich klar als Liebhaberei und Hobby eingestuft, da mache ich mir keine Illusionen. Trotzdem nett, die Coins einsammeln zu können.

Und auf der Suche nach interessanten Themen schaue ich auch ab zu an in Bereiche, die ich eher seltener frequentiere. Außerdem kann man immer mal wieder etwas Neues dazu lernen.

Add unnecessary pyramid quoting and other BS nonsense noise to that...

A supermarket like Rewe is an odd choice because supermarkets rarely have expensive goods but I like the idea and why not have "cold storage" near frozen goods.  

I would love to have more brands of hardware wallets in (electronics and household) markets like Mediamarkt and Saturn. I wouldn't mind if they place them by the fridges section. I want to buy such stuff with fiat money and without leaving digital traces of my purchase (despite survaillance camera footage and obscuring my face details isn't exactly rocket science; turn off of mobile phone on your way to and into the store if you extra paranoid cautious).

I wasn't speaking of custom derivation paths, but if someone uses those, they should know what they're doing and of course documentation is then mandatory. It doesn't really hurt to simply write down what your current wallet uses. It may also spark a user's interest to learn about and understand what a derivation path means.

It helps at later restore, especially when you have to use a different wallet for the restore, for whatever reasons.


I've seen quite some mobile wallets that don't really force you to write down your mnemonic recovery words. They tell you, you should make a backup but often don't force you to do it. The latter is a totally wrong design by default in my opinion, because there will be users who don't understand the importance of an analog backup yet and will skip it. Those will cry later when their mobile phone gets lost, broken or unusable for other reasons. Those noobs will loose coins.


I don't understand that part, but I don't have to.

You're twisting the message in a way, that I hardly find useful. If mnemonic recovery words are stored in a backup that potentially can be compromised (I know you can't exclude this completely), then you have a weak and less secure backup.

But I was talking in a more broader scope of documentation of your backups. If you have e.g. multiple different locations why not document this and keep this documentation somehow available to you. Human memory is fragile, people forget details after days, weeks, months or years. That's totally normal and happens.

Something bad can happen to you. You may recover, you may not. Are your assets still retrievable for you after a severe memory loss or for your heirs if you can't anymore?


I'd recommend to thoroughly assess how your assets could be lost and at least apply countermeasures for the most relevant loss factors which have a reasonably high probability. You can countermeasure anything...

So, additionally related to your quoted part: if someone can find my mnemonic recovery words (you say "your seed"), I shouldn't have them stored unprotected. A complex additional mnemonic passphrase makes the recovery words useless to an unintended finder. A sacrificial wallet on the non-protected seed could serve as a canary for compromise.

Apparently you shouldn't keep mnemonic recovery words and protective additional mnemonic passphrase in the same spot. Having both in the "documentation" is a single-point-of-failure problem. I think this is not the right place to elaborate deeper.

Ich hatte die letzten Wochen auch eher weniger Zeit zum Schreiben im Forum und habe dadurch natürlich auch Coins aus meiner Signatur-Kampagne liegen gelassen. Aber ich möchte eher nicht nur deswegen schreiben, um das Maximum rauszuholen, denn die Gefahr ist dabei groß, nur mittelmäßige oder gar spammige Beiträge abzuliefern und das möchte ich möglichst vermeiden.

Manchmal finde ich, zumindest temporär, kaum Themen und Beiträge, wo ich etwas nützliches zu schreiben könnte. Oder hab' gerade keine Lust und andere spannendere Dinge im Leben...

It's on average 576 vMB of transaction space weight units. Excuse if I'm picky about details. The coinbase transaction is mandatory and usually not large. A miner (rather mining pools who assemble the coinbase transaction) hurts itself if they waste block space with a larger than necessary coinbase tx.


When currently the low volume of >= 1sat/vB transactions don't fill all available block space, it seems economical to me to add sub 1sat/vB transactions for an additional profit. I wonder why not all pools do it, from a profit perspective.

The opportunity to use lower transactions fees for low-priority transactions might hurt miners a little bit, but in my opinion it only works because we currently have a low volume of non-spam transactions. I remember the times when the incriptions blockchain spam was the hottest shit and apparently profitable enough to drive transaction fees into high altitude orbits.

We still have the spam but it doesn't seem to drive the fee market anymore that strongly anymore.

Can you try to avoid such value-less posts (violates rule #1)? You basically use a lot of words to say just a "thank you" which doesn't really add any useful content to this thread.


The basically only reason why I in rare cases still use blockchair.com are the nifty filters you can apply if you search for certain transactions, something I miss on most other block exploreres. Otherwise the mobile phone centric display of data of blockchair sucks for me, not to mention what LoyceV complains about.

I would rate blockchair.com at most 5 or even lower. I don't know either how to put the only useful feature, the filters and download ability of filtered data, into a number. Without the filters I would rate it at not more than 4.


But I understand that rating is subjective to some point. E.g. I would rate walletexplorer.com higher than it is in the table because it has different valued features for me. I like the address aggregation feature (when I do some quick'n'dirty forensics) and can ignore that it lags behind current chain tip.

I've been thinking a bit more about this situation. From my limited perspective I still consider it a serious disadvantage to not avoid such an own fork.

If a pool happens to produce such a fork, now how does the pool decide on which branch they should concentrate their hash power?

I know that mining is a random process, the more lottery tickets (aka blockheader hashes) you draw, the more likely it is to find one that matches the current difficulty threshold for a valid block. In such a fork situation the pool would have to decide and possibly gamble on which branch of the fork they continue to build upon. Can't see how it could be beneficial to distribute hash power on both branches.

Then I was thinking: do some or all serious pools sample what kind of Stratum work items other pools distribute? I think this is what https://mempool.space/stratum does, while not being a mining pool but rather a very nice block explorer. Wouldn't a pool be able to sample by this, what other public pools are working on?

A fork situation is a gamble in any case, regardless if the fork tips have been produced by the same or different mining pools. So, having a glimpse on which fork branch other pools crunch their new template block seems beneficial and smart to me.

What I'm mostly missing here when emphasis is on analog offline backups (be it on archive grade paper or stamped into metal) is to actually verify that you can recreate your wallet from your backup of your mnemonic recovery words and possibly an optional additional mnemonic passphrase.

I highly recommend to backup some context details like when was the wallet created, for what purpose, which wallet software/hardware was used, derivation path, address type and whatever else would be beneficial to safely restore your wallet.

Practice the restore process, verify the outcome! Too many people think: I have a backup, I'm safe. Unless you've actually verified it, I'd say: you don't have a working backup at all.

Multiple redundant backups are highly recommended, too, in my opinion. Make sure that a compromise of one of your backup locations doesn't yield a total loss (there are multiple ways to achieve this, e.g. protect the mnemonic recovery words with an additional mnemonic passphrase, of course don't store them together at one spot; encryption with e.g. Shamir Secret Shares; multi-sig setups where you distribute the individual signers over different locations; it really depends on what you want to achieve).

Don't over-complicate it, you're likely to shoot yourself in your foot than make your backup strategy more safe.

Document everything related to your backups. You will thank me years later.  

Are you too lazy to read the pages of this thread?

First of all, most crypto wallets and particularly Bitcoin wallets don't store any coins. A confusing answer to your question therefore could be: none! But that answer is unfair to a beginner. (Wallets only store the private keys that allow you to sign transactions to move bitcoins. Bitcoins only "live" as unspent transaction outputs on the Bitcoin blockchain.)

I would recommend "lite wallets" like Electrum, Sparrow, Bluewallet. Try to stick to open-source wallets, because only there at least someone has a chance to audit the source code and assess how the wallet operates.

Beware that hot (online) software wallets are vulnerable to malware on poorly secured and operated computers. To increase the security for a software wallet's private keys, you could use a hot (online) watch-only wallet to prepare transactions which are then signed on an offline cold wallet that holds the private keys (this isn't beginner stuff, though).

If you plan to have coins worth low 4-digit dollars I would early recommend to invest in a decent hardware wallet (stay away from the Ledger crap; these pieces of hardware and software shit aren't worth your hard earned money).

I use a BitBox02 and a PiTrezor (the latter more for experiments) and would also buy a Trezor Safe 5 without hesitation. Stuff from Foundation Devices, Seedsigner, Krux wallet and Blockstream Jade are also cool.

Interesting, indeed, especially the part I highlighted! My question to someone (or one of the devs) fluent enough with Electrum's code is: does the command-line option  --server server:port:t|s  pin the history server and make any other additional server which Electrum chooses automatically the ones that are only used for new block header announcements and which according to above's quotation don't get to know an Electrum wallet's addresses?

If this were the case, I could and would use my personal Electrum server as my history server (I do that already but I use the option --oneserver which limits Electrum to use solely the specified server). This wouldn't leak my wallet's addresses to some unknown Electrum server.

Have you ever tried Gnuplot? From own experience, it handles large datasets to produce a graph quite nicely. I didn't look at the original data and therefore can't say what amount of "data massage" is needed to get the correct data to plot.

Zentrierte Zahlenspalten sind auch nicht so der Hit, da wäre ich jetzt auch kein Befürworter von. Aber für korrekte rechtsbündige Darstellung, mehr so a la Zentrierung am Dezimalpunkt muss man schon ein bisschen in die Trickkiste greifen. Ich glaube, dazu möchte ich dich auch nicht nötigen wollen. Jetzt, wo ich's in meiner Übungstabelle mal ausprobiert habe, finde ich das Ergebnis auch nur so lala.

Mein Genöhle zu Zahlenspalten kannst du einfach ignorieren, hab' nur mal laut gedacht.

Name	|	Zahl
	|
Na	|	1,0
Nam	|	2,3
Name	|	45,6
Namee	|	789,0

Some sort of decentralization (redundancy and/or regional) was also something I had in mind. Sounds plausible to me.


I know that block 912721 was in both UpdateTip events the same, clearly visible by the same hash. I was just surprised why it would need a second UpdateTip when this block 912721 wasn't realy affected by the fork of block 912722. It was block 912723 which decided what branch of the former tip of 912722 should be followed as the "true" blockchain (most accumulated hash work).


Thanks for the more in-depth explanations. I had only vague and more incomplete thoughts what probably was going on. With the immense hash power of those pools, many many devices are crunching hashes, timely coordination becomes a real problem and the competitive mining space doesn't make it easier.

I assume it's not trivial to manage such a large amount of mining gear and participating miners. As you say, I can follow that occasional race conditions happen. Trying to cope and avoid them completely likely has more or other disadvantages than letting them happen.


I didn't expect that my node see most or a lot of the forks. It totally depends on my node's peers and I didn't specifically tune it to be any optimized for such a task. RPC getchaintips gives me a list of branch forks where block 723102 is the first in my list and remarkable entries are the invalid blocks 783426, 784121 and 809478.