All the nodes should have different peers, so the mempool contents will never be identical, so diagnosis normal.

However, maybe you've changed the minimum relay amount on some of them? Or, do some run 24/7, while others are shutdown for any length of time? Those factors will contribute to how full a given node's mempool is, and/or how full it can potentially be. Plus, the propagation logic is subtle, it certainly doesn't try to get every tx relayed to all peers ASAP.

well, there's not exactly zero interest in this, this thread proves there's some demand from users, and previous work from the bitcoin devs suggested an appetite for it.

if everyone from this thread changed their node configuration to relay < 1 sat/byte, and other node operators followed (mine's already set lower than default IIRC), I think mining nodes should eventually notice that as a market signal. The more the BTC exchange rate increases, and the more reward halvings that occur, the more incentive miners have to change their relay minimum setting.

Edit: I'm wrong above, 1sat/vbyte is actually the minimum, and it can't really be reduced without an update to the fee estimation logic

Macron's not a well-liked leader, so he's unlikely to last long anyhow. All French presidents have been badly regarded by the French people in recent years, at least since Sarkozy.

As for Macedonia and Albania... I'm surprised in a way, but no so much in another. Macedonia literally changed it's name to avoid Greek objections to EU accession, but anti-EU/NATO sentiment has been increasing in Macedonia anyway, so it appears it's all stick and no carrot for the Macedonia. No Christmas cards from Brussels, and straight to bed without dessert.

Albania? When were they ever likely to join the EU? That whole part of the world is incredibly corrupt in a very open, overt way. And Albania is supposedly the quintessential example of corrupt culture in that region. Yeah, I know the EU is corrupt too, but they actually make an effort to hide it in the EU.

/usr/bin/armory isn't working, presumably the shell in Mint or possibly the install locations are different (and maybe it doesn't come with python2?)

so, find Armory folder, find ArmoryQt.py, then do python2 ArmoryQt.py

this may or may not work, depending on what the problem is. But you will get an error that tells you what the problem is.

this is definitely a good thing if you're going to run the Pi with Lightning too, as there'll be more RAM/CPU for Lightning to use (you can have more channels and route more payments)

The drawback is if you have a problem you can't solve quickly using your command-line knowledge. If you've got experience with any command line, linux/bash or not, you'll be more comfortable. But you might want to keep the GUI around for a while so you can solve problems in a more familiar way (but truthfully, you've got way more control on the command line, if you're feeling confident just go ahead, people here can help if you get stuck)

You can compromise too, you should be able to change Raspian's boot script to not load the GUI on boot, then just take note of the command (probably the startx script in /etc/X11) that loads the GUI. Then you can make sure you know you're good on the command line, but have the option of going into the GUI still available.

Last thing: get tmux (apt-get install tmux). It's for opening multiple command line windows, splitting the windows into sections etc (tmux let's you do this in headless more when normally you'd be pressing Ctrl-Alt-F keys to get extra terminal windows, tmux is way more flexible that that way of doing it). Makes working on the command line way faster and more versatile. You can configure it to automatically open up a bunch of windows on boot showing logging for bitcoind, openvpn etc

ahhhh

sounds like you've thought this through, carry on

yep cooling helps

no

that would risk forking the chain, which also cuts the miner's revenue in half until the fork is resolved/decided (as the risk is high that one chain fork would be permanently orphaned and everything mined on it worthless). Then the miner is incentivized to choose which chain will win before that. The outcome could be a total mess for days or even weeks.

to put it another way; miners could've chosen your strategy long ago. A small minority did. But some large number, probably more than half, know the risks I outlined above and decided to take minimal such risks.

that's not very safe



take this ^^ advice



it was a no

the correct solution is to research ways to make the RPi 4 stable. In particular, the premium (4B+) boards might be overclocked too much, change the CPU clock speed (or the memory controller's clock speed) and/or the amount of voltage to either, and you might find the Pi stays up.


If you keep syncing the blockchain while the board keeps crashing, there's a good chance the data in the blockchain will suffer some corruption. There's not much point in starting that job until you've figured out how to keep the RPi up. A good way to do it is find out the command for memory testing, this basically gives the CPU and RAM a workout that never ends. Leave it running like that for multiple days, then try something different to stabilize the RPi when/if it crashes. Once it stays up for a week or 2 just doing 24/7 memtesting, you've probably cracked it.

you'll never get much in the way of definitive 2nd hand evidence in places with monetary/economic turmoil, because almost everyone who is using cryptocurrencies is doing so to skirt restrictions i.e. they're breaking the law. But just like people using cigarettes in prison for currency, there is simultaneously a code of silence (because nearly everyone participates) and a widespread knowledge that the unspeakable is the abiding culture.

rich people in Venezuela, Argentina, Turkey, Chile, China and other countries with capital controls (or simply with failing local currencies) are not all well connected enough to get money in and out of the country in the volumes they want to. But of course, they find a way, and we cannot reasonably expect them to present the evidence to the world, yet we can surmise that it is very likely exactly what's going on.

Maybe the rumor that people use Bitcoin to transact internationally when banks won't do it is just a smokescreen, just to send investigations in the wrong direction to hide the way people really do international money transfers? Or maybe that's a double bluff? When it comes to clandestine activity, all evidence is circumstantial, indirect or anecdotal, and possibly a strategic rumor to disguise the truth.

no

take a look at the code, does it read a peers.dat file into a data structure from the config directory? If yes, you could run a modern version of Bitcoin to collect some peer IP addresses (you'll need to find other peers with older versions too) into it's peer.dat, then copy that into the config dir for the bitcoin 0.1 executable. If not, you'll have to make the changes to the 0.1.3 source to either read a pre-populated peers.dat file, or implement the DNS seeder code into 0.1 source, and compile it successfully. The code to read the peers.dat file is gonna be easier, I would expect. It'll still get stuck when you sync the first block >500 KB, on account of that problem with unpatched BDB library

not sure about 0.1.3, but 0.1 connected to other peers over an irc server (which is a geeky chat platform), I suspect that the irc server Satoshi set up for doing this job isn't running any more


@gmaxwell recently said that Bitcoin 0.1 will connect to other bitcoin nodes and start syncing, but that waiting for it to catch up the whole thing takes months. He also mentioned that you need to change the BDB code to permit > 500KB blocks, as the original 4.8 version choked on > 500KB for some reason.

So it can supposedly be done, according to someone who's tried at least.

what about btcd? I think that's still keeping up, but I have no idea as to how well it supports the protocol.

---

But when it comes to full nodes, a monoculture works better. If the miners were all using alternative versions of Bitcoin full nodes, the chances that the network would fork because of differing bugs would be much higher.

This already happened back in 2013, even with the Bitcoin Core monoculture (although it didn't have that brand name back in 2013). The way blocks were stored on disk changed in version 0.8.0, and all the 0.8.0 nodes split themselves off into a complete separate fork of the Bitcoin blockchain for a few dozen blocks before everyone noticed. The 0.8.0 code had to be fixed to stop that happening, and everyone mining/running a node rolled back to 0.7.3 to stay on the main chain while the fix was being coded.

I know alot of people will be all "muh choice of client", but reality/logic is a bitch. You can choose: a different coin, which has the exact same problem. Try to popularize an alternative full-node for Litecoin or Monero, the people owning XMR and LTC will tell you the same thing; "please don't, you'll destabilize the network"

stability is a bitch on RPi's.

the Pi 4 is new, so stability is even bitchier. But because you're using Raspbian, the fixes will be easy to find, as it's pretty much the official OS.

In order of importance:

• Get firmware updates
• Get kernel updates
• Get all other OS updates too

You can probably handle all the above using the command:


if you're not logged into the root account, you need to add sudo before each apt-get command (because the above is actually 2 commands, the && means "do the next command, but only if the last one worked") And your user needs to be in the wheel group, or have an entry in the /etc/sudoers file to be able to actually use sudo without Raspian telling you you tried to do something naughty.

Raspbian probably has you configured to get everything update-wise using those commands. But, the Raspberry Pi forums will tell you more. For instance, I clocked my CPU down on my Raspberry Pi 3B+, and I wouldn't have known that was a stability fix had it not been for searching/reading the RPi forums. Just updating the software didn't work, it needed tweaking somewhere else in the OS's config files.

brutally candid again:

I think this is probably a good thing (for now). If the channel open/close fees are set high and not configurable, people aren't going to experiment too much with such steep the on/off ramp fees.

I think it's right that fee-bumping has to be handled in a specific way when you close a channel (there's a new way to fee bump specifically included in the new version of Bitcoin 0.19.0, out soon), so it's safer right now to set a high fee for closing to make sure that you get the money spendable again asap. You have to wait for the timelock to expire (see upthread), then for the transaction to confirm onchain. That means guessing what fees will be like when the timelock expires.... not easy. All this stuff is part of the various improvements to Lightning, there's still alot to do.

the timelock doesn't start until you close a channel. It's there to protect the other participant from you trying to close using old transactions (from when you had more BTC in the channel than when you closed it)

there is no channel expiry, it just stays open till you or the other side closes it



my previous advice to you was "don't try it yet", so I hope you're willing to accept that you are 100% responsible for everything that happens to your BTC. That said, Zap should be pretty straightforward, although I don't have any direct experience using it.

NONETHELESS
I strongly recommend you try out the TESTNET version first. Play around, alot, then do that some more.

many already do, so I also believe the same thing

I'm totally up for having more purchasing power using my fake, manipulated, darkweb magical internet not-money I'm sure the haters realists are content with their real, official, steadily declining in value permission-to-buy-things money too

well, yeah. I'm not aware of the specifics of Ubuntu Server, but it's likely as if choosing a sex doll instead of going for the real thing. What's the point of Ubuntu's server version when...



...agreed, Debian's conservative, minimalist approach is pretty much perfect for servers. You don't want the package updates to be constantly changing the ground under your feet, you just want security updates only, and a well supported ecosystem so it's easy to find the information you need.

---

I'd add that if you really want a solid server, the systemd init system is a potential menace (it's ok for a laptop that doesn't need stability or security). Devuan is a Debian fork that gives you choice of init systems, there are various well-designed init concepts to choose from (Debian packages them all, but it's hard work actually uninstalling systemd and replacing it, as the init system is such a basic part of the operating system)

On similar grounds to replacing systemd (bad design makes it insecure), I'd suggest looking at ditching OpenSSL too. It's just as difficult to remove as systemd, as it's just as fundamental to the OS's functionality (nothing works if you have no init, the machine won't boot up! Removing SSL is almost as bad...) For that reason, starting without OpenSSL is the best option, but it's also not easy. The main OS's that support the alternative SSL (LibreSSL) are Gentoo, FreeBSD and OpenBSD (i.e. the only well known Linux supporting LibreSSL is Gentoo). They're great OS's, but not for beginners.

I take the "dynamic goldilocks" view on this. 4MB blocks (the entirety of which is not currently easy to use, 2-3MB is more realistic given today's way of using Bitcoin) is enough to compete against the competition when you factor everything in, given today's level of adoption. It's not necessarily wrong to say that's not enough, but blocks are nowhere near full today, so clearly the 4MB increase has bought some time. And as Bitcoin may continue in a positive feedback loop of increasing relevance, I don't think it will be as hard to find the level of unanimity needed to make infrequent step changes to maximum blocksize/weight, even though it will likely always be debated and argued over pretty pugnaciously. So it can only change when it's absolutely necessary. This is a good thing. And that may include the possibility that 4MB will always be enough, it depends on what can be done with that much transaction space (current techniques for efficient usage of 4MB suggest it is enough in the medium term, but not in the long term. That is subject to new innovations, of course)

The prevailing view is that it's best for the network to under-provide, given the background conditions (i.e. the health of the internet itself). Because if the conditions become worse (i.e. something happens to the internet that makes it harder to use), then at least we weren't maxing out usage of the internet as of the previous good conditions. This means Bitcoin could survive if the internet goes backwards in usability, and it's impossible to rule that out for all sorts of reasons. Payment channels (i.e. Lightning) would handle this particularly well, the blockchain itself could completely grind to a halt, and the comparatively less demanding requirements of a channel network could function more easily than the base layer. In a scenario like that, I can imagine people cursing even the present-day 4MB block limit as the internet gradually returned to it's previous state of health.



The devs are broadly taking all this into account with their approach:

• Reducing the resources (RAM, CPU, bandwidth) needed to run a Bitcoin node
• Making network level attacks (e.g. the various ways to split Bitcoin into two or more partitioned networks) harder to perform
• Increasing the utility of the space in blockchain blocks (there are all sorts of angles to take)
• Adding fallback modes/infrastructure to mitigate attacks or outages (e.g. redundant network code written differently, or 2nd layer payment rails etc)

There are multiple initiatives going on right now to address all the above. None of it will be enough, it's an eternal cat and mouse game. Every new paradigm begets a new method of attack, despite any ground gained. But Bitcoin has gained and held ground, and continues to do so.


Take a look at Bittorrent; endlessly attacked in all sorts of ways, and yet the developers keep innovating, and the bittorrent network is bigger, tougher and more usable than ever.