irwt

7 ms·

31.
by irwt 6y ago
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 ma
32.
by irwt 6y ago
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 innovatio
33.
by irwt 6y ago
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 cou
34.
by irwt 6y ago
I wouldn't expect anything different from François..
35.
by irwt 6y ago
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 compl
36.
Using Medoka encoding to compress sparse bitmaps(lums.blog)
2 points by irwt 6y ago|0 comments
37.
The Binary Vector Clock(arxiv.org)
18 points by irwt 6y ago|1 comments
38.
by irwt 7y ago
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
39.
by irwt 7y ago
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.
40.
by irwt 7y ago
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'
41.
by irwt 7y ago
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..
42.
by irwt 7y ago
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 t
43.
by irwt 7y ago
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 i
44.
by irwt 7y ago
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.
45.
by irwt 7y ago
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
46.
by irwt 7y ago
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 requir
47.
The Compact Merkle Multiproof(arxiv.org)
57 points by irwt 7y ago|31 comments
48.
by irwt 7y ago
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, where
49.
The Bloom Tree(arxiv.org)
11 points by irwt 7y ago|3 comments
50.
The Distributed Bloom Filter(arxiv.org)
8 points by irwt 7y ago|0 comments
51.
by irwt 7y ago
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", whic
52.
by irwt 7y ago
I'm happy you liked it :)
53.
by irwt 7y ago
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 sys
54.
by irwt 7y ago
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
55.
by irwt 7y ago
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.
56.
by irwt 7y ago
Thanks for the links. I will read them during the upcoming days and hopefully find some time to write a blog or something. This looks pretty cool.
57.
by irwt 7y ago
Excellent question. I did not address this in the paper, but I probably should have. The upper-bound you mentioned technically does not happen directly because of the nodes, but because of the increased "rate of events" (which can
58.
by irwt 7y ago
Very good question. I will have to think about it. Will get back to you later.
59.
by irwt 7y ago
Imagine that node A and B are in sync (they have the same bloom filter). If A sends a new event to B, B can check if A's new event really results in that new bloom filter. You basically have a cryptographic proof that an event really h
60.
by irwt 7y ago
Hi everybody. I'm the author of the paper. Let me know if you have any questions or comments.

More ›