Have found a definition for #nostr I am comfortable with: Nostr is self- and shared-hosted trustless event logs. (Nostr relay is a self- or shared-hosting thing) It had started as a platform for social networking, but can be used for groupware and corp applications, cross-device app synchronization, attestation logs and many other things.

Lightning was supposed to solve on-chain congestion problem, not join it! Routing nodes now have to reserve up to thousands of $ for fees: this is the way LN is designed today (example of how this might happen can be found in

X (formerly Twitter)

Mion (@MionGroup) on X

11: However, in a channel jamming scenario, 483 pending HTLCs might need to be included, meaning we’ll end up with a transaction of about 15,113...

It doesn’t mean this money are lost, but they have to be subtracted from the channel balance, increasing existing LN liquidity problems. One of the strategies the nodes may follow will be to stop routing until good fees are back - and keep commitment transactions originating from the times when fees were low. Current software doesn’t support this, but the future versions may do. This will mean that with high onchain fees LN will degrade in performance and liquidity too.

NIP-88 proposal adding support for the binary encoding of #nostr events: all file services, munsters and devs suffering from slow JSON serialization - I know you was looking for a such thing :)

GitHub

NIP-88: binary event encoding by dr-orlovsky · Pull Request #512 · nostr-protocol/nips

At the present moment nostr (NIP-1) uses text serialization of the event data, represented in a form of a JSON object. While being simple-to-implem...

This is the first proposal in the series I will do to address the points of my recent #nostr critique

Damus

dr.orlovsky on nostr

Thoughts on #nostr. Nostr is a websockets-based text protocol f

MyCitadel v1.3 is around the corner with some great updates: ability to compose complex time-locked conditions (like 2-of-4 multisig which in 1 year becomes 1-of-2). A tx created with MyCitadel spending from such complex miniscript descriptor:

The Mempool Open Source Project®

Explore the full Bitcoin ecosystem with The Mempool Open Source Project®. See the real-time status of your transactions, get network info, and more.

Miniscript descriptors with timelocks were available since the first release of our desktop wallet, but due to miniscript inability to work with the same keys in different pre-taproot script branches it was impossible to create non-trivial setups. The new version will introduce account-based spending conditions such that different branches now may use different accounts coming from the same hardware signer.

Descriptor wallet got updated to v0.9.2 with better command-line explorer functions: miniscript support, tx fee & minimg info, P2W* witness parsing, RBF info and colors! `cargo install descriptor-wallet --all-features`

GitHub

Release Descriptor Wallet v0.9.2 · BP-WG/descriptor-wallet

What's Changed Improved command-line explorer: Transaction weight and fee information Parsing witness data for P2WPKH and P2WSH outputs Miniscript...

I was thinking of what nostr is. The initial concept I had was that nostr is a specific client-server (relayed) protocol for social network defined as NIP-1, plus extensions on top. Now tend to see nostr is some other way. Nostr is the way of producing public authentificated data feeds by pseudonymous web-of-trust identities. NIP-1, existing relays etc are just current implementation details, which may change. What would always remain are the data feeds linked to decentralized identities.

Thoughts on #nostr. Nostr is a websockets-based text protocol for logs of authenticated (but unauthorized) tagged (and otherwise unstructured) messages stored at public relay servers. The rest is a specific nostr application (like social networking or payments) on top of it. Nostr takes several decisions on possible tradeoffs, which I try to analyze here: 1. Websockets. Good: pub/sub data access, web-integratable. Bad: high load on relay servers limiting scalability. Verdict: ⚠️ 2. Elliptic curve (secp256k1) for identities. Good: bitcoin-based. Bad: very low performance, not GPG/SSH compatible, sidechannels. Overall: ❌. 3. Signature scheme: BIP-340 Schnorr. Good: batch verification, standard. Bad: optimized for onchain, discarding y coord, making verification ~50% more expensive than non-BIP Schnorr. Verdict: ⚠️ 4. Hashing function: SHA256. Good: standard, bitcoin. Bad: slower than BLACKE3. Verdict: ⚠️ 5. Text JSON encoding. Good: easy to implement. Bad: hard to pass & slow to encode/decode non-text/binary data; no limits on data sizing opening a door for DoSing relays and clients. Verdict: ❌ 6. No authorization scheme. Good: easy to implement. Bad: limits use cases, limits scalability. Verdict: ⚠️ 7. No encryption on the transport level, relying on TLS. Good: easy to implement. Bad: centralized, not end-to-end. Verdict: ⚠️ So I see most of selected tradeoffs by Nostr as a bad or poor decision. This us arguable of course. Can Nostr survive and success? For sure, if even much worse systems had done that in the past (Ethereum, JavaScript, PHP). What is the greatest Nostr weakness? Limited scalability and possible DoS (not even DDoS) attacks. If I were the one who did nostr, what I would had made differently? I would had used Ed25519 signatures on Ristretto25519 (speed), binary encoding with strict limits on data sizes, use Noise_XK encryption - and provide bridges to Websockets only when they are needed for the web. But we have what we have.