Skip to content

Instantly share code, notes, and snippets.

@bretton
Last active April 24, 2023 10:59
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save bretton/d436e52a0dcdc3bc93675330a6df7b1d to your computer and use it in GitHub Desktop.
Save bretton/d436e52a0dcdc3bc93675330a6df7b1d to your computer and use it in GitHub Desktop.
Scenario Planning for a Lightning Provider

WIP 2018-02-08, comments updated 2022-04-24

Scenario Planning for a Lightning Provider

This gist is an outline of a likely scenario within South Africa, a developing country with a strong interest in Bitcoin & blockchain technologies.

Although it is expected within the LN community that users & merchants will run their own nodes, and fund their own channels, this approach seems to require a level of familiarity with the concepts and technology beyond the comprehension of the average joe, along with a level of access to bitcoin for channel funding purposes that is outside the financial reach of most in this country.

It's far more likely that mainstream adoption will come via parallels to existing widespread usage models, such as:

  • buying and loading prepaid airtime, via cash & EFT
  • linking credit card(s) to Snapscan, and paying by scanning a QR code.

A model I can see happening is a service provider makes an app available for a smartphone.

First, users download the app, sign up to become customers of the provider.

Then they proceed with two primary requirements:

  • FICA requirements (AML/KYC information)
  • Funding
    • Link a credit card
    • Make an EFT deposit
    • Make a cash purchase for a voucher code, which can be entered into the app

The provider would then verify the information provided, and based on funding and a unique app ID, setup a channel to the client, which is pre-funded in favour the client relative to the amount of money they deposited with the provider.

The client could then make use of the app to make instant payments.

Whenever the client ran low in balance, they would add further funding to the provider via credit card, EFT payment, or cash purchase of a voucher code from a vendor. The provider would then send more Bitcoin to their side over the existing payment channel.

The provider would have to ensure there were sufficient funded channels to the rest of the network, and with this being a costly exercise, only large players with deep pockets would be able to do this.

The provider could also provide services to merchants, in terms of node setup, LN channels, and cashing out Bitcoin received for cash.

The provider would generate an income from commission on the buying/selling of Bitcoin to fund client & merchant channels, along with fees from channels, and other value-added services in the setup of merchant facilities.

Benefits

The benefits of this model is it removes the technical barriers to entry for instant payments over the Bitcoin network.

A user need only download an app, complete the AML/KYC requirements, and fund via already familiar methods.

They do not need to know very much about Bitcoin to make use of a QR code scanner to make payments.

They do not need to calculate pricing in a volatile market - the app could simply show a Rand value, which may fluctuate.

Pitfalls

LN providers become 'another bank', but it is arguable whether this is a pitfall or not, because for the bulk of the bitcoin illiterate, it doesn't matter. They are expecting a bank.

Pending possibilities

Additional possibilities may exist in terms of providing credit to suitably credit-worthy individuals. The LN provider could do a credit check and prefund channels on a credit basis, with settlements coming from a monthly debit order.

This might be suitable for micro-loan facilities, where the risk of loss is not financially significant because the volume provided is so low - sufficient for a few small purchases only.

Challenges

In an ideal world people would have control of their private keys and wouldn't be dependent on providers.

Providers would also want to retain customers, and likely seek ways of preventing customers from closing channels with funds in their favour, and using the bitcoin elsewhere.

Customers will want channel sizes of 20k sats to 100k sats, any more is too expensive and venturing too far into the risky realm of fantasy in South Africa. What does the architecture look like for a million customers with 20k to 100k channels to LSP?

@bretton
Copy link
Author

bretton commented Feb 18, 2018

Slightly more detailed view of the economics here:
http://www.naturalfinance.net/2018/02/lightning-network-economics-and.html

@bretton
Copy link
Author

bretton commented Apr 24, 2022

Challenging questions from 2022:

  • how many thousand 20k sat channels do you support?
  • what do you mean you don't support 20k channels? That's R124 plus R4-R40 tx fee to setup.
  • how do you enable govt to pay R350 monthly grants with no tx fee, and recipients to spend at approved vendors for no tx fee? can't do this, then your solution is not for Africa, not ever.

@bretton
Copy link
Author

bretton commented Apr 24, 2022

According to this link

The average salary in South Africa is 31,100 ZAR (South African Rand) per month. This amounts to USD 2,009 as per the latest exchange rates in February 2022. 

The following illustrates channel sizes and Rand values as of 2022-04-24, 6:30pm SAST.

Channel size |  Value    | Notes
   20000     |    122.98 | low income earners won't go beyond this
  100000     |    614.89 | most South Africans won't go beyond this
  200000     |  1,229.77 |
  250000     |  1,537.22 |
  500000     |  3,074.43 |
 1000000     |  6,148.87 | Kraken minimum channel size
 2000000     | 12,297.73 |
 4619314     | 28,403.54 | Amboss says this is average channel size
 5000000     | 30,744.33 | close to average South African salary, Bitfinex minimum channel size
10000000     | 61,488.66 | fixedfloat minimum channel

@bretton
Copy link
Author

bretton commented Apr 26, 2022

The digital divide is evident with LN. The sub20k group is potentially the largest group of users in Africa. It may consist of wealthier individuals running bitcoin full nodes, with lnd and lndhub, who directly exchange sats for cash with other low income users - onboarding in the R100 level to their 'friends and family' node.

Additionally wallet providers like muun might service the sub20k group as people use it to scan payouts for reading LN newsletters. Muun will initiate a much larger channel and send some sats over for a small balance on the user side.

Other solutions like telegram and lntxbot may also allow coverage of the sub20k group.

Interfacing between the sub20k group and the rest of the LN is probably the growth area for LN service providers in Africa.

If you're poor, you're forever dependent on custodial solutions to make use of Bitcoin & LN.

@bretton
Copy link
Author

bretton commented Apr 26, 2022

The custodial LSP for the sub-20k market would need to commit more than 20k sats to opening capacity to the sub-20k client, and as much on uplink so client can spend.

So for every sub-20k sats client onboarded, at least 50k sats needs to be allocated over 2 channels.

Extrapolating from common channel and reserve minimums, also redundancy, every custodial LSP may be required to commit 100k sats in funding to service every sub20k sats customer, in return for a portion of their sub-20k sats.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment