A Bitcoin node will detect bugs in the matrix
since I'm not seeing any serious memory or disk issues, and assuming there are no bugs in bitcoin-core, I wonder if my bitcoin node is getting hit by cosmic rays and bits are getting flipped every now and then, leading to leveldb checksum errors.
I looked into ECC ram but I may need to build a home server, since it's not common in desktops motherboards.
Is this is why you’ve been going on about ecc memory @semisol ? I found a post about it from greg maxwell 10 years ago as well, saying all his non-laptop machines use ecc memory:
https://www.reddit.com/r/Bitcoin/comments/2jpk54/risks_of_running_bitcoin_client_on_a_computer/cle3qyb/nostr:note1ktns7scrqr00h9a400eajn8k23hcxzzp35syfr7j4tvzjkdpjjdsj4z0sf
protocols evolve... you don't need to use HTTP/3 + QUIC which is wayyy more complicated than HTTP 1.0. I still use http 1.0 in some C projects, doesn't mean we can't strive to build faster and more efficient versions of something.
funny HN comment
> Honestly I think Consensys/IPFS/Libp2p is just some corporatized way to derail real P2P and decentralization. Their libraries are total garbage. Lots of complicated code that simply doesn't work. No documentation. I mean look how much IPFS and Libp2p is pumped but IT DOESN'T WORK. IPNS is a joke. All way overengineered crap that does everything but actually nothing. Look at the $$$ and pedigree behind Consensys it's 100% establishment.
https://news.ycombinator.com/item?id=34177865
they have 3 different handshakes: tls, quic, noise... multiple transports. sigh.. someone should build a version of this that is a bit more opinionated. TURN/STUN is also still really hard, they have never been that reliable. I tried once with libdatachannel with no luck
it will save trillions of bytes of bandwidth. it is like rsync for nostr. the idea of fetching notes you already have will be an ancient concept.
this is even more important when you're pulling from multiple relays. right now you download tons of extra stuff for no reason. this fixes that.
so by my definition of a "nostr node" the damus notification relay technically isn't a nostr node, since there's no way to sync notes between it and yours. maybe nostr node = node that understands nip77 could be one definition.
this could enable nostr to be more like a p2p network in the future with the right overlay network, with nodes syncing with each other via negentropy. me and martti and a few others have been thinking about this.
nostr will outlive all social media platforms. legacy social are like one-off structures that eventually collapse. nostr is like dna, it can replicate itself into many forms and persist long into the future.
gm nostr
This is my main concern about edits on nostr, do people see the same concern or am I being overly cautious? Lots of ux issues. We would have to include metadata in the reply to even know which note is actually being replied to. This is pretty important in the example below. Many clients who don’t implement it may find replies confusing. I dunno… https://i.nostr.build/TLig8xyavw2KSq9c.jpg
the people on nostr are some of the smartest and coolest i’ve ever got to know. who cares if it doesn’t take over the world. It’s done more than i could ever ask for.
Oddbean new post about login | logout
Notes by jb55 | export