[cyberax]

How does Reticulum solve the fundamental issue of mesh networks: either you have to have a central controlling authority for addressing, or an adversary can just flood your network?

Does it have some kind of blockchain crap tie-in?

[__MatrixMan__]

I can't comment on Reticulum, but I think there are solutions to that problem re: content-addressing rather than node-addressing.

If you replicate a piece of data based on whether you or your (explicitly trusted) peers are interested in it, then the only way to flood the network is to convince all of the users to become interested in it, which is likely difficult enough to discourage misbehavior.

pub/sub, not request/response.

[cyberax]

Sigh. The problem is not the content. It's the addressing.

For the content-based addressing to work, you need to flood the network with the reachability information ("how can I get to this block?"), and it's trivially easy to just generate enough of it to overwhelm the routing nodes.

[__MatrixMan__]

But that's request/response, because you're requesting blocks.

I'm saying that when two nodes pass each other in the street or whatever they think "hey, a peer is in range" so they see if:

- The peer carries any topics they're interested in

- That topic's synchronization algorithm indicates that any actual synchronization is needed in this case

So some content may get shared between the devices, but nobody requested it. The event source was the arrival of the peer. You might also recheck periodically, supposing they stick around for a while.

If you subscribe to topics with dumb synchronization algorithms that just copy everything they see and don't check a web of trust, then yeah you could still get floods of data that saturate whatever resources you've allocated to that topic, but that would quickly become a useless topic, so just unsubscribe and pick smarter topics next time.

In summary, push the routing problem to the application layer.

Different data is going to have different needs. Map tiles need to stay near the parts of the planet that they describe. Information about how to mitigate a harm needs to be near the audience that might be harmed. Manuals need to be in the hands of people who are interested in the objects that they describe. Menu and open hours data needs to be near the restaurants with those menus and hours, or to nodes whose owners like that kind of food...

The goal is to converge on a particular distribution of data across nodes, not to get any one piece of data to any one particular node. No requests, and no handling data that you haven't opted into handling by subscribing to that topic.

I suppose you might conceive of the synchronization process as a series of requests, but they don't propagate anywhere. For each datum you either already have it, you decide to take it, or you decide to leave it.

[cyberax]

> But that's request/response, because you're requesting blocks.

It doesn't matter.

> - The peer carries any topics they're interested in

How do you implement it? Do you have a human manually looking over each message and marking the interesting ones? Heck, it's likely that everything is encrypted anyway!

> So some content may get shared between the devices, but nobody requested it. The event source was the arrival of the peer. You might also recheck periodically, supposing they stick around for a while.

So you get 10^12 anonymous peers arriving at your node. How do you filter them?

[__MatrixMan__]

The node operator subscribes their node to topics, so yeah that part is manual, and that's how the humans express their interest. You might have to update it every now and then if one topic is killing your battery or your hard drive or you just don't care anymore. The data which that topic governs is handled by the synchronization function which runs periodically without supervision.

Whether some or all of the data is encrypted is an application level detail. At the network layer you just call the function provided by the app/topic and it tells you whether to accept or ignore a datum, and which datum to delete if the storage quota for that topic is full. Lots of things don't need encryption (e.g. map tiles). Or if there's some kind of trust structure in place, the node may have keys necessary for doing the decryption--it's not like you're carrying data for apps besides those you're participating in.

As for the peer filtering thing, peer-discovery and synchronization would happen in time slots. So if it happens for 30 seconds each time and this app in particular gets 30% of that, then I guess you spend 10 seconds trying to see if any of those 10^12 peers are worth synchronizing with. Maybe you're checking to see if they're n hops away on your web of trust for that topic or something like that, it would depend on the case. But I don't see how this case has anything to do with mesh networking: all forms of communication are susceptible to DOS of some kind or another. The best we can do is limit the blast radius and maybe raise it to the user so they can handle the adversary out of band.

[AyyEye]

> either you have to have a central controlling authority for addressing, or an adversary can just flood your network

False dichotomy. IIRC reticulum does something like an inverse TTL, so packets have priority based on how local they are.

[cyberax]

Nope. It's fundamental.

The problem is in the _addressing_. How do you find the packet's next hop?

[AyyEye]

Not sure about reticulum but Yggdrasil uses a hybrid spanning tree and dht to guess based off dht and uses key weight to failover to the spanning tree.

[icepat]

No, Reticulum does not require a blockchain. My understanding is that Reticulum solves this by allowing network redundancy.

[cyberax]

So what happens if I create a node, then create 10 trillion addresses and send a message to every one of them?

[dicknuckle]

blockchain can be cheap (power, compute etc) and not crap. Doesn't mean every project that builds with it takes that into consideration.

[__MatrixMan__]

If you've picked mesh networking, then you care about partition tolerance. But blockchains prioritize consistency. So I think using blockchains on mesh networks puts you in a disadvantaged situation re: the CAP theorem. There's got to be a way which better aligns the application layer with the constraints of the physical layer.

[cyberax]

> blockchain can be cheap (power, compute etc) and not crap.

No. All blockchain is crap, no exceptions are fundamentally possible. The reality reflects that rather starkly.

By "blockchain" I mean a system with a distributed consesus via proof-of-work or proof-of-stake.

[__MatrixMan__]

So it stops being a blockchain if the criteria for adding a block is based on something else? Or do you intend to update your definition to incorporate other consensus mechanisms as they emerge?

Seems to me that a more useful definition would abstract out the consensus model such that a blockchain is essentially a merkle-linked-list together with some function for determining which of two candidate next-blocks will be the actual one, but without getting too specific for what that function is... just because there's so much potential for variation there.

[jazzyjackson]

> just because there's so much potential for variation there.

There really isn't. Either you expend some resource to make it expensive to attack or you stake some resource so you have something to lose to prove you're not a bad actor. I've never seen anything more creative than this.

[__MatrixMan__]

Or you participate in some activity which provides a service, like filecoin. Or you get somebody's approval of the block's contents, like in a permissioned blockchain.

I think we'll also see something where you do key-signing parties all at the same time as a way of providing sybil resistance. Or proof of having voted on whatever it is (the outcome of the vote would then go into the block).

Stake and work are just the easy ones to implement because they don't even try to be simultaneously useful.

Personally I'm not very excited about blockchains because I think global consistency is overkill for pretty much everything, and is in many cases harmful. But it's hard to take anyone seriously who classifies a technology as by-definition-useless. Its current forms are weak enough to defeat at face value, no need for propaganda.

As for the future ones... Maybe they be useful, we'll see.

[jazzyjackson]

Hm, thanks for the argument, I guess I'm turning it into semantics; filecoin and "permissioned block chains" sound more like reputation / web of trust systems. So to me it only becomes blockchain when there's some consensus mechanism not based on people making choices (because then we're just back to having a DB with auth...)

[cyberax]

"Permissioned blockchains" are basically isomorphic to git repositories. They certainly are useful, but they aren't "blockchains" in the regular sense.

[K0balt]

POW doesn’t have to be useless work. It can be useful work, so that mining actually creates a value tied to off chain economic systems. Then you have something that actually has value, and you can then use POS to give validators both a correct incentive alignment and a way to get paid for their work. Hybrid value backed POW for token creation with POS for validation creates a really good system for digital assets.

Sadly, extant systems for this are few because generating real value is actually challenging.

[cyberax]

> It can be useful work

It can be in theory, but in practice there are no tasks that fit the definition. All attempts to use something like protein folding ended up in failure.

[EGreg]

There are lots of other approaches - IOTA DAG, HashGraph, Ripple Consensus Process etc.

I am not a fan of blockchains, though. They are overkill for most uses. But here is an example of a non-blockchain system that doesn’t even require global consensus:

http://intercoin.org/technology.pdf

Also check out the Autonomi network

[cyberax]

It's not really going to work. Without a centralizing consensus, any such scheme is vulnerable to be drowned in forks.

A malicious notary network can simply flood the ledger with conflicting views. So clients will have to somehow find a set of notaries that is the "best".

Proof-of-stake means that there's effectively a vote on the set of "reliable" agents, and proof-of-work works because the malicious notaries can't outrace everyone else.

[acaloiar]

I'm afraid you're redefining what a blockchain is. A blockchain is a distributed ledger. Distributed ledgers are an application of distributed conensus, which is a truly interesting field within computer science.

[EGreg]

You’re being downvoted because you’re making sweeping unsupported assertions, likely based on an ideological opposition to blockhain.

I am guessing it has to do with anger at FTX and other negligent participants in the wider “crypto” ecosystem that has very little to do with blockchains. But that is a “non sequitur” (Latin for “it does not follow).

If I am wrong in my assumptions and you have an actual argument supporting your assertions about “all blockchains” being crap, please do elaborate on the substance.

[cyberax]

The reality is: blockchain has failed in EVERY area it's been tried, except for illegal/unregulated payments.

Assets tracking? Failed. Interbank settlements? Failed. NFT and art? Spectacularly failed (wanna an NFT for that spectacle?).

[LinuxinaBIt]

Reticulum uses absolutely no blockchain. It uses a fairly novel routing strategy with something called announces.

Read this page to learn more about it: https://reticulum.network/manual/understanding.html

TL;DR it only flood routes packets that tell the network the location of a node; each node stores the “next hop” to get to every other node on the network. Everything else is routed along a single path determined by those “next hops.”

[cyberax]

What stops me from flooding the network with 10^12 of fake addresses?

[adinisom]

The intended solution seems to be a 2% bandwidth limit for announcements and a preference for lower hop-counts to keep your flooding local.

There's a FAQ item on this: https://github.com/markqvist/Reticulum/wiki/Frequently-Asked...