Topic: Bitcoin Core 0.18.0 Released (Read 3314 times)
Yes but I can't occupy 243 GB of blockchain on my HD.
Bitcoin Core 0.18.1 has been released: https://bitcointalksearch.org/topic/bitcoin-core-0181-released-5174171
something wrong, i can't connect anymore, after i closed bitcoin core, it remain at 13 days behind...
Looks like connection problem or for unknown reason your nodes have low appeal which makes other nodes chose not connect to your node.
I recommend you to make a thread about this problem at Bitcoin Technical Support, don't forget to share relevant info such as debug.log file
i think it was the last update, windows serch is not working anymore...
ok i got it, it's because i was sitting on the previous old version, i didn't update to 1903
something wrong, i can't connect anymore, after i closed bitcoin core, it remain at 13 days behind...
what is the purpose of Bitcoin Core?
Except that you're running the most secured BTC wallet, the main purpose is to support the whole bitcoin network when running them and keeping them updated (blocks) on someone's device.
what is the purpose of Bitcoin Core?
Except that you're running the most secured BTC wallet, the main purpose is to support the whole bitcoin network when running them and keeping them updated (blocks) on someone's device. 
what is the purpose of Bitcoin Core?
it's software.
- Bitcoin is a network
- BTC currency is sent between nodes on the Bitcoin network
- Bitcoin Core is the software that lets your computer get onto the Bitcoin network (to send and receive Bitcoin/BTC)
what is the purpose of Bitcoin Core?
If you want to continue, I've replied here, to keep it concentrated under a dedicated thread.
dbcache doesn't help, possibly because pruned mode adds flushing (maybe also other things in play). A previous discussion here.
This may not be so much of an issue on SSDs, but on HDDs, the current roundabout solution for long IBD syncs is to use a RAM drive, effectively doing the caching externally.
Stop using HDDs, problem solved and no dev-time gets wasted. This may not be so much of an issue on SSDs, but on HDDs, the current roundabout solution for long IBD syncs is to use a RAM drive, effectively doing the caching externally.
dbcache doesn't help, possibly because pruned mode adds flushing (maybe also other things in play). A previous discussion here.
This may not be so much of an issue on SSDs, but on HDDs, the current roundabout solution for long IBD syncs is to use a RAM drive, effectively doing the caching externally.
This may not be so much of an issue on SSDs, but on HDDs, the current roundabout solution for long IBD syncs is to use a RAM drive, effectively doing the caching externally.
More important that's related to this?
I don't know if the details are easy, but the high-level concept is simple: allow to cache whole chainstate in memory, flush lazily.
We already have better caching than anything you will think of. Increase dbcache to whatever you can afford. I don't know if the details are easy, but the high-level concept is simple: allow to cache whole chainstate in memory, flush lazily.
More important that's related to this?
I don't know if the details are easy, but the high-level concept is simple: allow to cache whole chainstate in memory, flush lazily.
I don't know if the details are easy, but the high-level concept is simple: allow to cache whole chainstate in memory, flush lazily.
As far as I can see there are no write caching improvements in this version. Is there anything being worked on or planned?
The last change was #11658, which was only a minor upgrade.
What exactly makes you think that there is room for easy improvement in that area? More important things are underway anyway. The last change was #11658, which was only a minor upgrade.
As far as I can see there are no write caching improvements in this version. Is there anything being worked on or planned?
The last change was #11658, which was only a minor upgrade.
The last change was #11658, which was only a minor upgrade.
Please do not quote the entire gigantic OP just to write "When LN?"
Use SHA-2 and PGP to check the authenticity of Bitcoin releases, that method comes with at least some guarantees (using the fingerprint to id the PGP key is possibly not reliable any more though, there should be a t-shirt with the Wladimir van der Laan PGP public key + expiry date printed all over it IMO, or at least till PGP updates their standard for fingerprinting public keys)
there is no need for an upgrade to PGP standard as long as SHA-1 hashes that are used for PGP fingerprints is strong (2^160) against second preimage attacks (not to be confused with collision which SHA-1 is no longer strong against). so as long as the long form of the hashes (the whole 20 bytes) is used, everything is safe.
The thing with systemd is not simply "learning" things, but the fact that its so buggy and bloated and the main developer doesn't really care.
most Ubuntu or Mint users aren't going to notice the kinds of bugs it has, and they're equally unlikely to appreciate the poor design philosophy behind systemd
In fact I'm avoiding all his projects (don't need any of them), he tends to keep that same mindset in all his works.
sure, but convincing people to ditch systemd for OpenRC is one thing, getting them to configure jack audio and eudev is just more on top, it may be all too much for some people. Building up the ecosystem around well designed alternatives to invasive Red Hat products is important to keep Linux going in the direction of good quality software engineering.
Corporate software is basically attacking Linux with these bad quality system components (and in other ways too, arguably), so sure, start with yourself. But we really have to make the most convincing case to ditch this crappy stuff to those who otherwise wouldn't care.
Oh, everyone is free to choose, i'm all in for defending this freedom of choice.
To me dumping pulseaudio was very simple: Just make a decent asoundrc (either user or systemwide). Alsa can do its own software mixing for output AND input, it can even do fancier stuff such as a global equalizer or you can make virtual devices with your favorite LADSPA plugins.
Code:
pcm.!default {
type asym
playback.pcm "plug:dmix"
capture.pcm "plug:dsnoop"
hint {
show on
description "Default ALSA"
}
}
type asym
playback.pcm "plug:dmix"
capture.pcm "plug:dsnoop"
hint {
show on
description "Default ALSA"
}
}
Pulseaudio like systemd does have some interesting features, but they are rarely needed for most users (such as a network audio device). Indeed most audio professionals stick with jackd, but honestly alsa itself will do for most needs. One glaring exception is bluetooth compression codecs, luckily i don't even use bluetooth.
Avahi i have never used in my life, and the systemd talk has been already made. I think he is now involved in a fourth project but i forgot about it.
I'm on Artix and eudev is in use, the distro maintainers (all two of them) did all the work for me
. There are various DAW oriented distros that include jackd, and iirc they even ditch pulseaudio in the debian/ubuntu based ones. Artix does come with pulseaudio but i quickly got rid of it. There is apulse for the rare program demanding it (Skype?).But we really have to make the most convincing case to ditch this crappy stuff to those who otherwise wouldn't care.
I guess the simplest way is:
Bad:
- Fedora
- Centos
- Ubuntu
- Mint
Good:
- Devuan
- um, Gentoo
trouble is there aren't many non-systemd Linux distros, and Devuan is probably gonna be the most user friendly of them all (Gentoo isn't really user friendly). There must be some more I didn't mention
Actually, its much simpler, just visit Distrowatch and do this custom search. 81 results and counting...
Can someone please explain this to me
Start here https://twitter.com/lopp/status/932350908461133825Any questions? Ask here https://bitcointalk.org/index.php?board=39.0
Can someone please explain this to me
Jump to: