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.

But the more I live, the less I keep believing in the Hanlon's razor ("Never attribute to malice that which is adequately explained by stupidity"). It is ENTIRELY plausible that these "child mistakes" might be deliberately left in their code to facilitate some automated shadow fund distribution by request in the form of invalid transactions... Am I a conspiracy theorist or are they really THAT stupid?

As a total noob with those blockchains, I find it scary that even such a noob can find such security holes in some services using them within a few days. Yes, it's not a single one anymore.

My kisstron project is now proven to work on OpenBSD, being the second non-browser-based Tron wallet that works here. Here, dependency installation is like this: ``` doas pkg_add autogen autoconf automake libtool py3-cffi export AUTOMAKE_VERSION=1.16 # replace with yours export AUTOCONF_VERSION=2.71 # replace with yours pip install -r requirements.txt ``` The only inconvenience is the warning that urllib3 is giving about not supporting LibreSSL. Doesn't seem to affect the functionality though.

I need something like OCaml, but that doesn't generate such a huge binary when statically linking with musl because it tries to put the entire runtime, even the unused functions, in there. What should I try? Myrddin or something else? #asknostr

Just checked — indeed, the vulnerability I discovered yesterday is not on the particular merchant's side, but on the entire crypto payment provider. Of course I won't tell which provider it is, but I wonder which other shops are using it now...

Interesting how the ToS of many (if not all) VPS and cloud instance services, even the anonymous ones, explicitly prohibit their usage for mining crypto. Guys, I'm paying you for the computing resources, what I do with them should be none of your fucking business, at least as long as I'm not congesting your network or sending out spam. Does anyone know of a VPS service that doesn't put any restrictions on mining? #asknostr

But the main phenomenon is: it's 2024 out there, there is a horde of devs saying they are "into crypto" yet having no slightest clue about how to _properly_ validate the transactions on the blockchain of their choice. This phenomenon is primarily driven by the fact that customer wallets offer too little control over the transactions. The aforementioned devs, who use the same wallets (because the proper ones with fine-grained control usually have too complicated UI), don't even expect atypical scenarios to happen because they think no wallet will let them happen. They also seem to have missed all information security courses, otherwise they would know this: validation always must happen on what theoretically can be sent, not on what usually is sent. Yet they want us to use browser extensions and other inherently insecure bollocks. Good luck...

I was going to post another Tron-related thing I accidentally found but I already predict the reactions like "Told ya, Tron is a shitcoin!" and I don't want to keep explaining why it isn't. I will share this story in one of my weekly phlog entries though. Maybe in the same post as the one about kisstron. You'll like it.

Just did the first transaction on the Tron mainnet using my own CLI wallet written within 2 days: kisstron. 423 SLOC. Public domain. BIP-39 mnemonic and offline transaction support. Wrote it purely for myself but decided to share the knowledge.

README - kisstron - KISS-friendly Tron CLI wallet

A large flock of rooks has arrived to the village. Local magpies are visibly concerned.

On a side note, hosting "censorship-resistant" platform docs on GitHub, the most censorhip-friendly Git hosting out there, is peak stupidity. My path was: GitHub -> GitLab -> SourceHut -> standalone Git node with stagit on a static Web server. Still need to migrate some important stuff out of GitLab though.

Ok, so I found out that tronpy does allow to export transactions to JSON, before or after signing. And it also supports importing such JSONs to broadcast elsewhere. As much as I hate JSON, I think this use case gets a pass from me.

Given: 1) tronpy library, (relatively) lightweight and straightforward to use. 2) Fast Tron testnets like Nileex. 3) Memo field that can optionally be attached to each transaction. Question: blockchain-based forum anyone?

On Hongdian Black Forest Max: got two of them (EF nib), cleaned both, inked one, writes very nicely. The nib assembly is screw-in, not pressed or glued, which is important for my pocket usecases. #fountainpen

Found out that the tronpy library is installable in a Python 3.11 venv in Alpine chroot in rooted Kindle (the one on MT8110, Bellatrix board), just needed to make sure the following packages were installed on the Alpine side before running pip install tronpy: python3-dev libtool autoconf automake musl-dev libffi-dev (note: if you actually decide building tronpy directly on a Bellatrix device in a venv like I did, be ready to wait for about 30 minutes for the build to finish, if you're not using venv, you can also add py3-regex, py3-ctoolz and py3-pycryptodome packages and the process will be quicker) Why? Well... The situation with usable FOSS TRON wallets for desktop/CLI is close to catastrophic. Really ready to begin writing my own one on top on tronpy, starting tomorrow. Just wanted to be confident that I'm going to be able to run it even on my wifi-enabled e-reader if I really need to.

The first time of bloatware appearing in mobile phones is not something that happened in 2010s or late 2000s. It was 1999, and it was called WAP. I still have Nokia 7110 and 8310, the first WAP CSD- and GPRS-enabled Nokias respectively, in a perfectly working condition. WAP was a huge mistake. A separate XML-based markup language (WML) that was "compiled" into some "compressed" binary representation of the same language (WMLC) by carrier-side gateways. And the client side still had to waste the resources for XML-like parsing, and, given the lack of RAM in cellphones at the time, this meant even less content could be displayed on a single page. And the gateway still had to fetch the original WML page via HTTP. A lot of complexity for something that simple. What should they have done instead? Just adopt Gopher. Yes, it still is alive. Gophermaps are TSV (tab-separated value) files, literally the easiest format for machines to understand with no overhead at all (fields are separated with \t, lines are separated with \r\n). The protocol itself is as straightforward as it can be, much less overhead than HTTP. The client has full freedom of choice of how to display every item type, so WAP-like menus wouldn't be a problem anyway. "Standard" Gopher only has 7-type records for search requests, but I guess some custom types could be invented for form filling, or even Gopher+ format could be implemented. It still would be much smaller mess than what they came up with. Needless to say, when phones became capable of displaying plain (X)HTML (that happened around 2003), WAP faded away pretty quickly. Because no one wanted to maintain parallel versions of their websites that generally couldn't be generated from a single source because of those WAP limitations anymore. Still, modern MAUI-based phones (MediaTek MT626x and MT6276), Mocor-based phones (Unisoc SC6531x, SC770x, UMS9117(L)) support basic WML pages, and remaining RDA-based phones (Coolsand/RDA CT8851, Unisoc SC6533G) even can run compiled WMLScripts. WAP formats support also remains to some extent in the Opera Mini browser and the devices that run it, but that's another huge flop to be told about another time.