From 85436b296e37d2441f6952bfaf3de88073cdda9f Mon Sep 17 00:00:00 2001 From: "judymcconville@roadrunner.com" Date: Tue, 2 May 2017 13:11:35 -0700 Subject: [PATCH] Edited ch12.asciidoc with Atlas code editor --- ch12.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch12.asciidoc b/ch12.asciidoc index f7b26c03..22dfdd0e 100644 --- a/ch12.asciidoc +++ b/ch12.asciidoc @@ -215,7 +215,7 @@ More details about Counterparty can be found at https://counterparty.io. The ope [[state_channels]] === Payment Channels and State Channels -_Payment channels_ 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 eventual batch settlement. Because the transactions are not settled, they can be exchanged without the usual settlement latency, allowing extremely high transaction throughput, low (sub-millisecond) latency, and fine (satoshi-level) granularity. +_Payment channels_ ((("blockchain applications", "payment (state) channels", id="BCApayment12")))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 eventual batch settlement. Because the transactions are not settled, they can be exchanged without the usual settlement latency, allowing extremely high transaction throughput, low (sub-millisecond) latency, and fine (satoshi-level) granularity. Actually, the term _channel_ is a metaphor. State channels are virtual constructs represented by the exchange of state between two parties, outside of the blockchain. There are no "channels" per-se and the underlying data transport mechanism is not the channel. We use the term channel to represent the relationship and shared state between two parties, outside of the blockchain. @@ -434,7 +434,7 @@ Anyone who knows the secret +R+, which when hashed equals to +H+, can redeem thi If the secret is not revealed and the HTLC claimed, after a certain number of blocks the payee can claim a refund using the second clause in the +IF+ flow. -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 know the secret +R+. +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 know the secret +R+.((("", startref="BCApayment12"))) [[lightning_network]] === Routed Payment Channels (Lightning Network)