|
|
|
|
@ -1,11 +1,11 @@
|
|
|
|
|
[[ch12]]
|
|
|
|
|
== Blockchain Applications
|
|
|
|
|
|
|
|
|
|
Let's now build on our understanding of bitcoin by looking at it as an
|
|
|
|
|
Let's now build on our understanding of Bitcoin by looking at it as an
|
|
|
|
|
_application platform_. Nowadays, many people use the term "blockchain"
|
|
|
|
|
to refer to any application platform that shares the design principles
|
|
|
|
|
of bitcoin. The term is often misused and applied to many things that
|
|
|
|
|
fail to deliver the primary features that bitcoin's blockchain delivers.
|
|
|
|
|
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
|
|
|
|
|
@ -37,7 +37,7 @@ payments.
|
|
|
|
|
long term, the Bitcoin system offers certain guarantees, which can be
|
|
|
|
|
used as building blocks to create applications. These include:
|
|
|
|
|
|
|
|
|
|
No Double-Spend:: The most fundamental guarantee of bitcoin's
|
|
|
|
|
No Double-Spend:: The most fundamental guarantee of Bitcoin's
|
|
|
|
|
decentralized consensus algorithm ensures that no UTXO can be spent
|
|
|
|
|
twice.
|
|
|
|
|
|
|
|
|
|
@ -78,7 +78,7 @@ Nonexpiration:: A valid transaction does not expire. If it is valid
|
|
|
|
|
today, it will be valid in the near future, as long as the inputs remain
|
|
|
|
|
unspent and the consensus rules do not change.
|
|
|
|
|
|
|
|
|
|
Integrity:: A bitcoin transaction signed with +SIGHASH_ALL+ or parts of
|
|
|
|
|
Integrity:: A Bitcoin transaction signed with +SIGHASH_ALL+ or parts of
|
|
|
|
|
a transaction signed by another +SIGHASH+ type cannot be modified
|
|
|
|
|
without invalidating the signature, thus invalidating the transaction
|
|
|
|
|
itself.
|
|
|
|
|
@ -121,12 +121,12 @@ Predictable Issuance:: Less than 21 million bitcoin will be issued, at a
|
|
|
|
|
predictable rate.
|
|
|
|
|
|
|
|
|
|
The list of building blocks is not complete and more are added with each
|
|
|
|
|
new feature introduced into bitcoin.
|
|
|
|
|
new feature introduced into Bitcoin.
|
|
|
|
|
|
|
|
|
|
=== Applications from Building Blocks
|
|
|
|
|
|
|
|
|
|
((("blockchain applications", "examples of")))The building blocks
|
|
|
|
|
offered by bitcoin are elements of a trust platform that can be used to
|
|
|
|
|
offered by Bitcoin are elements of a trust platform that can be used to
|
|
|
|
|
compose applications. Here are some examples of applications that exist
|
|
|
|
|
today and the building blocks they use:
|
|
|
|
|
|
|
|
|
|
@ -372,7 +372,7 @@ whereas RGB can technically support both.
|
|
|
|
|
|
|
|
|
|
_Payment channels_ ((("blockchain applications", "payment (state)
|
|
|
|
|
channels", id="BCApayment12")))((("payment (state) channels",
|
|
|
|
|
"defined")))are a trustless mechanism for exchanging bitcoin
|
|
|
|
|
"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
|
|
|
|
|
@ -485,8 +485,8 @@ image::images/mbc2_1205.png["Emma purchases streaming video from Fabian with a p
|
|
|
|
|
In this example, Fabian and Emma are using special software that handles
|
|
|
|
|
both the payment channel and the video streaming. Emma is running the
|
|
|
|
|
software in her browser, Fabian is running it on a server. The software
|
|
|
|
|
includes basic bitcoin wallet functionality and can create and sign
|
|
|
|
|
bitcoin transactions. Both the concept and the term "payment channel"
|
|
|
|
|
includes basic Bitcoin wallet functionality and can create and sign
|
|
|
|
|
Bitcoin transactions. Both the concept and the term "payment channel"
|
|
|
|
|
are completely hidden from the users. What they see is video that is
|
|
|
|
|
paid for by the second.
|
|
|
|
|
|
|
|
|
|
@ -699,7 +699,7 @@ to wait for their funds too.((("", startref="PSCtrust12")))
|
|
|
|
|
((("payment (state) channels", "asymmetric revocable commitments",
|
|
|
|
|
id="PSCaymetric12")))A better 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
|
|
|
|
|
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
|
|
|
|
|
is by double-spending its inputs with another transaction before it is
|
|
|
|
|
mined. That's why we used timelocks in the simple payment channel
|
|
|
|
|
@ -717,7 +717,7 @@ Network.
|
|
|
|
|
|
|
|
|
|
To explain revocation keys, we will construct a more complex payment
|
|
|
|
|
channel between two exchanges run by Hitesh and Irene. Hitesh and Irene
|
|
|
|
|
run bitcoin exchanges in India and the USA, respectively. Customers of
|
|
|
|
|
run Bitcoin exchanges in India and the USA, respectively. Customers of
|
|
|
|
|
Hitesh's Indian exchange often send payments to customers of Irene's USA
|
|
|
|
|
exchange and vice versa. Currently, these transactions occur on the
|
|
|
|
|
Bitcoin blockchain, but this means paying fees and waiting several
|
|
|
|
|
@ -1130,7 +1130,7 @@ 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
|
|
|
|
|
announcements to their peers, in a "flooding" model, similar to how
|
|
|
|
|
bitcoin propagates transactions. Future plans include a proposal called
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
@ -1223,7 +1223,7 @@ a route can see payments propagated across their channels, they do not
|
|
|
|
|
know the sender or recipient.
|
|
|
|
|
|
|
|
|
|
Fungibility:: A Lightning Network makes it much more difficult to apply
|
|
|
|
|
surveillance and blacklists on bitcoin, increasing the fungibility of
|
|
|
|
|
surveillance and blacklists on Bitcoin, increasing the fungibility of
|
|
|
|
|
the currency.
|
|
|
|
|
|
|
|
|
|
Speed:: Bitcoin transactions using Lightning Network are settled in
|
|
|
|
|
@ -1231,7 +1231,7 @@ milliseconds, rather than minutes, as HTLCs are cleared without
|
|
|
|
|
committing transactions to a block.
|
|
|
|
|
|
|
|
|
|
Granularity:: A Lightning Network can enable payments at least as small
|
|
|
|
|
as the bitcoin "dust" limit, perhaps even smaller. Some proposals allow
|
|
|
|
|
as the Bitcoin "dust" limit, perhaps even smaller. Some proposals allow
|
|
|
|
|
for subsatoshi increments.
|
|
|
|
|
|
|
|
|
|
Capacity:: A Lightning Network increases the capacity of the Bitcoin
|
|
|
|
|
@ -1239,7 +1239,7 @@ system by several orders of magnitude. There is no practical upper bound
|
|
|
|
|
to the number of payments per second that can be routed over a Lightning
|
|
|
|
|
Network, as it depends only on the capacity and speed of each node.
|
|
|
|
|
|
|
|
|
|
Trustless Operation:: A Lightning Network uses bitcoin transactions
|
|
|
|
|
Trustless Operation:: A Lightning Network uses Bitcoin transactions
|
|
|
|
|
between nodes that operate as peers without trusting each other. Thus, a
|
|
|
|
|
Lightning Network preserves the principles of the Bitcoin system, while
|
|
|
|
|
expanding its operating parameters significantly.
|
|
|
|
|
|
David A. Harding
11 months ago