I think I have an idea for preventing the 'block withholding' attack in Bitcoin, where an individual finds a 'mining share' that is actually a block and they withhold it from the pool operator. The basic idea is to make it such that the individual miner doesn't know if the share is a 'full block'; only the pool operator is able to know. I believe this can be done as a soft fork. The idea is: when a share is found, the operator of the pool - as the only person that knows the secret key for the coinbase output - will sign the (witness) merkle root. A block will be consensus valid only if the first 3 bytes of the signature are all zeroes, 0x000000.... This means that only 1 in each 16 million shares will actually be a full block The signature scheme needs to be deterministic,. i.e. for a given message (merkle root) and private key (the coinbase key), there must be only one signature. That means we can't use Schnorr signatures, but apparently BLS signatures work Upgraded nodes would need to pass this extra signature along with the blocks when they are talking to each other, but skip it when talking to non-upgraded nodes. Miners would need to upgrade, as they need to produce this extra signature Non-upgraded non-mining nodes would continue to operate as usual, i.e. it's a soft fork. The only thing they would notice is a massive decrease in the conventional measure of difficulty. This might be relevant for hashpool, @vnprc , I've been thinking that block withholding becomes too easy if large hashers don't need to defend a reputation of being able to find blocks

Looks like glozow's X account was hacked an hour ago, to promote something involving Solana

This refactor was supposed to be a big job, but OpenCode (Gemini 3 Flash - high) did it one one go in 19 minutes. Even though I've been using AI heavily for about five months, it still sometimes shocks me how good it is I think I'll have to give myself credit for some stuff, I don't want to feel totally useless 😀, so I did have to spend a few messages going back and forth in advance to get it to use the right abstractions View quoted note →

Next step in the Cashu Spilman channel system is to redesign the backend to make it easier to plug in any storage system that you like, e.g. sqlite, nostr, in-memory. I want to wrap up the functionality into easy-to-use high level functions, such as 'validate_payment', in order to make it very easy for service providers to start accepting payments via these Cashu channels. Some of those functions will need efficient ways to reach out to state management systems, but I don't want to hardcode one particular system into this library. The core code will stay in Rust for now, as that can be easily exposed (e.g. via WASM) to other languages. And I'll probably write these "bridges" for TypeScript [for continued use within the Cashutube blossom-server] and Python. So here's an LLM description of what I'll likely work on this evening, although I expect I'll want to convince the LLM to change some of the details of this plan before executing: == LLM description: == View quoted note →

Don't forget that you can learn from LLMs too, not just get them to write code for you. It added a bunch of CSS to my code that I didn't fully understand and got this great answer when I asked it to explain it: === Q: I want to you help me learn a lot more about CSS. can you explain thoroughly and thoughfully what all these do, including the flex and min-width that were there before you made that change: #left-column { flex: 1; min-width: 0; + position: sticky; + top: 0; + align-self: flex-start; + z-index: 100; + background: #1a1a1a; }

"Why does software privacy have such a great sound track?"