The (almost) only problem that's left is the requirement of having the webcam on.
Regardless of the client-side software that you can't trust, there are also third-party servers that will store all the recordings with personal information for a potentially long time, which is unacceptable and isn't fixable by temporary hardware (as we don't have a temporary face).
Is it really "locking" when putting bitcoins on LN actually make them easily spendable with very little fees?
Imo, all of those are outdated claims. For consumers, it's easy to open outbound channels (e.g. to well connected nodes). For merchants, it's becoming easier as well. Remember that it's a network, merchants can have outbound channels and "pay themselves" to get back inbound liquidity (can also be automated).
You're not limited to one "gateway" either.
If liquidity is a problem on LN right now, you're already dealing with bigger amounts that can happen on-chain.
I'm not saying it's perfect, but I find LN to be elegant as a payment system for Bitcoin.
> Is it really "locking" when putting bitcoins on LN actually make them easily spendable with very little fees?
Merchants don’t want to spend, they want to receive. Why should a merchant have to lock e.g. $100k worth of bitcoins at the beginning of the month (in a payment channel connected to a gateway) just in order to receive that amount from consumers during that month?
No other payment system in the world requires this.
Well if a merchant doesn't want to spend or lock anything, it doesn't have to. Consumers and gateways can open channels to the merchant and that's enough for them to pay the merchant.
In the case of a merchant that doesn't want to participate much in the network, gateways have interest in opening to him to allow consumers to pay the merchant for a fee.
> Well if a merchant doesn't want to spend or lock anything, it doesn't have to.
If the merchant wants to receive funds via the gateway then funds need to be locked in a payment channel between the gateway and the merchant.
This is in addition to the funds locked in multiple payment channels between consumers and the gateway.
Consider a super simple LN setup, consisting of (a) one thousand consumers, each with 0.001 BTC to spend, (b) a single gateway and (c) a single merchant. The consumers are connected to the gateway, the gateway is connected to the merchant. In order for the one thousand consumers to each send 0.001 BTC to the merchant there needs to exist a payment channel between the gateway and merchant with 1 BTC in it (assigned to the gateway), and every time 0.001 BTC is sent from the consumer to the merchant, 0.001 BTC moves from a consumer to the gateway (in one payment channel) and from gateway to merchant (in a separate payment channel).
My concern here is that this is (1) expensive, and (2) inflexible. Expensive because the gateway needs to borrow 1 BTC to sit in a payment channel between it and the merchant, and inflexible because if another consumer connects to the gateway then the merchant cannot receive additional funds because it would require increasing the capacity of the channel between the gateway and merchant.
You have a wrong understanding of how LN works. You are conflating inbound and outbound liquidity. To receive 1 btc a merchant does not have to open a 1 btc channel. Another node has to open a channel with him. He can buy 1 btc of incoming liquidity for a few cents. Some nodes offer incoming liquidity for free (it costs them almost nothing to keep their btc in a channel for a while).
And your super simple setup is completely isolated from the rest of the economic world. It wouldn't even work with cash because every merchant would need to manage a cash reserve in every store, manage transfers of cash back and forth, and the associated risk. It would be expensive and inflexible.
> If the merchant wants to receive funds via the gateway then funds need to be locked in a payment channel between the gateway and the merchant.
If I keep the scenario where the merchant doesn't want to lock anything in the LN, then the gateway can do it, and charge a fee for transacting through it. It's the gateway's choice to open such a channel or not. The "expensive" part is compensated by the fee which is chosen by the gateway operator.
If the merchant chooses to "lock" a bit to participate in LN, it's easier to rebalance his channels once 1000 people depleted the channel, eliminating the "inflexible". Besides, after all the fees saved by not using the Bitcoin blockchain for 1000 transactions, one can open a new channel to deal with that as well.
And again, nothing is ever "locked" in the LN, at any moment anyone (e.g. the merchant) can send everything back to on-chain or even to exchanges that use LN. There is no reason to believe that on-chain is less "locked". As such, it's not expensive nor inflexible, or in any case, less than Bitcoin itself.
Of course it would be easier if there was nothing to think about, but centralized solutions all have their set of problems as well, and that's another debate. In the mean time, LN works well at its scale and push back like yours feels like a "perfect is the enemy of good" kind of situation.
On a similar fashion (centralized alternatives to crypto ideas), there is Etleneum[0], which is a centralized smart-contract platform built on top of Bitcoin (lightning).
I used to watch livestreams of Øfdream making his music. Me and my friends felt close to him at the time because there wasn't a lot of viewers and we could easily talk. Feels bad indeed.
> I wonder if the people who run LE ever travel via the same means
Afaik, the LE team is distributed across the globe.
> If somebody took them out all at once, would the web's security essentially crumble?
No, there are other both free and paid CAs
> We have shitty hacks, like "serve this unique file on this web server that this domain record is pointing to", or "answer an e-mail on one of 20 addresses at this domain", etc.
Yes, but we also have certificate transparency. You can monitor all certificates issued to your domains and revoke them if needed. Not perfect but imo still reasonably safe considering you know that all the issued certs are on your servers.
> You tie a private key to domain ownership, and a private key to a domain record. Then you only have to trust registrars' keys/certs, and you can walk backward along a cryptographically-signed web of trust.
That exists and is called DNSSEC. If you haven't heard of it, you already understand: it isn't widely used. Also, it would require major rethinking of how we use the internet. Most clients do not validate DNSSEC, only public and maybe ISP resolvers do, but they can (and probably will) tamper the DNSSEC answers if they can better spy and mitm you.
> Your browser trusts the registrar's key X
Sure, we could do it in browsers, but the internet is wider than the web, and we would need to rewrite a great part or what we use every day (not saying that we can't or should not).
In the mean time, if you use a DNSSEC-compatible TLD and registrar, you can already sign your zones. That way, the current CAs will be able to cryptographically verify that the server asking for a cert also owns the domain/subdomain.
Right. Because of the hundreds of millions of domains out there, every one of them is monitoring the CT logs for their domains....? And once someone does create a false cert, by the time you find out about it, the cyber criminals have already hauled away a bank transfer or personal data, etc.
CT isn't security, it's a broken window.
> That exists and is called DNSSEC.
Every time I propose this, somebody equates it to something else (DNSSEC, DANE, etc), but what I'm proposing intentionally avoids those designs' pitfalls. I'm saying we need a brand new design that does not piggy-back on existing solutions.
> Also, it would require major rethinking of how we use the internet.
It would require rethinking of the workflows between registrars, domain owners, nameservers, and webservers. But in theory, browsers would work exactly the same; they'd just trade their ca-certificates for registrar-certificates. Validating the full chain of certs that they already do should be the same.
In France (at least), all swimming pools are protected by a fence. If you own a pool and don't put a fence around it, you can be held responsible for a child drowning into it.
It is possible this principle applies to other countries and other things than pools.
Looking for a 3-month internship (or a 3-month job contract) OUT of France between April and November 2021. I currently work as a fullstack developer and I learn about networking, infrastructure and systems administration on my free time and at school (dual education system).
Location: France
Remote: I prefer ONSITE (partially remote is alright), but I'm open to remote as well
Willing to relocate: Yes, globally
Technologies: PHP/Laravel, Javascript/React, Python, git, docker...
Interests: Fullstack Web, DevOps, systems (Linux), networking, automation, virtualization, cryptography
Résumé/CV: https://xfl.jp/qa4wYV
Email: pastech at sfr dot fr
I learn fast, and adapt to a codebase/environment efficiently. I care about quality over rapidity.
It's more complicated than that: using unbound is basically trusting your ISP with your DNS data (it's not encrypted so it can MITM). Using an upstream resolver doesn't necessarily mean you give up on privacy.
It may actually be more private to use a public resolver (with DoT or DoH of course) that will know your IP address but maybe not directly tie it to your identity (like an ISP does). Also, imo they generally have better privacy policies than ISPs (not that I trust those but still).
The next more private options include using DNS over Tor or Oblivious DNS (https://blog.cloudflare.com/oblivious-dns/). Those options are better for privacy, but I don't see them are default (at least for now) as they imply some slowness (Tor) or are more opinionated (ODNS).
Even after all that, your browser will leak the SNI header in clear-text (eSNI isn't popular yet) so your ISP can still get the precise name of the site you want to visit.
Thanks, I guess this is a fair point. I'm with Sonic (who I absolutely trust) but currently my fiber is provided by AT&T, who I do NOT. Still waiting for that native fiber.
I guess I'm so used to thinking about this from the the standpoint of building DNS resolvers for business that I didn't think through the differences when it's just my house's traffic.
> a SSL connection is transient and you can't replay it to show that Google's certificate digitally signed that email in GMail.
Actually, there the TLSNotary[1] protocol that allows you to use the https connection as a means to sign the web content your browser received.
There is the PageSigner browser extension that uses TLSNotary to sign webpages.
However, it seems like this project wasn't given a lot of love this last few years.
Good news is version 2.0 has been released just a week ago[2], with support for TLS 1.2, but with a major drawback for me: it now trusts a server generating the TLS keys for the notarized page. Sure, it's an "oracle" server not controlled by PageSigner but still operated by Amazon.
Regardless of the client-side software that you can't trust, there are also third-party servers that will store all the recordings with personal information for a potentially long time, which is unacceptable and isn't fixable by temporary hardware (as we don't have a temporary face).