Saturday, February 17, 2018

Lightning Network Economics and business models

The lightning network (LN) is an off chain protocol that works with the cryptocurrencies bitcoin, litecoin, and bitcoin gold and others.  Its not completely ready/deployed, but I think it will be successful.

This paper assumes a high familiarity with the concept of LN.  LN promises free instant direct payments, and cheap indirect/routed payments.  There is more anonymity than blockchains as most information exchanged between 2 parties stays with the 2 parties rater than becomes public record.

Business use case 1: Settlement layer for exchanges/banks
Bidirectional channels between exchanges allows them to conduct customer balance transfers free and instantly.  This is of significant decongestion benefit to the main blockchain freeing up transaction  space and lowering its fee level.

2. Customer to exchange channels
Exchanges offer gateways between crypto and fiat, but also between the blockchain and LN.   Closing LN channels is the means to transfer LN balances to the blockchain, but ideally, LN channels are never closed, because doing so closes a path for free and instant transactions and incurs blockchain fees.

Customers having a LN channel between them and their exchanges allows them the opportunity to mitigate the risk of exchange hacking/seizure by providing a way to keep some of their crypto funds off exchanges, but with an instant and free method of putting it back on the exchange.  They also gain the ability to load and unload LN funds with the blockchain without closing their channels by having the exchange convert the funds.

More importantly, the customer channels provide a way for the exchange settlement (and customer) channels  to rebalance:  restore transactibility in both directions of the channels. ie. a more popular exchange having transfers with a less popular exchange is likely to have the interchange channel balances saturate in favour of the more popular exchange.

Rebalancing economics: popular vs unpopular exchange
A popular exchange is defined as one where cryptocurrencies are deposited more, while an unpopular exchange is one where crypto is deposited less.  A more popular exchange will  eventually/quickly saturate (transfer capacity towards it being full) its direct settlement channel(s) with a less popular exchange and then also saturate the indirect channels (through customers of both).  There are several ways for the unpopular exchange to restore LN capacity towards the popular exchange
  1. open new direct channels to the popular exchange committing blockchain funds(/fees) to do so.  Or request that customer pay to open new capacity with it.
  2. let the natural LN fee structure through indirect channels develop that would charge fees in the direction of the popular exchange while being free (theoretically even negative) in the unpopular direction.
  3. A popular exchange where crypto is flowing is one where sellers are flowing in.  It is likely/possible that the trading price would be pushed down compared to the unpopular exchange.  LN's instant and free transfers towards the unpopular side would encourage channel rebalancing/deposits to the unpopular side.
  4. An exchange can request to increase a customer or counterparty "bank" balance in exchange for a decrease in their channel's LN balance, so that the customer-unpopular LN channel can be restored to customer balance, while the popular-customer LN channel set to popular balance.  Very likely that a sizeable fee is paid to the customer (and charged to the originating transferer) for this extreme LN routing assistance.
Deposit account regulation
Exchanges provide deposit/withdrawal services to their customers.  They do so with a private ledger that (should) keeps some audit trail of user requests.  It is not ideal that this audit trail is generated by supposed user clicks on their banking interface, and so not a truly verifiable audit trail.

An append only ledger as a form of blockchain is a verifiable audit trail.  Where user requests are cryptographically signed requests a mechanically verifiable/regulatory judgement can be made if the "bank" is a legally identifiable entity, and if the customer (not required to have public identity) is able to provide a copy of the blockchain generated by the bank that disagrees with the calculated balance.

The LN network and clients is fundamentally a cryptographic communications channel used primarily to secure and transact money.  LN clients including functionality to manage deposit accounts with nodes cryptographically signing requests and receiving/storing the "tx history blockchain".  A "LN communications service" that helps the nodes be banks by providing them software and/or acting as an intermediary layer that helps clients manage their requests/blockchain copies.  A inter/trans/exa-national "LN Regulatory service" can exist to handle "bank customer" appeals to impose retribution on legal entities to their customers.

but wait there's more ....

3. LN channels as 3rd party deposit accounts
A LN channel is a signed balance assignment by 2 parties (and 2 signatories).  There is no limit however on the number of output accounts (extra balances) that the channel can hold.  Simply that the 2 "real" parties agree on the balance assignment.  So, providing deposit accounts within a channel is possible.

The external security/regulatory service mentioned in previous section is made stronger because when closing a LN channel through timelocks (doesn't apply to penalty version of LN) there is time for regulatory intervention, and bankruptcy/insolvency cannot be a defense because funds exist in the closing transaction.

While a 3rd party LN channel deposit account does not provide the depositor with perfect cryptographic security (secure if secrets not lost/stolen), it is better than a deposit account with a single institution because it requires 2 parties (both individually liable) to collude to steal the depositors funds.

A primary use for such deposit accounts is to accumulate "dust" (small amounts) in small increments to be paid later either through LN or the blockchain during closing transaction.  Even if routed transactions are very cheap, when dealing in dust, even cheap can be expensive.  There are no LN fees involved in requesting a channel to create a balance for you (though there may be channel fees).  This allows the unbanked or unbitcoined to participate in LN without incurring the costs of opening their own channel(s).  Depositors can move their balance upon request to any other channel accepting deposits or to their own controlled channel for cryptographic security.

A secondary, but almost as important, use of "LN bank accounts" is for channel rebalancing purposes.  Moving deposits to other channels can free up directional capacity on the free'd channel.  The moved depositor can even be compensated (along with channel owners) for being moved.  This works the same as point 4 in rebalancing economics section.

LN Channel "bank accounts" can be teleported accross the network without a routing path between channels.  This improves rebalancing options for the network, and allows payments anywhere on the LN network without routing fees, though hosts may require fees if they have no economic relationship with the depositor.

The elements needed for a robust economic network
The use cases so far, seem to meet all of the preconditions for useful adoption and maintaining balanced payment capacity.  Even onboarding anyone who can simply download a bitcoin wallet (without resorting to usual means of obtaining cryptocurrency).  The key to all of the above is popular exchanges adopting LN.  There are certainly more adoption reasons and network enhancement benefits listed below.

Node quality
A node just refers to an account/person.  A high quality node is one that is highly available (monitors/responds to channels 24/7),  has enduring attentiveness (will be responsive for many years), highly connected (has many quality channels), offers a useful service, and is a payment destination away from popular receiving nodes.  The latter quality criteria is essential for channel rebalancing.

The highest quality node is an exchange service that you can use.  The 2nd best node would be one that you might still see a purpose of potential trade with, but that trades in the opposite direction from the service channels that you (or the wider public) often trades with.

4. Traditional commerce channels
Stores and consumer services accepting LN channels for free instant payments should seem like a good idea for stores and customers.  Once, accepting payments is seen as a good idea, LN remittances are also a good idea, as the flow to suppliers and employees can find their way to rebalancing customer channels.

Payment and remittance service are a good idea for those who don't want to manage any complexity or work in processing LN payments/remittances.

Security and risks in LN
An LN wallet connected to a frequently used computer has the same malware risk as an online bitcoin node/wallet.  Running the LN wallet on a single purpose low power computer may be a worthwhile precaution.

In addition, a LN wallet that is rebalancing or routing transactions for others is making frequent updates that must be saved, and backed up to an encrypted cloud service or private network computer.  Furthermore, to monitor your channel counterparties for potential cheating when offline, you need either an alert service that emails you, or confederates you trust enough to provide signed blockchain transaction copies to, and who will have their LN software always on in the future or can respond to their own alerts.

In terms of counterparty cheating risk, the risk is much lower with a publicly known commercial entity because even with the 1 week+ time window available to respond to cheating attempts (by submitting proof, or truer transaction copy to blockchain), its possible to prove cheating even if you are too late for the blockchain update.  Real identities of counterparties are strong insurance against cheating.

Who would screw yew?
In the section of node quality most people would fail.  They would not want to keep consistent uptime.  Most people would not have high bidirectional transactional volume, and are not already highly connected, or seen as potential trading partners for third party audience.

Because of these reasons and the security issues with managing your own poorly connected node, a gateway service can be appealing to many.

5. LN Gateway service
Opening a LN channel does not have to have a funding source controlled by the 2 counterparties owning that channel.  A gateway service is like a deposit account bank but with the added feature that customers open/fund LN channels in its name with the counterparties they wish.  Channel capacity funding customers of the gateway service may share in the fees generated by that channel capacity.

The gateway service should be a publicly identifiable entity, and the audit chain tools mentioned in (3) LN banks should be employed.  In addition to deposit account management audit trail, software should provide channel management commands that include delegation to gateway to maximize either convenience or fees.

An even better security proposition for general users is to open a channel between 2 gateways, and keep their bank balance in that channel.  From a security standpoint it requires collusion by the 2 gateways to steal customer/user funds.  The gateways have direct channels to where the user needs/wants to spend, though this is likely to be charged fees to the user.  Once the user balance decreases, the channel capacity between the gateways can be used to share fee income on that channel with the customer.  If LN is being used by the customer to pay monthly bills, then in subsequent months, the customer can open channels from gateway(s) to payees in order to make use of those channels free for the customer.

A note about the audit management software is that it should be free and open to provide a consistent and compatible interface for gateway services, and the interaction between dual gateways.  One arrangement of channel/shared gateway customer bank balances is the customer has 2 accounts (to be consolidated in a cooperative channel close) where each balance deposit/withdrawal results in adjustment of each specifically assigned channel counterparty's balance.

Operating a gateway service involves no investment by the operator in opening customer channels.  For a user that is already committed to have high uptime and their own direct channels to popular services simply for the free/instant benefits and small fee income, starting a gateway operation is an opportunity for more income and better utility/interconnectedness that also enhances the LN's "userful decentralization".  Useful decentralization refers to more highly connected hubs being obviously useful compared to fewer hubs.  A solitary connected spoke being useless decentralization, and a moderately connected node, less useful decentralization.  A new airport is almost always useful (and decentralized node of air network).  A cul de sac without any homes or interesting destinations is useless to the road network, and if it has useful destinations, strains/congessts the feeding arteries without opening relief paths to other road network arteries.

Ideal LN channel balances
The great majority of economic relationships are between sellers/buyers.  Even banks/exchanges and even personal barter relationships have periods of consistently imbalanced transaction flow towards one side.  So, all economic relationships at a point in time can be described as one of Net buyer/Net seller.  In LN channel terms a net buyer is one that is sending their balance to the net seller.

The ideal balance setting for a LN channel from both the buyer and seller's perspective is one tilted to the buyer, so that he's empowered to buy from the seller.  This means that for transaction and routing purposes, the seller would never need to charge fees to the buyer to send in either direction.  The buyer will want to charge fees to route towards the seller assuming he anticipates buying again.  If he doesn't immediately value buying power, the buyer c/would charge fees for routing in the opposite direction as well.  The seller would charge fees for routing to non customers... ie on its remittance or its non-business related channels.

Routing and rebalancing basics

  1. You cannot route or send LN txs if your total LN balance is 0
  2. Though you cannot route txs if your total LN balance is full (equal to all channel sizes), one way to make it less full is to make a deposit to an exchange or bank
  3. While a user might have preferred channel balances based on the spending propensity of channel partners on that channel, if all channels are to well connected nodes (gateways, merchants, exchanges), then it is always (at least usually) possible to spend the entire LN balance on one channel. ie. There is either a route departing every channel to your destination, or a rebalancing route towards hops on other routes that have multiple routes to your destination.
  4. Therefore, for well connected channel partners a 50% balance setting is ideal as it allows the quickest bidirectional routing fulfillment, and provides the most rebalancing path options upon moving the first balance.  When total LN balance is above or below 50% of total capacity, excesses or deficits should be moved towards lesser connected nodes.  This is simpler than setting preferred target balances per channel. 
  5. To be a well connected node needs just a channel to 2 well connected nodes.
  6. A node receiving more than it spends will either have to keep opening more channels to maintain routing capacity, or make bank/exchange deposits.  An exchange receiving excess LN deposits that are not traded will need to aggressively open (or have opened for it) channels to keep incoming routing/spending paths open.

Economics of opening LN channels
Some sellers are monopolists that take a "fuck you pay me" attitude to their customers.  Most sellers, though, are hungry for business.  All LN participants should accept a channel opening request from any other participant when the offering participant agrees to pay all opening costs (fees paid to blockchain miners).

A reasonable promotional proposition on behalf of sellers is to provide a customer credit equal to part or all of the costs in opening a LN channel between the buyer and seller.  In fact, if the seller offers a 3% customer credit for opening the channel, he's offering the equivalent of the visa/mc fees that the seller would pay on the first channel balance paid by the customer.  When opening a LN channel, the initial balance is set by the opener, and so for a merchant, offering 3% rebate for an immediate sale while gaining the benefits of a permanent LN channel.

Exchanges and banks don't save payment processing fees when their clients deposit crypto.  They are both ultra desirable nodes.  In the case of exchanges, they are by definition always perfectly balanced in customers being sellers or buyers.  Where customers are repeat traders, they should all want LN channels to their exchanges.  The fee to open a channel may be 50% higher (not positive of this amount) than a one-off transaction, but it is profitable to have the channel after the 2nd transfer, and there is additional profit opportunity from fees from that channel.  The gateway account option carries no additional security/operating costs compared to a personal wallet.  Withdrawing from an exchange normally involves the customer paying the mining fee (+profit fee to exchange).  For same fee, withdrawals should be preferred as LN channel openings, with subsequent withdrawals free.

Exchanges (and other businesses) may still wish to offer LN channel opening bonuses above and beyond the single transaction processing fee savings as a competitive marketing promotion.  So, in terms of user costs, many useful channels can be opened at no user costs compared to alternative payment schemes, while generating lifetime passive (your computer finds fees for you) fee income.

6. Opening LN channels for others
When a merchant accepts a LN payment, he does not own bitcoin that he can spend anywhere but back to his channel partner, until the channel is closed (which can be initiated by either party) which defeats the purpose of opening the LN channel just for the one transaction.  The normal buyer/seller financial relationship makes a balance tilted to the seller not useful.

A buyer opening a channel between the merchant and a remittance or exchange partner of the merchant (and of the merchant's choosing) provides the merchant with bitcoin that they can immediately spend it instantly and without fees, along with a channel they can reap long term benefits from.  If the channel is with an exchange, the merchant now has bitcoin which they can use to open a channel with a remittance partner.  At time of 2nd purchase from buyer, they can open a direct channel  between buyer and merchant (if first channel opened was with exchange).  If the buyer has a channel with the same exchange as merchant, then there is a closed rebalancing path that allows all parties to reset trade balances in their preferred direction allowing for the buyer to spend to merchant and merchant immediately offloading to exchange.   Even without setting up a direct channel between buyer and seller (for 2nd purchase), the buyer can pay the merchant again for free (small fee possible) either through his exchange balance or LN channel with the exchange, or for a small LN fee by routing through a LN path that goes through the exchange.

Payment/remittance gateways for merchants through LN will be popular services just as user gateways, but improving the merchant or its gateway's spending connections will usually always be the most valuable connection for the merchant.  If a business transacts everything through LN, then its revenue channels must carry the same volume as its remittance + profit (exchange/bank) channels.  Making the first transaction with the merchant on their "outgoing" side is of greatest utility to the merchant.

So, the discount/promotion offered to buyers in the previous section can be higher.

7. An electric utility settlement market
Electric utilities and bitcoin miners should form special relationships.  Bitcoin miners are heavy users of electricity and they may have more bitcoin than cash to pay their bills.  Electric utilities that own their transmission lines often have to trade with neighbour utilities.

Ultra High Voltage DC intercontinental transmission lines are one of the highest potential projects for humanity this century.  It would allow solar electricity produced in the deserts of the world at a cost of under 2 cents today (and getting cheaper) to be transmitted halfway accross the world (where it is night) delivered at triple the cost (but still cheaper than local fossil production).  Whether or not bitcoin can help fund the buildout of this infrastructure, using LN as an inter utility/national settlement network for electricity is something that can definitely be funded by bitcoin miners and other utility customers using the techniques in previous sections.

An advantage to using the "global money" settlement network that is LN for electricity settlement is that it adds substantial global cyclical transaction bandwidth that concentrates in both directions with the sun, and disperses before the sun returns again.  The electric settlement network can both borrow and lend capacity from the rest of LN.

channel factories
channel factories are a means of setting multiparty channels where pairwise subchannels between each party are set up with the advantage of lower blockchain fees than independently opened channels, and creating a defacto gateway service with connections to all nodes owned by each party.  The cost, however, is increased risk of one party becoming unresponsive, though there are "splice out" and "overlapping subgroup out" solutions to this that increases the size of the final commit transaction while waiting for unresponsive party to come back.

Faults with LN
The current specification of LN uses penalty transactions.  This makes "on channel 3rd party bank balances" not possible, and also makes channel factories and the following section(s)' features impossible.  Only the 2 signatory parties can ever receive an output, because with penalty transactions only one remedy to an inaccuracy is possible.

Other faults with LN 1.0 include tying up a minimum balance per channel recommended as 1%, using very small maximum channel (0.04 tokens) and transaction (0.004 tokens) sizes as a safeguard for bugs, and a dependence on mainchain miners setting a "congestion flag" on mined blocks that may potentially never allow a closed channel to unlock the balance of the closing party.

For these reasons, LN 1.0 is more suitable to LTC and BTG than BTC (bitcoin).  The main reason for a LN maturity delay for bitcoin are that the small channel sizes  prevent much of the decongestion benefits to the main chain.  Exchange channel openings may be 10 to 10000 times higher than they would need to be if there were no maximum size.  Enabling merchant mini/micro transactions  use cases are pro-congestion expanded uses for bitcoin, which are better suited until the decongesting appllications of LN/transaction channels are applied.

The good news is that alternate payment channel structures are entirely compatible with LN 1.0 and drastically different payment channel structures still compatible.  LN 1.0 gets the interchannel routing process right, and that is the only criteria for compatibility.

Escrow/Regulated 2 of 3 LN channels, is there a need?
A 2 of 3 signature contract is typically used for escrow/arbitrated contracts where a 3rd party is able to intervene if the 2 principal contractees are unable to agree on the distribution.  The risk of such a contract though is collusion between the arbiter and one of the parties.  LN channels could be created with 2 of 3 signature requirements (instead of 2 of 2).

A naive appeal of such channels is that it has the same connections as 3 channels for rebalancing and routing purposes, and only 2 of 3 people need to be online for rebalancing operations.  Yet, a channel factory creating those 3 channels still meets the requirement that only 2 of 3 of the parties need be online for a route or trade to take place.  It may also be possible to use a common routing to a 3rd party as an escrow service with 2 of 3 contracts within one/some of the channels.

8. Private blockchain enabler services for LN channels
LN (or more accurately negotiated payment) channels have much higher potential uses than tracking just 2 balances, some of which have already been described in this paper.  A LN channel private blockchain is described as an append only log managed by the 2 channel signatories.  There are 2 attack vectors on "the log":  Ommitting last few transactions or pruning the log to append to an older state.  The easiest structure to guard against these abuses is a 2 of 3 signature channel where the 3rd party understands how to compute final balances from the specific private blockchain channel, and  2 of 3 channels between each of the channel main parties, the "regulator 3rd party", and a publicly identifiable, reputation at stake, 4th party "regulator of regulators".  The main 3rd party provides the following functions:

  1. Acts as an oracle, such that a closing/consolidation of the blockchain between the 2 main parties obtains a closing signoff from the regulator effectively making the channel 3 of 3 signatures in the ideal.
  2. Maintains a copy of the chain each time it is modified, receiving updates from any stakeholders.
  3. Acts as a routing node to the chain preventing, or at least detecting, unfair blacklisting/refusal to include transactions from stakeholders.
  4. Assists with closing a channel when 1 of the 2 parties is not responsive for a considerable time.

The 4th party (regulator of regulators) is there to receive complaints from blockchain stakeholders and with the assistance of the 3rd party, to make correcting offsets in the sidechannels (the 2 extra channels with parties 3 4 and each of 1 2) of the private blockchain.  This assumes there is no 3 of 3 collusion (or 4 of 4).  A reputational stake is essential for 4th party, and arguable for 3rd party.  3 party collusion is provable with a blockchain (each transaction signed by channel partners, and refers to previous transaction hash) that is longer or different than the computed chain.  In 3 of 3 corruption/collusion, a remedy against the 3rd party is available if the 3rd party is monitoring other blockchains with 4th party as supervisor.  The proof of corruption is sufficient to make a balance adjustment on other 2 of 3 chains that the 3rd party is member of.  2 of 3 collusion is fixable within the channel groups set up with original chain.

The required stake of the 3rd party in the sidechannels would go down with the more channels they supervise.

Features and benefits of private settlement chain administered private payment (LN) channels
The features of private LN settlement chains are unlimited including handling other assets/balances that settle on multiple blockchains.  But they also must include the core LN functions of deposit/withdraw/move/route funds.

Benefits include:

  1. Only the partner side(s) reducing their balance must be online to sign the transaction in addition to the original stakeholder (spender).
  2. Final closing blockchain transaction is the simplest possible consisting of spend of original channel funds.  So, lowest bitcoin fee possible.
  3. Allows true 0 fee micro/nano transactions.  For example a channel between advertiser and web site that shares pageview/click revenue with browsers.
  4. upon channel closing, allows moving balances too small to be included on blockchain to the associated side channels.
  5. Can reset channels without closing them by moving 3rd party ("customer") balances elsewhere.  Or generating periodic external (non btc) blockchain transaction posts without closing the LN channel/posting to bitcoin blockchain.
  6. Cloud computing, cloud storage, smart contract "sidechains", micro power generation are all suitable "micro revenue" models administered by a pair of service-offering and a domain partner.
  7. Feeless micropayments are best implemented as a channel between payer and a micropayment aggregator service, though these also work if aggregator is a LN hub connected to payees, private settlement chains allow payees to accumulate funds prior to seeing benefits of opening a channel.
  8. cross chain balance transfers are LN transfers.
  9. Transformation of LN network as a cryptographic communications and routing  platform that includes services such as offline (email) storing/routing of communications, content publishing, and micropayments for those services without LN channel creation, but with LN channel settlement (3rd or  4th layer "blockchain") allows an infrastructure supporting nanopayments with much higher throughput and lower fee friction than other methods.
  10. The pitfalls of LN channels: guarding against cheating, inconvenience of online status of counterparty, minimum balances, are significantly mitigated by a "usually-on" 3rd party. 
An important glossed over concept in the above is the distinction between nano-revenue (payments usually by business to thousands or millions of individuals) and nano-payments (payments by individuals for services).  Individuals should have one "LN" channel with a nano-payment hub that also allows for settlement with their micro-revenue balances.  Businesses accumulating micro payments can also settle/consolidate amounts from multiple "hub channels".

The economics of closing channels
LN/Transactional channels are revenue generating assets.  Closing them is destroying that asset, and incurs a blockchain fee.  The LN 1.0 specification is defective in not formalizing the most useful fee allocation scheme to disincentivize closing channels:

  1.  On cooperative closing, fees paid should be proportional to balance of each party.
  2.  On unilateral closing, the closer should pay (most of?) the fee.  Asymetric transaction balance states should be used to account for this.
Economics of channel fees
These will be broken down by type of node.  The primary concern is return on channel opening costs.  Often, though the opening costs are paid by just one of the parties, even when they benefit both.  LN fees generated are based on a small fixed fee and a percentage of the transaction value.  How often a route gets used determines the ROI for the channel.  Pressure to make the fees low include the alternatives to routing through your node are:
  1. An on chain transaction: since it has fixed fees independent of the transaction amount, the average routing channel fee will limit the threshold for which a LN tx is a viable alternative to an on chain tx.  
  2. A direct LN channel:  about the same cost as a mainchain tx, but with long term revenue potential.  This limits average routing fee levels both in terms of frequency of transactions for the economic relationship of the ultimate 2 parties, and if too high, further incentivizes creating channels with infrequent natural trading partners (but high routing volume) for the high ROI of routing transactions for others.
Of note, LN transactions are cheaper the higher the price of bitcoin.  Transaction prices are measured in fiat equivalents, and so a % of transaction amount is smaller the smaller the amount of crypto is transacted (though % measured in fiat is constant).  A given channel capacity generates more fiat-equiavalent-fees the higher the value of the crypto.

with a 0.16 max btc channel, 0.04 max btc transaction, 5000 satoshi channel opening cost, then a LN fee of 1 satoshi + 1/10000th of value (what I understand to be defaults)
  1. with price at $10000/btc:  a $400 transaction costs 4.01c, a $4 transaction costs 0.05c.  a $0.04 transaction costs 0.0104c.
  2. with price at $1M/btc: a $400 transaction costs 5c, a $4 transaction costs 1.04c.  a $0.04 transaction costs 1.0004c.  A $40k transaction costs $4.01
  3. in satoshis, transacting(routing) the max btc transaction on LN  earns 401 satoshis.
These returns can be potentially very high if transaction volume is high, and/or if the channel opening was inherently a substitute for a payment that needed to be made anyway.  Note that the main barrier to nano transactions in the above is the 1 satoshi fixed transaction fee component.  LN 1.0 allows setting it 1000 times lower, which even at $1M/btc, would bring a 4c transaction fee down to 0.00014c, and feasibly allow 0.01c transactions and comfortably 0.1c transactions.

Economics of rebalancing transactions

Rebalancing transactions c/should be free of fees.  Every channel has a natural economic usefulness balance (more useful to net spender to have net balance), and a desire for nodes to increase the balances in their spending channels and decrease them in receiving channels.

0 fees for transactions in a certain direction is probably sufficient to get regular rebalancing to occur.  If a network of 0 fee routes exist then rebalancing will be easy.  The incentive to participate in 0 fee directions is to give your "customers" the power to buy from you.  Yet if I have a channel with coinbase that I usually fund from, my other channels could still potentially use me as a route to pay coinbase, and so unless I have an immediate need to withdraw funds from my coinbase account, I can set fees to transfer in the counter-economic direction to just be low enough that a route through me is likely to be used eventually.  Until I need to withdraw from coinbase, I don't need to set fees in other direction to 0 to facilitate that.

An important feature needed on LN is the ability to set fees for setting a balance to the halfway point (likely lower) compared to fees for spending over the halfway balance point.  A halfway balance allows earning fees in 2 directions for routing as well as providing direct spending flexibility.

Economics of LN fees for exchange/bank nodes
As a competitive advantage/service and to promote LN health, exchanges/banks might set transmission fees on channels with their customers to 0.  Since exchanges are likely to be the most well connected nodes, and they offer the ability to set LN balances to any point through customer account balance changes, they offer high availability short routes from most point As to most point Bs.

Customers of an exchange will thus be able to set their fees for transmitting towards the exchange to 3-10 times the "standard fee level" because going through theses channels is likely to be shorter and higher-available path than alternative routes.  This further incentivizes creating channels with exchanges even without customer relationships with the exchanges.

Economics of merchant LN fees
A merchant is a (likely highly connected) node with  overwhelming balances on its customer channels in its favour.  Even if it is able to get a significant portion of its employees and suppliers on LN payment channels, a profitable merchant will have an overwhelming channel balance in its favour, and the need to funnel the excess balance to an exchange/bank.

A merchant customer that is also highly connected with spending capacity on routes towards exchanges is highly valuabable to a merchant, because it gives it a path to spend its LN balance towards something useful to it, while freeing "return capacity" for any customer that has a route to the exchange, and likely willing to pay any reasonable fee to use that route.

Merchants are also likely to offer negative channel fees in the direction of their customers, thereby enabling payments from exchanges to those customers to route through them cheaper than any free or direct path between the exchange and that customer, and allowing the merchant to increase its balance with the exchange in an immediate subsequent transaction.

For this reason, having channels to merchants is a highly profitable option for any node connected to popular exchanges.  Negative fees on the merchant side allows for higher fees on channels that could be destinations of either the merchant or its channel partners.  It also further incentivizes employees/suppliers to obtain LN channels with the merchant because they can have relatively high fees in both directions and capture high trade volume on their channels.

Earlier in the paper, I mentioned the option for a customer to pay a merchant invoice by creating a channel between it and a supplier.  The value of that option involves creating value for 2 parties and so is difficult for the channel creator to capture remuneration from both sides of that channel.

If a customer already has spending channel capacity with a merchant's supplier, for instance an exchange, then there are 2 options to funding a channel between the merchant and exchange.

  1. Pay the merchant invoice through free routing through the exchange assuming the merchant already has such a channel, and its spending capacity is nearly always tilted to the exchange.  The customer captures no value from this option, other than a free transaction, and may find the effects of depleting his exchange balance to be negative.
  2. Create a direct channel with merchant, and set routing fees to exchange to 30x "standard levels" and routing fees to other nodes to 5x-10x standard levels if the customer prefers those channel balances to be depleted.  30x standard can be 0.3% of transaction.  The value to the customer is a long term profitability of a high volume route to a merchant, and the "double fees" of the return path from the merchant to an exchange or suppliers.

An important LN feature (needed rather than existing) is the ability to chain transactions and chain routing.  If a customer has a $50 channel with a merchant but $1600 spending capacity to an exchange that the merchant is happy to dump all proceeds to, then the customer can spend or route $1600 in chunks, where each chunk results in a chained transactions in the reverse direction and routed to the exchange, freeing up pending capacity for the next chunk.  Being able to advertise $1600 spending capacity to the merchant as a routing option is important to facilitating large transactions (and large fees paid by merchant).  A "chained route back" setting can travel backwards for multiple hops on a route permitting large transactions through small channels and/or small direct routing capacity on those channels.  Its also a component to permitting payments of an invoice through multiple routes.

Economics of paying fees instead of generating fee producing assets
For those who receive a lot of LN payments, respending those through any available route by paying fees can be preferable to spending mainchain bitcoin they may not have to create new channels.

In the example of creating a channel with a merchant for payment, the creator can "capture" the merchant by setting high fees to any route the merchant would use to spend those funds.  The customer can also setup a channel with the merchant's employee, and capture the employee's use of funds on that channel too.  Setup channels with the employees landlord and credit card payment processor to capture those channels.

Note that the value of these channels to the "customer's" partners only exists if the customer keeps spending power above 0 on some of his LN channels.  Otherwise there is no routing possibility, and spending the balance only exists for inherent services provided by the channel partner.

When accepting a channel from a random source, the value of that channel to the recipient can be negative if the recipient incurs any closing fee costs, and spending the funds through LN is either impossible due to all 0 balances of partner, or the fees for spending through LN are higher than closing the channel and spending the funds through alternate means.

Even if fees are 1% or 2% to spend through a route, this can be more attractive than alternative ways to spend/take the LN channel balance, yet there is a tremendous difference in the value of a channel when your partner has high balances and an eagerness (low fees) to spend them compared to a partner with low balances and high fees to route through them.

Economics of being a LN hub
A hub is defined here as being a node that spends mainnet bitcoin to create channels, and that has little to no natural economic receipts for btc/LN payments.  If the hub can consider natural spending options, then over time, their balance in useful channel directions will tend to 0.

A hub with no economic value is a poor choice to pay (use mainchain btc) to create a channel with.  Destinations that you might route to (especially if they are net recipients of LN payments or at least have high bidirectional volume) are always better choices, because you can capture your partner's spending on that channel instead of being potentially extorted yourself in fees.

An important needed feature for LN is an ability to query (or for a node to publish voluntarily/verifiably) a node/hub's connections, spending capacity, channel addition rate, and fee levels on its channels.  A node's natural revenue rate is also valuable, but less important than the former list.  Doing so can provide a single number estimate of the potential value of that node as a trading partner, and from that single number, a merchant discount/service credit can be calculated, or the general advice of not connecting to a hub can be ignored, or connections to hubs with the highest index score can be pursued.

Still, positive hub metrics are likely temporary.  A node could/will eventually stop creating useful channel routes. 

A "good hub" has a channel with an exchange and a merchant.  An important LN needed feature is the ability to discriminate on fees based on the source.  The most important spending balance to maintain is one towards exchanges.  So fees routed from an exchange being lower than the standard charged to "captured" channel partners, can allow for high transaction volume flowing to "your captured merchant" (from a customer routed through exchange), and then high fees on the return path from merchant to exchange.

A routing segment needs to be understood as 2 channels connected to a node.  And fees set based on the 2 affected balances for the node, and the perceived value of the combined effected balances from the node's perspective.

Connecting to other "good hubs", and generally having (mutually not needed) low fees for routing to the other hub allows you to "dump balance" towards the other hub while increasing your other balances, and increasing your overall transaction volume/paths towards your captured high fee return routes.

Basically, if any funds routed to a merchant always get immediately routed back through you to an exchange at 2% fee, then huge potential profits are realizable by even offering slightly negative fees for routing funds to the merchant in order to boost volumes.

An essential LN tool to help merchants mitigate their capture would be a variable customer discount based on the route chosen to pay them, that gets factored into choosing the best route by the customer.  For example, a base LN discount of 3% could be offered to all customers (VISA alternative reference), but this discount is adjusted down based on the routing fees the merchant must pay to spend those funds where it wants to (exchange most likely).  This would mitigate the "extortion" of merchants to "market levels". 

Though, "chained route back" and "extortion" are mitigated by using routes that go through exchange directly to merchant, and then "chained back" as merchant deposits on exchange  provides low fee preferred value to customer and merchant, the value of hubs becomes using alternate balances than a customer's exchange balance, and rebalancing alternatives.  Hubs/customers also onboard merchants and their LN capacity.

Despite the above, a "good hub" can simply be a channel to an exchange.  If the expected centralization occurs, there are still paths to every useful destination, and the exchanges adoption of LN can be motivated by other business models than LN transaction profit (pressuring fees down).  LN and hubs become a mutual check on exchange merchant services extortion.  LN channels can be profitable without extortion power and priced below current crypto merchant service fees.

Economics for the marginal LN participant
The marginal LN participant is one who is unlikely to be enthusiastic to run a node, and unlikely to own bitcoin.  But it is someone who someone else wants to pay through LN.  The merchant's employee in previous sections may make a typical example.

Onramping these people is best done through exchange accounts.  It avoids the extortion capture of previous solutions, and an exchange account is a jumping pad towards forming new LN channels if the user wishes to adopt LN's security model (security from exchange's risks/policies), transactibility and revenue generating features while choosing bitcoin as an investment/savings vehicle.

LN, even with 1.0,  facilitates "mini payments" ($1- $8) which allows new digital business/transaction models at scale greater than VISA, both regulated and unregulated, with a standard way to enhance any exchange's merchant services by opening up those who can transact freely with it.

Centralization concerns
By describing a network topology that economically rewards channels with exchanges and popular payment recipients suggests a highly centralized LN world.  Some people wish for decentralization.  LN is a decentralizing force permitting permissionless payment channels (structural relationships).  It incubates many services to facilitate access to the network (including launching new competing exchanges and other highly connected hub services), eventually applications including blockchains currently implemented as separate tokens, and eventually the web protocol itself will be updated to support payment channels.

Where centralization is an objectively undesirable risk is the risk of an attack on key hubs/exchanges harms the whole network.  Redundancy is valuable in of itself.  Exchanges successful in being a highly centralized focus of the network, are likely to seek LN fees instead of relying only on main service fees.  A cure for centralization is centralization, motivating alternate path creation.

Privacy and regulation concerns
An open LN network provides advantages of discoverability and enhanced trust from identity-based relationships.  The LN protocol itself leverages the privacy infrastructure of the TOR network, and privacy-first approach is built in, though deanonymizing of bitcoin addresses and LN nodes is likely (and easier with centralization).  Open portions of the network can and should exist if only to satisfy the needs of those transacting with the official economy and financial system.  Nodes can act as bridges between open and dark LN paths, as well as bridges across currency tokens.

Estimating value of a channel
Projecting a 6 month payback on channel opening costs seems like a sufficient incentive to justify opening that channel.  When opening a channel replaces a mainchain transaction that payback can be almost immediate.  At 1/10000th transaction fee and 5000 satoshi channel opening cost, payback occurs after 50M satoshis (0.5btc).  Over 6 months, that is 300k satoshis/day in transaction volume, or a single transaction worth of saved fees.

Transaction volume processed increases the more channels one has.  Many people will respond positively to the binary decision of opening channels to many destinations.

No comments:

Post a Comment