Maybe you could have a system that heuristicially detects when an crawler is making the request and then feeds them a modified page, itself generated from an LLM, that injects vulnerabilities and bad code and discussion and such.
With micropayments, the server owner makes 1 million requests times 0.05 cents = ~$500
The status quo with those js PoW pages doesn't really benefit the server owner at all, it's wasted energy.
I mean proof of work is always wasted energy, but I figure it's better to kill two birds with one stone.
CoinHive was one example of this. (I think this is a correct link? https://github.com/cazala/coin-hive). Although I think ideally you would want to have some sort of browser plugin or app that runs on bare metal instead of a proof-of-work in the browser, because RandomX is designed such that it's slow when implemented in JS (https://github.com/tevador/RandomX/blob/master/doc/design.md)
Something like Chaum's blind-signature based ecash, or GNU Taler would be ideal in terms of efficiency, but it's still centralized in distribution. Freenet currently uses something like this.
Another option I was thinking of would be a pretty inflationary (or demurrage) cryptocurrency in which you have some sort of RandomX or other CPU-bound PoW. A web server could act as a mining pool and use mining shares interchangibly with micropayments.
You could do this mining-share method with Monero right now, it's just that you have higher transaction size in Monero and no real analogue to Bitcoin's LN-based microtransactions. Also you would want the cryptocurrency to be more inflationary (or demurrage-based) to promote usage.
Monero's FCMP++ lays some groundwork for payment channels, but it still lacks the nessisary timelocks. Also there was DLSAG which could have enabled payment channels I think, but it's no longer relevant. I also insist that you would need to change the tokenomics to favor greater inflation (maybe you could make coinbase scale linearly with hashrate?), otherwise the miner reward would be economicially insufficient.
Lightning - a fast, instant, bitcoin layer 2 network - is perfectly sufficient for micropayments. Volatility is a no-issue in this case, as you can freely trade the 5 cents in realtime into other assets and minimize holding time of BTC. You will loose the spread, ofc.
1) it requires you to open a lightning channel. So you need some amount of initial investment (which usually means you need a credit card and an account on a bitcoin exchange), not just any computer which is the issue that using mining shares solves. The initial investment is my main grudge, as it is way too much friction for 402 Payment Required applications. Also as bitcoiners like sztorc note, this isn't feasible for most of the world's population due to bitcoin's small block size.
2) It's not private. People are going to be linking these things to their identities on crypto exchanges. So now feds can basicially track everything you do on the internet that way. LN is only private in the sense that not every transaction is broadcast to everyone else on the network, which is a very low bar. Chainalysis is possible with the right connections.
To a lesser extent, 3) Centralization in the lightning routing protocol which contributes to the effect of #2.
1) is not a problem because you can chose a custodial wallet and not deal with anything - just as any bank account is also a custodial wallet. And when you pay anything online with credit card, it sure as hell is also not private or non-custodial.
2) it is at least as private as cash. If you withdraw cash from an ATM, the serial numbers are linked to your account. But you can simply spend that cash and obtain it from people you know and transact with, in which case it is private. So yes, if you acquire lightning from an exchange, it is not private. But those lightning transfers you receive outside from an exchance, are untraceable and private. And where you send/spend them too is always private and untraceable.
I am not opening libertierian and freedom-of-money discussions, it is all about being able to facilitate micropayments over the internet. In contrast to traditional banking and credit cards, lightning serves that purpose quite well because it is decentralized because it is based on bitcoin.
Plug in an EG25-G USB module. It has good driver suppport on linux as this is the same modem that's in the pinephone. About $60 plus the antennas. It also gives you GPS.
I'm actually working on this right now. I made a case for the module + antennas if you want.
EDIT: oops I hadn't read the article yet LOL. But the wisdom about the USB module still applies. There are also adapters for mpcie or m.2 or whatever modules to convert them to USB modules. Also you probably want to have a module or adapter with a sim card tray.
I bought mine off of aliexpress and also bought the LTE antennas. You need a separate antenna for GPS as well.
Lastly, with some of these adapters, the sim card goes in backwards relative to how you normally think it goes in. This had me stuck for a couple hours.
What if the supplier backdoors the secure element? It would be better to just encourage the user to use a high-entropy key, and not bother with the secure element at all.
The secure element rate limiting is integrated in a way that can only add security. It can't reduce the security of key derivation since it's only used to get an extra input for deriving the key. There are various other inputs in addition to the PIN/password too to add various security properties. The most relevant one is the token obtained from the secure element rate limiting system via successful authentication, but there are others.
The secure element comes from the same company making the main processor for both the upcoming Motorola devices (Qualcomm) and Pixels (Google). Why would they put a backdoor in the isolated secure element rather than the CPU? The backdoor argument can be made about any hardware.
A key is derived from the PIN or password and used for multiple purposes by using separate statically keyed hashes. One of those purposes is obtaining a token from the secure element to implement rate limiting and extremely reliable erasure of all the encrypted data for the profile. It's also passed alongside the obtained token into the final key derivation process. Why would you want to remove the secure element integration? That would mean losing the rate limiting with no benefit and solely relying on erasing key derivation material stored on the SSD for wiping data. That would still work due to hardware support for it but the SSD isn't nearly as reliable as the secure element and can be copied at a hardware level before trying any PIN/password.
We want more secure element features including duress PIN/password support as part of the rate limiting.
reply