Exchange Union Daemon 🔁 ⚡️


: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

A tool for converting .proto files to markdown for Slate

:dog::cat::horse: An offline-first mobile veterinary practice management web app



issue comment
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.

Created at 1 month ago
Created at 2 months ago
Add support for custodial off-chain accounts

My last handful of thoughts about this PR & feature:

  1. 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.

  2. 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.

Created at 2 months ago
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.

Created at 2 months ago
pull request opened
fix typo

Cool project! Spotted this while reading the README.

Created at 2 months ago

fix typo

Created at 2 months ago
Created at 2 months ago
Created at 2 months ago
Created at 2 months ago