I'm cutting back a lot on carbs, feeling pretty hungry too. It's a strange feeling

I got pretty strict about a week ago, and had some expected symptoms like a headache, but salt fixed it.

Fascinating topic, how visceral fat really isn't healthy

Whoever is funding their attack is switching their funding to Project Eleven (for the quantum lies) and Paul Sztorc (for his fork)

Luke and Mechanic and Kratter have failed, and are now abandoned

https://njump.to/nevent1qqs9zq6g2pgl2ycus75raf0gh6ukggu539k2k8g2jnd0samll64yswqprpmhxue69uhkummnw3ezucmgv95k6cfwd9hxvme0qgsp9msr6ytgfgf9mkrmapuu9qvsg9d78ua3ajntfmt580t5llvgpesrqsqqqqqpmw2mq5

The second two of those points are 'easy' to think about, in the sense that it's just about detecting which peers are spammy/unreliable. If their Bloom advertizes they can reach nodes, but they rarely/never get the relevant signed CoordinateLookupResponses, then they are unreliable. It might take a long time to get the right balance of heuristics to make it work, but in principle it's solvable.

> Bloom filter validation — reject suspiciously dense filters
> Per-source LookupRequest rate limiting — cap flood generation

I'm less sure about the first two points though; solutions are not so obvious. I had a lot of fun with faking fake roots and fake ancestries and varying 'depths'.

> Root election with cost — proof-of-work, minimum age, or stake

Maybe the root should be the oldest node; although I'm not sure how to get consensus on that in a simple way.

> Per-entry ancestry signatures — already on their roadmap

Signatures won't stop me from firing up a million nsecs and signing many different ancestries and spamming the network. If I have many entry points into the network, then I can spam with new (fully-signed) ancestry paths very regularly

I don't say I have a solution, but I think we need to either make it difficult/slow to change the root in chaotic ways, *or* have a system which is robust to such chaos.

Ideally, a change of root will change only the direction of arrows on the spanning tree, without changing anything 'fundamental' about the tree. This should allow us to preserve the property that a spanning-tree-edge divides the network into two sets of nodes. Swapping the direction of edges doesn't change those divisions, and therefore I think the bloom filters don't need to be rebuilt immediately on every change of root

We might need to keep tracking of mutiple roots, and therefore multiple coordinates, during the transitions. Don't discard a given root until all your peers are happy with a different new root.

But I'll stop rambling now. I might not be making much sense. In any case, a written document which we could review would be useful to discuss how we might have a reasonably scalable and robust protocol

What's stopping you from making the Reticulum PR yourself? 😂

It's quite easy to add new transports to FIPS; the transport interface is quite simple

I think the questions are similar in the end. Do we want hash-based signatures? Lattice-based? Both? Neither?

One advantage of that we can be more relaxed about signatures sizes in Nostr. If a Nostr event is 64k, then I don't mind attaching a 3kb signature

And Nostr will be able to move more quickly than bitcoin, if needed

I think I'm looking for the opposite. I don't want to share a bolt11 invoice with the mint, as that will share the the public key of the receiving Lightning node with the mint

Unless bolt11 already supports some blinding, which can be used to hide this?

Crazy yes 😀

But I kinda think the idea of a FIPS node in the browser might be useful.

The whole Linux and ipv6 thing was a bit silly (just fun for a demo) but a FIPS node that uses the FIP Native API might be useful to some people, and therefore the 'websocket' transport might be useful.

For example, imagine a Cashu wallet like cashu.me that is a PWA. It could have a minimal FIPS node built in to connect to a mint over FIPS.

For now, I'll ignore this. But curious if I/we/others should maybe follow up on this sometime

Code here: https://github.com/SatsAndSports/fips-in-the-browser