HN user
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).
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.
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.
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.
I've experienced the opposite: a lot of what Symfony gets wrong, Laravel gets it right at the moment (also imo).
Exactly, both contribute towards a common goal and they can easily share code thanks to a common language.
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.
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
Questions are welcome by email.