Hacker News new | ask | show | jobs
by rodarmor 1778 days ago
It's actually pretty easy to get into and out of Bitcoin. river.com, is a US-based service that allows buying and selling bitcoin with USD, making USD transfers to and from a linked bank account, and making and receiving Lightning Network payments.

So you could set up an LND instance, get inbound liquidity with a service like Bitrefill*, and then withdraw any funds via the Lightning Network to a River account, sell the proceeds for USD, and transfer them to your bank account.

I use River as an example because it's my favorite, but there are many other services that you could also use.

* It's slightly subtle aspect of the Lightning Network, but in order to receive funds, you need inbound liquidity, i.e. a channel with your Lightning Network node with funds on your counterparty's side of the channel. This can be accomplished buy buying inbound liquidity from a service like Bitrefill: https://www.bitrefill.com/buy/lightning-channel/

1 comments

For those of us who aren't totally up on crypto stuff, liquidity in this sense is basically buffering the money until the final Bitcoin transaction settles? So if you buy, say, 1,000,000 sats from Bitrefill, that means you can only have 1,000,000 sats worth of transactions "in the pipeline", so to speak?

If so, what happens if you do have more than that amount in outstanding transactions? The transactions fail? They hang around and complete after the pipeline empties out?

What if I just want to assume that the customer is good for the money and queue it up myself for settlement once I have the liquidity to spare. Does Agora let me do that?

I apologize if these are dumb questions.

These are definitely not dumb questions!

Liquidity management is one of the most complicated aspects of the Lightning Network, and certainly one of the most counter-intuitive.

The basic primitive that makes up the Lightning Network is a "channel". A channel is between two nodes, has a fixed capacity, is opened by making a on-chain Bitcoin transaction, and is closed by making an on-chain Bitcoin transaction.

While the channel is open, the two parties to the channel can make payments between themselves, but do not have to publish a Bitcoin transaction for each one of these payments. They only have to publish a Bitcoin transaction when they want to close the channel, which nets-out the intermediate transactions made since it was opened.

As a concrete example, let's say Alice and Bob open a channel, with Alice contributing 1 BTC when the channel is opened, and Bob contributing 0 BTC. Initially, their balances on the channel are:

    Alice: 1 BTC
    Bob: 0 BTC
In this state, Alice can send a 0.1 BTC payment to bob, and the channel balances will be:

    Alice: 0.9 BTC
    Bob: 0.1 BTC
Alice and Bob can send each other money, but only up to the amount that they have in the channel. So at this point, Alice can send Bob up to 0.9 BTC, and Bob can send Alice up to 0.1 BTC.

However, at the very beginning, when Bob's balance was 0 BTC, he could not have sent money to Alice. Due to a lack of inbound liquidity, which is, quite simply, money on the other side of a channel, which can be sent to you.

This is an aspect of the Lightning Network that is very different from other payment systems, and from on-chain Bitcoin payments. You must arrange to have sufficient inbound liquidity to receive payments.

You ask a good question: What if I just want to assume that the customer is good for the money and queue it up myself for settlement once I have the liquidity to spare?

Let's imagine that we were in the initial state, Alice had 1 BTC in the channel, Bob 0 BTC, and Alice let Bob make a payment to her of 1 BTC. The new balance would be:

    Alice: 2 BTC
    Bob: -1 BTC
However! When a Lightning Network channel is closed, you divide up the funds from the funding transaction between the parties to the channel. The channel was funded with an on-chain Bitcoin transaction of 1 BTC, so there would be no way to pay out Alice 2 BTC from that initial transaction. Since both parties to a payment channel can close the channel at any time, Alice would be trusting Bob to keep the channel open until he no longer had a negative balance, and avoiding the need for trust is the whole purpose of the Lightning Network in the first place, otherwise we could just trade unenforceable IOUs back and forth.
Thanks so much for the explanation!
You bet!