Your obfuscation carries no argumentative weight, as the uncertainty your obfuscation attempts to introduce might as well be used in the reverse: maybe the guy who made the original threat (that was not prosecuted) had a criminal record involving violent crimes whereas Lars' text obviously should be taken in the political, non-violent, activist context that is his modus operandi.
Corruption is defined as "the abuse of entrusted power for private (usually financial) gain". Lars' case falls under the category of conscientious objection, as he's ideologically motivated. Pretty disgusting to frame that as corruption.
That same prime minister supports the warrant-less use of medical records in police work and the ban of encryption through chat control. She wants to prevent the Danish population from having privacy, but demands it herself. Sorry, but that's not the Western way.
Lars is good at exposing the hypocrisy of the Danish government. In a former case he, sent the exact same threatening text to a prosecutor as that prosecutor had received a police report from a third party about, and that the prosecutor refused to pursue. Lars got jail time for that. Rules for thee but not for me.
See-through blockchain's biggest problem might be that their coins are not fungible, as their history affect their current value. A protocol solution to this problem is to make their history opaque.
Bitcoin's conception was immaculate and new blockchain projects can't hope to match that, yet alone beat it. But Bitcoin can be challenged on technical aspect. We identify four properties that Bitcoin is lacking:
- throughput scalability (is being fixed)
- programmability (could be fixed)
- privacy (could be fixed)
- post-quantum security (can't be fixed)
Making a STARK prover fast enough to be feasible requires multiple algorithmical tricks. This article showcases the latest algorithm that was implemented as a part of speeding up Triton VM.
Nice. I helped write the original Python implementation, so thanks for building this. STARK proof generation is definitely a good candidate for GPU acceleration.
Worth noting is that this solution does not constrain the memory value of the last execution trace if the execution trace ends with a `>` or a `<`. Since this value cannot be output, you could argue that that's OK.
Building sound and complete STARKs are really an intricate affair! I have no doubt that we'll eventually get there though!
Unfortunately this can add some overhead to the memory table though. I wonder if there's a better solution than the one proposed here. Not that it matters for Brainfuck too much, as it's a toy language, but it would be very relevant for bigger STARK VMs.
The current US inflation rate is 8.5 %. In Argentina its 55.1 %. Since the founding of the Federal Reserve in 1913, the dollar has lost 97-98 % of its value. How's that trust working out for you?