irwt

Also the creator of Bend is... lets just say he doesn't stick to projects for long.

That's completely irrelevant to the discussion. Creating a bank account as a non-resident is even in the US not that straight forward.

Let me guess, you're German? Germans will say they're not very patriotic, but really the way German patriotism manifests is a resistance to outside criticism paired with a stubborn insistence that it's worse in other countries.

I don't think you've lived in many EU or Asian countries... While incorporation sucks in France, Spain, and Germany, in most North European countries, East European countries, and even in most Balkan countries, it's a breeze (when compared to Germany).

TL;DR

This idea proposes that synonymous codons may act as more than passive alternatives — they could be part of an evolved error-correcting code hidden in the genome.

It’s a new angle on an old code.

The Koha model describes an algorithm for how neurons within a neural circuit specialize to become pattern detectors. The model also describes the role that dendritic spines have in memory formation and storage.

Some short segments of the recording are missing, and there were also some audio issues at the beginning of the recording. But overall the idea is followable.

That's the thing though, it's very easy to perform approximate nearest neighbor search in an efficient way. There are plenty of simple solutions for that. The real challenge is to design an algorithm that can scale & that remains robust even when there are additions and deletions to the set.

What exactly is elegant about this algorithm? The approach seems computationally quite inefficient to me.

As he's expressing several opinions, let's comment on each one separately:

1) His comment that "People don’t want to run their own servers, and never will" is correct, but I think it's not the right way to think about the problem. All of us have gigabytes of cached shit on our devices. Ideally that locally stored information should be part of a decentralized web. By "decentralized web" I mean smth very different from today's web3 bs.

2) "A protocol moves much more slowly than a platform" - again, he is correct, but I feel like he's not seeing the larger picture. The fact that a protocol "moves much more slowly" is actually a feature. Elaboration: He is looking only at the pace of change, not at the robustness of the system in question. Old software that was designed for use value, still works flawlessly, i.e. it doesn't break. The dependency graph of older protocols is mind blowingly small. Today's software, which most often gets designed for exchange value, breaks within a year if it doesn't get updates, because their dependency graph is enormous. It's correct that protocols rarely update, but they get forked way more. Most updates get introduced through new forks.

3) his section "Making some distributed apps" - spot on. As long as you need to have a local copy of a ledger (even if it's just the block headers) to be a validator, the majority of users will still have to trust a server. crypto fanatics will claim "yeah, but you can ask for a merklle proof of the state" miss that lying by omission is a thing (i.e. in the classic merkle tree, you can prove that smth is present, you cannot prove that smth is not present). As a result servers can still lie to you by omission. Crypto fanatics will say "yeah, but you can contact several nodes", but that assumes that there are several nodes. In reality the majority of projects will only call an Infura node. It's all insane. Nothing about today's crypto space is actually trustless & decentralized.

4) His section "Making an NFT" - Yup, the NFT space is ridiculous on several levels. His arguments against metamask are also legit, same reasoning as in the previous point.

5) Section "Recreating this world" - I think he's making the same logical mistake as in the earlier sections here. The cryptocurrency protocols did not converge to a client - server setup. They always were a client - server setup in disguise. The problems related to simplified payment verification (SPV) were never actually solved. I think it's wrong to think that things must converge to platforms. Things that are use value based often resist such dynamics, e.g. Torrents.

6) The "It’s early days" section - yup, it's not early days anymore. These problems are inherit in the architecture design of blockchain protocols.

7) "But you can’t stop a gold rush" - This whole section was spot on. It's all a gold rush. There's no use value to any of the crypto projects right now, except maybe enabling people who live under authoritarian regimes to take take their capital with them.

8) "Creativity might not be enough" - I don't agree with the first part of his conclusion, but the second part is legit.

Personally I think current web3 is going down a very bad path. The old school p2p protocol designers were still driven mainly by a socialist / anarchist zeitgeist. They were designing for use value. Today's protocols have a neoliberal zeitgeist. Use value was thrown out of the window in exchange for speculative value.

The real reason why people don’t use the blocked bloom filter, is because it’s FPR is much higher + it requires more storage. It has the worst of both worlds.

TLDR:

- The paper argues for the existence of a code within dendritic spines.

- The paper describes a biological mechanism for how information is processed within neurons.

- The paper describes a biological mechanism for how neurons within competitive circuits can learn to become pattern detectors.

Germany has lost the race for renewable energy against China, and it is losing the race for EVs against both the US and China. Two tech sectors that will generate immense wealth. Around 30% of Germany's GDP depends on the automotive market. There are whole factories in Germany that design parts that will soon be completely obsolete, and they're not adjusting any of their strategies. The EU has most definitely lost the tech race.

People in most EU countries are 1) annoyingly conservative when it comes to tech, and 2) the insane bureaucracy and regulations in most EU countries simply does not allow for the formation of a startup sphere. As a result we see 0 innovation in the tech space from Europe's side.

I believe that the hostility of EU countries towards foreigners plays also a big role in all this. If you're a non-EU citizen trying to setup a startup in an EU country, you're out of luck. For me as a non-EU citizen living in an EU country, it's just much simpler to start a startup somewhere else than here.

So we’re ignoring the fact that Germany basically backstabbed Ukraine with that deal on purpose? Germany did not want to get involved into the Russia / Ukraine conflict because of Russia’s gas dependence, but they knew that Ukraine could force them to take a stance because of their pipeline. So Germany screwed them over and started a pipeline directly with Russia. Germany here is just as much of a scumbag as the US.

I wouldn't expect anything different from François..

I think you're getting a few things wrong. Bloom filters do not serve as data structures for faster lookups, on the contrary, other approached perform probably much better. Bloom filters are only useful because of their low space complexity. E.g. look at genome assembly https://en.wikipedia.org/wiki/Bloom_filters_in_bioinformatic.... Storing and looking up every k-mer is super expensive (memory-wise). Bloom filters allow for efficient k-mer lookup, without actually having to store all the possible k-mers in memory.

I have the impression that most people in this thread are using LiquidText the wrong way. I use it on a daily basis and love it, but one has to know in what scenarios to use it. If you have to write lots of notes, don't use it. As much as I love the app, its note taking capabilities are not the best. Where LiquidText really shines is when one has to do deep research. I usually upload several papers around a similar topic to LiquidText, and keep the note section more for finding snippets of all the papers. Most of my best ideas came from using this app. All that said, I would love if the note taking part of LiquidText would be more similar to GoodNotes. Combining the pros of those two apps would be a killer app I'd be willing to pay on a monthly basis.

Very clever design. It's not exactly like our proposal, or the one implemented by @nemo1618 a year ago, but it's just as legit. I will edit the paper and cite your work properly.

You son of a gun, good job. I initially looked at the wrong part of the code, my apologies. This part describes it very well: https://gitlab.com/NebulousLabs/merkletree/-/blob/master/ran... It's basically the same thing. Implementation wise it's slightly different, but it's the same idea.

During the upcoming days I'll add to the paper that you were the first to propose this algorithm.

I don't want to be rude, but after checking your code I can say that what you did is most definitely not the same thing as the compact Merkle multiproof idea..

Thank you for the links, I will try and edit the paper in the upcoming days to include Vitalik's mentioning. Jim McDonald's article is also wonderful, we referenced it multiple times and experimented quite a lot with his Merkle tree repo: https://github.com/wealdtech/go-merkletree

I am glad that you liked our paper :) (the distributed bloom filter paper requires serious editing though).

Current sparse Merkle multiproofs require an index and a hash inside the proof. So in our hypothetical example that would be 30-40 indices and 30-40 hashes. Only then can a recipient of the proof perform the operations in the right order to recreate the original merkle root. With our proposal on the other hand, for this hypothetical example, we would need 30-40 hashes, and only 5 indices for a recipient to be able to recreate the correct Merkle root.

Here's by the way a great repo that can create sparse Merkle multiproofs https://github.com/wealdtech/go-merkletree

I see your confusion, from that perspective, you're absolutely right. But the usefulness of Merkle trees isn't in its 'fast lookup', it is rather in its bandwidth efficient way to prove that something remained unaltered.

One of the authors of the paper here. We did not cite this work, because it has nothing to do with what we're proposing. One should not confuse Merkle multiproofs with sparse Merkle trees. We mentioned that in the paper as well. I do know that Vitalik once proposed the idea of sparse Merkle multiproofs somewhere informally, and we would love to cite that if someone could provide a link to that. But regarding the compact sparse Merkle tree, just because this paper shares some words in the title, does not make it the same thing.

About the second point: I think you misunderstood something.

Imagine that we have a tree with 1000 leaves and we want to have a Merkle proof that can prove the presence of, let's say 5 elements. The sparse Merkle multiproof will require an index for every non-leaf hash, so worst case around 30-40 indices (that's just an estimate, as every multiproof can have different sizes, depending on the location of the leaves). The compact Merkle multiproof on the other hand requires only 5 indices.

The “github” word in the paper is clickable and redirects to the github repo. It appears to become highlighted only when it is in PDF format, thanks for indirectly pointing that out. The presence proofs are as you said probabilistic, whereas the absence proofs are non-probabilistic. In our specific use case (which we’ll explain in a future paper) the false positive nature of the bloom tree becomes actually handy to the problem we try to solve. But you are correct, we should probably rephrase the sentence to make it clear that the presence proofs are probabilistic and can be false positives, thank you for your feedback. We wrongfully assumed that this would be clear after explaining the probabilistic nature of bloom filters.

Anyone interested to read more about the octopus' brain, this article is worth reading: http://greymattersjournal.com/dive-into-the-mind-of-an-octop...

In a nutshell:

1) Octopuses have a "vertical lobe", which is very similar in function and organization to our hippocampus.

2) Mammalian hippocampuses have the ability for something known as "longterm potentiation" (LTP), which is believed to play a crucial part in memory and learning. Experiments found a similar longterm potentiation mechanism in the vertical lobe of octopuses.

Quoting the article: "The discovery of LTP in octopuses provides evidence for convergent evolution that has led to the selection of similar synaptic activity. Though not yet agreed upon in the scientific community, the existence of LTP in both mammals and octopuses strengthens the concept of LTP as a cellular basis for learning and memory and may be a general mechanism for associative learning".

I'm happy you liked it :)

Your argument about N messages per event is wrong though. You don't have to broadcast logical clocks to every other node necessarily, that's another issue. As long as every node in the system multicasts the logical clocks, the system-wide clocks will still "move forward" together.

The internal update order shouldn't really matter, as long as you send the right logical clock to other nodes. Communication depends on the system. Imagine the bloom clock a timestmap for your messages. Whenever you send a message, you will send the timestamp with it.

You are right, broadcasting is not a good strategy. I did not really explain the event sharing part in the paper, but as long as everyone multicasts the logical clocks, things should be scalable.