shafemtol

Cypherpunk raccoon

Public Key

npub1mh94j7j7nwvzl7kwcg70fhxe67kdy50fccakmueq9jjf77zmc25svanahj

NIP-05 Address

_@sha.femtol.net

NIP-57 Address

shafemtol@stacker.news

Profile Code

nprofile1qqsdmj6e0f0fhxp0lt8vy085mnva0txj285uvwmd7vszefyl0pdu92gj6gz7r

Author Public Key

npub1mh94j7j7nwvzl7kwcg70fhxe67kdy50fccakmueq9jjf77zmc25svanahj

Show more details

Last Notes

2023-06-06 00:43:53

- reply

Apart from the shared secret issue, one thing not addressed here is sender authentication.
Assuming the encryption key is `S' = w * Q2`, since the sender signs with the ephemeral key `w`, unless the recipient can somehow verify that `w` belongs to the intended counterparty, the recipient has no way of authenticating the sender.
Anyone who correctly guesses one of the participants of the silent inbox (e.g. a relay operator would be able to trivially figure this out in many cases) can send a DM to that participant with an ephemeral private key of their own, pretending to be the other participant.

2023-06-04 21:49:17

- reply

What you could do is hash the shared secret curve point `S` (preferably using a tagged hash function) into a shared private key `r`, then use the corresponding public key `R = r * G` for the `p` tag. This would not leak the actual shared secret.

2023-06-04 21:38:41

- reply

Maybe something's missing in the pictures. Note that I'm not talking about decrypting *silent inbox* DMs. Here's an example of it going wrong as I understand it:
First, Alice (keypair p1, Q1) sends Bob (keypair p2, Q2) a *regular* NIP-04 DM (no silent inbox).
NIP-04 uses shared secret `S = p1 * Q2 = p2 * Q1` to encrypt the message. In NIP-04, this is given in the example code as:
`let sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey)`
Eve also picks up this DM. She sees that Alice sent Bob a DM of a certain length at a certain point in time. She can't decrypt it yet, but stores it in her collection for later.
Next, they Bob decides to try using a silent inbox. This time, Bob sends a message to Alice.
Silent inbox uses shared secret `S = p1 * Q2 = p2 * Q1` (from the picture titled "Shared Secrets").
Bob constructs the event using an ephemeral key `w`, encrypting to `Q1` (I presume using `w * Q1` as the NIP-04 encryption key, but this is not relevant to the attack). She puts `S` in the `p` tag of the event and signs it (from the picture titled "Send and receive flow").
Eve also picks up this DM. She doesn't yet know its sender or recipient, but she reads the `p` tag and starts trying to decrypt the DMs she's got in her collection one by one, using the contents of the `p` tag as the shared secret.
One of the DMs does decrypt to a valid message, namely the first, regular, DM from Alice to Bob. Eve can now decrypt every past and future regular (not silent inbox) DM between Alice and Bob. Furthermore, while Eve can not decrypt silent inbox messages due to the use of different encryption keys here, she learns that the silent inbox in question belongs to Alice and Bob and can see the length and timing of each message going to it.

2023-06-04 17:02:31

- reply

I'd be uneasy about a supposed "shared secret" being put in a public `p` tag.
Indeed, AIUI, using a silent inbox as presented here completely breaks the security of any past and future regular NIP-04 DMs between the same parties, because the same "shared secret" used for encryption in regular NIP-04 DMs is being used publicly in the silent inbox. An attacker doing trial and error decryption of NIP-04 DMs would be able to decrypt all regular DMs between the two, as well as deanonymize the silent inbox.

2023-05-09 04:35:29

Seems like Binance has currently queued up at least 5 blocks worth of panic consolidation transactions in the mempool at 201 sat/vB for a total of at least 10 BTC in transaction fees. https://mempool.space/address/bc1qm34lsc65zpw79lxes69zkqmk6ee3ewf0j77s3h

2023-03-21 12:55:53

- reply

Not gonna compromise my on-chain privacy for the sake of keeping some pocket money secure. Sorry not sorry.

2023-03-19 18:27:36

- reply

NIP-03: OpenTimestamps Attestations for Events

2023-03-15 11:21:15

When the client adds `"nip05valid":true` to the public profile 🎖️
https://nostr.build/i/nostr.build_a6962c7495538ac66b36e2aaea9944915997c2bb87d985977d4415e0d729165d.jpg

2023-03-15 10:51:22

- reply

Cashu tokens are still power-of-2 denominations, right?
Wen confidential amounts?

2023-03-12 20:49:56

Idea: Relay that only serves events that are slightly corrupted in different ways, if your client accepts any of them, it's broken
#[0]

2023-03-12 19:47:42

- reply

The current specs could be much better even if sticking to "human language". E.g., nowhere does NIP-01 say that created_at must be an integer, yet to #[2] that is apparently obvious. All NIP-01 says is that it's a unix timestamp in seconds. Go to the Wikipedia page for Unix time, and you'll see several non-integer examples.
Test vectors that cover all kinds of corner cases would definitely help.

2023-03-12 19:30:43

- reply

It's not so fun when you just want to type plaintext but random clients absolutely want to imagine it's markdown and completely butcher your note. I'd be mostly fine with it if they'd stick to only modifying the style and not the text itself. Cf. #[2]

2023-03-09 09:10:41

- reply

I think public broadcast standards mostly rely on most people being unwilling to go to the trouble of setting up high-power transmission equipment in order to interfere with public broadcasts in a way that's probably not too hard for some government agency to track down.

2023-03-07 05:51:55

- reply

See also my NIP PR: #[2]
I proposed using a single-letter tag for the hash to cover a particular use case. Unfortunately the PR discussion derailed a bit IMO.

2023-03-07 00:23:46

- reply

I proposed a NIP for just that kind of tag: #[2]

2023-03-06 05:20:08

- reply

Was just thinking about this.
#[2]
Some users follow a _lot_ of others, though, and might have a higher risk of following spam/impersonation accounts. As a refinement, maybe you could score each follow by dividing by the paid user's total follow count, and only include users with a follow score above a certain level, e.g. 1/200. And/or disregard the follows of users who follow identified spammers/impersonators.

2023-03-06 01:18:33

I see clients are removing likes/reactions. How about removing something actually harmful like NIP-04 DMs? That would be something.

2023-03-03 03:56:53

This is why we can't have nice things
https://nostr.build/i/nostr.build_3816dcfc090da03ddc43cd29cff1b2db31a65307e6035711567226093081c43c.png

2023-03-02 20:51:54

- reply

Results on generating notes:
- astral.ninja: 💩 fail #[2]
- coracle.social: 💩 fail #[3]
- iris.to: 💩 fail #[4]
- snort.social: 💩 fail #[5]
They *all* fail to avoid creating false-positive NIP-08 mentions. This is a failure of NIP-08: It does not specify how to actually create a message with the plaintext `#[x]` (where x is a number) in it if the event has tags. #nostr

2023-03-02 20:40:30

- reply

Testing reply from snort.social: #[0] #[1] #[9]

2023-03-02 20:37:59

- reply

Testing reply from iris.to: #[0] #[1] #[9]

2023-03-02 20:37:01

- reply

Testing reply from coracle.social: #[0] #[1] #[9]

2023-03-02 20:33:51

- reply

Testing reply from astral.ninja: #[0] #[1] #[9]

2023-03-02 19:19:31

coracle.social seems to fail on relay URLs with a trailing slash. My profile there is outdated and shows none of my posts, presumably because it refuses to connect to the relays declared in my profile. And snort.social adds a trailing slash to the URL of every relay I add to my profile 💩

2023-03-02 18:31:14

Testing how clients deal with undefined parts of NIP-08: #[0] #[9]

2023-03-02 03:08:13

Trying to understand the cryptography behind WabiSabi for like the fifth time

2023-03-01 03:30:09

- reply

This broke my internet connection

2023-03-01 02:45:48

- reply

Or rather, I'd like the whole event shown in human-readable format, falling back to the json values for things it doesn't know how to parse.

2023-03-01 02:39:05

- reply

Using Flamingo right now. Its signing dialog is very limited, it only shows the `content` part of the event, with newlines replaced with spaces for some reason. For events without content it just shows a blank dialog. I would want it to show the whole event to be signed in json format. Otherwise it seems to be working well.

2023-02-28 16:56:12

- reply

Results: iris.to and coracle.social display the image, snort.social fails (doesn't strip off the fragment before sending the URL to its image proxy, guessing the proxy itself doesn't remove it either).

2023-02-28 16:45:58

- reply

Testing .png URL with fragment
https://i.stack.imgur.com/Iil7a.png#1

2023-02-28 12:09:40

Test
https://void.cat/d/HUBDjrsgNcc4YH7Htv9HMc.webp#1

2023-02-26 21:05:14

- reply

The NIPs don't seem to be fully consistent in its use:
| kind | description | NIP | content | note |
|-------|-----------------|-----|---------|------|
| 0 | Metadata | 1 | Yes | - |
| 1 | Text Note | 1 | Yes | Yes |
| 2 | Recommend Relay | 1 | Yes | - |
| 3 | Contacts | 2 | ignored | - |
| 4 | Encrypted DMs | 4 | Yes | - |
| 5 | Event Deletion | 9 | MAY | - |
| 7 | Reaction | 25 | Yes | Yes |
| 8 | Badge Award | 58 | - | - |
| 40-42 | Chat | 28 | Yes | - |
| 43-44 | Chat | 28 | may | - |
| 1984 | Reporting | 56 | MAY | Yes |
| 9734 | Zap Request | 57 | MAY | Yes |
| 9735 | Zap | 57 | No | Yes |
| 10002 | Relay List Meta | 65 | No | - |
| 22242 | Client Auth | 42 | - | - |
| 24133 | Nostr Connect | 46 | Yes | - |
| 30008 | Profile Badges | 58 | - | - |
| 30009 | Badge Def | 58 | - | - |
| 30023 | Long-form | 23 | Yes | - |

2023-02-26 15:32:22

- reply

Working on it 🤙

2023-02-25 23:26:00

Having scanned through all of the NIPs, I'm still not sure exactly what is meant by a "note". All notes are events, but I'm guessing not all events are to be called notes? #nostr

2023-02-24 06:21:36

NIP: Proof of Freshness
https://github.com/nostr-protocol/nips/pull/296 #nostr

2023-02-22 20:41:19

- reply

These are the concerns and edge cases I can think of regarding a soft fork to set a maximum timestamp limit on block 2015:
## Can a maximum timestamp requirement of prev timestamp + 20 min conflict with the minimum timestamp requirement of prev mediantime + 1 sec, making it impossible to mine a new block on top of the latest one?
No, because prev mediantime can not be greater than prev timestamp. The mediantime of a block is the median of the timestamps of that block and the 10 before it. Because that block itself must have a timestamp greater than the median of the 11 blocks before it, it must have a timestamp greater than that of at least 6 of those blocks. It follows that it must have a timestamp greater than at least 5 of the 10 blocks before it. Thus, its timestamp can only be set so low as to also define the block's own mediantime.
## Could non-upgraded miners run off in a chain split?
Yes, if they start a block storm. But they would reorg and join the upgraded chain as soon as the upgraded chain finds block 2015. This is because the non-upgraded chain would all consist of difficulty-1 blocks for the next 2017 blocks (and then increasing by no more than 4x for every difficulty period after that). That is, the blocks do not make a heavy chain. Even if the non-upgraded chain had more hashing power in theory, they would be limited by the rate of new blocks having to be sent across the network.
## Could the chain stop at block 2014 for hours because all ASIC miners left?
This is a possibility. Is it worse than a block storm, though? Not everyone has their own ASIC miner, but renting some ASIC time shouldn't be too hard or expensive (should cost no more than about 40 cents per expected block at the current difficulty and BTC price).

2023-02-22 18:05:59

- reply

Apparently a boost/repost is kind 6, which I can't find mention of in the NIPs? And snort includes the reposted event in full as stringified JSON in the content field, while iris leaves the content field blank?

2023-02-22 16:33:14

- reply

By the way, #[3] , you say that a fix would require a hard fork. Is that a common belief?
A simple soft fork* would be to require that the last block in a difficulty adjustment period has a timestamp no greater than 20 minutes after the previous block.
__
* A soft fork in the sense that it only restricts consensus rules. Miners that don't implement the change might get their block invalidated by this. But such a block would be a difficulty-1 block, so no big deal.

2023-02-22 16:12:36

Exploring a method to reduce the risk of block storms on Bitcoin testnet

2023-02-20 20:21:23

- reply

His client mangled the npub in the plaintext as per NIP-08, your client might show the mangled part as "@jimmysong". If you replace that text with the npub, you should be able to verify it.

2023-02-19 16:25:30

- reply

My biggest gripe with NIP-04 is that all DM metadata is public, including sender and recipient: #[5]

2023-02-19 15:30:41

- reply

So I checked your lnurl-pay endpoint, and it doesn't include the NIP-57 fields `allowsNostr` and `nostrPubkey`. So no zap support, just regular lnurl-pay. But apparently that doesn't stop #snort from calling it a zap and then doing absolutely nothing on payment 🤪

2023-02-19 11:41:49

- reply

IMHO, the current NIP-04 DM stuff should be killed with fire. The less integrated it is with other functionality, the better.

2023-02-19 05:31:04

- reply

Apparently snort defined only a single hashtag for this message, according to the json output. Does it only ever add one tag per message, or was there some other issue with the second hashtag? #Nostr #hashtag #test

2023-02-19 05:19:55

- reply

I do like the idea of "personas" (I would maybe call them something else, maybe "personal topics"?)
This could be implemented per NIP-12 in combination with a new tag type for this feature. Or, if we make it a convention, just plain #hashtags.

2023-02-19 03:06:33

- reply

I learned about silent.link from CD77. Very exciting project. Looks like (for low usage) the data price can be quite decent as well in certain areas.
One issue I have with it is that you'd ideally have to use this on a phone whose IMEIs are not tied to your identity (so no KYC SIMs ever used on it).
They said on CD77 that the physical-SIM and eSIM IMEIs are different and thus the network operator cannot easily link these, but from what I've seen, the two IMEIs seem to be adjacent (apart from the final Luhn checksum digit), e.g:
- 004101846898885
- 004101846898893
So it seems they would be trivially linkable.
Are there devices where these IMEIs are at least somewhat unrelated?

2023-02-19 01:03:04

I've been observing issues with sending and receiving #nostr events on certain relays. Added some relays that don't seem to be blocking #Tor as often, hoping that will improve things a little.

2023-02-17 13:37:22

- reply

DM sender, recipient, timestamp and message size is all public. You can see for yourself and browse e.g. here: https://brb.io/n/list?kind=4
People see "encrypted" and think it means "private". Something something we kill people based on metadata. People are going to get burned on this.
Tempted to make a bot that publicly mentions who DMs whom for visibility 🤔