JanisErdmanis

For my application of the history trees (tansparency log) there are additional measures that help to ensure a global consistency view eventually. The authorithy would need to publish the final tally at the end of the vote which also would contain a tree root. The tree root would be distributed in print, in official anouncements thus any user can check that the tree root shown on the client coresponds to that with anounced tally and thus the authorithy would not know who does the check. Thus it would be unreasonably hard for adversary to deploy a deception attack at such scale.

Additional measure is that the TOR integration with the help of Arti project is deployed with the client. That ensures that every client does make the requests in the same way. It is surelly important to not disclose the server any local data or make identity revealing requests within the same session like giving away clients local commitment index before the server has shown their current commitment. Using anonymous channel for ensuring global consitency for sure is not universal but for some applications it is doable if the problem is approached holistically particularly in situations where anonymous channel is already needed within the protocol.

> Witness cosigning is secure even if the way you fetch the proofs is completely attacker-controlled

Opting for this approach makes sense if the protocol doesn't initially require an anonymous communication channel. However, if the protocol already uses it, introducing an additional assumption for trusted witnesses adds complexity.

> A malicious or compromised Log conducts a split-view attack by showing different views of the Log to different parties. This is done by providing different parties with different inclusion proofs and consistency proofs. Thus the Log remains consistent from the respective network vantage points of the target(s). They all see an append-only log.

You are spot on the vantage points. It is therefore at utmost necessity that the server does not know who has made a request, is not able to track clients. This is why requests need to be routed through anonymization service like TOR to preserve a single consitent view. The client only gives away the current root commit index they have stored locally which gives a little wiggle room there to be malicious. The latter can also be improved by first asking for the current tree root commitment and then aksing consitency proof with respect to locally stored commitment.

The global consistency in this design is achieved by the server not knowing who makes requests and thus gosiping is not needed.

I generally agree with what you have said. However regarding this part

> Yes, Clients are "thin", to use blockchain terminology, but they don't monitor the Log in order to detect attacks

The clients can monitor the ledger via consistency proots and it is highly beneficial as that prevents any chances of split being undetected view without requiring to trust other parties in the process. Clients submiting the record to the chain they can get inclusion proofs, but they can also at random times can query that the previous chain root commitment is consistent with existing one in the process keeping consistency proof chain. If it isn't judiciary actions in the presence of evidence can be taken against the authorithy. This is particulary interesting when ledger hosts votes which allows for a fully centralized deployment which is the basis of an voting system I am developing [1].

> it is important that Clients trust multiple logs for redundancy

Replication solves the issue that the records would would always be available which can be done by anyone who has stakes in the integrity of the ledger. Wheras the censorship reistance is an emergent phenomena where multiple people organize and collect unincluded records and overthrows the authorithy. Thus there is no actually need for Clients to trust multiple logs. Clients only need to trust that they would be able to do incident response in the case of misbehaving authorithy.

[1]: https://janiserdmanis.org/artefacts/EVOTEID-2023-poster.pdf

> blockchain could be seen as a permissionless transparency log

This is not the case. The essence of the transparency logs are thin clients which can do monitoring of the append only nature of the ledger. This allows accountability to be distributed more widelly wheras in blockchain one would need to retrieve the full ledger to do such testing.

On the other hand the responsability of adding records to the ledger in transparency log lies to a single authorithy whereas in permissionless blockchain it lies to individuals who solve the puzzle. However in practice there is centralisation of the computation power making the record inclusion also centralised.

The censorship resistance is somewhat a wicked problem. With transparency logs solve the by counter logging. In cases authorithy does not accepts a record it can be delivered to a counter authorithy. The counter authorithy also keeps records of main authorithy and thus users can eventually switch to it. This is though a manual process, but perhaps one can figure out a protocol to do such thing automatically.

Is there a specification one can follow to implement a verifier for certificate transparency logs? I looked up RFC 6962, but it does not contain test vectors. I am particularly interested in history tree inclusion and consistency proofs and don’t care how tree root is signed.

I understand that it is enjoyable to rework all protocols involving public key cryptography and propose alternatives, and I support that. It can be an excellent catalyst for coming up with new cryptographic primitives and a better understanding of existing ones, and Google can certainly afford such activities.

The issue is the emphasis on the importance of an inevitable threat. Organisations start to justify implementing QC-resistant algorithms on the basis that others are doing so, and in that way, they justify themselves that the threat is real. After that, we would end up with government agencies issuing a requirement that only QC-safe algorithms are acceptable for security in the process, killing useful cryptographic primitives like ElGamal cryptosystems, homomorphic encryption, blind signatures and a class of zero-knowledge proofs.

At the moment, there are only three points from which one can extrapolate further advancements. The Shor algorithm requires exponential suppression of errors with the number of qubits. This is why, although we have hundred qubit QCs, the most significant factorisation is being done at most with five qubits. Threfore, if we would have “exponential progress” in advancing QC, the advancement of factoring integers would be linear. Faster progress requires miracles. QC error correction would be no panacea either, as it would require repeated application and would require an unreasonable number of qubits as well as would increase runtime.

The miracle as well be that we figure out a way to factorize numbers on classical computers in polynomial time. Or as well break lattice based crypto on classical computers.

It is not enough to place qubits on a single chip or on a grid. We already know how to do that. The hard part is keeping them isolated while allowing arbitrary control of their interference.

The core issue why Schor algorithm is hard is that it requires exponential supppression of error with number of qubits to produce meaningful results. Therefore we don’t actually see much results here as the error rates have not yet reached thresholds to do it with more qubits. The error correction would not be a panacea either because it would necessitate it’s repeated application to get necessary threshold to run Schor algorithm. This would require unreasonable amount of physical qubits.

The threat estimate for a quantum computer that breaks cryptography shall be based on currently available data and the understanding that only the Schor algorithm is known to provide exponential speedup for factorisation.

Let’s give IBM credit for attempting to factor in the number 35 in 2022, although they failed there [1]. Before that, the successful factorisation happened for the number 21 in 2012 [2] and the first factorisation of 15 in 2001 [3].

Now we have three points. There is a trend that the factorised number grows by a number of 10 for every ten years. Thus, to get a quantum computer that facilitates RSA-2048, we shall wait for 2^2048 years.

[1]: https://arxiv.org/pdf/2103.13855v1.pdf

[2]: https://www.nature.com/articles/nphoton.2012.259

[3]: https://www.nature.com/articles/414883a

> Imagine you have a scenario where you need to get a token first, then with GET retrieve an id of the item, then with POST create a new entity related to that id. And then you need to call another microservice with created id from post request.

This is a good explanation. I would however be inclined to do that within a script.

> And more serious question is how you going to force developers keep swagger up to date so I can execute such scenario?

The swagger is created automatically from the routes themselves so it is always up to date. To maintain endpoint an integration test can be written which executes the scenario.

I just finished watching the introductory video and found the whole concept of PostMan and Bruno disappointing. It's baffling that one has to dive into the code to unearth the appropriate routes—a completely unnecessary and time-consuming endeavour. This process should be automated, ensuring that documentation and code are always perfectly aligned, eliminating any out of sync issues. The endpoints themselves should be directly accessible from automatically generated documentation using tools like Swagger. This isn't just a convenience; it's a necessity for efficient and effective development.

So, what is the utility of tools like PostMan, Bruno and others when one has automatically generated docs with Swagger with which one can interact? As an example, you can check my current project where I have set docs like that (still need to add an endpoint field): https://peacefounder.org/PeaceFounder.jl/dev/schema

> Contrast with a PhD who leaves in the middle of a program: The years he spent are 0. Generally, the experience/knowledge accumulated is not factored into it when he applies elsewhere for a PhD - unless he has some fantastic publication.

When I relised this kind of power inbalance during my PhD resulting docile behaviour of my collegues and partly myself, I even did not even wanted to chage my supervisour nor make a protest as the power inbalances are normalized. This awareness made my PhD easier as I did not put false hopes and did not invest my leisure time into becoming more specialised or come up with my own ideas which could latter be turned down to not allign with funded project as my collegues did. I found the remedy in fight for a better tooling and investing my leisure time in completely different field in which papers were still not been written by robots.

Ok. I see that we are on the same page if we were to agree on the definition of “born” to reaching a mature age.

> Now that I've sanitized the sentence, could you point out why I should care about how russians have come to be this way rather than caring about stopping them to avoid the destruction of Ukraine?

The distinction is necessary because the war does not only occur on the battlefield, but there is a significant portion on propoganda. The propaganda reaches best thoose who are not being integrated and with very open immigration policy there now are many within the Europe. With stratification of wealth there are many poor who don’t feel that they belong. Imagine telling them that they are born inferior.

> Humans are born with equal rights (at least in some countries) but aren't equal in capacity, character, judgment, and so on.

This is the most insulting statement on humanity and democracy I have read recently. I don’t really think you have meant it the way you have written it. Let’s unpack some parts of the statement.

> Humans are born with equal rights

This part sanitizes the fact that some are born in poor some in rich families. The rights may be in theory equal but only the one with the wealth and knowledge on political environment will be able to use them.

> [Humans] aren't [born] equal in capacity, character, judgment, and so on.

I can only read this part sensing some rasism and elitism. This neglects a dramatic impact on the environment where the person is born and expectations from them if they want to fit in.

To conclude, Russians are not orcs because they are born that way, but instead because they have been raised in an orc fertilising envirtonment.

Isn’t a durable store the same thing as a transactional database where transactions are listed on a tape and then read in to reconstruct the state?

Also, don’t use eval on your inputs, but instead make proper endpoints.

> uses a secret only exists on each individual phone

There is actually a way to prevent individuals from being traced while having a strong membership proof. This can be achieved by issuing signatures on a relative generator created in an exponentiation mix together with a set of output pseudonyms. One can picture it as strands braided together where it is hard to trace the link between the input and output strands, while it is very easy to tell that such a link exists.

More on that can be found on:

https://github.com/PeaceFounder/ShuffleProofs.jl

Sure. But what if the cropped part is sensitive content? Or if the video is exceedingly long? Then, providing a full source could become prohibitive.

It will be interesting to see what solutions people will come up with to support cropping images and videos. Perhaps one can already do that with Merkle tree inclusion and consistency proofs. Definitely good times ahead for doing cryptography.

It used to be frustrating when I forgot the basic keybindings, which I occasionally still do after 10 years of use. In particular, I find it quite suboptimal that moving around windows is hidden as `C-x o`.

For this reason, I remapped my arrow keys to move around them. I also have `Command + Left/Right` for cycling between buffers and `ESC` to kill a window. Recently, I also started to use function keys for managing bookmarks and buffers. Though for the latter, `C-x b` has also been quite often used since I remapped my CapsLock key.

I guess with all this, I wanted to say that there is much untapped potential for eMacs just by remapping some basic keybindings to fully appreciate `C-f` and `C-b` editing nuances.

I agree Rust does not make it easier either. This is an interesting design problem.

I tried it with ChatGPT and it did produce a robust solution. This does not seem to be a limitation for strong type hierarchy after all:

```

# Define a struct for Customer struct Customer

    id::Int

    name::String

    # Other customer-related fields

end

# Define a struct for Account

struct Account

    id::Int

    balance::Float64

    type::String  # e.g., "Savings", "Checking"

    # Other account-related fields

end

# Define a struct to manage the many-to-many relationship

struct CustomerAccount

    customer::Customer

    account::Account

end

# Define a struct for the Bank which holds all information

struct Bank

    customers::Dict{Int, Customer}

    accounts::Dict{Int, Account}

    customerAccounts::Vector{CustomerAccount}

end

```

I don’t think multiple dispatch solves this issue. Julia does have a strong type hierarchy and the proposed example with customers and accounts would be likewise hard to model. IMO only Rust like traits solves this issue elegantly.

Very cool. It would be interesting to see applications built on top of Veilid in the future.

What are assumptions involved for submitting and retrieving node’s IP address with a given public key to a Veilid network? For instance how does new users discover other Veilid nodes. Are those baked in statically? What happens if public IP addresses of the network change?

Unfortunately the qubit number is not really good parameter to parametrize. Everyone could just copy paste their qubits on the chip today and claim to have the largest quantum computer. Making interactions with low enough error rate is the hardest part.

I really wish there would be a better parameter which would also inform when they become useful for breaking crypto.

I didn't know that QtQuick is GPL. That is a commonly used dependency for QML apps.

I guess I misread the chart. Can you explain what it means for QtQuick to be purple under the GPL/LGPL section?

I have developed/prototyped a voting client with QML/Julia in PeaceFounderClient [1]. Few weeks ago I made bundling setup for it and have published bundles [2]. This may not scale well but I opted for bridging the backend with frontend in top scope with Bridge.qml [3] which on the Julia side is loaded with ‘loadqml’ using ‘QML.jl’ pacakge [4].

[1]: https://github.com/PeaceFounder/PeaceFounderClient/tree/main

[2]: https://github.com/PeaceFounder/PeaceFounderClient/releases

[3]: https://github.com/PeaceFounder/PeaceFounderClient/blob/main...

[4]: https://github.com/PeaceFounder/PeaceFounderClient/blob/cf9d...

I agree. Lack of typing in JavaScript is a hassle.

It is also possible to have a backend implemented in JS in similar way. Though I personally only have used in intial UI prototype which I latter swapped with Julia backend.

Can you elaborate on “recipe for tears”?

Also someone previously mentioned that large chunck of Microsoft investment is in their compute credits. If so Microsoft effectivelly have acquired OpenAI.