43
44
21
:zap::gem: A game of speculation using bitcoin and the lightning network
A simple and lightweight library for creating a JSON-RPC 2.0 compliant HTTP server
:zap::rainbow: Purchase pixels with lightning payments - Submission from L2 Summit Hackathon 2017 @ MIT
:dog::cat::horse: An offline-first mobile veterinary practice management web app
Events
Creating invoices with `amount: 0` is not possible
Zero value invoices seem desirable, I know there's a decent bit of real-world usage of them, and it would make sense to support. Especially if it just involves dropping that required tag. The other side of the coin would be having an ability to pay zero value invoices, which looks like is currently supported since you can specify an amount as well as an invoice when paying an invoice.
Add support for custodial off-chain accounts
My last handful of thoughts about this PR & feature:
-
It might be nice to have an RPC call that increments an account's balance. That way there's an easy way to, for example, add 1000 satoshis to an account. Or possibly decrement balance (by passing a negative value), but then there'd need to be the checks for sufficient balance on the account. Right now, you can update an account's balance via RPC, but that's only good if you're trying to set the balance to a specific amount, not add or subtract from the existing balance. Trying to do that by querying the balance and then updating the account balance would be subject to race conditions (maybe the balance updates in between the two calls). I figure this can be done in a follow-up PR, though.
-
It'd be nice if self-payments from one account to another were better supported. Right now, it seems like it does work if I use the
--allow_self_paymentflag, which then sends a payment out one channel and back in on the same channel. I think it'd be cool to be able to make an account-to-account payment without actually needing to make a real lightning payment (which may incur a fee, delay, and/or chance of failure). But I can imagine that would be a complicated change since it would likely break some internal assumptions in lnd about payments, namely that they actually involve the external lightning network. Just something to think about for future work.
Add support for custodial off-chain accounts
Yes, on every startup we re-initialize the payment tracking for each payment and invoice update stream.
So this should be pretty robust. Though in general "lnd instance that comes online & offline unpredictably" is never recommended in a production environment. Or are you thinking about a mobile setup? Curious about your use case!
Gotcha, I think one thing I was overlooking was that (if I'm not mistaken) litd will stop when it sees that lnd has stopped. So this Start function will be called every time either litd or lnd restart. My concern was only that lnd goes down, all subscriptions are lost, and then when it comes back up we don't re-establish the streams.
I wasn't thinking about a mobile setup or anything like that, just about what might happen if there are unexpected outages in an otherwise stable environment.
fix typo
Cool project! Spotted this while reading the README.
sangaman push sangaman/rn-ldk
fix typo
