Solid argument. Get back to what Bitcoin is. I like it.

One point of correction, the people with the most money aren't the privacy nuts, it's the middlemen wanting their cut.

This is false: "Then, Tim Bouma made a major breakthrough." There's an obvious flaw (with, I think, an easy fix) in Tim's proposal. You know this already. It will allow anybody who offers SP-scanning services the ability to steal the funds and the nsec and the identity Everyone who really understands SP knows how to derive an SP from a Nostr key pair (and how to do it in a way that's safer than Tim's). Those experts don't need Tim's sloppy proposal and sloppy code. It didn't add anything to the discussion The problem with you and Tim isn't that you make mistakes. We all do, and I've made cryptographic mistakes. It's that you double down after your mistakes are pointed out. Tim (and you) could have humbly said "I withdraw my original proposal, as it's crap, and I'd like to learn how to fix it". Many of us would have loved to help

and this: "Tim and hzrd deserve a lot of credit for their perserverance here. I don't think people appreciate the gravity of this discovery yet." If you wrote this a few days ago, I would forgive this as just a normal human mistake. It's natural to get very excited about these topics and about *apparent* discoveries. But you know now that Tim's proposal is fatally flawed, and that it doesn't do any SP-derivation that isn't already obvious to a relevant expert (I forget the details of hzrd's proposal: it may be (much) better than Tim's flawed proposal)

There exists no solution to derive an sp address from an npub, as any computation that can be done by a public party can also be undone by the scanning server. hzrd's proposal, and in general the only class of proposals that could work, is using the nsec and hashing it to get a "root key" to derive different keys from. This can't be done from an npub, only from the nsec, and in this case the nsec is used as a seed.

And by hzrd's proposal, I mean a script they published 4d ago. NIP-SP has the same flaw.

It's one address where you trade the scanning key for being able to send to anyone. An intentional tradeoff. You're an idiot.

So don't use a scanning server. It's that's simple.

Then, what is the point of this protocol? If you have to download millions of transactions for each user just to find possible matches, for the sole purpose of avoiding publishing one Payment Target event, what's the point? Protocols with major footguns will end up being misused by accident. You can't fix flaws by adding exemptions and warnings for every flaw found.

What's the purpose of silent payments just to expose your entire transaction history to a server? You can do the scan locally. We already have wallets that do it this way. It's the better design.

You are exposing your nsec to a component with much more moving parts without good reason.

??? Do the scan locally, I'm confused vwhy you're confused. Never send the scan key anywhere

These people don't see a problem with storing secret keys on their clipboard.

Um akshually we can do Bitcoin transactions in Ditto Extension and in Amber now

Waiting for replies

Onchain zaps feel inevitable. Turns out people like sending Bitcoin without opening seventeen channels, sacrificing a goat to liquidity routing, and praying to the LN gods.

I'm not a first grader, I sometimes do strange stuff, but to even get anywhere near the LN, one needs a box full of WTFs, FFSs and ohcomeons

Great post. Brilliant news that Amethyst now implements this. On-chain payments was always going to be phase 1. A bit of trial-and-error ahead, but it opens countless doors. Next learn about tweaking keys. Add one to your privkey and then add one point to the pubkey and you have a whole new set of keys.

I still remember your original pitch. We just needed AI to fully implement it.

Did you send Bitcoin to Jack's taproot address in 2023?