Here’s a visual way to get a sense of filter optimization in the local relay model. See quoted post for motivation.
Once you define the is_subset function you just call this for each filter on every other filter. This creates an array of true/false for each filter. This is equivalent to there being an arrow above each filter in the diagram. then you just remove each filter if the value is true for that index. Simple!
Adding this to the nostrdb api, might come in handy for anyone implementing the local relay model. https://i.nostr.build/8PuntrZ2ak6yvHND.jpgnostr:note183q8djwxueg2qq9gpqv5vgrt5cgnle4pg9vv3qde48und7822r2s4ff9p5
There may be one more nuance with respect to limits and until/since and merging these properly… will ponder. This makes the most sense when optimizing realtime feeds for now 🤔
On the plane I came up with an algorithm that does the following:
given a set of filters, find all filters that are redundant. It pretty simple, you just determine if a filter is a subset of any other filter in the set, and then you prune those.
Example: everything is a subset of {}, the filter that matches everything, so this algorithm could take a list of 100 filters, and if {} was present it would only return that 1 filter.
This is useful for notedeck, as you would only need to open the minimal number of subscriptions remotely, while still having granular local filters active on nostrdb.
Will write up this algo soon, i have some of the code done already.
gm nostr
Apparently 22 channels forced closed when my node was offline… wow. Why do ln nodes do this?
More inbound liquidity would be appreciated:
03f3c108ccd536b8526841f0a5c58212bb9e6584a1eb493080e7c1cc34f82dad71@ln.damus.io:9735
“I joined nostr and only saw bitcoin content so i left”
Yeah well i joined bluesky and only saw commies and guys dressed as girls, so pick your poison I guess.
I personally don’t, these people will not make it through the financial reckoning anyways. may seem harsh but if they want to fuck around then they will find out.
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
I also noticed i had a pretty small dbcache which could have possibly increased the frequency at which these errors might occur due to frequent flushes.
I’ve had many bad memory issues in the past and it usually always leads to system instability. If it is memory it must be a very minor issue that somehow doesn’t cause anything else to crash.
Oddbean new post about login | logout
Notes by jb55 | export
On the plane I came up with an algorithm that does the following: given a set of filters, find all filters that are redundant. It pretty simple, you just determine if a filter is a subset of any other filter in the set, and then you prune those. Example: everything is a subset of {}, the filter that matches everything, so this algorithm could take a list of 100 filters, and if {} was present it would only return that 1 filter. This is useful for notedeck, as you would only need to open the minimal number of subscriptions remotely, while still having granular local filters active on nostrdb. Will write up this algo soon, i have some of the code done already. gm nostr