Ok, so the "evolution" of IT mainstream has come from exclusion of those who don't run Faildows to the exclusion of those who don't run Mac as well, then of those who don't run Linux either, and then of those who just don't want to buy new hardware because their twenty-year-old one still works perfectly. Running Arch, CRUX or even Alpine Linux is no longer a statement. Running OpenBSD or Haiku is.

2 minutes 56 seconds to do a single ECDSA verification using busybox bc. I'm not complaining, just demonstrating that elliptic curve cryptography is *slow*. We don't notice its sluggishness because someone already implemented it in the lowest-level languages available for the platform. We take the underlying complexity for granted and don't even think of what's going on under the hood. By the way, the fact that OpenBSD's bc does this in under 4 seconds shows that it could be done differently. I wish 95% of programmers were forced to return to CPUs like 6502 or Z80, so they could learn to think in terms of not wasting computational resources.

Successfully passed first two test vectors on ECDSA signing and verification using secp256k1 curve implemented in pure POSIX bc and driven by POSIX sh. Yes, it is quite slow even on my nettop and even with GNU bc in the POSIX mode (bc -s): every sign/verify operation takes up to 40 seconds. I thought to maybe create an alternative path to include "native" non-POSIX modexp on the platforms that allow it, but I cannot find any explicit modexp in any bc manual except on FreeBSD. An alternative path, of course, would be using OpenBSD's bc to compile this library into dc. And the interesting part is, on OpenBSD's bc, these operations take 3 or 4 seconds at most... even on my slow ARM64 VPS.

bc is surprisingly easy to deal with, even with all the POSIX limitations like one lowercase letter variable/function identifiers and strictly uppercase hex applied to everything if you have set the ibase=16 before. The only *real* limitation is inability to return multiple values from functions, but come on, you've got arbitrary precision, nothing prevents you from just multiplying the first point coordinate by fucking 2^256 (or 2^100 in ibase=16) and then adding the second one and returning both as a single number...

Ok, dug up my minimal ECC (ECDSA + ECIES) implementation in newer JS (the one with BigInt type support) written 1.5 years ago. Custom modexp implementation included. Now thinking of how to port it to POSIX bc (because bigints really are bc's/dc's specialization). The SHA256 requirement can be temporarily dropped for now, as I really can't think of any embedded system that has bc and doesn't have sha256sum. POSIX AWK can be a glue language for all this. Just need to find some time to start rolling it.

No, I'm serious. Which currency is the easiest to implement a wallet from scratch? According to this list (https://www.susanka.eu/coins-crypto/), only one of the top-20 cryptos, IOTA, uses Winternitz OTS (which is really simple and elegant) and thus only requires SHA-256 (+Keccak-384 for Kerl) to be implemented. All others use ECC. Even Nano is ed25519-based (with Blake2b). So, for any crypto other than IOTA, looks like the minimum set is: secp256k1 or ed25519, SHA-256, SHA-512 and/or RIPEMD-160 and/or Keccak-256. And base58check for address encoding where it's applicable, of course. See where the problem is? What would be the chances to put such a wallet onto a, say, Siemens CX75, Samsung B312E or another J2ME-enabled phone? As I said before, if a protocol cannot run on such hardware then it's flawed by design.

I wonder how hard would it be to implement all required crypto primitives with POSIX AWK and all networking with nc, optionally with openssl s_client or its substitutes like busybox ssl_client. Imagine a system where you have nothing, not even a working compiler, only a Linux kernel and busybox/toybox binary (so you do have e.g. vi, awk, bc/dc and non-SSL wget and nc). Yet you need to have a crypto wallet. Which currency would you choose to implement it from scratch using only the tools provided within busybox/toybox?

Interesting that busybox dc contains non-POSIX modexp operator | while OpenBSD's dc doesn't. Meanwhile, dc has been excluded from POSIX in favor of bc. So, my top-5 of current POSIX standards is:

awk

ed

bc

od

date

When you send an OUT_OF_ENERGY token transaction to an inactivated Tron address:

No kidding, now I really think of setting up a hook to pack tgz snapshots on each push to git.luxferre.top and offering the recent snapshot downloads somewhere on a new subdomain for those who might end up in the same situation.

Almost 3 hours to build Git and one of its critical dependencies from ports on an ARM64 VPS with #OpenBSD (because the package dependencies are still broken in 7.5-beta). The dependencies that could be installed from packages pulled the entire XML parser stack and two text-mode Web browsers I don't need there (lynx and w3m). This is an example of FUBAR at its finest. I think the practice to distribute source code in .tar.gz (or, even better, .shar.gz) first must return, and for pretty good reasons. People must not depend on a bloated VCS that takes 3 hours to build.

Which cryptocurrency requires the least amount of SLOC to implement a fully functional (non-custodial) wallet, including all the required cryptographic primitives, marshalling and network protocol calls?

Whatever happened to that famous 3-line RSA implementation in Perl? I mean, why is modern asymmetric cryptography so damn huge and inaccessible?

export-a-crypto-system sig

What a good time to install #OpenBSD -current and break gitwrapper, lol:

OpenBSD -current moves to 7.5-beta

I won't revert to 7.4 though. Life exists without git.

OK, those VPS providers that do offer OpenBSD and full VNC control over its manual setup are allowed to not have Alpine, I guess. But in case you need Docker, Alpine would be much easier for both human and silicon brains. Because Docker inside Alpine inside VMD inside OpenBSD inside KVM... Not sure about the performance of all that.

Snowden is gonna be replaced with Rainden soon, and then with Sunden. But remember that in 10 months, Snowden returns. Always.

Any working #Monero setup for #OpenBSD? Despite numerous claims of people doing this, I haven't been able to build either the official or the Feather wallet on OpenBSD 7.4-current.