I haven't used anything FROST-based, but I think I would if I could do it in a way that seems more secure than regular NIP-46, and convenient to use.

For it to be more secure than regular NIP-46, I would want to require all shards for signing and keep exclusive control over at least one shard myself. If there isn't anything in the cryptography underlying FROST which makes it inherently less secure than using an unsharded key, it seems that this way of using it would be at least as secure as regular NIP-46.

And then on the convenience side, the actual signing would ideally be controlled through an app that sits on my phone and feels generally like Amber, and that app should probably hold one of the shards over which I have exclusive control.

I've only taken a cursory glance at FROST, but if there is something that provides this kind of experience or something equivalent, I think I'd try it.

Huh, so it's starting to sound like inkan would likely run on rootstock. One question then is whether that would be advantageous as compared to ethereum. I need to better understand what merge mining is. It seems like rootstock gets a lot of hashrate from it but it's not clear if the miners have anything really at stake there, i.e. it seems like a large pool could reorg rootstock without losing anything? I'm not sure if it protects against reorgs in the way in which Ethereum finality does. Also, rootstock seems like the more exotic product and it seems to have fewer endpoints, so it might be less suitable for broader adoption than something based on ethereum maybe. But I first need to do more reading to really understand how it works.

thanks, let me know any questions any time.

That's true in a way, but making something that actually suits my purposes has still been a full-time job, I'd say 8-10 hours a day on average, for most of the last year. It's interesting that it should be like that.

"Your whole identity is ONE private key. No rotation. No recovery. Paste your nsec into one sketchy web client and it's gone forever. Your only option is "hey guys new npub pls refollow""

Seems like this got overlooked 👇

See?

I've been asked about this and spent some time thinking about it, and I don't have a conclusive answer.

Where it gets difficult is the revocations. Clients need to know if a delegation is still alive at any given moment, and for that they need to be sure that they haven't overlooked a revocation declaration somewhere. So it's not enough that declarations be written somewhere durable, the client needs to be able to assemble the entire set of declarations for a given key and needs to know that it's complete. That completeness property is available on Ethereum, but I think Bitcoin script is attached to single outputs and doesn't accumulate state across transactions. So you could write declarations into the Bitcoin chain in some agreed format, but then anyone wanting the full picture needs to scan the whole chain with a full node and otherwise they can't tell whether a revocation is being withheld from them. I'm not an expert on this, but that's my current understanding.

It seems like rootstock may be different again though if it's a full EVM. But the thing is I'd never heard of rootstock before this came up, and I suspect most people outside bitcoin haven't either. Ethereum is at least something normal people may have vaguely heard of. So it's not obvious to me that swapping in rootstock or bitcoin scripts helps adoption overall, as opposed to just helping with this particular audience, which may be acting on niche preferences that don't have strong technical justifications. Don't get me wrong, though, I'd love to have this conversation with the current nostr community and the bitcoin crowd, and there may be actual technical advantages with using bitcoin that I'm not aware of.

There's been some previous threads relating to this, and also don't forget to actually try it out, otherwise it just ends up being just these abstract discussions 👇

Actually you can simply keep using your current nostr keypair and make it the signer for a cold storage identity, this just came up in another conversation 👇

When use of an EVM provides a solution to the key management problem, which is a central problem for the nostr protocol, wouldn't it make sense to simply use that solution rather than continue sitting on the problem?

And there is also the idea that nostr was supposed to have broader appeal beyond the Bitcoin community. Leaving problems with the protocol unaddressed because a working solution doesn't fit the tastes of the Bitcoin community doesn't seem like a good strategy to achieve broader adoption.

That seems right, I also just responded with the same reference to the NIP draft.

You need a blockchain with certain completeness properties. It's just a technical requirement, not some partiality towards Ethereum in particular.

The gas fees required for an identity creation are tiny, I think it was maybe $0.20 or so the last time I did it.

I'm happy to take care of the tiny gas payment if you don't hold Ether. There's an option at the end of the toy identity wizard to send me the transaction file that was created and I can record it on-chain.

FYI, the technical specs (which among other things explain why a blockchain is needed) are here 👇


naddr1qvzq...

You can keep using your current npub and delegate down to it.

For example, the npub I'm using right now does double duty as the signer key for a cold storage identity. The profile page of that identity is here:

https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9

People who are currently following the signer key can continue to do so for as long as they like, although I'd hope that they'll eventually get around to directly following the identity key (since the identity key will survive if / when the signer key gets compromised).