pull down to refresh
Nostr Wallet Connect is in the works! We have most of it implemented, but turns out NIP-44 adoption isn't that widespread, so we need to downgrade to NIP-04 and do some testing to get it working. We've set up the relay hooks but still need to productionize / deploy our relay.
Lightning has always been broken in one way or another.
In the early days of Lightning, users ran nodes at home, which costed $300 in hardware, plus managing channels and liquidity. Way too expensive in terms of both time and money. Mobile wallets like Breez and Phoenix made things easier, but 'offline receive' was unreliable: payments would still fail if your phone was in power-saving mode, had bad reception, or was off the grid. Custodial wallets fixed that, but now you had to give up your keys.
@phlip9 and I got sick of all this and wanted a Lightning wallet that Just Works™ while retaining the self-sovereignty that Bitcoin is all about. After some iterating, we landed on the radical idea of running an entire Lightning node inside a hardware enclave (specifically, Intel SGX) in the cloud. The enclave isolates your node from the operators of the system - we can't read your keys. But because it's hosted, your node stays online 24/7.
This is our first ever public release, still in beta. We'd love to hear your feedback.
Sure thing! Right now we are offering free inbound liquidity and free JIT channel open fees to all of our users. Eventually each user gets about 50k sats of free inbound liquidity; above that, you'll pay daily interest on your inbound liquidity, and you can continue to keep that liquidity so long as you continue paying interest - your channel never 'expires'. When that feature comes out there will be options to limit the amount of inbound liquidity so you have so you can stay below budget or pay nothing at all.
The other big benefits are we are self-custodial unlike Rizful (your nodes run inside a TEE that comes with remote attestation), and keeping your node online 24/7 is free.
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.
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.
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
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.
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.
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.
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.
- 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.
- 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.
- Users can toggle between USD/BTC/sats display :)
- 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.
- 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.
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.
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.
Yes, that's the one.