oleganza

Maybe that was true in 2017, but today borrow checker and compiler in general has covered so much of the Rust design space that the "correct programs" it rejects are more like rejecting Duff's Device kind of code. You are more likely to find yourself implementing low-level data structure or device interface where you need raw pointers tightly localized in the unsafe{} scope.

Do people realize that Keccak replaces a lot of complexity and offers powerful composable primitive already? Instead of saying "blake is faster, but sha3 is standard", pick SHAKE-128 and build everything with it: hash, MAC, symmetric encryption, fiat-shamir transcripts etc.

As a wise programmer once said: "Lisps are created by those who are lazy to write proper parsers"

Homoiconicity does not mean your syntax should be backwards. Look at Io language: it is basically a Lisp, but it has parens in the familiar places.

Same with Forth: it is a small and powerful language, but it's good for implementing low-level stuff. You will quickly run into desire to have normal(language(with, familiar, syntax)) for writing non-trivial programs.

Certificates just add more keys to worry about. The beauty of SSH is that it does not add hugely trusted parties in the name of convenience, while the UX of TOFU (trust on first use) is pretty decent.

The real solution to break out of these UX/security tradeoffs is to put domain names on a blockchain: then you can simply rotate the key in your DNS record, while the blockchain model is such that you need to compromise many parties, instead of "one out of many parties", as with CAs.

Tracking Bitcoin chain for DNS updates is lightweight enough that it can be built into OS alongside other modern components such as secure enclave, TCP/IP stack and WiFi/BT/5G radios.

That was a new spin to the explanation that I didn't think of before.

Strongly disagree.

I am the person who hates C/C++ and likes languages like Ruby. I like Rust specifically for the reason that I don't have to learn C++ like "grown ups" and can write my crypto libraries in something much more ergonomic.

When I started writing in Rust, it was 2018 and there was old borrow checker (NLL was experimental) and error messages were much more annoying than today. And still, that was nice language that is easy to write and read once you understand a couple of basic rules.

Here are the rules that you need to learn and always keep in mind, even if Rust had a more verbose syntax. And I bet many people struggling with Rust simply were not lucky enough to have those rules explained to them.

Rule 1. By default, in Rust things are "owned" and "moved", all the time. When you do `x = y`, you literally move "y" to "x". In other popular languages you might expect automatic copying or automatic referencing, but in Rust you get an unusual "move" semantics.

This rule applies universally to all things: be it simple numbers or structs, or references, or weird Rc<T> things or whatever. Once you move "x" to another location, you cannot use it any longer from the old location.

Rule 2. As an optimization, some simple types are marked "Copy" which means that you get a cheap implicit copy whenever you want to continue to use moved value. This applies mostly to numbers and fixed-sized types. This liberates you from explicitly calling ".clone()" on stupid integers.

Rule 3. There are references, mutable and immutable, that let you avoid moving value when you don't need to. At any point of time, each value may have N immutable references or 1 mutable one.

There are lexical references (most commonly used): & and &mut, for these the rule 3 is statically checked at compile-time. And there are runtime counterparts that implement rule 3 in runtime: Cell/RefCell.

So when you design an API or use an API, you should really think about ownership of the values that you pass in according to these 3 rules. You may have these questions and use the rules above to answer them.

- Should that API "consume" (get the value "moved into") that value, or should it have read-only or mutable access to it?

- What part of code (which other value) actually owns the value and is responsible for cleaning it up?

- Is that a dumb value that can be Copy-ied explicitly, or is there non-trivial copying cost that requires explicit references or clones for it?

- What does it mean to say `y = &x`? Per rule 1 we move reference "&x" to "y", but since it's a non-mutable reference, we can have a lot of them, so it implements Copy and &x can be used again per rule 2.

No it is not. The whole point of GC is to collect cycles and not think about ownership, while Swift and Rust require you to think about ownership.

In Rust you do so via borrow checker or explicit Rc/Weak wrappers. In Swift you do that via additional weak annotations (strong being the implicit default).

Ristretto is a restricted form of Decaf, that is, specific to curve25519 and deals with a sign choice, while Decaf is generic for all cofactor-4 Edwards curves.

In other words, the joke around coffee takes a 90º turn with Ristretto because our first application was Bulletproofs where you need (among other things) a lot of orthogonal generator points.

Math is about precision, so it's generally not a good idea to have something become "more 0" than actually needed. Especially in cryptography.

So here's my advice. If you multiplied too much by zero, you can make it less 0 by dividing a few times by zero. Then maths would be closer to the precise 0 that you were looking for in the first place.

Ristretto is not a curve, it's a group.

Curve25519 is a _curve_ that implements a non-prime order _group_. Ristretto255 is a prime-order _group_ that uses Curve25519 as an underlying _curve_.

In other words, Ristretto is a pair of encode/decode functions that map points on _curve25519_ to _ristretto group elements_ and vice versa. It's called "ristretto" because it's a restricted (specific to curve25519) version of Mike Hamburg's Decaf format that "reduces amount of coffee/cofactor by 4" for Edwards curves.

What is being meant (i presume) is that even if you are a developer of those repos, do not edit them within the host repo. Work on them separately, as if you were an independent developer, and then bump their revision as a submodule - the same you do with bumping a dependency version in your Makefile/package.json etc.

This is not a problem with splice per se, this is N+1 problem with treating network as "file socket" per Unix classic idea "everything is a file". It is crazy to consider that writing to a TCP socket over wifi with 1001 reasons for failure is similar to writing to the local memory or hard drive.

Unix began when "networked computers" were sitting in one local network wired in a stable manner with patchcords. Then, latency of communication over the wires was no much different from writing to a local magnetic tape.

Today those latencies diverged dramatically. Your machines talk over radio, with multiple hops between cities and different providers, while local storage pushes terabytes in seconds. Trying to "splice" those two for latency gains is kinda crazy. And so are networked filesystems.

Git / Dropbox are much better approaches: you have your stuff on both ends and sync up content explicitly, without trying to provide interactive abstraction of having data locally while it actually isn't.

OTOH, was there really a time when humans were not enslaving each other in any form? I don't mean in a wide marxist term like "wage slave", but more specific kinds of bonding and control. Liberal changes in Europe in end of 18th century / beginning of 19th coincided with imported slavery from Africa and new colonies. That is freer factory worker would gain their productivity and better relative freedom while producing added value to raw materials produced by serfs elsewhere.

In 20th century you either had direct serfdom in some countries like Russia, while countries like US owned slaves indirectly by setting up large-scale production in 3rd world countries and controlling their governments.

Today we could probably breakdown the supply chain so that the lower you go by the ladder of "added value complexity", the more interchangeable and less free the people are. On the top of such chain there are managers, IT people, accountants and various service workers for the above who enjoy freedom while the bottom half of the supply chain is much more prosaic and constrained.

The point of the OP was that Dalek library provides API to Ristretto (https://ristretto.group) which is a proper mathematical prime order group, unlike stock Ed25519 API that exposes cofactors and caused famous issues in Monero.

HTTP/2 is more like a transport envelope around HTTP/1, the goal of http/2 was to optimize transmission and avoid breaking http/1 semantics for servers and clients.

Bitcoin is quite literally a religion. It has dogmas ("not your keys, not your coins"), traditional values ("21 mil"), a prophet (satoshi), celebrated dates (Jan 3).

On the serious side, Bitcoin is all about "let's all agree this is money". This means it's a useful tool only after you play the social game. Technology does not matter if people don't get to a consensus on it, but when they do (and they seem to continuously re-enforce this consensus over years), it works better and better.

Yes, and we are all going to die.

Barcelona’s blocks turn out to be not so cute.

Traversing multiple blocks straight requires diagonal zig-zags eating 10% of time and you could easily lose orientation, especially if you jump into a shop on the corner. Also it’s simply annoying to see your straight path ahead and having to wave around it and then wait on a traffic light.

I learned Rust because I need to write low-level high-performance stuff and I don't want to spend time learning how to do it correctly in C++. Rust compiler automates many chores for me, just like any computer technology is supposed to.

(Not to pick on your particular comment, but to highlight a broader issue.)

I feel like convenient shortcuts are becoming hugely inconvenient when a system has hundreds of them. The unlimited amount of unix non-orthogonal options made "for convenience" cannot scale mentally.

>In fact, you would not have to implement any function; you’re just write its name, and the compiler would implement it for you.

Isn't this equivalent to placing the function code into its name, in other words, inlining the function? Looks cute for 2-bit programs, but I doubt it scales for 100-bit ones.

We wrote about the same idea in 2018 when implementing multi-party computation protocol in Rust: https://medium.com/@cathieyun/bulletproof-multi-party-comput...

The key idea is to make cryptographically-incorrect usage of the API impossible to compile because we provide the library, but you put networking and your app logic around it.

Specifically, the protocol fails if you allow a counter-party to retry interaction from some intermediate state instead of starting over. Move semantics in Rust allow us to make sure you won't be able to misuse our library in your app.

I understand and even share a little bit of your sentiment, but I'm tired of stretched "X is now not what X was supposed to be".

Strictly speaking, the Internet was supposed to help some servers survive and continue working together despite some others being destroyed by a nuke. That is more-or-less the case today: we see how people use VPNs to route around censorship. Whether you were supposed to stream TikTok videos directly from the phones of their authors or through a centralized data hose - i'm not sure that was ever the grand idea.

Also "decentralized" and "monetize" don't go well together because innovation is stimulated by profit margins and rent-free decentralized solutions by definition have those margins equal to zero (otherwise the solution is not decentralized enough).

You are right, that's not a technical problem and Bitcoin is not a technical solution either — that's a social game of "let's make ourselves some new money without built-in constraints".

Then you would need to add some constraints over it for security, but the key difference would be that it's an open market: you can invent one solution, I can invent another and people will be free to choose between them or nothing at all.

When your money comes with some regulatory framework built-in, there is no much room for any choices in that respect and more temptation for all kinds of bureaucrats to abuse their power.

I don't get it. The landing page promises finesse and then the very first screenshot displays horror typography and UI a-la linux 1998.

https://ravynos.com/images/airyx_0.3_installer_confirm.png

That's a false dichotomy. Anyone would choose someone they trust most out of other need-to-trust counterparties. If there was an alternative to not use any unnecessary counterparty at all - that would be even better. E.g. if you transfer Bitcoin from country A to country B you know for sure that it will arrive without any intermediate bank inserting their opinion in the process and causing surprising delays.

You understand that "taxes you owe" are defined as an optimization function (Laffer curve), not some kind of moral imperative? By the very definition of the process you cannot possibly "owe" these taxes.

I like the sound of "this time it's different" from the bitcoin doomsayers.

LOL, but no.

What they probably mean is that they have a transaction that consumes $1000000 on their address and creates two outputs: $100 withdrawal for client A, and $999900 on a "change" output. Later withdrawals have to link to that change output (bitcoin is a directed acyclic graph of inputs-outputs). If that transaction is not confirmed, then later txs also cannot be confirmed and backlog grows.

Also bitcoin != crypto, those are not even subset/superset for the most part.

Bitcoin solves one single problem of "digital cash" with the most robust and boring mechanism (known to mankind so far).

While the "cryptos" aim at satisfying demand for all sorts of p2p apps and moneymaking schemes that can be funded with the digital cash to avoid getting regulated out of existence.