Use cash, while you can!
Use cash instead of electronic methods (where Bitcoin payment is not available).
Good old, proven, tangible, more-difficult-to-trace, smelly banknotes and coins.
CDBCs will ultimately kill cash.
I'd like to be considered for bounty 😎
https://github.com/catenocrypt/nip41-proto0
It's quite complete, but I can continue working on it
There is a Nostr NIP proposal for key invalidation, using a chain of pre-generated keys, so a key can be rotated safely to another one (cannot be faked)
https://github.com/nostr-protocol/nips/pull/158
While working on a proto implementation, I got an idea how the crypto part of it could be somewhat simplified by using only BIP32-style key derivation. Stay tuned :)
I suspect an issue with the scheme in the NIP:
key addition is performed on the secret key at generation, but at verification on the public key. The two just don't add up.
I've left a review comment on the Nip-41 PR.
https://github.com/nostr-protocol/nips/pull/158#pullrequestreview-1364047017
This has been sorted out; for public keys its not scalar, but point addition
Work-in-progress:
I suspect an issue with the scheme in the NIP:
key addition is performed on the secret key at generation, but at verification on the public key. The two just don't add up.
I've left a review comment on the Nip-41 PR.
https://github.com/nostr-protocol/nips/pull/158#pullrequestreview-1364047017
I've learnt that it's different level to be able to install an app on Droid vs. being in the official F-Droid repo...
On-chain: definetely self-custodial, Lightning: either way, I'm still unsure what's best to recommend to a new uset, I'm leaning towards custodial due to UX issues.
What's a good source for Nostr stats?
No. of pubkeys, events, relays, etc.
Which Bitcoin/Lightning wallet on F-DROID to recommend to a first-user?
I had a look and was a bit disappointed by the selection (or lack of). The only familiar name I saw is Simple Bitcoin Wallet (SBW), but AFAIK it is no longer maintained (for 1+ yr).
With the simplicity of Nostr protocol, and the good library support, writing a simple crawler from scratch is so easy! Coding pleasure.
Where are you, next block???
BTC Azores '22 was a waste of time, absolute boring people on a cringe location, but I FOMO, I bought the ticket (with 4x overpaid fee not to miss it)
it may interests you #[2] #[3] #[4]
Haven't planned that, I had the impression Nip-41 spec is still fluid, but I may consider it! It is a quite interesting idea!
I'm also interested in ideas how to bring revocation into Nip-26 (e.g. https://github.com/nostr-protocol/nips/issues/123)
Nip-26 and 46 ate different approaches for the same basic problem: posting without secret key, but they are quite different.
One nice thing though is combining the teo for creating the delegation: connect with your signer app, 2nd client asks for delegation, in 1st app you set terms (expiry) and approve, and suddenly your 2nd app has delegation for a period!
Using this with short periods is convenient, you need your keys only once, and you risk only a short period (in case 2nd ID gets compromised).
I plan do implement this flow next in Keystr.
here's a demo using https://nip26.lol to sign and publish an event with a NIP-26 delegation token.
What is NIP-26?
NIP-26 enables signing events with one set of keys on behalf of a different set of keys, under certain restrictions.
If you want to test it: build and use my fork of #[0]'s nos2x or my fork of #[1]
Nos2x:
https://github.com/pablof7z/nos2x#develop
Getalby:
https://github.com/pablof7z/lightning-browser-extension/tree/feature/nostr-nip-26
Kudos! Nice to see devs working on Nip-26, I think delegations will be very handy in the future!
Self-shill: I'm working on Keystr, added delegation *and* Signer support.
Nostr Signer demo video, with my KEYSTR app!