mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-16 04:59:35 +00:00
CH14: s/bitcoin/Bitcoin/
This commit is contained in:
parent
8ddd89270b
commit
aeb9f81f26
@ -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.
|
||||
|
Loading…
Reference in New Issue
Block a user