The Lightning Conference 2019 Recapitulation

The Lightning Conference 2019 Recapitulation

By Veriphi almost 2 years

The 19th and 20th of October 2019 is a weekend which even Berlin won't be able to forget. More than 500 developers, investors, entrepreneurs and simply enthusiasts got reunited for the first Lightning Network Conference where a mix of technical presentations and product demonstrations took place.

It's important for those in the space to capitalize on the knowledge shared through the presentations but if like us, you couldn't attend, you could watch the 14 hour conference available on Youtube here.

Else, if like many, you can't find the time to digest the conference, we've prepared a brief recapitulation. Enjoy.


The Lightning Network is still in its infancy, many hard forks are to come.

Everything that can be done on the network, will be done on the network. Invoices, messaging, service advertisement.

UI is pretty good already, UX is lacking but heavily improving (ACINQ, Joule, Zap)

Fiat on / off ramps are coming to Lightning (Zap, Sparkswap, Escher.)

Tokens are coming to the Lightning Network (RGB Spectrum)

Biggest takeaway : Lightning opens the door to many financial services such as :

  • Routing
  • Submarine swaps (on chain to off chain swap)
  • Inbound liquidity
  • Watchtowers
  • Blockspace derivatives

There is still a lot of work to do regarding the different metrics of the Lightning Network, analyzing this data provides a lot of insight on how to conduct development.

The Watchtowers standard isn’t ready yet, but they are really important for the LN.

Entreprise Lightning by Jameson Lopp

Why enterprise lightning? Many benefits.

  • Lower fees
  • Instant withdrawals on exchanges
  • Privacy with KYC/AML service
  • Routing fees will not be the driver for going on Lightning but instead you can save on chain fees as an organisation heavily.
  • Lightning is a scale free network, it’s fairly well distributed. Jameson is unconcerned about a hub and spoke model.
  • If we have a big liquidity provider, we will get to use channels way longer since we can top them up.
  • Chainalysis did research where it concluded that 150 million of recently active addresses are owned by businesses, 25 million for individuals.
  • 50% of payments outputs come from exchanges, if a portion of this could go on Lightning it would save a lot of blockspace, a lot of those payments are even exchange to exchange.

Enterprises will get into the space when it’s much more stable, they will be looking for. An additional level of assurance and the following items :

  • Software to deploy many nodes for redundancy
  • Tools to manage liquidity on the nodes
  • HSM Integration
  • Analysis software
  • Policy enforcement
  • Accounting tools

Rusty Rusell, Blockstream

He starts the talk with a Public Service Announcement about how the Lightning Network will change, to become more adversarial. It will have to develop defences. This is a general agreement between the developers of what will happen in a few years.

  • Fees will rise, current ones are insufficient to maintain connectivity. To block spam, there might be upfront fees.
  • Slow HTLCs will suffer since they’re easy to attack.

Proposed Idea

If there’s not an intermediary for a transaction, an invoice is the key to keep the vendor honest.

That’s why cryptographical invoices are an important feature.

Much like bolt 11, it has a similar address format and can be turned into a QR code. An offer is done. It’s composed like this : lno + TLV data + nodeid/signature

  • TLV data contains the offer itself : offer_id, description, expiry (can have none unlike bolt11, path (optional), max quantity (optional), amount + currency.
  • It can have recurrence : period, paywindow, basetime, etc.
  • You could also add additional info, phone number, address, voucher code, whatever.
  • It can also be for unsolicited payments, it has no offer_id in that case.

This gets on the payer’s hand and his node pings the payee’s node, who then sends back a real invoice to that particular node. It can then be paid in an ordinary way.

Then there is the invoice_req message:

  • Certainly it’s onion encrypted like HTLC payments.
  • It contains the offer_id, plus :
  • A sender chosen tag
  • A transient payer pubkey
  • Optional quantity, amount, recurrence number, delivery info.

Then there is the invoice_reply message :

  • It could say this is an error, either not understanding what the offer is or it’s expired.
  • It can be a remplacement offer

The invoice

  • Contains an s value which is the invoice secret that is actually a merkle tree of the invoice_req
  • This allows the payer to prove to third parties many parts without revealing them such as :
  • Delivery information
  • You paid it

We can also have an invoice_req have a address/qr code format.

  • Ini1 + TLV data + nodeid/signature
  • This is very useful for refunds or any kind of reverse flow, by proving you’re the one entitled to it.
  • This gives you static invoices, unlike bolt 11 which can’t be reused and expires.
  • It also gives you user-controlled recurring payments, unlike the pull model of Credit Cards.
  • Finally, this also applies to donations with receipts.

Fabrice Drouin, ACINQ

  • There are many UX Problems with Lightning, it would take 30 minutes to demo a transaction.
  • They’re linked to the Protocol design choices such as :
  • Single funded channels
  • Penalty transactions
  • Hash based payments
  • Routing mechanism
  • Offline (watchtowers)
  • backups

How to improve on those problems :

  • AMP : distribute a payment through many channels
  • UX issues could be hidden from the channel
  • Difference between on chain and off chain
  • Channel management

But you can’t solve generically, there are choices to make :

  • Inbound liquidity, someone has to lock funds.
  • Zero conf channels, there’s a risk involved and the service provider could take it.

They’re releasing a new wallet called Phoenix, where many UX improvements are demonstrated, it’s kind of an experiment. They’ve been developing Eclair Mobile for 2 years now, which is a LN Node and doesn’t hide how LN works, you have to make channel management. It’s widely used.

Lightning is not a network where the rules are always shared, nobody can see what happens between two participants.


  • Zero conf channels
  • On demand channels : routing to channels that don’t exist yet
  • Based on tweaking the short channel id field in LN payment requests
  • Inbound channel will be created on the fly the payment will be processed
  • This gives you instant channels on both directions
  • You could restore the channel state from the node you’re connected to, there is trust but it still works.
  • You’re connected to ACINQ node on every moment.
  • We use swaps in and out, level of trust as well. It’s going away
  • Trampoline nodes : delegate route calculation to another node while preserving privacy, it currently isn’t since they’re the provider

A lot can be done to improve UX, at both protocol and application level. It has to be done while keeping it non-custodial wallets. On the long run, they will KYC/AML


Will talk about the state of the specification development. There is a path constraint which means that you can’t send over your channel value on a payment. The solution is Multi Path payment, there are many flavors.

  • Multi-Path (MPP), singular payment hash, preimage reveal.
  • Atomic Multi Path (AMP). randomized payment hashes, no preimage reveal. Additive secret sharing. It offers better privacy.
  • Discrete log atomic multi-path (DAMP), randomized, reblinded payment points. Optional preimage reveal aka invoice tunneling.


  • New amp tlv record for final hop, builds on mpp record
  • Differences from mpp
  • Sender supplies randomness for HTLC preimages/hashes
  • No reveal, sender already knows preimage
  • Invoices become reusable
  • More privacy, unique hashes
  • spontaneous payments (keysend), don’t need an invoice
  • I start by generating root seed shares which I can then create the root seed.
  • You can create the child preimages from that as well.
  • The receiver can then turn it into child hashes.

Will O’Beirne

Over the last year and a half, so much improvement has been done on UI by many wallets such as :

  • Zap
  • Lightning App
  • Joule
  • Tippin
  • Breez
  • Blue Wallet
  • Wallet of Satoshi
  • Eclair

Although these applications look beautiful, UI isn’t the same thing as UX.

  • Currently, to setup a Lightning Wallet it takes around 1 hour.
  • You have to note the seed words, sync to the network, fund the wallet, wait for confirmation, open a channel and wait again
  • A solution to this lengthy process, it’s to combine tasks.
  • When I’m syncing, I could be noting down my words and funding my wallet.
  • Education can also be done at that moment.
  • Then, when the time comes to setup a channel, improvements can be done.
  • Offering nodes to connect to like Zap and Eclair.
  • Educate a user about who he wants to setup his channel with.
  • It can also be a good idea to open more than one channels.
  • What about Autopilot? It was supposed to work like that.
  • It works well but not always.
  • The user remains uneducated, the decision is opaque.
  • If it fails, the experience can be very frustrating.
  • Ok. now that a chanel is open. Why can’t I receive funds?
  • You need inbound liquidity, someone else to open a channel to you.
  • It’s important like Eclair and Lightning App do, to make the user know that he can’t receive payments if he doesn’t have inbound liquidity.
  • There are paid services such as LNBIG, Lightning Power Users, Thor by Bitrefill.
  • A great solution for both sides liquidity is if a user can make an on chain transaction to you, then you open a channel to him and you push that amount to his side while keeping some on yours to give him inbound liquidity.
  • Even if everything happens, errors happen. Most errors aren’t analysed, a way to do so, is payment probing like Christian Decker has talked about, to test routes before taking them.
  • The graph data is available to the node so this should be leveraged more to improve the experience.
  • Fees are important, UX shouldnt hide them, particularly since they will go up.
  • Also opening and closing channel onchain fees.
  • Channel opening is a business.
  • Ux shouldn't be too hidden, our user base are bitcoiners who want to learn.

Hedging the Chain by Jack Mallers

  • This talk won’t be about the Zap Wallet, which is known by now, and many wallets are on the market, people want to hear something else.
  • Zap is a business since it operates the Olympus service now.
  • Through a conversation with family members, who have a financial background, came the ideas for this talk.
  • Everyone at this conference uses the bitcoin blockchain a lot, for opening and closing transactions when dealing with the Lightning Network.
  • The problem is that using the bitcoin blockchain costs money. How much? A lot, some more, who knows what it will cost in the future?
  • A block is limited in size, its space is scarce in a weird way.
  • Blockspace is a commodity. Gold and Bitcoin are commodities but block space as well?!?!
  • What roles do we play in this blockspace market as developers and businesses? We’re buyers. We are inherently short fees.
  • At the same time, as Bitcoiners, we realize that fees must rise for Bitcoin to prevail as sound money since supply is capped.
  • Every business has financial exposure and usually that is hedged with derivatives.
  • An example of a derivative being used is a corn producer expects to make 100$ in revenue per day on Corn, if he gets 100 bushes at 1$ a pop, he can make that amount.
  • Although if the price drops and he can’t make that revenue, his short position on the derivatives market will make him enough money to compensate.
  • The other way around as well : if the corn value skyrockets and he loses on his short position, well it doesn’t matter since he wins on the increase of the value of his market!
  • Back to Bitcoin, on the other side of the bet, miners are inherently long on fees so they make more revenue.
  • A derivatives market can exist since there are parties on both sides of the bets. We need a liquid on-chain fees derivatives market.

Smartphone to Cryptophone by Phil Chen

HTC built the first android phone on September 2008, which was an open-source project at first but Android quickly disappointed by becoming one of the best data collecting technologies.

HTC Exodus 1 (700$) has a hardware wallet built in it and it isn’t just feature, it’s the essence of the product. That’s why it’s called the Cryptophone. It’s physically separated from the Android part of the device, fully offline.

  • It allows you to look after your money, to make payments and to even lend and borrow. HTC calls it the UBF (Universal Basic Finance)
  • You become your own bank.

What happens when you lose your phone?

  • Shamir Secret Sharing is the technological solution.
  • You have to make 5 of your friends and family members to download an app on their phone and keys get stored to their keychain.  You only need 3 out of 5 to recover.

Today is about announcing HTC Exodus 1S (219$)

  • This phone will run a full Bitcoin Node with Tor configuration possible. It’s based on Abcore.

The Perfect Storm by Udi Wertheimer

Recently, Peter McCormack admitted that he had never run a node before in a tweet storm and a lot of folks got triggered, some are calling this episode NodeGate.

Running a node isn’t an easy process and the experience isn’t the best.

If we’re going to make this the best experience for most users, they don’t need to be aware of the node, it can run in the background and it should probably be a mobile experience.

First off, let’s ask ourselves, why do we run a node?

  • For those who say it’s to help the network, the meaning of that isn’t very clear. A user should run a node for selfish reasons.
  • To store the blockchain? No reason to do so.
  • Broadcast a transaction? Maybe but there’s ways around this, connecting to another full node, even with privacy, is possible.
  • The reason we run a node is to verify incoming transactions and to receive notifications.

It seems to many users that without them running a node, only with a mobile wallet app, they are doing both those things.

  • Someone else’s nodes is verifying the transactions and you’re basically trusting them to tell you the truth.
  • You’re also leaking some data which isn’t good for your privacy.

Mobile phones are getting better in terms of CPU performance and also disk size, although that isn’t necessary since you can easily prune a node for it to be only 5GB of data.

  • What about bandwidth and battery consumption? Those are the critical problems and to fix them, the mobile app could be setup in a way that it syncs only when connected to wifi and a power adapter.
  • We can’t expect users to do these tasks but maybe as developers, we can do it for them.
  • Also something that can be done is an assisted IBD like a simple tool on a desktop or laptop computer which can be easily transferred to the mobile device later. It’s a challenge to make it a good experience but it’s possible.
  • Also, when a user prepares to receive a deposit by asking the app for an address, the node can naturally start resyncing in the background since a transaction is to be expected.

When it comes to Lightning, what does a user need from his node?

  • To verify opening and closing transactions.
  • This includes potential breaches.
  • The important thing is that off-chain transactions don’t required the Bitcoin node.
  • If when you open a channel you’re using your own funds, you don’t even need to verify it.

When it comes to closing channels

  • Cooperative closing is easy
  • To protect from breaches, set up a long timeout (1 week) and sync up every night.
  • Also, you could use a Watchtower service.

Boxes are cool for power users, but for most users, just make it disappear. They don’t need to know that a node exists.

Lisa Neigut, Blockstream

There are tokens in life and we can call anything a token. If I produce scarves, I sell them for USD tokens. When I got the USD tokens, I deposit them on a bank and there is an interest rate and sometime later I got more tokens.

How can I make the BTC I have make me more BTC?

  • Obviously, you can mine Bitcoin.

There are two ways to get staking rewards :

  • Currency Inflation : central banks and Bitcoin mining.
  • Utility : transaction fees on Bitcoin, interest accounts (loans)

On the Lightning Network, there are utility rewards mostly for routing but there can also be a Liquidity Marketplace.

Bitcoin needs better price discovery, not only in its value but on all the services that can be created on top of it.

How it works? A node advertises on the Lightning Network their rates for liquidity providement. If it’s easy to advertise, a marketplace comes out.

Goals for this idea are :

  • Provide a more visible valuation for liquidity across the network
  • Make liquidity easier to access

How to make this a reality :

  • Add dual funded channels to the protocol
  • Finalize liquidity advertisement specification
  • It has to be into two implementations for it to be considered into the BOLTs.

Justin Camarema

He works at bitrefill which is a company that sells giftcards and phonere fills in exchange of Bitcoin, on Lightning as well. They also offer three services.

  • Thor Turbo : you’re able to buy channels
  • Thor : inbound liquidity
  • Thor Charge : submarine swap

Lnurl : https query string, open source, to talk to mobile wallets. It’s one of the main technologies used, for withdrawals and payment, we want to push that standard

  • There’s QR code communication to connect

Thor channel opening service : users face liquidity challenges and need inbound capacity.

  • We’ve lowered the price and we will, the reason it was so high it’s because we get to pay the commit fee. Hopefully we will lower them even more
  • API front, it’s useful for businesses and merchants to have more capacity for your services, used by wallets, could be a fallback.
  • APi document is on github.
  • Thor Turbo channels
  • You can give it away as a gift
  • You have to scan a QR code and you can instantly have access to the Lightning Network
  • Zero conf channels
  • We’ve lowered the fees as well, it’s ranged so you can choose the amount
  • 100 000 sats to half of network maximum
  • Api as well
  • If your business wants to enable Lightning withdrawals, it would be good for them.

Recharge : it basically allows anyone from paying a Lightning invoice.

  • We did it with coinbase users in mind
  • webLN support for invoices
  • Embeddable options for wallets, services
  • All payments methods over the api and accept zero conf under 200 euros in certain situations
  • API valuable to add support lighning payment
  • Topping up existing lightning wallets
  • Useful as a fallover

We want to have tor as an option to be able to connect out and create channels to tor mobile wallet users as well as those running nodes exclusively over tor

Service for businesses to transfer lightning on chain

Guaranteed capacity service for businesses, monthly fee to always have incoming capacity


  • Lightning is on master branch now, no ETA for release.
  • Electrum was started end of 2011, why ? because there were only custodian web wallets at that time, besides core.
  • was a huge scam which resulted in the loss of many hundreds of thousands of bitcoins, even bigger than mt gox.
  • Electrum servers will remain on chain only, lightning will run client side only.
  • Private channels, no routing
  • There will be public and private watchtowers and you can choose it.
  • Did a full implementation in Python.
  • Cli also
  • EPS won’t work with Lightning

Iterative capital

  • They are a mining operation in the US and in China but also an OTC trading desk.
  • They have a volume of half a billion dollars annually for the OTC desk.
  • They wanted to reduce the friction between fiat conversion
  • Escher Hub will be an app & SDK that developers should deep link their wallets with Escher app.
  • They connect to your bank account and your channels and do the bridge.
  • 0% money movement app, and 50 bps for spread.
  • Buy up to 2000$ instantly with Zelle, a bank protocol, on Lightning.
  • Buy up to 2M with ACH same day, base layer only.

How does it work?

  • You log into your bank accounts inside the app, they never leave the device
  • Then you connect your channels or your addresses of your wallet.
  • And you make a transaction which completes instantly.
  • You can also move money from your bank accounts. You can sell BTC.

Multicoin Capital

  • Product succeeds when the problem it solves will naturally exist for 10 years from now.
  • Bitcoin has achieved protocol market fit, and for a long time it was the best investment in the land, better than a private company shares.
  • Now, this doesn’t look like it will be the same anymore since Bitcoin is worth too much now.
  • Still, Bitcoin’s value proposition is to be a store of value. It means, anyone will want Bitcoins either now or later.
  • People will want to be paid in Bitcoin. How? With Lightning Network.
  • Venture scale businesses

Problem 1

  • Hot wallets.
  • Solution : Hardware Nodes, Watchtowers or Software Wallets.

Problem 2

  • Liquidity management is hard.
  • Solution : Opennode, Lightning Loop

Problem 3

  • Multi hop payments are hard
  • Solution : Bitrefill, Breez, etc.

Problem 4

  • Routing revenue is low
  • Solution : Pandora (New protocols), Lisa’s Proposal.

Problem 5

  • Capital efficiency
  • Thor Channels : Zap, Bitrefill.
  • Short term loans to solve that problem.

Problem 6

  • Client side validation
  • Solution : dev tools

Lightning Network exits.

  • Acquisition by web 2.0, fintech, exchanges
  • STO on Liquid Network
  • RGB


  • TravelbyBit is a company that offers travel services online.
  • They’ve also installed Lightning merchant solutions in 400 shops in Australia
  • They have implemented BOLT 11 + BIP 21, which allows to simply show 1 qr code and people can pay with either layer 2 or on chain
  • They are implementing NFC soon, and their strategy is to go one step at a time with the merchants and with the users, first get them set up stacking sats or accepting payments, then roll the nodes and advanced stuff.

GIACOMO & Maxime

Three parts of the talk

  • RGB Protocol
  • RGB & Lightning
  • Lessons learned about the Lightning Network while working on this

RGB Protocol

  • Asset protocol proposal, based on Bitcoin and not on Shitcoins
  • Based on the client-side validated approach, it doesn’t pollute the time chain with metadata of the assets
  • Lightning Network compatible
  • Purposes are : it’s for scams as well, but to make USD IOUs like Tether are important to skip KYC/AML, digital collectibles
  • Testbed to experiment for the architecture, also a R&D project

RGB & Lightning

  • RGB leverages direct benefits from Lightning support, like privacy & scalability
  • Somebody must be online, either you or someone else, to receive the data since it’s client side validation.
  • You must save all the off-band metadata of the token.
  • Both of these issues are more critical in LN than on RGB.
  • Asset security & UX, DEX Functionality are R&D to be done for multi-asset LN implementations
  • Spectrum : turn the Lightning Network nodes in some kind of trading bots to skip the liquidity issue to route payments in different types of assets It can also improve liquidity with Spectrum.
  • If this works, we can have heavy improvement on Privacy on LN. Currently we have network level privacy problems. If you don’t know what is being transmitted through LN then you have can annoy espionage.

Lessons learned

We learned a lot, we is Pandora, Bitfinex, inBitcoin, etc.

There are two types of extending LN functionality such as extending the payment LN functionality like :

  • Routing algorithms
  • Channel rebalancing
  • Submarine swaps
  • There is also the layers on top of LN such as :
  • Onion routed messaging protocol
  • Gossip protocol
  • Commitment transactions for commitments
  • Lightning wasn’t built for these kinds of layers 3 and layers 4s so it’s natural that it has limits when it comes to support these kinds of technologies, but the efforts to make it better aren’t that big.
  • One of the key pieces to building these layers is the Client-validated rich state, which is to be found on the Lightning Network since it’s supported by default, but can also be leveraged in Bitcoin and Sidechains.
  • From Gossips to onion routing, messaging is a natural application of the Lightning Network technology as well, which is useful to transfer the client-validated rich state and there some issues were found.

What are these protocols being built on top layers?

  • RGB : Digital Assets (securities, collectibles)
  • Spectrum : DEX Lightning Network Solution
  • Storm : trustless escrowed storage & messaging
  • Prometheus : high-load parallel computing

RGB & Spectrum

Spectrum is an RGB extension into payments which can allow a liquidity provision over these payments that works like a DEX.

Privacy gets enhanced

  • Client-side validation : No L1/L2 visibility
  • Zero-knowledge bulletproofs for transfers, getting Blockstream insight on how to implement it.
  • Hardened Lightning Network analytics
  • Enhances LNP/BP adoption through Stablecoin usage
  • New node monetisation options
  • Potential off-chain BTC transfer L2/L3 solution

Client side validation uses cryptographic commitments and single use seals using zero footprint public key tweaking procedure which has originally designed to put any commitment data into the public key without expanding its size.

There are ways these technologies might be implemented unsecurely which is the reason LNP/BP standards, which aren’t covered by BIP or BOLTS but should be seen as best practices to be used on the market.

RGB and Spectrum are composed of those standards, particularly, collision resistance elliptic curve based commitments, we need to be able to add these commitments to LN commitments and HTLC transactions. This will be necessary for any type of client validated L3 type solutions.

What is required to enable L3 solutions :

  • Cryptographic commitments
  • Public key tweaking in channel transactions
  • Fee adjustments in channel transactions
  • Simple TLV extensions in all LN messages
  • Gossip protocol for announcing client-validated state
  • Onion routing as a generic messaging protocol
  • P2p messages to agree on the client-validated state parameters
  • Generic LN node plugin extension standard supporting the above to integrate these L3 solutions on top of any implementation

In conclusion, Lightning Network is not ready for this stuff yet for many reasons.

  • The current specification approach doesn’t allow to reconstruct simple things such as a sequence diagram that can simultaneously cover channel transaction updates and messaging between the nodes for multi-hop payments.
  • LN isn’t built with L3 in mind.
  • LN isn’t even a beta yet, there are many things to add yet such as :
  • Hash-locks -> EC-curve derivation for multi hops.
  • American call-option problem.
  • To_remote output : P2WPKH -> P2WSH with CSV-lock
  • Eltoo after SIGHASH_NOINPUT
  • Gossip protocol changes improving traffic issues.

The aim is to fix subsets of Lightning Network to provide robust operations to eventually allow these kinds of L3 solutions in the future.

ALEX BOSWORTH: Principles of Lightning Liquidity

Misconception: sending on the lightning network is always going to be cheap (more of an aspirational goal)

  • Liquidity is a scarce resource.

Liquidity: channel funds can only be used once (until capacity is reached), until it comes back (channel capacity is filled back up).

  • Takes time and effort.
  • There is also a fee to get capacity committed to network and must keep an eye on both channel and node.

Lightning network is different to bitcoin’s main network of altruistic forwarding.

  • As we add more money, we start to add more fees.
  • There are technologies that exist, such as multi-path payments that make it more efficient, but there are still costs for the users and node operators.
  • Still need a market solution to make things cheap, all the while making sure that capital is allocated the right way.
  • Need to focus on costs and benefits.

Costs associated to being a node operator

  • Possible loss of funds.
  • There’s a potential of a forced close due to uncooperative peers.
  • Having no activity on the channels created.

There is a utility provided to using the Lightning network, so a lightning node can be monetized. There is also a need to rebalance.

  • Circular rebalancing: taking the balance of one channel because you are bidding on future traffic on that channel.
  • If you’re running a script to balance, you are potentially unbalancing someone somewhere else.

There is then a need for an external settlement system, which would be opening up a new channel (using the external settlement system of the blockchain).

  • Not always possible, some nodes only want one or few channels, or want inbound liquidity only.
  • Pointless from the high level perspective of the flow graph. If one person is receiving liquidity and another is losing, we’re not making the payment any more possible to reach its destination.
  • When doing circular rebalance, you’re telling the market where liquidity needs to be, giving a signal to another peer. At the market level view, we are solving problems since you can condense your liquidity.

Single pair liquidity: believe there is a need for liquidity in a specific direction, thus creates a new channel or buys liquidity from someone else, so you can get the liquidity to where you believe it is going to be useful towards.

Currently there are no ways to differentiate between different sources of liquidity, can’t say that inbound liquidities are different.

  • All liquidity is treated in the same way creating an inefficient market.
  • Solution: all fees on outbound side are equal, and only think on inbound side.
  • If acquiring inbound liquidity on a single pair market, don’t know if you’ll be making money in the future on a good or bad route, which makes it hard to justify a purchase of inbound liquidity, unless all outgoing channels are the same fee.

Another cost is time

  • Time is needed to understand liquidity.
  • Write programs to make sure that liquidity is allocated efficiently.

Balance of Satoshis: automation in order to reduce downtime and manage funds in channel (too little or too much).

Things to look at with Balance of Satoshis:

  • Activity state of channels (am I making money or not).
  • What peers am I using to send or receive?
  • Are ppl making new channels with me, affecting my liquidity.
  • Uptime of my peers.
  • Channel closes.
  • Peer policies.

Lightning loop service: way to break flow constraints.

  • A new node can’t do circular rebalance since no one has assigned liquidity in their direction → prisoner of the flow constraints.
  • With this you can pay through your peer, to the lightning loop server, which then sends back to you on-chain using external settlement and non-custodially locked to the same payment hash so you can increase your total inbound liquidity.

Autopilot assignments: recommended to direct it when using it in LND.

  • Doesn’t necessarily make decisions but follows guidelines.
  • It can copy channels of peers it deems good (have good liquidity)

External things to keep track of:

  • Monitor chain fees.
  • Look for new market entrants.
  • Monitor known nodes in graph.

Another cost is security, since you’re using a hot wallet.

Future security features:

  • Watchtowers
  • Rebroadcasting
  • Exit policies
  • Macaroons
  • Low access principle
  • Hardware tokens
  • Redundancy
  • Backups

TREY GRIFFITH: (Not So) Atomic Swaps

Sparkswap Desktop allows users to buy Bitcoin with USD from their bank accounts instantly.

  • It connects to your Lightning node, does not have one.

The talk will focus on Atomic Swaps in Lightning and similar tools.

What is a Hash/Time-lock Contract (HTLC):

  • How money in the Lightning network moves.
  • Transactions in a channel consists in sending a HTLC to your counterparty.
  • Payee can’t receive a payment until they reveal the preimage to the Hash.
  • If the preimage isn’t revealed within a certain time frame, the money is returned to the payer.

HTLC lifecycle on Lightning:

  1. Payee creates invoice that includes the hash of the preimage that they have created previously and that is shared out of band;
  2. Payer creates HTLC to the payee;
  3. Payee accepts the HTLC.

Finalization of the HTLC:

  1. Settlement between payer and payee with the revelation of the preimage.
  2. Payee cancels HTLC.
  3. HTLC is settled on-chain.
  4. First two options can happen instantly so long as both channel counterparties are cooperating.

New feature in LND: Hold-invoice

  • As an application developer, you now have direct control into how these HTLCs gets finalized.
  • Can plug into the lifecycle of an invoice and finalize it the way you want.
  • Can link multiple transactions together into a single atomic transaction à multi-hop payments.
  • Independent transactions that are linked with the same hash.
  • Allows the payer and the payee to go through an intermediary without having to trust them (cannot take funds from the payer unless they release them to the payee).
  • Intermediary is not at risk either since they cannot have funds taken by the payee unless they are able to claim funds from the payer.

Multi-hop HTLC lifecycle:

  1. Payee extends HTLC to intermediary;
  2. Intermediary accepts HTLC and extends it;
  3. Payee accepts HTLC;
  4. Payee finalizes HTLC;
  5. Intermediary finalizes HTLC.

Submarine swaps: Lightning network transaction with a HTLC on one side of the transaction and an on-chain HTLC on the other side (see Loop).

  • Can have an on-chain payment that is linked to an off-chain payment (pay an off-chain invoice with an on-chain payment).
  • Can help expand the experiences that are possible with the Lightning network.

Cross-chain Swaps: linking transactions across blockchains (e.g. the Bitcoin Lighting network to the Litecoin Lightning network) to enable trading between the two assets.

How can we link the transactions to elements of the real world (not just other blockchains)?

  • A physical transaction is linked to an off-chain transaction.
  • You’d pay a vendor with an HTLC in which you control the preimage. Vendor can’t collect payment until they provide their end of the deal to collect the preimage.
  • An HTLC acts like an escrow that doesn’t require trust in a third party.
  • The equivalent in the Fiat system would be an Escrow Administrator (trusted third party).
  • Without increasing the trust assumptions of these two modes of escrow, you can have a single transaction in which two parties can exchange Bitcoin for fiat.

This is what Sparkswap does:

  • Buy Bitcoin on Lightning that uses a trusted third-party escrow provider with a system that looks like a HTLC (uses a SHA-256 hash to cash an escrow). They trade with the use bitcoin for USD in a way that either party only gets their funds if the other party does to.
  • When you fund your account from your bank account, you are sending funds via ACH to their escrow partner (held in a US domicile escrow account).
  • When you buy bitcoin, you are first requesting a quote from the Sparkswap server. The quote is returned with a Hash to use when creating a transaction to obtain bitcoin. When you accept the quote, you are: 1) adding a Hold Invoice on LND and 2) telling the server you accept the quote. The server then sends the HTLC with the same pre-agreed Hash. The application holds onto the invoice and creates a fiat-based escrow with the escrow partner.
  • Sparkswap settles the escrow with the escrow partner, retrieving the fiat, and the application retrieves the preimage to settle the HTLC on LND.
  • Central banks around the world use a delivery versus payment settlement mechanism in order to reduce the risk that they take during trades. Both halves of a transaction in Sparkswap and trading institutions are inextricably linked. When using this settlement system in Lightning, it is in real time, and It is available to everyone.
  • It is not decentralized, since you are dealing essentially with their server, but it is also non custodial.

BRANDON CURTIS: Unpopular Paths to a Billion Lightning Users

Top priority should be getting more users.

  • Circular btc economy is not currently a reality.
  • First need to manage the net flows on the lightning network in a way that is not cost prohibitive.
  • Total self-custody is the ideal way to use Bitcoin.

Custodial Lightning:

  • Number of costs associated with engaging with the Lightning network.
  • Bitcoin transaction outputs
  • Uptime, monitoring and set up of lightning nodes
  • Managing liquidity
  • Custody can benefit those not willing or able to cover all of the above
  • Marginal cost for these services is low when scaling
  • Not a significant issue to place trust in these service providers if many are willing to join the network for small transactions.

Fractional reserve Lightning:

  • Two routing nodes on the network may choose to allow a channel balance under certain circumstances to go negative.
  • They would choose to do so because channel capitalization and liquidity management costs money.
  • Can potentially reduce costs and increase ROI by having channel balances go negative, if for example two business have some sort of legally binding agreement.
  • Channel ROI = f(utilization,1/capital)
  • Businesses are used to being able to capitalize on their trust relationships to reduce capital and cash flow requirements.
  • Lightning effectively isolates trust between peers, so you can customize your trust model with each peer you choose to open a channel with.

Altcoins seen as mispriced block space:

  • There are costs associated to balancing (moving funds on and off chain)
  • Submarine swaps would allow to mitigate some of these costs by moving some of these on-chain transactions to other chains. So you can trustlessly couple a payment between a layer 2 network like Lightning and any layer 1 network that supports Hash timelock contracts. A HTLC is essentially an escrow.
  • A user can escrow funds on one chain and a service provider can pay a lightning invoice and uses the pre-image to sweep the escrow, an effective technique for moving some of the state required to rebalance the network on to other chains.

Radar redshift: a multi-network submarine swap provider that allows Bitcoin and altcoins on layer 1 to trustlessly to be moved into the lightning network as Lightning bitcoin.

  • It collects quotes from market makers between lighting bitcoin and other assets they support, user then accepts quotes and escrow funds, service provider pays the lightning invoice and sweeps the escrow.
  • If invoice can’t be fulfilled on the LN, then the escrow times out and user can reclaim funds.
  • Unique opportunity because there are 250,000 users of the metamask browser from Ethereum which has a similar UX/UI flow to lightning apps.

ROY SHEINFELD: Lightning at the End of the Tunnel Overcoming Bitcoin's UX Challenges

Adoption is UX driven:

  • Must drive adoption without compromising on core Bitcoin values.
  • Users must have total sovereignty of their funds; Bitcoin should remain a peer to peer decentralized cash.

The challenges facing UX:

Zero configuration

  • Autopilot: ability to have payment service work out of the box, channels and routing nodes are worked out by an algorithm. However, still need to maintain a L1 hot wallet to enable this process.
  • Lightning service providers (LSP): responsible for opening channels, facilitating inbound liquidity issues, for having a good connection to the network for all payments to succeed and for rebalancing.

Receiving funds immediately once connected to the network

  • Inbound liquidity via LSPs
  • On-demand channels & Atomic multipath payments: can wait for the first Lightning transaction before creating the channel
  • Loop-out: create a submarine swap from the existing lightning capacity back to the chain in order to release space for the inbound liquidity.

Single balance experience, not multiple balances on multiple channels and layers, need for a much more natural flow.

  • Challenges: On/off-chain transactions & multi-channel balances
  • Possible solutions: Submarine swaps, automatic rebalancing, atomic multipath payments
  • Need a level of service that is on par with fiat services (like a single balance).  AMP support would allow for single balance payments for multiple channels and further simplify and abstract the user experience.

Effortless and instantaneous payments:

  • Too many failed payments, the challenge is to have a non-custodial solution for mobile, often the node is not active.
  • Breez creates the notion of having two end nodes into a single session in order to fulfill a payment, called Connect to Pay. It’s a good way to mitigate the problem, but still not on par with fiat for ease of use.
  • Lightning Rod: acts like a relay node that allows to synchronize a payment in an asynchronous and trustless manner.  Allows to split one transaction into two separate transactions, that both rely on the same preimage that the receiver of funds created. So, the Rod collects payment from the sender only if it goes to pay the receiver. The idea is to implement a Venmo type solution in Lightning.

Ongoing continuous payments

  • Challenges: Syncing with the chain, updating the LN graph (routing)
  • Possible solutions: running a background synch in order to always be synchronized with the chain, advanced routing algorithms (Trampoline payments)

Easier for making large payments

  • AMP
  • Wumbo channels
  • Splicing

Other challenges:

  • On-boarding time (zero-confirmation channels)
  • Topping up from fiat (e.g. Olympus)
  • Must be able to empty the balance (i.e. channel reserves)

IGOR KORSAKOV: Typical Vulnerabilities in Lightning Apps

Four typical Lightning apps vulnerabilities:

  1. Double spends with hold-invoices; anatomy of sendPayment
  2. Stealing free fees
  3. Race-condition attacks
  4. Negative amounts

What is a Lapp?

A web app that can interact with the Lightning Network

  • Receive payment
  • Send payment
  • Authenticate (sign with node’s key)

This talk will mostly cover withdrawal functionality and how one can withdraw more than what they are supposed to, which is basically hacking.

Anatomy of SendPayment:

  1. Create preimage;
  2. payment_hash = hash(preimage)
  3. Create bolt11 invoice with payment_hash, amount, description, signature
  4. Give invoice to payer
  5. Recipient sends HTLC to routing node protected by payment_hash promising that recipient has solution to hash
  6. Routing node send HTLC to recipient protected by same hash
  7. Recipient reveals preimage in order to receive payment.
  8. The recipient is always in a determined state: either they receive the payment, or they don’t, either they accept the payment, or they don’t.
  9. Once the payer makes the first channel state update, you don’t know its status. If the payment is stuck, you cannot cancel it and cannot redo it without risking making the same payment twice.
  10. Several Lapps are not prepared for a scenario in which payments are stuck.

First attack: Hold-invoice attack

Function that handles withdrawal requests with a balance check:‘/payinvoice’,function(req, res) {
if (userBalance >= sum_satoshis) {
//got enough balance
lightning.sendPayment(invoice, function(err,result) {
//callback with result of sent payment

If the payment is stuck, an attacker could request another withdrawal and it could be stuck again.

  • Gets stuck on the callback function before reducing a user’s balance.
  • An attacker can issue several withdrawal requests, and once it gets unstuck, the amount is deducted from the payer (can even cause a negative balance from payer).

Hold-invoice: Once the recipient sees the incoming channel state update, they can wait for node operators input on whether to accept the invoice and release the preimage or to reject it completely.

  • This can enable payments to be stuck.

How to protect against Hold-invoice attack:

  • Atomically lock out full withdrawal amount before doing anything else.
  • Lock out should not auto-expire, only release the payment when it is in a determined state (failed or went through).
  • Check stuck payments periodically.
  • Disregard invoice expiry.

Second attack: Stealing free fees

  • Lightning payments are thought to be instantaneous and cost close to zero fees.
  • A routing node can be set up with high fees and withdrawals can only be done through it.
  • A fee limit will not help.

How to protect against Stealing free fees attack:

  1. Don’t give away fees.
  2. Lock in total payment amount with fees, if it is 1% on a 100 satoshis payment, only lock 101 satoshis.
  3. Calculate route’s actual fees and add them to amount when charging user and ask whether they are willing to pay those exact fees for that route.
  • Querying route to destination with a specific amount and sending a payment with a fake payment hash. If it bounces back with a payment hash error, this means that the destination does not know the solution to the hash. You can take fees from this route and ask the user whether they are willing to pay those fees.

Third attack: Race-condition attacks

  • Common attack and easy to make this mistake.
  • Code is usually handled by a web server, most likely by a multi-threaded web server.
  • Someone could request several withdrawals at the exact same time, user balance check goes at the exact same time, and it passes.
  • The execution reaches the sent payment stage and several withdrawals are executed

How to protect against Race-condition attacks:

return errorTryAgainLater(res);
}‘/payinvoice’,function(req, res) {
if (userBalance >= sum_satoshis) {
//got enough balance
lightning.sendPayment(invoice, function(err,result) {
//callback with result of sent payment
→ Must set atomic lock
Mistakes: having negative amounts‘/payinvoice’,function(req, res) {
if (req.body.amount < 0) return errorBadArguments(res);
  • Usually you’ll have all the checks in place and make sure that amounts are always positive, but then you rearrange some of the code and omit a check, now all of a sudden you are vulnerable.

→ Solution: Write tests! Must include a test case for negative amounts, so if you introduce regression to your code and something went wrong, you should go back and fix it.

Other risks:

  • Unsafe zero-amount invoices: routing node can guess that you are paying a zero-amount invoice, so instead of routing full amount, routing node will only send one satoshi to destination. Destination node will release preimage, which will finalize the payment across the route, and the routing node effectively steals the payment.
  • Unsafely opened channels
  • DDOS preventing you from issuing retaliate tx
  • Observing counterparty offline/online patterns to choose best timing to issue old state tx
  • All web-app vulnerabilities apply (XSS, injections, fuzzing, etc.)
  • Study Open Web Application Security Project (OSWAP).

Best practices:

  • Don’t store user balance as single variable. It should be a sum of all transactions.
  • Don’t store amounts as float, only as int. Signed int is okay, no point in enforcing unsigned int everywhere.
  • Relational database management system (RDBMS) and Transactional databases are good to have.
  • Log everything and keep all logs.
  • Do your accounting regularly (at least daily) and investigate whether actual values differ from expected.
  • Don’t be obsessed with MVPs.

ERIC Wall, Human Right Foundation

Threat profiles from government:

  • Mass surveillance coming from technology, massive network of cameras and facial recognition.
  • People cellphones are perfect way to surveil people. Every aspect of a human life can be tracked through one single app, all the payments are going through one central settler. (Such as WeChat)

What Lightning can do to protect us from these threats?

  • Lightning doesn’t enforce KYC.
  • In a monetary system you want a large dataset of users so a single user doesn’t particularly stand out. (Called the Anonymity set)

Bitcoin has the largest number of users so it has the potential to have a meta anonymity set.

  • Lightning can be really useful for privacy purposes since it can leverage the biggest set of user.

Why Lightning can be bad for Privacy (How can it be broken)?

  • If you try to deanonymize some users in the Lightning Network by putting yourself inside of it, due to the properties of the payments routing and the Sphinx protocol, you can’t really infer what is happening. (You only see the amounts and the time of the transactions passing through your node).
  • You don’t know the end points of the paiements.

How would a state actor leverage the weaknesses of Lightning?

  • Leverage the fact that liquidity is scare in the Lightning Network. By creating a popular routing node in the network (Low fees and high inbound liquidity), you can attract people to create private channels with you.
  • You can infer that these aren’t routing nodes which makes it easier to deanonymize you.
  • Such services as LNbig, Bitreffil, will want to track information about all the people visiting your website, either by making them subscribe to your different social media account, newsletters. When someone opens a channel with them, they can find more easily the identity of the LN user. Theses companies will likely keep a data log from all the paiements coming on each of the private channels.

What can we do to prevent this:

  • Connect to different gateways/ nodes to obfuscate your activity

CLAUDIA DIAZ: Lightning Network: Privacy Threats Towards Network Adversaries

Privacy measure: No third party, whether other nodes in the network or the nodes routing the payments between the sender and the recipient should know who is the sender and the recipient in a transaction.

Adversary 1: Global Network Eavesdropper

  • Sees encrypted traffic between all nodes, but only the metadata (to, from, length and time).

Adversary 2: Intermediaries (routing nodes)

  • Sees predecessor, successor, payment identifier, payment amount, and time. Can’t see the original sender or final receiver.

How LN performing against such adversaries?

Privacy towards Adversary 1:

  • Payment amounts are hidden by encryption (unless there is a corrupted node in the route).
  • The first payer and the final recipient is trivially observable.
  • The faster a transaction propagates, the easier it is to trace them end-to-end.
  • Private channels make no difference, the adversary can see that there are transactions being conducted even though there aren’t any public links between nodes. Therefore, a private link exists, and they can complete their own version of the graph of nodes since the two nodes are executing a protocol that has a traffic fingerprint that is consistent with making a payment.

Privacy towards Adversary 2:

  • Payment amount visible to all intermediaries.
  • Non-adjacent nodes can tell they are in the same payment route due to observing persistent (linkable) payment identifiers.
  • Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability (Malatova et al. NDSS’19) has been proposed as an alternative design that blinds the payment identifiers to mask the linkability.
  • However, non-adjacent nodes can still infer they are part of the same payment route based on payment amount and timing.

Anonymity in LN

  • The principle intuition is that with the implementation of Sphinx (the ability to send spontaneous payments directly to one another without the use if invoices and multi-hop anonymous routing), intermediaries do not know the full length of the route nor their position in that route relative to other nodes.
  • However, routing nodes can still infer which the sender or receiver of payments since routes are optimized for cost. It is the shortest (cheapest) path between sender and receiver and the full graph of channels is known to all participants.
  • If an adversary would control two or more nodes in the route, they can know who is paying whom and the amount.
  • Nodes with higher betweenness centrality have a better vantage point of attack.
  • Uncertainty over knowing the successor and the predecessor can only work with long random walks.

What can we do for anonymity?

  • Use an anonymous transport layer that offer unlikability between inputs and outputs.
  • Ex. Tor, but it is not resistant to global network adversaries
  • Nym Mixnet
  • Multiple packets go through different paths, making traceability of traffic flow much harder, and uses Sphinx.
  • Continuous-time mixes, so as a sender you can predict when your message will be delivered, this increases the anonymity set since messages arriving to a receiver can possibly be the input.
  • Layered network topology.
  • Loops of dummy traffic to enhance the anonymity set, the network observer cannot distinguish between real and bogus activity.
  • Anonymous replies are possible.
  • Its infrastructure can support multiple applications (messaging, file sharing, VPN service provider, etc.) and blend their anonymity sets.


  • The current Lightning network does not offer payment privacy towards global network adversaries.
  • Using the Nym mixnet to communicate between LN nodes would provide protection.
  • Very low or no privacy towards intermediary Lightning network nodes, in particular those that are close to the sender or receiver.
  • Protection towards intermediaries is much harder to achieve, might require redesign of the LN routing protocol.
  • Private channels do not improve the situation.


How to solve the financial fuck up of the Lightning Network

Privacy is crucial for a free and prosperous society, the Bitcoin community must make sure they don’t screw that aspect.

Tips and techniques to be more private in the Bitcoin ecosystem.

Ways to acquire Bitcoin Privately

  • Earn them
  • Buy them directly from a peer.

Use CoinJoin and do multiples rounds of it.

  • Before opening a lightning channel, you must coinjoin your coins as well.

Avoid Services that KYC.

This applies to companies providing liquidity channels on the lightning network

Use wallets that let you manually select your UTXO’s.

Label your UTXO’s and channels.

Use your bitcoin applications over the Tor Network.

Play with the latency of your paiements on the Lightning Network. The paiements don’t have to be instant.

A lot of privacy improvements coming to the Bitcoin protocol.

  • Schnorr signatures
  • Taproot
  • Atomic Swaps


Incentivizing Mobile Nesh Net with Lightning

Low cost and fast permissionless micro-payments embedded in hardware devices can operate off-grid scenario and can lead to another type of communication.

Current communication networks are completely centralized by few monopolies. You can easily be censored. Centralized system are not really resilient and can be shut down by governments.

Historically mesh networks have been proposed to tackle the problems coming from centralized communication systems, but they were mostly used in the military.

Gotenna is the first off-grid, long-range, mobile, consumer ready mesh network.

Bitcoin being a protocol, it’s really hard to bring down. Similarly, a mesh network can be really hard to stop once it reaches a certain critical scale. Bitcoin has grown naturally since the incentives to use it are embedded into the protocol itself. Although Bitcoin isn’t ideal for a large number of micro-transactions, the Lightning network might be a solution to fix that problem.

How does Gotenna works in regards to all of this ?

  • When you send a piece of data, you’re also attaching a pre-image. This will get encrypted and sent in a peer to peer fashion until it reaches its destination.
  • Once its reaches its destination, the confirmation gets sent back with the same technique and the nodes that participated in the transmission gets rewarded accordingly to the input. Some of the factors that can be fairly accounted for are:
  • The cost of the device relaying the payment
  • Battery usage
  • Bandwidth

What could be the ideal scenario for a mesh network in regards to the Lightning Network ?

Using the Current Bitcoin and Lightning Network protocols:

  • Reducing the resources demands for running a node in order to increase the size of the network.
  • For an effective routing, the Gotenna team has to modify certain things in the Lightning Network Protocol.
  • Suppress gossip
  • Trampoline paiements
  • Using blockheaders when receiving information from the blockchain.(The mesh network nodes should act as light clients.)
  • HTLC timeouts would have to be longer since mesh network are functioning on a lower bandwidth.

Current situation and what needs to be done?

  • Currently: Update channels off grid (works on the c-lightning implementation)
  • What has to be done
  • Setup channel off-grid
  • Include pre-image with message
  • Delegate routing
  • Pay relays off-grid

Adapting the mesh network protocol considering futur soft-forks coming to the Bitcoin and Lightning Network Protocol:

  • Eltoo/ No-Input
  • Taproot
  • Watchtowers
  • Channel Factories

RANDY BRITO: Chat and Send Bitcoin without Internet

“The best expression of a permissionless network might be a permissionless off-grid system”

You can use different techniques to build such a network.

  • Ham radio is really effective to send messages over a long distance. However a static antenna can easily be spotted and found with basic surveillance technology.
  • You need to be able to move around and obfuscate your position.
  • Ham radio messages are not encrypted. Bitcoin communication must be encrypted.

What Locha Mesh permit you ?

  • Open source software that can be used by anyone.
  • Different devices can communicate even if there aren’t necessarily the same kind of devices.
  • The route for the message is pre-calculated.
  • Long-range communication and high frequency band. (This will let someone sync their wallet with a remote electrum server if there are close to it.)

Why Locha Mesh ?

  • Antenna: Portable, low energy consumption, run on battery or solar power, long-range.
  • The Network is decentralized, censorship resistant, resilient, high bandwidth, 6 LoWPAN for IPv6.
  • The communication is encrypted, verifiable and anonymous. Based on open-source software and hardware.

CHRISTIAN DECKER, Of Channels, Flows, and Icebers

The talk revolved  around measurements in the Lightning Network.

  • It's crucial to calculate the different metrics of the lightning network in order to know how to improve it.

First Measurement: the Gossip (how nodes communicate between one another).

  • The general growth of the numbers of nodes in the network has been steady (around 4000 nodes during the time of the conference).
  • You can have different numbers coming up depending on how you measure the network, in this case only the nodes and channels that have been up in the last two weeks were counted.
  • This doesn’t take into account the nodes that have not been announced to the network.

What’s a probe?

  • It's a method to test out if the channels in the lightning network work properly by sending a Lightning payment that will not complete.

But how can you do this if you don’t have an invoice ?

  1. First you gather all the node IDs in the network and try to iterate through theses node IDs by trying to send them a payment.
  2. You generate a payment hash, but without using an invoice which will inevitably results in a failed payment attempt, but you can analyse the failed attempts and it can tell you a lot of information about the network.


1st attempt:

Around a third of payment attempts have resulted in failures for different reasons:

  • A channel or a peer is offline.
  • All the channels are disabled.

25th attempt:

  • After gradually eliminating the routes and discarding the channels or the peers that weren’t functioning. The probing reaches a 79% success rate.

The attempts were conducted on all the nodes of the network and not on economic nodes, which give us the work possible scenario in regards to the efficiency of the network.

Time tp Completion

Here are the results for the time of completion for a payment to go through.

  • 66% will succeed in the first attempt.
  • 90th percentile of success in 4 attempts.
  • 90th percentile of 30 seconds. (Not optimal)
  • 95th percentile of 3 minutes.


  • Instead of probing sequentially. Probing in parallel might be a solution, probes will race against the first attempt and considerably reduce the time of completion of the payment.

Another problem is Stuck Payments

  • An attempt is considered stuck when its HTLC lingers after the run. Although they represent a pretty small percentage of the whole trials. (0.19%)

Some nodes aren’t signaling their presence on Lightning, but it might also be interesting to analyze this invisible part of the network. You can do so by following certain heuristics and look for private channels trace on-chain.

  1. Funding output script is unique.
  2. Closing TX has single input.
  3. Unilateral close may has non-final sequence number.
  4. Funding TX only ever has at most 2 outputs.
  5. Only one of the funding outputs may be a P2WSH that is spent with a conditional witness script.


By analysing the outputs created since Segwit was activated up until the lightning conference:

  • 195,348 potential channel outpoints were founds.
  • Of theses 135,096 were gossiped about.
  • 59% Public, 41% private.

Patrick McCorry, Sergi Delgado: Towards an Accountable, Highly Available, and Fault-Tolerant Watching Service for Bitcoin’s Lightning Network.

Pisa research

Why do we care about Watchtowers in the Lightning Networks?

After the creation of a channel between two parties (let's say Alice and Bob), if Alice decides to trigger a dispute by trying to close the channel and claim the funds on-chain via an ancient state. BOB has a certain amount of time to go back online and prove the falseness of the claim by showing the latest channel state.

What would a Watchtower do in an ideal situation?

It will simply responds on the user’s behalf while he’s offline. (If he was asked and paid for it).

But what is the perception of an external party watching the network?

A user might pay a bunch of watchtowers on the network to watch the network. This poses a problem however since it could be extremely expensive. The solution consists on creating a bounty-contract on chain for which all the watchtowers will compete.


Watchtower have to deal with a certain amount of storage and bandwidth per channel. This can result in a lot of resources that will be spent but the reward isn’t guaranteed.

Miners might be in a good position to be at the forefront and watching the network. This is not a good thing for the lightning network since they can manipulate transactions in the blocks at their advantage.

Characteristics to preserve when we design the watchtowers system:

  • Trust minimisation; you don’t want to blindly trust a single watchtower for your funds.
  • High availability: you should have a variety of different watchtowers from which to choose.
  • Fair Reward: Watchtowers should be fairly compensated for their services and costs.

These fundamentals are really hard to balance, it is much easier to make the watchtower accountable for the performance. The original paper of PISA (Adding accountability to Watching Network) consists of creating a smart-contract that will be composed of a signed receipt by the Watchtower.

If some clear on-chain evidence is presented to the smart contract that the watchtower didn’t do its job, it will be punished financially.

This would require a new OPCODE to support:

  • SPV Proof
  • Parsing Receipt

The only accountability you can do with the current protocol today is reputational and not financial.

Pisa is currently trying to create a standard for watchtowers.

Sergi Delgado proceeds to demonstrate a live demo of the system they're developing.


Extensive Lightning Wallets Feature Comparison

Extensive Lightning Wallets Feature Comparison

Discover the most complete analysis of lightning network wallets. With over 50 analyzed functionalities, you can find the one that fits the best your needs.



3 min read


Self-Hosted Nodes: The Best Way To Protect Your Bitcoin

Self-Hosted Nodes: The Best Way To Protect Your Bitcoin

Using your own Bitcoin full node gives you enormous advantages in terms of privacy, sovereignty and security. Learn why you should run one and how to do it!



3 min read

Montreal, Quebec, Canada
MSB License: M20484233


  • © Veriphi Inc. 2021 All rights reserved
  • Terms of Service
  • Privacy & Security