pull down to refresh

We're Max Fang and Philip Hayes, co-founders of Lexe (lexe.app). AMA
27.1k sats \ 41 comments \ @MaxFangX 5 Oct 2023 bitcoin
Hi everyone,
We (Max and Philip) are working on a new self-custodial Lightning wallet called Lexe which can send and receive funds 24/7. We want to make Lightning as simple as using a mobile app, letting users custody their own keys, giving our users the ability to receive and settle payments 24/7 without having to run any infrastructure themselves.
The core technology that powers our product is Intel SGX, which allows programs to run in an hardware enclave completely isolated from the rest of the software stack, even the operating system. You might have heard of confidentiality of data at rest and in transit - SGX is part of a class of hardware-based technologies called TEEs (Trusted Execution Environments) which allows data to remain confidential in use, among other things. After seeing the Lightning ecosystem struggle with 24/7 interactivity and async payments, we thought: "What if we ran an entire Lightning node inside an SGX enclave? Then our users could be online all the time without giving us access to their keys." Over the last year and a half, Philip and I have been working hard to make this vision a reality.
Our mobile app is still in development, but most of the core components have already been built. Two weeks ago we launched our website, open-sourced our main codebase, and went public with our company and product. If you'd like to learn more about Lexe, you should check out these resources:
Here's some more links about us in general:
We (Max and Philip) have known each other since 2016 and worked on various projects together since then. We've worked on decentralized Bitcoin mixing protocols, wrote the world's first undergraduate course on cryptocurrencies, and were founding members of Blockchain at Berkeley, among other things. Philip also worked at Facebook Diem (formerly Libra (now revived as Aptos)) and wrote most of their networking stack.
Max (@MaxFangX) and Philip (@phlip9) are both online as of this post. Ask us anything!
Edit: Converted links to Markdown
write
preview
related posts
3472 sats \ 2 replies \ @TonyGiorgio 5 Oct 2023
Appreciate all the hard work and thoughtfulness with the security considerations file. I'm just still unsure that it's wise to be doing this. The attack vector for crypto SGX honeypots are high. At the end of the day, you have to extract the seed in order to present it to the user, and do occasional SGX server migrations which will require this seed again to provision.
Is this all so that you can offer offline receives for consumers? Because this is being worked on as far as the concept of Lightning goes.
Or do you see this as something you get enterprise customers with that already feel confident in the SGX model, whether that is wise or not?
reply
310 sats \ 0 replies \ @MaxFangX OP 5 Oct 2023
In terms of there being a "honeypot" due to keys being centralized in one place, SGX makes things more secure, not less. If someone wants to hack a centralized custodian like Coinbase or Binance all the attacker has to do is get into their infrastructure to get access to their funds. If someone wants to hack us, they have to first get into our infra, and then also break SGX.
We believe that despite expected protocol advancements in handling async payments / offline receives (e.g. PTLCs), the problem is fundamental - someone has to come online in order to settle the payment. Our approach is simple - just keep the user online.
reply
202 sats \ 0 replies \ @phlip9 5 Oct 2023
There are definitely security tradeoffs here -- I'm somewhat more confident
  • The user nodes are never exposed to the public internet, which removes a huge class of attack vectors. All inbound connections are either from our LSP (inside the same VPC) or our gateway proxy, which authenticates the user connections. Standard hot wallets are notoriously problematic here.
  • All communication user app <-> node enclave are e2e encrypted+authenticated. Provisioned seeds/keys are never exposed to Lexe.
  • User nodes won't provision secrets unless it's to Lexe-signed enclaves running on our infra (among other things)
As far as features this enables:
  • I think there are some cool additional payment products we can enable, like subscriptions, automatic weekly remittance payments, etc... That'll always work even if you're on vacation or you lose your phone :)
reply
3153 sats \ 2 replies \ @benthecarman 5 Oct 2023
I love the concept of doing this, basically self-custodial without the UX tradeoffs, however, it relies on SGX security model which AFIAK has been compromised tons of times. Do you guys have concerns about this?
https://sgx.fail/
reply
2934 sats \ 0 replies \ @phlip9 5 Oct 2023
Self-custodial w/o compromises is absolutely what we're aiming for.
As far as SGX security, Intel has been pretty good about releasing mitigations and TCB recoveries in a timely manner. Usually that means we need to change a few compiler flags in exchange for reduced performance or update some certs. Running on the most recent Intel CPUs also helps a lot here. When the Lexe app wants to provision keys to the node, it can check that nodes have mitigations applied, are running on recent hardware, etc...
At the end of the day, security isn't all-or-nothing and I think SGX gets us to a good middle ground.
reply
2 sats \ 0 replies \ @MaxFangX OP 5 Oct 2023
Adding on to what Philip said, we've also tried to be practical and architect things in a way where we aren't solely depending on SGX for security. User nodes aren't exposed to the public internet, for example, which would allow attackers to attempt exploits by sending crafted network messages. If a 3rd party wants to attempt an SGX exploit, they'd have to get into our infrastructure first, or find a vulnerability in our reverse proxy.
reply
3734 sats \ 1 reply \ @DarthCoin 5 Oct 2023
  1. Why only BOLT12 and not LNURL/LN Address?
  2. Why LDK as backend?
  3. Why is displayed USD on the main wallet screen and not BTC? We are talking about a Bitcoin wallet not fiat wallet, right?
  4. What is doing the "Fund" button on the main screen? Open LN channels or buying sats from an exchange?
  5. The 0.5% fee/payment is only for sending or also for receiving? Is an interesting model to keep online a node and charge a fee per tx, without need to take care of liquidity. But what about privacy? How do I know that the liquidity you provide is not actually tracking all my txs?
  6. Is Lexe another FBI stunt move like FBIbook?
reply
2917 sats \ 0 replies \ @MaxFangX OP 5 Oct 2023
  1. We do intend on supporting a subset of the LNURL protocols - our current priority is launching our product. It's been a while since I read over the specs, but last I looked there were only a handful of protocols that met our security requirements - we don't want Lexe to accidentally become a 3rd party that can steal payments, for example.
  2. LDK was the obvious choice for us because it's the only implementation where the Lightning logic is fully separated out from I/O. This is a hard requirement for running in SGX, where you don't have access to things like disk / network / syscalls. We're very grateful for LDK and the Spiral team.
  3. Users can toggle between USD/BTC/sats display :)
  4. The fund button is for if we eventually want to add an exchange integration in the future. We'll probably end up removing it, the screenshot on the website is a preview of our very much WIP mobile app.
  5. Good catch - yes, the 0.5% fee is both for sending and receiving. We thought that this business model was the most fair because users don't have to keep paying for a node that they don't actually use (which sometimes happens in a subscription model). To make this possible, however, Lexe has to be the only LSP. So we'd see the amount and directionality of payments, and know your channel balance (not your on-chain wallet balance), but we don't know (1) who you're sending to or (2) who you received from.
reply
2633 sats \ 3 replies \ @WeAreAllSatoshi 5 Oct 2023
How do you pronounce “Lexe”?
reply
741 sats \ 2 replies \ @phlip9 5 Oct 2023
lek-see :)
reply
2 sats \ 1 reply \ @cryotosensei 5 Oct 2023
What’s the inspiration behind the name Lexe?
reply
116 sats \ 0 replies \ @MaxFangX OP 5 Oct 2023
Lightning EXecution Environment - a play on "TEE" :)
reply
1649 sats \ 1 reply \ @idsera 5 Oct 2023
How long until first users be able to download and test Lexe wallet?
reply
1280 sats \ 0 replies \ @MaxFangX OP 5 Oct 2023
I'd estimate in about 6 months. There's a lot of work and it's just the two of us! It also depends if / when we scale up the size of our company.
reply
1253 sats \ 1 reply \ @idsera 5 Oct 2023
Will Lexe use Photon to backups? https://docs.photonsdk.org/
reply
11 sats \ 0 replies \ @MaxFangX OP 5 Oct 2023
Backups are stored using the Google Drive v3 API so that it is interoperable with our current E2EE persistence system (we call it our "vfs"). We don't have access to users' GDrive API credentials though, since these are provisioned into the enclave and hidden from Lexe.
reply
1250 sats \ 3 replies \ @kr 5 Oct 2023
Philip, what was your experience like at Facebook? It’s interesting to see that your team has spawned multiple Lightning businesses.
What was the general sentiment around the Lightning Network while you were on the Facebook team?
reply
6732 sats \ 2 replies \ @phlip9 5 Oct 2023
funny story, myself and 3 other ppl pitched David Marcus on integrating lightning into Messenger/WhatsApp in like October 2018, rather than building our own blockchain (DIem/Libra). in hindsight, I don't think LN was ready at the time. but pretty funny how things ended up w/ Lightspark and all
reply
1261 sats \ 1 reply \ @idsera 5 Oct 2023
Do you think David in Lightspark will be able to onboard big companies like Airbnb or Uber?
reply
945 sats \ 0 replies \ @phlip9 5 Oct 2023
if anyone could, he's probably got the street cred to pull it off
reply
1115 sats \ 1 reply \ @idsera 5 Oct 2023
Is it only 0.5% in first receive ln payment too? So no inbound liquidity setup fees?
reply
11 sats \ 0 replies \ @MaxFangX OP 5 Oct 2023
We expect to give users a small amount of free liquidity when they receive their first payment over a JIT channel initiated by our LSP. The user pays for the on-chain fees of opening the channel but there are no liquidity fees for now. It's possible that we'll add a "premium liquidity" service in the future to supply extra inbound liquidity for high-volume users that want it. Paid for using Lightning, of course.
reply
1115 sats \ 0 replies \ @phlip9 5 Oct 2023 freebie
Hey all, @phlip9 here. AMA about Lexe, crypto, Intel SGX, or the reproducible user node builds I added a few days ago (just nix build .#node-release-sgx) :)
reply
912 sats \ 4 replies \ @2bithits 5 Oct 2023
This sounds similar to phoenix's model.
reply
1879 sats \ 0 replies \ @MaxFangX OP 5 Oct 2023
Yes, there are a number of similarities. Both of us run an LSP and user nodes only connect to the LSP(s). But with Phoenix, the Lightning node runs on the mobile device, while with Lexe, the Lightning node runs inside an SGX enclave in the cloud; the mobile app is mostly used to remotely control the node (after the node and mobile app mutually authenticate each other of course). This difference in architecture allows us to help users receive payments when they're away from their phone.
reply
1034 sats \ 2 replies \ @nerd2ninja 5 Oct 2023
Phoenix releases for Android first and iPhone second though, whereas this doesn't even have an Android option on the site ;_;
Also, Phoenix is based on Eclair (both written by the same company) whereas this is using LDK (could be relevant to what gets supported in the future)
I would also point out, that Phoenix's model is the LSP model which is also used by Breez and Mutiny. Its a good model imo, I like it.
reply
832 sats \ 0 replies \ @phlip9 5 Oct 2023
oh we support both iOS and Android! @MaxFangX and I both use Android phones primarily
I'll update the site so it's clearer...
reply
705 sats \ 0 replies \ @MaxFangX OP 5 Oct 2023
Adding to Philip said, we use Flutter/Dart for the app which is cross-platform. Hypothetically we could even ship a desktop app as well.
reply
100 sats \ 2 replies \ @chris42 5 Oct 2023
Ah forgotten about sgx, interesting to see it being used to run a lightning node. I remember the corda guys using it(although you might know this from your Diem time ;)
reply
10 sats \ 1 reply \ @phlip9 5 Oct 2023
yeah i know Kostas came from Corda -- great guy. think he's now chief cryptographer @ Sui, working on (more) interesting zk stuff :P
reply
100 sats \ 0 replies \ @chris42 5 Oct 2023
Nice! Makes sense he's doing zk stuff, I still use his explanation using two balls to explain zk
reply
100 sats \ 3 replies \ @kr 5 Oct 2023
Can you share an ELI5 explanation of the importance of Intel SGX?
reply
1378 sats \ 2 replies \ @MaxFangX OP 5 Oct 2023
Alright: Intel SGX is important because it allows someone to run a computer program for someone else without having access to any of their sensitive information. This is useful because not all people want to run the programs they use themselves, so they can let someone else do it for them without sacrificing their privacy.
reply
0 sats \ 1 reply \ @kr 5 Oct 2023
Got it, is Intel’s technology unique in this regard? or do you expect there will be a number of other companies with commodified solutions over time?
reply
1529 sats \ 0 replies \ @MaxFangX OP 5 Oct 2023
There are a few other options - Arm Trustzone, AMD SEV, RISC-V PMP, Nitro enclaves, etc, which all come with different features. Nitro enclaves does not have remote attestation, and AMD SEV includes the hypervisor in the TCB. We chose SGX because (1) it's the most mature, (2) it has the most complete feature set, especially remote attestation, which is critical for verifying that you're actually talking to the program you expect.
I have a confidential computing section in my notes if you'd like to take a look
reply
1 sat \ 0 replies \ @cryotosensei 5 Oct 2023
How do you intend to encourage users who have been conditioned to use their current wallet - self-custodial or otherwise - to drop it and give your untested product a go?
reply
0 sats \ 0 replies \ @hugomofn 6 Oct 2023
Congrats on the launch @MaxFangX @phlip9! Great to see more self-custody options.
reply
0 sats \ 1 reply \ @idsera 5 Oct 2023
How the Lexe will swap from lightning to onchain? Third Party services like Boltz?
reply
11 sats \ 0 replies \ @MaxFangX OP 5 Oct 2023
Lightning -> onchain will be handled by splicing out of the channel - no need for a swap.
reply
0 sats \ 0 replies \ @028c94cae7 5 Oct 2023 freebie
Lexe.app
76 sats \ 0 replies \ @idsera 5 Oct 2023
deleted by author
reply