Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nostr

nostr.com

Post reply on HN
Print view View original

321–330 of 347 posts

Re: Nostr

#321

Post by Yizahi »

agalush wrote: post #312
Yizahi wrote: post #274

Earlier quoted context omitted.

If I'm not mistaken, running own Lightning node would mean opening channels to every single merchant you want to trade with AND those same merchants would need to open a symmetric channel back to you with the same amount of locked funds. And then during the transaction this system would need magically solve traveling salesman problem per each transaction in the system, taking into account that after each completed tr…

you just need to open one channel to another node (better if well connected) and all your payments will be routed through that node. If you have multiple channels you have more routing alternatives and can choose the best one for every single payment.

So, for a normal case where multiple people want to trade with multiple other people/merchants we would need a centralized node with connections to every single one of the clients and every single one of the merchants (so a "bank"). Both clients and merchants need to open a channel on L1 (so it's goddamn slow or expensive) to that node and freeze in the channel the full amount of tokens they would wish to spend with every single peer or merchant in the future (so basically a "deposit" of all or at least a lot of the funds in a "bank"). And every merchant would need to do that too for the full amount of anticipated transactions. And then this system will work on L2 somehow, if the system will correctly calculate paths and and sums in all the channels there are. To exit the system, channels must be closed on L1 (slowass or expensive) and if there are not enough funds in the channels, create new channels with more funds, again on L1.

Even in the most absurdly centralized scenario, the system is practically unusable as soon as there are more than a handful users. Or people just stop pretending and use custodian tokens, aka bullshit IOUs.

Re: Nostr

#322

Post by Yizahi »

msm_ wrote: post #282
Yizahi wrote: post #274

Earlier quoted context omitted.

If I'm not mistaken, running own Lightning node would mean opening channels to every single merchant you want to trade with AND those same merchants would need to open a symmetric channel back to you with the same amount of locked funds. And then during the transaction this system would need magically solve traveling salesman problem per each transaction in the system, taking into account that after each completed tr…

Wouldn't repeated block size increases lock out "normal people" from participating too? Hosting a local BTC node is already hard, and completely impractical on a mobile device.

If I'm not mistaken, you don't need to host a full node to access and operate BTC network. But hosting full nodes certainly adds resilience and speed to the system.

Point 1. Increasing node storage size would not be very expensive, people are buying NAS storage for fun, some of the more idealistic ones would certainly do that for BTC. BTC chain today is less than one terabyte. Even increasing chain size x10 times would still mean that it would fit on a single cheap consumer HDD. Increasing it x100 times would require something like a 6-8 HDD stripe, under 1-2 thousand bucks in price. People do that for memes or hosting torrents every day, all across the globe.

Point 2. Increasing chain size by a lot would mean that the amount of full nodes would inevitably drop, lets say by half, or even by 3/4. Still a lot would remain and the system would be very decentralized. While with lightning crutch the decentralized part is clogged permanently and is unusable for any serious currency replacement use, while users are forced on a broken by design centralized Lightning.

In my opinion the answer is obvious, if we want to have a truly decentralized currency, and not some casino replacement for gambling and law avoidance.

Re: Nostr

#323

Post by nout »

tptacek wrote: post #317
skinkestek wrote: post #315

Earlier quoted context omitted.

I think it is an HN standard: I am less on HN these days, but as far as I have seen: Telegram is still judged by its very early releases, still called "unencrypted" while it is about as encrypted as your bank transactions (they definitely aren't e2ee either). Signal can do what they want including dabbling in crypto currency without being open about it. Signal can also have extremely "interesting" bugs (didn't it at…

Your bank doesn't operate in Telegram's threat model! You are never concerned that your bank's servers are attacking your transactions: if you can't trust your bank, you're fucked anyways. That's precisely what's not supposed to be the case about a messaging service!

I agree with your bank related statements, but for the wrong reasons. You should not trust your bank.

Re: Nostr

#324

Post by brisky »

keiferski wrote: post #26

Something I don’t quite get about these new social networks that are clearly aimed at technical people: my model of a truly decentralized social network is more like a network of privately hosted personal websites, à la the original web. Not yet another platform I need to make an account to interact on separately. Have there been any attempts to make more of a “network” that incentivizes operating personal websites b…

You might want to check out Really Simple Decentralized Syndication (RSDS) https://writer.did-1.com/

Re: Nostr

#325

Post by vnuge »

some_furry wrote: post #319
vnuge wrote: post #300

Earlier quoted context omitted.

Hard to say how relevant that is. DMs are simply a collection of events sitting on a relay. It's not really a mutual tunnel, most clients implement nip44 via nip19 (giftwrap DMs) so your ni04 message wouldn't likely make it to them. It's not considered backward compatible such that you could send a user a DM, then cause their client to downgrade to the DM scheme that uses nip04. It's also worth noting, the user _must…

> It's also worth noting, the user _must_ be made aware of the encryption method that was used, their "signer" application, which is also responsible for encryption and decryption, would require their permission to do an operation in either direction. Let me ask a more pointed question about downgrade attack resistance then: Is the algorithm being used determined by the encrypted message contents? Or is it determined…

Regardless of the signer interface the procedure call remains the same. The client application determines what method it wants to use, then the plaintext is passed to the signer (web extension, nip46 remote signing, android etc) with the nip44.encrypt or nip04.encrypt procedure calls.

The user is then requested to confirm the encryption operation. So a "downgrade" could happen in two ways. The client selects nip04 without the user's instructions, and the signer does not properly guard or notify the user that the message to be encrypted is using nip04. Still not really an attack I don't think, since no "sessions" exist in DMs there shouldn't be any way a remote user gets to cause a client to change algorithms.

To answer directly, the client app chooses, makes a remote procedure call with the desired algorithm, user confirms, message is encrypted, returned, signed (another rpc round-trip), then written to relays.

The signer application is ALWAYS authoritative, if it chooses to.

Re: Nostr

#328

Post by some_furry »

vnuge wrote: post #325
some_furry wrote: post #319

Earlier quoted context omitted.

> It's also worth noting, the user _must_ be made aware of the encryption method that was used, their "signer" application, which is also responsible for encryption and decryption, would require their permission to do an operation in either direction. Let me ask a more pointed question about downgrade attack resistance then: Is the algorithm being used determined by the encrypted message contents? Or is it determined…

Regardless of the signer interface the procedure call remains the same. The client application determines what method it wants to use, then the plaintext is passed to the signer (web extension, nip46 remote signing, android etc) with the nip44.encrypt or nip04.encrypt procedure calls. The user is then requested to confirm the encryption operation. So a "downgrade" could happen in two ways. The client selects nip04 wi…

That doesn't answer my question at all.

Is the decision (regardless of who fucking decides) based on metadata attached to the key the client controls or from a breadcrumb included in the message itself?

Re: Nostr

#329

Post by duskwuff »

some_furry wrote: post #328
vnuge wrote: post #325

Earlier quoted context omitted.

Regardless of the signer interface the procedure call remains the same. The client application determines what method it wants to use, then the plaintext is passed to the signer (web extension, nip46 remote signing, android etc) with the nip44.encrypt or nip04.encrypt procedure calls. The user is then requested to confirm the encryption operation. So a "downgrade" could happen in two ways. The client selects nip04 wi…

That doesn't answer my question at all. Is the decision (regardless of who fucking decides) based on metadata attached to the key the client controls or from a breadcrumb included in the message itself ?

I think that the (unsatisfying) answer is that there's no established standard for how protocol selection works. nip04 and nip44 are completely different types of messages, and it's up to the client how it'll use and/or respond to them.

Re: Nostr

#330

Post by vnuge »

some_furry wrote: post #328
vnuge wrote: post #325

Earlier quoted context omitted.

Regardless of the signer interface the procedure call remains the same. The client application determines what method it wants to use, then the plaintext is passed to the signer (web extension, nip46 remote signing, android etc) with the nip44.encrypt or nip04.encrypt procedure calls. The user is then requested to confirm the encryption operation. So a "downgrade" could happen in two ways. The client selects nip04 wi…

That doesn't answer my question at all. Is the decision (regardless of who fucking decides) based on metadata attached to the key the client controls or from a breadcrumb included in the message itself ?

We are obviously speaking from different understandings. I would say neither. I would need you to define your terms differently maybe.

In all cases the client application chooses the algorithm used when the user writes a DM. What do you mean by breadcrumb in the message. Message in what context? Message sent to the signer?

Edit: Maybe I should say the client developer? Is that the answer you're looking for? The developer _could_ give the user the option of choosing which to use, but clients generally are hard-coded to use one or the other.

Post reply on HN