Last Notes
This is forcing me to learn about things like side chains and pegs. So from talking with an LLM, it seems like the custodial problem with rootstock is "pegging out," i.e. releasing escrowed BTC when RBTC is getting redeemed. Bitcoin cannot know mechanically when RBTC gets redeemed, so there has to be a federation of entities that are trusted to correctly operate PowHSMs which co-sign the bitcoin transactions that release escrowed BTC. And these are held out to be "respected companies" but their "identities are not public," which raises the question what basis there is for the respect. And then there is still the other issue, i.e. that it's not clear what exactly would stop bitcoin miners from reorging rootstock. The miners get paid in BTC no matter what happens to rootstock, so beyond the small fee incentive they get for participating there doesn't seem to be anything they'd lose by attacking rootstock. At least at first glance, it doesn't necessarily seem more robust than Ethereum.
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.
"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 👇
#nevent1q…qdtx
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.
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.
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 👇
#nevent1q…yzpx
#nevent1q…x3pj
#nevent1q…c3qh
Following up on this one, with inkan "verify" isn't just a slogan.
Every OTS-stamped event on inkan.cc comes with a download button for the raw .ots proof, together with a report that tells you exactly how to reproduce the hash the proof commits to:
leaf = SHA-256( id_bytes || sig_bytes )
It takes one line of shell to recompute it from the event's id and sig, then feed the .ots to any OpenTimestamps verifier, the CLI, the web one, whichever you like. Nothing from inkan is in the loop. It either resolves to a Bitcoin block header or it doesn't.
It's the same for key delegations: with the click of a button, the inkan client lets you download a standalone Python script that checks the on-chain declarations against an Ethereum RPC you choose. It recovers every ECDSA signature locally, checks the contract binding, flags nonce replays. You can read it top to bottom, no inkan server involved.
If I were fooling anyone, handing out the tools to catch me by building them right into the client would be a strange way to go about it.
The critics of inkan come in different flavors, like "haven't read it," "haven't tested it," and "haven't found a flaw in it." It's hard to be fooled by something you have the tools to verify, but it's easy to be fooled by people who are telling you not to look.
pubkeys that have recently applied for AI search should have access now 🧞♀
You should already be whitelisted on the timestamp server, as well as on the relay.
You can check your status at "Settings > Inkan Settings > Service Access". It should show that you have access everywhere, if not let me know.
https://www.inkan.cc is a jumble fork that's pretty nice to use.
It supports cold storage identities, if you ever want one of those.
And you can search the nostr network with the new AI Search feature. That's actually how I found your note that I'm replying to right now. I asked it what Laeserin had been up to, and here is what it came back with. 👇
https://image.nostr.build/9196ab0d52d41bb02e8e70fbc1c9a379895eb4d6d71160b9c98540fce3d49f00.jpg
Huh, I guess it's an opportunity to post yet another a link to inkan, which I'll do in a minute. 🤔
As a reminder, there's a standing invitation to make a toy identity directly in the browser on the homepage at https://www.inkan.cc. Useful if you'd like to try it out without going through the steps of making a true airgapped identity.
And even if you don't make your own identity, you can still use https://www.inkan.cc to interact with existing cold storage identities. You can find some of them by clicking on the Explore tab.
I saw Disclosure Day. It was a throwback to the days when people still knew how to make movies, although among those competent ones this would not have been an especially good one. The ending sequences brought me to brink of tears, which was however not a genuine emotion but more of a physical reaction to the particular combination and sequencing of images and voices and music, sort of like a vasovagal reflex, or the mental state you get into when you sit in front of a slot machine with all the blinking lights, or I guess a horror movie jump scare. There was a very clean separation between that physical reaction I was experiencing and the consciousness of being manipulated. Not unpleasant but also somewhat annoying. In any event, it's nice to encounter something of good workmanship even though it may ultimately not be very remarkable.
It's been almost a month since this discussion, so here's a quick reminder that Nostr already has a working key rotation / replacement system.
You can go to https://www.inkan.cc and click on "Explore" to interact with some cold storage identities that have never signed a single Nostr event.
You can also create a throwaway "toy identity" on the homepage if you want to try it out yourself. If you don't mind going through the steps, you can even make a full-fledged airgapped identity with the Management Utility.
"meeting analogically" is a great phrase, I'll remember that.🙂
By the way, I'm still trying to get the word out on this key rotation system.
If you go to the "Explore" menu at https://www.inkan.cc, you can interact with cold storage identities that have never themselves signed a single Nostr event but that are nonetheless doing posts every day. If you like, you can also make your own toy identity on the homepage.
I realize there's a strong presumption among the Nostr community that this kind of thing doesn't work. But as a matter of fact it works quite well. I've been using it for many months now.
This also plugs into the recent discussion that we should adopt good practices while the Nostr community is still small. And in any event, it doesn't break anything in the current protocol, it just sits on top of it.
Or going further back: https://music.youtube.com/watch?v=dIyqQ7aANWY&si=N_C5rtiBk0Ci0ZQg
AI Search for Nostr is a pretty good UX experience I think. I just made it this week and am already pretty hooked on it. 👇
#nevent1q…jsrr
I agree with pretty much all of this, including that its's a self-fulfilling loop.
#nevent1q…eyzk
I always forget what this discussion is about, and then I worry whether I need to change anything in my client, I think probably not though, oh dear oh dear.
AI Search for Nostr has been live for a day now. 🧞♀
Here's the kind of thing it comes back with, more details below the screenshots 👇
https://image.nostr.build/c18f60cd4ba23a65401920bb361b784f38c41165f42503397d8403da29f88308.jpg
https://image.nostr.build/588d6eef47ac04ac01b93b8c2b6c2cb2602f77363250867b99550f49931d2198.jpg
https://image.nostr.build/9267f4938a9564508422b9d1867420cb8fae7af4e692fcc1257dbe77de990971.jpg
https://image.nostr.build/43455af0c02589ed30db66718ac178bec9b2b8e22eb270f171cb91232efc1cc5.jpg
#nevent1q…rlrz
Thanks, good to know that part is working ...
Thanks, that's a great catch! I tried to fix it, when that happens now, the model is now made aware that the value was probably the wrong kind, so it should correct course. You can go to Settings > General > Check for updates to get the new version of the app, or just do [ctrl/cmd] + shift + R.
Please feel free to keep using it, and let me know any comments or questions anytime.
Great to hear it works better. FYI, you can always check if you've got the latest version of the app by going to Settings > General > Check for updates.
Thanks, you should have access now.
Click on "Assay" in the nav bar and enter a search.
If you get stuck anywhere, let me know.
Please do - I'll switch it on when I get the Terms. Let me know anytime if you have any questions about anything.
There's no cost, it's free during testing (I'm covering the model fees). There's usage caps per key, with current usage indicated to each user when they are logged in. Auth is NIP-98, and you sign a kind-27235 challenge to log in. The terms acceptance itself is a kind-1 that you sign whose content is the full Terms text, which gets sent to me for my records. The signature is necessary partly because your input is forwarded to the model provider and I have to consider their own terms. If you'd like to try it, you can sign the Terms under Settings > Inkan Settings > Service Access and let me know, and I'll switch your key on.
Thanks very much for flagging this. I checked just now and the cert is valid covering both inkan.cc and www.inkan.cc, and I haven't had this report from anyone else. It's likely something between your phone and the site. You may want to try in your regular browser and see if that fixes it. If it doesn't, please let me know.
"the initial step is really hard"
That's why I created the "Toy Identity" option on the Inkan home page. People can create a throwaway identity in a few minutes and play around with it. If they get used to it and like it, they may at some point get around to creating a real airgapped identity.
I'll take a closer look at the Foundation devices, they look very attractive.
FYI, this allows you to say "these 10 keys are all me." 👇
#nevent1q…x0vp
Are you maybe looking for this? 👇
#nevent1q…x0vp
It's easy to use, the friction is basically the airgapped identity creation. Not really difficult, just stepwise, and people have no patience for going through a stepwise process right up until they do, and at that point it basically becomes second nature.
Yes a narrative is needed and it's hard and I don't have one yet. One thing that's working for inkan over the mid-term is that people will get their keys compromised, some of them more than once. The people interested in inkan now are sort of like coldcard users who rolled dice before this summer, not necessarily smarter but maybe a bit more introspective, or maybe just having better habits in the first place. But it's a somewhat different narrative when money is involved more directly, so not fully on point.
I'll taka a look at Seligman and Maier, I agree that's the right kind of lense for this.
Yeah, and it's actually worse than just hate, they are *correct*. I think economists call it "rational ignorance," and it can be the right move with limited cognitive resources. So you don't read the NIP, you instead watch what your peers do, except the problem is your peers are watching you, so there's paralysis. The key rotation discussion on nostr is this bottomless information cascade, and that probably applies to other topics as well. I guess the trick is to make checking cheaper than doubting.
So there's this nostr paradox, why would a community obsessed with crypto and key security refuse to even test working key rotation?
Because you can't tell working from broken without spending your own time on it.
After enough broken NIPs and abandoned apps, you learn to price every new thing as a lemon and assume broken. The good leaves the market with the bad. 👇
https://en.wikipedia.org/wiki/The_Market_for_Lemons
That feels right ... I had never heard of jev, thanks for pointing it out.
This sounds like when a mechanical solution exists you'll want to use that. And when none exists, it may be cheaper to create a mechanical solution and use it. Maybe jev is useful when it's not clear how to create a mechanical solution?
Do your mechanical solutions require custom-tailoring to the task at hand that jev doesn't require?
If "convergence delay" is meant to refer to a delay that occurs before *relays* agree on the same set of revocations, then that term carries a presupposition that relays *will* at some point converge. As far as I can see, there isn't any particularly strong reason to think that they will ever converge.
(I'm not sure what "DST" is.)
more reliable? unreliable? relia-bro?
Huh, I had kind of forgotten about these sites. I never really used them, let alone considered posting anything on them, and this made me remember why.
It also makes me think that we actually have a pretty nice crowd here on current nostr, at least relatively speaking.
And I'm not so worried about the community here turning nasty, not because I think it couldn't ever happen, but because the consequences would be limited.
On sites like reddit, it feels like you are locked into some narrow space with your peers, and there is no escaping or avoiding them. With nostr, because you have your own keys, you can be more of a nomad. When this particular spot doesn't suit you any longer, because there's no shade or for whatever reason, you just take a minute to pack up and move to another one, taking everything you need with you.
It's a very different feel, and it has to do with the underlying structure of the protocol.
With a retrospective disavowal, you have to trust that what they are telling you is true, i.e. that their key was really compromised.
I think it's difficult to do without a blockchain.
Thanks, I guess "fork" and "join" are concepts that apply in the cryptocurrency context, so probably not directly applicable to inkan.
I agree about signatures.
I think your post was maybe referring to my statement "To trust a self-declared disavowal, you have to trust the *person* behind the master key" ?
What I meant is - suppose a person posts a note that's validly signed by their master key which says:
"My signer key was compromised two weeks ago. Don't trust any notes that were signed by the signer key during the last two weeks, especially the notes saying that I was traveling in Denmark, I did not post these, someone impersonated me!"
Then you have to decide whether or not to trust that the person is telling the truth when they say that that their signer key was compromised and that they did not themselves post the notes saying that they were traveling in Denmark and that someone impersonated them.
That's what makes retroactive disavowals of events *very different* from key revocations. Key revocations are acts that occur at objectively verifiable times, i.e. when they are recorded on-chain. Retroactive disavowals of events are subjective statements that other parties may choose to believe, or not.
Also: If others know and agree on the objective time of the revocation, they can *at least* agree that events that are dated subsequent to that revocation time should not be attributed to the revoker.
They can do so regardless of whether or not they agree on how to handle events that are dated between the self-declared start time of the disavowal and the objective time at which the revocation was recorded.
I'm not sure what "it" is in this sentence:
"it's cryptographically identifiable"
I agree, and inkan gives you exactly that functionality.
When you revoke, you can optionally declare a past time starting at which you "disavow" events signed by the key you are revoking ("I consider this key to have been compromised since September 14, don't trust anything signed by it after that date!").
But the design point is that inkan won't allow you to silently rewrite history that others relied on. Everyone can see both (i) when the revocation was actually recorded on-chain and (ii) the past time from which you disavow.
So third parties get the full picture, i.e. these events were validly signed during the delegation, and the author now disavows them. Clients can either hide disavowed events or show them with a disavowal badge.
There's also a re-ratification mechanism that allows you to rescue your our own legitimate events inside a disavowed window. 👇
#nevent1q…krrt
My primary use case is actually just regular nostr users whose keys can get leaked or lost, basically the same reason everyone wants to be able to reset their X password when it gets stolen. It's nothing too specialized, although the system *can* be used for contracting if one wants to.
And just to note this, a revocation primarily protects *the impersonated person*, not the reader of the revocation. So "just ignoring revocations" means basically "the thief gets to keep posting as you to every client that ignores the revocation."
And for revocations to protect anyone, clients have to be able to find them, and they must agree *when* the revocation happened since the revocation is what separates your own old posts from those of the thief.