:zap::rainbow: Purchase pixels with lightning payments - Submission from L2 Summit Hackathon 2017 @ MIT
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.
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_payment flag, 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.
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
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.
Cool project! Spotted this while reading the README.