sam / HODLMES 🍊 is on Nostr

I am me.

Last Notes

2023-07-02 18:20:18

- reply

For notes, I mean.

2023-07-02 18:19:40

- reply

When we’ll we get zaps back on iOS?

2023-02-08 03:49:43

- reply

I like DLCs a lot. But I don’t see how they can stand in place of covenants. What is far away for BIP119?

2023-02-06 16:07:42

- reply

This one I have to disagree with. I’ve mentioned this several times because I really want to get at the truth to the claim that it isn’t Turing complete. I’ve done my own thinking on the matter and concluded that it must be Turing complete. I think the reason for the debate is a matter of nitpicking. I know bitcoin script is not Turing complete because it doesn’t have loops nor recursion of any kind. However, across multiple transactions, one can achieve recursion on a script! That’s what makes Bitcoin Turing complete; it’s not just the script. I find this aspect fascinating.
I was excited for BIP119 because it would introduce covenants which are key to achieving this recursion. Though, the only difference with being able to do recursion on BTC is that processing time would be take time because of the limited block size. The program could live in the mempool for a considerable amount of time.
Anyway, that’s what I understand. If you have some insights to share, I’m all ears.

2023-02-06 00:57:04

- reply

"It seems like $BSV is the original design of Bitcoin." is not the same as saying that "BSV is the original design". Where you misunderstand is that I was saying "it seems" and that is merely an observation of mine, not an assertion that BSV is in fact the "original design". I certainly isn't the original design. Also, what do you think I mean by "original design"? There is nuance to this that is difficult to discuss over notes. I'm happy to try to discuss it.
However, I'm more interested in what you think I got wrong. Please school me because I assume you're a well intentioned individual who wishes to correct and educate others.

2023-02-06 00:14:50

- reply

I’m not a BSVer. I am me. I did talk about BSV and compared it’s design to
the original design and implementation. I don’t pick side for the sake of being tribal, because I am just me (no labels).

2023-02-05 23:08:18

- reply

Nope

2023-02-01 00:58:26

lnbc433165200p1p3anwfxpp5rsqrzvvcheys52hlhrhvt2xk4pm9c9cyzfvyvljjgxan20as5w0sdq6235kx6mvv5sx67fqwp5kx6mvv5cqpjsp55eclaw6w3cyzfpczvhpgpw7jdge7wmy8ew6q2ys6g88qj5v96f7q9q7sqqqqqqqqqqqqqqqqqqqsqqqqqysgqmqz9gxqyjw5qrzjqwryaup9lh50kkranzgcdnn2fgvx390wgj5jd07rwr3vxeje0glcllaqfy6thujwl5qqqqlgqqqqqeqqjq5edq2a94avvxrt87tqzfhhn0f4yp6gu98hs8jcy30pjd0a99l09rg8u3ddxjtwzq6rhezxxq9udchrn5g2h6zj5veygh30hngkvkl5cq2aw8vr

2023-01-09 04:36:04

- reply

Thanks for the reply.
I know it's young, and I'm only interested in being involved in some discussion/development.
I understand read access doesn't risk the user's profile. But my point is about securing a user's account when using a client with write access. This is important, and my suggestion is just one idea. I'm interested in what has already been discussed so far.

2023-01-09 04:00:22

Let's talk about nostr security really quick:
AFAIK, each nostr "account" is a public/private key pair. When "signing in" to an account on the various clients, you paste your private key into the client and trust that the client doesn't compromise your key. This is really bad key management and opsec. If these accounts are going to have any value over time, they must be managed correctly by users and proper key management must be enforced through a hardened UX design.
Perhaps the better way to do this is by using something like hierarchically deterministic keys. You're master key or seed is kept secret and hidden (perhaps in your password manager or safe/vault at home). Then, you derive a single use private key for the first client you sign into. Then, a new NIP defines a protocol for other clients to sign into your account from the first client; an interact between the second client and the first client will result in the second client having a new derived private key from the first derived key. With this setup, if the second client is compromised, the first client should be safe.
Each note shared could attach some client identifier in order for followers to be able to derive the public key necessary to verify signatures/decrypt notes. This identifier also allows the master key owner to be able to revoke a client key in the event it is compromised. A new key could be derived for the client again and a protocol could be defined in order to recover notes that were compromised within the use of the client.
This scheme describes a sort of sign-in architecture not unlike access keys which may be created by centralized services like Twitter, GitHub, etc. The access keys are permissioned and the actual user's private key stored in a colder fashion. At any point the master key stored by the user is the ultimate recovery key.
I'm sure there is a lot to unpack here, and I left a lot of details out. But, I think this is a general good conversation starter and would like to work on it a bit more if it seems like a good idea to the nostr devs (#[0] npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s #[1])