Nomad, communicate off-grid mesh, forward secrecy and extreme privacy

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.

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.

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.

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.

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.

11 meters is in a different part than ham and is usable unlicensed.

Doesn't mean you can send encrypted traffic and there are FCC rules about duty cycle, etc.

Correct: I misread the thread. Thanks!

yeah occurred to me a while after posting :-D

Sure, in some cases, when the network has fewer announces to deal with, the 2% limit has less effect, the best way Reticulum can deal with this is with a network made out of more specialized node types connecting the lower speed links (http://reticulum.network/manual/interfaces.html#interfaces-m...)

However when the network (and each node) is receiving enough announces to saturate that 2% chunk of most smaller links, those interfaces prioritize announces with less hops, and there is a queue, meaning it takes that interface longer to transport announces coming from further away. This makes it much more likely that nodes will form routes over a faster but longer path.

thanks!

fwiw, those seem to apply to only a single destination, and any node can sybil up as many destinations as it wants, right? `announce_cap` seems more relevant

is there a place where you've written down the threat model reticulum is intended to defend against? it's hard for me to evaluate its security measures without that context

how do you rate_limit with "anonymous initiation"?

one malicious peer can have as many sources as they want. don't even need a botnet of IPs.

The link you posted seem to guard against flood of sinks on the distributed routing, but there's no mention of source flooding.

Check out the newly released Freenet feature https://freenet.org/news/introducing-ghost-keys/ anc Proof of Trust system: https://freenet.org/news/799-proof-of-trust-a-wealth-unbiase...

i agree about the blockchain, though now possibly there are multiple viable approaches under that rubric now that ethereum has abandoned pow

there are a lot of possible approaches to the problem, though

hashcash for announcing new destinations is one possible measure

reserving most of the bandwidth for established connections to which both parties are indicating their continuing enthusiastic consent is another, and one which the circuit-switched pstn does implicitly, which is why your phone calls wouldn't drop or skip when there was a commercial break in prime-time tv. reticulum seems to do this by reserving 97% of bandwidth for non-announcement traffic, though i might be misunderstanding

the agorics 'digital silk road' paper from 01995 (unrelated to the later darknet market) describes another approach: include a source route and postage on every packet, with each network provider deducting however much postage it feels like deducting, and keeping track of bilateral account balances with each peer network (postage sent minus postage received). if the postage runs out, your packet gets lost, and the sender can choose to try resending it over the same route with more postage or routing it over a less expensive network. periodic cash settlement between network service providers zeroes out any persistent imbalance in cash sent and received: http://www.cap-lore.com/Agorics/Library/dsr.html. i don't think this has ever been implemented, though current nsp peering agreements do resemble it to some degree. the original paper suggested using eft for the periodic settlements, but nowadays you could very reasonably do it with something like ether

you can supplement the established-connection-prioritizing mechanism with a granovetter-diagram introducer mechanism: if alice has an established connection to bob, and bob has an established connection to carol, bob can dedicate some of his bandwidth on those two connections to passing messages between alice and carol. he can do this either completely at the application layer, with no support from lower layers of the network, like an irc server or turn server, or potentially with support from the network layer to find a more efficient and reliable route. (reticulum seems to support this; bob can pass alice's destination to carol or vice versa, which the manual seems to say eliminates the need for the announce mechanism, though i don't yet understand how the protocol works.) this allows bob to prioritize such connection requests using information that isn't available at the network layer, such as whether alice and/or carol have passed a captcha and/or are paying him, who they were introduced to him by, who they've introduced him to in the past, and what valuable data they've sent him. if bob repeatedly introduces alice to people she doesn't like talking to, she might cut off contact with bob, or at least look on his future introductions with a jaundiced eye and not allocate them much bandwidth