@ -419,7 +419,7 @@ Invoices are usually encoded either as a long __bech32__-encoded string or as a
[NOTE]
====
The term _preimage_ comes from mathematics. In any function _y = f_(_x_), the set of inputs that produce a certain value _y_ are called the preimage of _y_. In this case, the function is the SHA-256 hash algorithm, and any value _r_ that produces the hash _H_ is called a preimage.
The term _preimage_ comes from mathematics. In any function pass:[<span class="keep-together"><em>y</em> = <em>f</em>(<em>x</em>)</span>], the set of inputs that produce a certain value _y_ are called the preimage of _y_. In this case, the function is the SHA-256 hash algorithm, and any value _r_ that produces the hash _H_ is called a preimage.
====
There is no known way to find the inverse of SHA-256 (i.e., compute a preimage from a hash). Only Bob knows the value _r_, so it is Bob's secret. But once Bob reveals _r_, anyone who has the hash _H_ can check that _r_ is the correct secret, by calculating SHA-256(_r_) and seeing that it matches _H_.
@ -522,7 +522,7 @@ The user might only realize that probing is taking place if the payment does not
[NOTE]
====
On the internet, we use the Internet Protocol and an IP forwarding algorithm to forward internet packages from the sender to the destination. While these protocols have the nice property of allowing internet hosts to collaboratively find a path for information flow through the internet, we cannot reuse and adopt this protocol for forwarding payments on the Lightning Network. Unlike the internet, Lightning payments have to be _atomic_, and channel balances have to remain _private_. Furthermore, the channel capacity in Lightning changes frequently, unlike the internet where connection capacity is relatively static. These constraints require novel strategies.
On the internet, we use the Internet Protocol and an IP forwarding algorithm to forward internet packages from the sender to the destination. While these protocols have the nice property of allowing internet hosts to collaboratively find a path for information flow through the internet, we cannot reuse and adopt this protocol for forwarding payments on the Lightning Network. Unlike the internet, Lightning payments have to be _atomic_, and channel balances have to remain _private_. Furthermore, the channel capacity in Lightning changes frequently, unlike the internet where connection capacity is relatively static. These constraints require novel pass:[<span class="keep-together">strategies</span>].
====
Of course, pathfinding is trivial if we want to pay our direct channel partner and we have enough balance on our side of the channel to do so. In all other cases, our node uses information from the gossip protocol to do pathfinding. This includes currently known public payment channels, known nodes, known topology (how known nodes are connected), known channel capacities, and known fee policies set by the node owners.
@ -671,7 +671,7 @@ To route a payment, an intermediary node will have to move funds in two or more
Thus, when there are many transactions in the queue, users have to pay a higher fee to be included in the next block, or they have to wait until there are fewer transactions in the queue.
This naturally leads to the emergence of a fee market where users pay based on how urgently they need their transaction included in the next block.
The scarce resource on the Bitcoin network is the space in the blocks. Bitcoin users compete for block space, and the Bitcoin fee market is based on available block space. The scarce resources in the Lightning Network are the ((("channel connectivity")))((("channel liquidity")))_channel liquidity_ (capacity of funds available for routing in channels) and _channel connectivity_ (how many well-connected nodes channels can reach). Lightning users compete for capacity and connectivity; therefore, the Lightning fee market is driven by capacity and connectivity.
The scarce resource on the Bitcoin network is the space in the blocks. Bitcoin users compete for block space, and the Bitcoin fee market is based on available block space. The scarce resources in the Lightning Network are the ((("channel connectivity")))((("channel liquidity")))_channel liquidity_ (capacity of funds available for routing in channels) and _channel connectivity_ (how many well-connected nodes channels can reach). Lightning users compete for capacity pass:[<span class="keep-together">and connectivity</span>]; therefore, the Lightning fee market is driven by capacity and pass:[<span class="keep-together">connectivity</span>].
On the Lightning Network, users are paying fees to the users routing their payments. Routing a payment, in economic terms, is nothing more than providing and assigning capacity to the sender. Naturally, routers who charge lower fees for the same capacity will be more attractive to route through. Thus a fee market exists where routers are in competition with each other over the fees they charge to route payments through their channels.
kristen@oreilly.com
3 years ago