The latter starts with entirely leaving out his original cofounder: https://www.wired.com/2014/03/what-is-bitcoin/
A mix between actually interesting and a shameless puff piece.
Interesting experiment(s) by nostr:npub1ej493cmun8y9h3082spg5uvt63jgtewneve526g7e2urca2afrxqm3ndrm.
Now we wait and see what holes people shoot in the analysis. That's science in action, as long as enough people keep trying to find flaws in the analysis, but increasingly fail to so, it increases confidence in the result.
Meanwhile Nostr can experiment in finding a better way. Without having to ask a CEO and shareholders for permission first.
Let's hope Apple and Google remove X when it drops the block feature. Because I'd love to see Musk poor a few billion into fighting the obvious anti-trust issue here.
I also think the feature is naive and too easy to abuse by charlatans, who use it to make their replies a paradise of yes-persons.
That said, muting does not fully solve the problem of harassment in threads. He doesn't give a fuck about that, that's the real reason, even if there are technically valid arguments at play here.
Before Musk and his minions banned me I only used the web app.
Or sues them. Both will be entertaining.
That will probably be:
1) ignored by browser makers as long as it's just France
2) shot down by an EU court
However they'll then try to push it into EU law, which is where it gets a lot more dangerous. So best to stop the French early (this has been historically true aa well :-).
Dit gaat Nassim Taleb leuk vinden...
We should try to avoid a world where being a clauset female is the only practical way to use Nostr. Client-side muting is the only thing that works in a decentralized system. But it could be enhanced with social-graph based reputation management. E.g. if a friend-of-a-friend marks someone as a mysogenist, you wouldn't see their replies. And perhaps more generally clients could filter replies on a post from person B based on their knowdlegde of who B considers hostile. By default that is, e.g. for CSW I would want to turn that feature off. In general it risks amplifying filter bubbles.
If you find this stuff interesting, you should read (some of) the Serious Cryptography book: https://nostarch.com/seriouscrypto
It wouldn't hurt if cppreference.com would be more clear about this. Instead of "It produces high quality unsigned integer random numbers" , it should say "high quality, but not cryptographically secure, ".
https://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine
It doesn't help that it links to a standards document which in its Requirements section mentions:
> "true" non-deterministic random numbers (for cryptography)
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1398.html
Only if you read the document carefully you'll learn why that requirement was pushed to the developer.
I added an addendum to the show notes for the #MilkSad episode, to explain that Mersenne Twister didn't become unsafe at some point: it was never designed to be used in cryptographic applications. But it's fine for its intended purposes (like Monte Carlo simulations).
https://podcast.sprovoost.nl/@nado/episodes/episode-83-the-milk-sad-vulnerability
If you find this stuff interesting, you should read (some of) the Serious Cryptography book: https://nostarch.com/seriouscrypto
I added an addendum to the show notes for the #MilkSad episode, to explain that Mersenne Twister didn't become unsafe at some point: it was never designed to be used in cryptographic applications. But it's fine for its intended purposes (like Monte Carlo simulations).
https://podcast.sprovoost.nl/@nado/episodes/episode-83-the-milk-sad-vulnerability
Wrong example, I meant this one: https://mempool.space/tx/56a76f8a056de85bee7f46b7b05cd62972b34dd6631526ebbac99d76f587a564
From my log:
2023-08-18T09:27:31.644274Z [mempoolrej] 56a76f8a056de85bee7f46b7b05cd62972b34dd6631526ebbac99d76f587a564 from peer=40 was not accepted: non-final
Eventually my node got the transaction anyway, because it was mined.
2023-08-18T09:36:23.506105Z Saw new header hash=00000000000000000002aa586c441bb575a4d9d51c94fa8182f0c44758479fc9 height=803739
2023-08-18T09:36:23.506194Z [net] Requesting block 00000000000000000002aa586c441bb575a4d9d51c94fa8182f0c44758479fc9 from peer=69
2023-08-18T09:36:28.294225Z [net] received block 00000000000000000002aa586c441bb575a4d9d51c94fa8182f0c44758479fc9 peer=69
2023-08-18T09:36:29.247778Z UpdateTip: new best=00000000000000000002aa586c441bb575a4d9d51c94fa8182f0c44758479fc9 height=803739 version=0x2e648000 log2_work=94.366442 tx=880923786 date='2023-08-18T09:36:12Z' progress=1.000000 cache=112.3MiB(840196txo)
(sadly not received as a compact block)
While briefly staring at my mempool, I noticed that some transactions got rejected because their locktime was based on a freshly mined block, which my node hadn't seen yet. Even several minutes later my mempool doesn't have it.
nostr:npub18d4r6wanxkyrdfjdrjqzj2ukua5cas669ew2g5w7lf4a8te7awzqey6lt3 did pick it up, presumably because it saw the block earlier? https://mempool.space/tx/8c235cb0eb540ed75aeebca5d3beeb0c0d968b8590b1ddf31ed87f997e2ea3b8
I wonder if it gets added later as other peers tell me about it again.
Wrong example, I meant this one: https://mempool.space/tx/56a76f8a056de85bee7f46b7b05cd62972b34dd6631526ebbac99d76f587a564
From my log:
2023-08-18T09:27:31.644274Z [mempoolrej] 56a76f8a056de85bee7f46b7b05cd62972b34dd6631526ebbac99d76f587a564 from peer=40 was not accepted: non-final
I think I linked to the wrong example. Though it's a similar phenomena. This one got rejected for being in a too large unconfirmed chain:
2023-08-18T09:27:32.705237Z [net] got inv: wtx 8c235cb0eb540ed75aeebca5d3beeb0c0d968b8590b1ddf31ed87f997e2ea3b8 new peer=50
2023-08-18T09:27:32.706424Z [net] Requesting wtx 8c235cb0eb540ed75aeebca5d3beeb0c0d968b8590b1ddf31ed87f997e2ea3b8 peer=50
2023-08-18T09:27:33.912485Z [mempoolrej] 8c235cb0eb540ed75aeebca5d3beeb0c0d968b8590b1ddf31ed87f997e2ea3b8 from peer=50 was not accepted: too-long-mempool-chain, too many descendants for tx cca29e4a3f560b3414e47feede6de0c2d9cb94af535780479e531f14bd003395 [limit: 25]
The chain was too long from the point of view of my node, because it hadn't seen the confirmations yet.
While briefly staring at my mempool, I noticed that some transactions got rejected because their locktime was based on a freshly mined block, which my node hadn't seen yet. Even several minutes later my mempool doesn't have it.
nostr:npub18d4r6wanxkyrdfjdrjqzj2ukua5cas669ew2g5w7lf4a8te7awzqey6lt3 did pick it up, presumably because it saw the block earlier? https://mempool.space/tx/8c235cb0eb540ed75aeebca5d3beeb0c0d968b8590b1ddf31ed87f997e2ea3b8
I wonder if it gets added later as other peers tell me about it again.
And of course the fact that I don't care about some use case doesn't mean someone else won't put up a fight to defend it.
Anyway that seems mostly academic. The way soft forks work, existing fuctionality doesn't go away.
I would just add that I don't see putting non-money stuff on the blockchain as a protected use case. If some useful new payment feature happens to break it, I don't care. There's a whole spectrum between not protecting a use case and actively destroying it though.