From ea1a64bd616f58c750e8ac3e8a015f95afb7c4b6 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Mon, 26 Jun 2023 11:56:24 -1000 Subject: [PATCH] CH14: small edits for style and consistency --- ch12.asciidoc | 122 +++++++++++++++++++++++++------------------------- 1 file changed, 61 insertions(+), 61 deletions(-) diff --git a/ch12.asciidoc b/ch12.asciidoc index d5b75fff..2e7f0b33 100644 --- a/ch12.asciidoc +++ b/ch12.asciidoc @@ -8,10 +8,10 @@ of Bitcoin. The term is often misused and applied to many things that fail to deliver the primary features that Bitcoin's blockchain delivers. In this chapter we will look at the features offered by the Bitcoin -blockchain, as an application platform. We will consider the application +blockchain as an application platform. We will consider the application building _primitives_, which form the building blocks of any blockchain application. We will look at several important applications that use -these primitives, such as colored coins, payment (state) channels, and +these primitives, such as client-side validation, payment channels, and routed payment channels (Lightning Network). === Introduction @@ -22,12 +22,12 @@ However, most of its functionality is derived from much lower-level constructs that can be used for much broader applications. Bitcoin wasn't built with components such as accounts, users, balances, and payments. Instead, it uses a transactional scripting language with -low-level cryptographic functions, as we saw in <>. Just +low-level cryptographic functions, as we saw in <>. Just as the higher-level concepts of accounts, balances, and payments can be derived from these basic primitives, so can many other complex applications. Thus, the Bitcoin blockchain can become an application platform offering trust services to applications, such as smart -contracts, far surpassing the original purpose of digital currency and +contracts, surpassing the original purpose of digital currency and payments. === Building Blocks (Primitives) @@ -39,25 +39,26 @@ used as building blocks to create applications. These include: No Double-Spend:: The most fundamental guarantee of Bitcoin's decentralized consensus algorithm ensures that no UTXO can be spent -twice. +twice in the same valid chain of blocks. Immutability:: Once a transaction is recorded in the blockchain and sufficient work has been added with subsequent blocks, the transaction's -data becomes immutable. Immutability is underwritten by energy, as +data becomes practically immutable. Immutability is underwritten by energy, as rewriting the blockchain requires the expenditure of energy to produce Proof-of-Work. The energy required and therefore the degree of immutability increases with the amount of work committed on top of the block containing a transaction. Neutrality:: The decentralized Bitcoin network propagates valid -transactions regardless of the origin or content of those transactions. +transactions regardless of the origin of those transactions. This means that anyone can create a valid transaction with sufficient fees and trust they will be able to transmit that transaction and have it included in the blockchain at any time. Secure Timestamping:: The consensus rules reject any block whose -timestamp is too far in the past or future. This ensures that timestamps -on blocks can be trusted. The timestamp on a block implies an +timestamp is too far in the future and attempt to prevent blocks with +timestamps too far in the past. This ensures that timestamps +on blocks can be trusted to a certain degree. The timestamp on a block implies an unspent-before guarantee for the inputs of all included transactions. Authorization:: Digital signatures, validated in a decentralized @@ -113,8 +114,8 @@ with exponentially decreasing likelihood, based on the depth at which they are recorded. Once deeply recorded, the computation and energy required to change makes change practically infeasible. -Recording External State:: A transaction can commit a data value, via -+OP_RETURN+, representing a state transition in an external state +Recording External State:: A transaction can commit to a data value, via ++OP_RETURN+ or pay-to-contract, representing a state transition in an external state machine. Predictable Issuance:: Less than 21 million bitcoin will be issued, at a @@ -131,10 +132,10 @@ compose applications. Here are some examples of applications that exist today and the building blocks they use: Proof-of-Existence (Digital Notary):: ((("digital notary -services")))((("Proof of Existence")))Immutability + Timestamp + -Durability. A digital fingerprint can be committed with a transaction to -the blockchain, proving that a document existed (Timestamp) at the time -it was recorded. The fingerprint cannot be modified ex-post-facto +services")))((("Proof of Existence")))Immutability + Timestamp + Durability. +A transaction on the blockchain can commit to a value, +proving that a piece of data existed (Timestamp) at the time +it was recorded. The commitment cannot be modified ex-post-facto (Immutability) and the proof will be stored permanently (Durability). Kickstarter (Lighthouse):: Consistency + Atomicity + Integrity. If you @@ -143,8 +144,8 @@ others can contribute to the fundraiser but it cannot be spent (Atomicity) until the goal (output value) is funded (Consistency). Payment Channels:: ((("payment (state) channels", "building blocks -(primitives) used in")))Quorum of Control + Timelock + No Double Spend + -Nonexpiration + Censorship Resistance + Authorization. A multisig 2-of-2 +(primitives) used in")))Quorum of Control + Timelock + No Double Spend + Nonexpiration ++ Censorship Resistance + Authorization. A multisig 2-of-2 (Quorum) with a timelock (Timelock) used as the "settlement" transaction of a payment channel can be held (Nonexpiration) and spent at any time (Censorship Resistance) by either party (Authorization). The two parties @@ -158,7 +159,7 @@ id="BCAcoins12")))((("colored coins", id="color12")))The first blockchain application we will discuss is _colored coins_. ((("extrinsic asset management")))Colored coins refers to a set of -similar technologies that use bitcoin transactions to record the +similar technologies that use Bitcoin transactions to record the creation, ownership, and transfer of extrinsic assets other than bitcoin. By "extrinsic" we mean assets that are not stored directly on the bitcoin blockchain, as opposed to bitcoin itself, which is an asset @@ -375,10 +376,10 @@ channels", id="BCApayment12")))((("payment (state) channels", "defined")))are a trustless mechanism for exchanging Bitcoin transactions between two parties, outside of the Bitcoin blockchain. These transactions, which would be valid if settled on the Bitcoin -blockchain, are held off-chain instead, acting as _promissory notes_ for +blockchain, are held off-chain instead, waiting for eventual batch settlement. Because the transactions are not settled, they can be exchanged without the usual settlement latency, allowing -extremely high transaction throughput, low (submillisecond) latency, and +extremely high transaction throughput, low latency, and fine (satoshi-level) granularity. Actually, the term _channel_ is a metaphor. State channels are virtual @@ -429,15 +430,15 @@ valid transactions in that they _could_ be submitted for settlement by either party, but instead are held off-chain by each party pending the channel closure. State updates can be created as fast as each party can create, sign, and transmit a transaction to the other party. In practice -this means that thousands of transactions per second can be exchanged. +this means that dozens of transactions per second can be exchanged. -When exchanging commitment transactions the two parties also invalidate -the previous states, so that the most up-to-date commitment transaction -is always the only one that can be redeemed. This prevents either party -from cheating by unilaterally closing the channel with an expired prior +When exchanging commitment transactions the two parties also discourage +use of the previous states, so that the most up-to-date commitment transaction +is always the best one to be redeemed. This discourages either party +from cheating by unilaterally closing the channel with a prior state that is more favorable to them than the current state. We will -examine the various mechanisms that can be used to invalidate prior -state in the rest of this chapter. +examine the various mechanisms that can be used to discourage +publication of prior states in the rest of this chapter. Finally, the channel can be closed either cooperatively, by submitting a final _settlement transaction_ to the blockchain, or unilaterally, by @@ -493,7 +494,7 @@ paid for by the second. To set up the payment channel, Emma and Fabian establish a 2-of-2 multisignature address, with each of them holding one of the keys. From Emma's perspective, the software in her browser presents a QR code with -a P2SH address (starting with "3"), and asks her to submit a "deposit" +the address, and asks her to submit a "deposit" for up to 1 hour of video. The address is then funded by Emma. Emma's transaction, paying to the multisignature address, is the funding or anchor transaction for the payment channel. @@ -645,10 +646,6 @@ needs nothing more than absolute transaction-level timelocks +CHECKLOCKTIMEVERIFY+ and +CHECKSEQUENCEVERIFY+, can be used to construct more flexible, useful, and sophisticated state channels. -The first form of unidirectional payment channel was demonstrated as a -prototype video streaming application in 2015 by an Argentinian team of -developers. You can still see it at pass:[streamium.io]. - Timelocks are not the only way to invalidate prior commitment transactions. In the next sections we will see how a revocation key can be used to achieve the same result. Timelocks are effective but they @@ -674,10 +671,25 @@ creating a very high burden for the channel participants who have to be vigilant, remain online and watching, and be ready to transmit the right commitment transaction at any time. +In the above example of a single-direction channel, it's easy to +eliminate the per-commitment timelock. After Emma receives the +signature on the timelocked refund transaction from Fabian, no timelocks +are placed on the commitment transactions. Instead, Emma sends her +signature on each commitment transaction to Fabian but Fabian doesn't +send her any of his signatures on the commitment transactions. That +means only Fabian has both signatures for a commitment transaction, so +only he can broadcast one of those commitments. When Emma finishes +streaming video, Fabian will always prefer to broadcast the transaction +that pays him the most---which will be the latest state. This +construction in called a Spillman-style payment channel, which was first +described and implemented in 2013, although they are only safe to use +with witness (segwit) transactions, which didn't become available until +2017. + Now that we understand how timelocks can be used to invalidate prior commitments, we can see the difference between closing the channel cooperatively and closing it unilaterally by broadcasting a commitment -transaction. All commitment transactions are timelocked, therefore +transaction. All commitment transactions in our prior example were timelocked, therefore broadcasting a commitment transaction will always involve waiting until the timelock has expired. But if the two parties agree on what the final balance is and know they both hold commitment transactions that will @@ -697,7 +709,7 @@ to wait for their funds too.((("", startref="PSCtrust12"))) ==== Asymmetric Revocable Commitments ((("payment (state) channels", "asymmetric revocable commitments", -id="PSCaymetric12")))A better way to handle the prior commitment states +id="PSCaymetric12")))Another way to handle the prior commitment states is to explicitly revoke them. However, this is not easy to achieve. A key characteristic of Bitcoin is that once a transaction is valid, it remains valid and does not expire. The only way to cancel a transaction @@ -758,7 +770,7 @@ Input: 2-of-2 funding output, signed by Irene Output 0 <5 bitcoin>: CHECKSIG -Output 1: +Output 1 <5 bitcoin>: <1000 blocks> CHECKSEQUENCEVERIFY DROP @@ -777,7 +789,7 @@ Input: 2-of-2 funding output, signed by Hitesh Output 0 <5 bitcoin>: CHECKSIG -Output 1: +Output 1 <5 bitcoin>: <1000 blocks> CHECKSEQUENCEVERIFY DROP @@ -907,7 +919,7 @@ Asymmetric revocable commitments with relative time locks (+CSV+) are a much better way to implement payment channels and a very significant innovation in this technology. With this construct, the channel can remain open indefinitely and can have billions of intermediate -commitment transactions. In prototype implementations of Lightning +commitment transactions. In implementations of Lightning Network, the commitment state is identified by a 48-bit index, allowing more than 281 trillion (2.8 x 10^14^) state transitions in any single channel!((("", startref="PSCaymetric12"))) @@ -929,7 +941,7 @@ then calculate the hash of this secret +H+: H = Hash(R) ---- -This produces a hash +H+ that can be included in an output's locking +This produces a hash +H+ that can be included in an output's script. Whoever knows the secret can use it to redeem the output. The secret +R+ is also referred to as a _preimage_ to the hash function. The preimage is just the data that is used as input to a hash function. @@ -963,7 +975,7 @@ This is a basic implementation of an HTLC. This type of HTLC can be redeemed by _anyone_ who has the secret +R+. An HTLC can take many different forms with slight variations to the script. For example, adding a +CHECKSIG+ operator and a public key in the first clause -restricts redemption of the hash to a named recipient, who must also +restricts redemption of the hash to a particular recipient, who must also know the secret +R+.((("", startref="BCApayment12"))) [[lightning_network]] @@ -985,16 +997,10 @@ channel network, which has now been implemented by at least five different open source teams. ((("Basics of Lightning Technology (BOLT)")))The independent implementations are coordinated by a set of interoperability standards described in the -http://bit.ly/2rBHeoL[_Basics of Lightning Technology (BOLT)_ paper]. - -Prototype implementations of the Lightning Network have been released by -several teams. For now, these implementations can only be run on testnet -because they use segwit, which is not activated on the main bitcoin -blockchain (mainnet). +http://bit.ly/2rBHeoL[_Basics of Lightning Technology (BOLT)_ repository]. -The Lightning Network is one possible way of implementing routed payment -channels. There are several other designs that aim to achieve similar -goals, such as Teechan and Tumblebit. +Implementations of the Lightning Network have been released by +several teams. ==== Basic Lightning Network Example @@ -1124,15 +1130,12 @@ construct a _path_ through the network by connecting payment channels with sufficient capacity. Nodes advertise routing information, including what channels they have open, how much capacity each channel has, and what fees they charge to route payments. The routing information can be -shared in a variety of ways and different routing protocols are likely -to emerge as Lightning Network technology advances. Some Lightning -Network implementations use the IRC protocol as a convenient mechanism -for nodes to announce routing information. Another implementation of -route discovery uses a P2P model where nodes propagate channel +shared in a variety of ways and different routing protocols have +emerged as Lightning Network technology has advanced. +Current implementations of +route discovery use a P2P model where nodes propagate channel announcements to their peers, in a "flooding" model, similar to how -Bitcoin propagates transactions. Future plans include a proposal called -http://bit.ly/2r5TACm[Flare], which is a hybrid routing model with local -node "neighborhoods" and longer-range beacon nodes. +Bitcoin propagates transactions. In our previous example, Alice's node uses one of these route discovery mechanisms to find one or more paths connecting her node to Eric's node. @@ -1247,11 +1250,8 @@ expanding its operating parameters significantly. Of course, as mentioned previously, the Lightning Network protocol is not the only way to implement routed payment channels. Other proposed systems include Tumblebit and Teechan. At this time, however, the -Lightning Network has already been deployed on testnet. Several -different teams have developed competing implementations of LN and are -working toward a common interoperability standard (called BOLT). It is -likely that Lightning Network will be the first routed payment channel -network to be deployed in production.((("", startref="BCAlightning12"))) +Lightning Network has already been deployed and has tens of thousands of +users. === Conclusion