Subnostr

optout

b190175cef407c593f17c155480eda1a2ee7f6c84378eef0e97353f87ee59300

freedom tech ⚡ freedom money

I grew up in a trailer park and was basically taught to cuss from walking age.

I eventually put that away for most contexts in my professional world, but I let it out mainly just on Nostr or in front of my husband lol.

You can take the girl out of the trailer park, but you can't take the trailer park out of the girl.

If you don't like cuss words, I politely recommend that you go fuck yourself. But then, quite honestly, have a lovely evening. ;)

People who can't handle cuss words, even in certain contexts like Nostr, amuse me. It's basically an advertisement that they're fucking soft and out of touch. I use those words even more now to make a point.

It's inappropriate when someone can't rein in cuss words in a professional context. But I would argue that it's similarly inappropriate when an adult is too weak to hear cuss words in an unprofessional context. If they can't handle that, there's a lot of more real stuff that they won't be able to handle either.

🙏 ❤️

nostr:npub1a2cww4kn9wqte4ry70vyfwqyqvpswksna27rtxd8vty6c74era8sdcw83a is carved out of hard wood (as they say over here)

"You can take the girl out of the trailer park, but you can't take the trailer park out of the girl."

nostr:note183ghmqxmrrly4c6r4mwdfl34y07l9er0k6shqkv4z0w2ltt20xjqzrwadd

Fiat coin in, lightning out

Cool factor high

nostr:note1qv2mpkys8f2yee0j4n52herjhjlgt4g5lttp9qhh883ygggg9mgspvgg9t

Ldk-node is super convenient. You can put together a fully fledged LDK node app with just a few lines of code.

My new sample app is here:

https://github.com/optout21/ldk-node-sample

Great list of KYC-free service here:

https://primal.net/p/npub188x98j0r7l2fszeph6j7hj99h8xl07n989pskk5zd69d2fcksetq5mgcqf

https://kycnot.me/

Opt out the big tech!

Frost has arrived!

I mean the real one, not the schnorr threshold stuff :P

That looks like exactly what I described, no?

The trick is which peers are selected. Do you preselect them before losing your key?

Select a number of peers when initiating recovery, but only restricted to contacts in your follow list.

agreed.

I think we can leverage all these together.

to me the fact that facebook accommodates for social recovery within the paradigm of them actually owning your account, is very telling as to how acceptable it is as a flow and how robust it can be at not getting your account compromised

regardless, I think the pregeneration/HD key would be tremendously valuable as an addition to the alternatives you listed (with which I agree with).

If we were to roll this scheme now, allowing people to migrate pubkeys, I would imagine a vast number of existing users would leverage it (it's kinda OP_VAULT-y in that way)

Social account recovery can work more-or-less reliably, if peers contact the user in some means _other_ than Nostr, to verify that the identity of the user. I think the protocol should enforce this someohow, otherwise the sceme is easy to trick (peers will just press on the green button wanting to help, without real check).

The flow I imagine:

- User realizes that he lost his key, or someone else is posting shit in his name (key compromise), or potential key compromise (not yet misused)

- User initializes Emergency Recovery in a supporting client. A new identity is created.

- User identifies a few trusted nostr user peers who can verify his identity and have other real-life non-nostr means of contacting the user

- Posts a event about the key rotation, with the list of the peers, and a min. threshold.

- Tagged peers should:

- contact the user through some non-nostr means, make sure it is indeed the real person

- generate a unique secret code (details tbd, e.g. by signing the event ID of the rotation event)

- if not in doubt about the user, send the secret code to him through non-nostr channel

- The user, once collecting enough 'ack' codes, posts an event closing the key rotation.

Any client can verify the integrity: that it is posted by the same account, and that each ack indeed comes from the mentioned peer (verify cryptographically), and the number is sufficient.

A malicious attacker can misuse a scheme to steal an account, if he can convience a few users that he is the impersonated user. To alleviate this, the real user can launch a similar counter recovery process, which takes over provided that it is backed by _more_ peers. This way the real user can win as long as more peers attest this.

This scheme is basically what fiatjaf has described in NIP37, with the enhancment to capture the proof that peers have contacted the user. What do you think nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 ?

weaker than what? what alternative are you contemplating?

I just have the feeling the pregeneration/msterkey/HD-based schemes will never catch on widely even if implemented.

Though if nsecbunker-style separate key storage catches on (even only for power users), that might be a good start to 'deploy' such schemes.

The social network based scheme is rather interesting, but has other challenges.

One of the big debates is whether the halving is the key driver of bitcoin price action or whether it is macro forces like liquidity.

Supply halvings:

Global liquidity:

Of course, I think both are important. Supply halvings and the HODL wave represent the supply side and how many coins are available or tightly held. Liquidity is the main driver of new, external demand, and it makes sense that bitcoin's price is highly correlated with the global money supply. And then of course there are other variables as well, including overall UX/accessibility of the network for more and more types of capital to easily come in and to *want* to come in.

It's a mistake to assume for sure that any one variable drives markets, like the universe owes you a bull market just because the halving happens. Although like prior times, my assumption is that we'll have another positive liquidity cycle after the halving, and so the debate will likely live on for another epoch.

IF there is a correlation between liquidity peaks and halvings, the question is whether there could be a causal relationship, and if so, in which direction.

Liquidity affecting halving is not possible, as the halving schedule was effectively set out with the initial bitcoin code (2010).

A causal relationship in the other direction would be surreal and mind-blowing...

The most likely is just coincidence.

Yeah, agreed in all those points. The alternative I proposed in the other note doesn't require the subsequent pubkeys being children of the same master pubkey, just that the next-in-line pubkey is disclosed upfront, which would make it work for existing, non-HD, pubkeys.

I think the details of key relation doesn't really matter, be it HD-derived from a master key, be it derived in a chain from each other, or just a set of predefined keys, they all have in common:

- you have to create some state upfront, with secret and public part

- you have to safeguard the secret part separately from your 'day-to'day' nsec

These two points make pregenerated/HD schemes weaker.

good morning, elon has turned twitter into a psyop machine, opt out, use nostr only 🫡

https://m.primal.net/HNfT.mp4

Fucked up incentives. We're approaching fast the 'There is no truth' state.

nostr:note1hs2kd3ggmacpx2uz8wdk92egqhl2nypq2kd3s3zld3jufq2sexus6agyqs

what if we just start with kind:1521 with opentimestampped events; this seems like such a trivial get and doesn't open the door of crypto/HD bikeshedding.

Regardless, if we do HD keys we'd still need to do kind:1521 stuff as described in https://github.com/nostr-protocol/nips/blob/key-invalidation-and-migration/37.md

what do you think nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s ?

Pregenrated/Masterkey/HD schemes are not good for several reasons:

- Cannot be used for keys already in use

- Can be used for newly created profiles, but only if created with a supporting client

- If two-level key protection is not done by the user/clients (ie. master key is in client), there is a chance for the master key being compromised, for which case the scheme is ineffective

- Basically works only if the user considers the key compromise risk explicitly upfront, which is not the case for most users.

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 's proposed NIP41 scheme is a clever scheme to ease proving the relationship between subsequent keys, but still has the above issues (pr #158, since abandoned).

what if we just start with kind:1521 with opentimestampped events; this seems like such a trivial get and doesn't open the door of crypto/HD bikeshedding.

Regardless, if we do HD keys we'd still need to do kind:1521 stuff as described in https://github.com/nostr-protocol/nips/blob/key-invalidation-and-migration/37.md

what do you think nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s ?

Some fresh ideas are always welcome for key rotation!

Any scheme has to handle well these cases:

1. A malicious attacker quickly rotating to a new key, which the original victim cannot rotate

2. No key theft occurs, but a user just maliciously rotates away the key of an unrelated, victim user.

For Simple key deletion, 1. is ok as it makes no sense for an attacker to use. To protect against 2., the event has to be signed by the corresponding private key (if this is not enforced, anyone can delete any key; the consequence is that it is not possible to use this in case of lost key).

The Social Key Migration sounds interesting. Though an attacker could be successful in convincing enough contacts to rotate to a new key controlled by them, some contacts would benevolently and unsuspectingly help.

what if we just start with kind:1521 with opentimestampped events; this seems like such a trivial get and doesn't open the door of crypto/HD bikeshedding.

Regardless, if we do HD keys we'd still need to do kind:1521 stuff as described in https://github.com/nostr-protocol/nips/blob/key-invalidation-and-migration/37.md

what do you think nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s ?

How would kind:1521 in itself be helpful?

Social key recovering is very interesting idea, but tricky.

let's get bolt12 into ldk lightning-fast!

One fiat tell for me is when a person's desire to not offend is the primary concern for their speech.

This made me introspect...

Miners either have access to dirt-cheap energy and mining rigs, or they are betting big on the increase of Bitcoin value

Let's focus on the present, while also keeping an eye on the future

Load More