mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-22 08:08:11 +00:00
Merge branch 'master' into develop
Editorial changes from ORM
This commit is contained in:
Andreas M. Antonopoulos
commit
9f7a0a8cd6
@ -1,9 +1,9 @@
|
||||
[[appdx_bx]]
|
||||
[appendix]
|
||||
|
||||
== Bitcoin Explorer (bx) Commands((("Bitcoin Explorer (bx) commands", id="BX19")))
|
||||
== Bitcoin Explorer (bx) Commands
|
||||
|
||||
Bitcoin Explorer (bx) is a command-line tool that offers a variety of commands for key management and transaction construction. It is part of the libbitcoin bitcoin library.
|
||||
((("Bitcoin Explorer (bx) commands", id="BX19_1", range="startofrange")))Bitcoin Explorer (bx) is a command-line tool that offers a variety of commands for key management and transaction construction. It is part of the libbitcoin bitcoin library.
|
||||
|
||||
----
|
||||
Usage: bx COMMAND [--help]
|
||||
@ -178,4 +178,4 @@ $ bx mnemonic-decode < words
|
||||
eb68ee9f3df6bd4441a9feadec179ff1
|
||||
----
|
||||
|
||||
Mnemonic encoding can make the seed easier to record and even remember.((("", startref="BX19")))
|
||||
Mnemonic encoding can make the seed easier to record and even remember.(((range="endofrange", startref="BX19_1")))
|
||||
|
||||
@ -332,6 +332,7 @@ Let's look at the complete process of creating a bitcoin address, from a private
|
||||
[[addr_example]]
|
||||
.Creating a Base58Check-encoded bitcoin address from a private key
|
||||
====
|
||||
[role="c_less_space"]
|
||||
[source, cpp]
|
||||
----
|
||||
include::code/addr.cpp[]
|
||||
|
||||
@ -299,7 +299,7 @@ There is also a BIP-39 generator implemented in a standalone webpage, which is e
|
||||
.A BIP-39 generator as a standalone web page
|
||||
image::images/mbc2_0508.png["BIP-39 generator web-page"]
|
||||
|
||||
((("", startref="mnemonic05")))((("", startref="BIP3905")))The page ( https://iancoleman.github.io/bip39/) can be used offline in a browser, or accessed online.
|
||||
((("", startref="mnemonic05")))((("", startref="BIP3905")))The page (https://iancoleman.github.io/bip39/) can be used offline in a browser, or accessed online.
|
||||
|
||||
==== Creating an HD Wallet from the Seed
|
||||
|
||||
@ -430,6 +430,7 @@ To counter this risk, HD wallets use an alternative derivation function called _
|
||||
.Hardened derivation of a child key; omits the parent public key
|
||||
image::images/mbc2_0513.png["ChildHardPrivateDerivation"]
|
||||
|
||||
[role="pagebreak-before"]
|
||||
When the hardened private derivation function is used, the resulting child private key and chain code are completely different from what would result from the normal derivation function. The resulting "branch" of keys can be used to produce extended public keys that are not vulnerable, because the chain code they contain cannot be exploited to reveal any private keys. Hardened derivation is therefore used to create a "gap" in the tree above the level where extended public keys are used.
|
||||
|
||||
In simple terms, if you want to use the convenience of an xpub to derive branches of public keys, without exposing yourself to the risk of a leaked chain code, you should derive it from a hardened parent, rather than a normal parent. As a best practice, the level-1 children of the master keys are always derived through the hardened derivation, to prevent compromise of the master keys.
|
||||
|
||||
@ -208,6 +208,7 @@ $ bitcoin-cli getrawtransaction d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda1
|
||||
----
|
||||
|
||||
[source,json]
|
||||
[role="c_less_space"]
|
||||
----
|
||||
{
|
||||
"hex" : "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0f03443b0403858402062f503253482fffffffff0110c08d9500000000232102aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac00000000",
|
||||
@ -258,6 +259,7 @@ The calculation can be seen in function +GetBlockSubsidy+ in the Bitcoin Core cl
|
||||
[[getblocksubsidy_source]]
|
||||
.Calculating the block reward—Function GetBlockSubsidy, Bitcoin Core Client, main.cpp
|
||||
====
|
||||
[role="c_less_space"]
|
||||
[source, cpp]
|
||||
----
|
||||
CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
|
||||
@ -443,6 +445,7 @@ Now, if we change the phrase, we should expect to see completely different hashe
|
||||
[[sha256_example_generator]]
|
||||
.SHA256 script for generating many hashes by iterating on a nonce
|
||||
====
|
||||
[role="c_less_space"]
|
||||
[source, python]
|
||||
----
|
||||
include::code/hash_example.py[]
|
||||
|
||||
@ -33,6 +33,7 @@
|
||||
|
||||
<ul class="releases">
|
||||
<li><span class="revdate">2017-06-01:</span> First Release</li>
|
||||
<li><span class="revdate">2017-07-21:</span> Second Release</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
|
||||
@ -32,8 +32,8 @@ coinbase transaction::
|
||||
cold storage::
|
||||
Refers to keeping a reserve of bitcoin offline. Cold storage is achieved when Bitcoin private keys are created and stored in a secure offline environment. Cold storage is important for anyone with bitcoin holdings. Online computers are vulnerable to hackers and should not be used to store a significant amount of bitcoin.
|
||||
|
||||
Colored coins::
|
||||
It's an open source Bitcoin 2.0 protocol that enables developers to create digital assets on top of Bitcoin Blockchain utilizing its functionalities beyond currency.
|
||||
colored coins::
|
||||
An open source Bitcoin 2.0 protocol that enables developers to create digital assets on top of bitcoin blockchain utilizing its functionalities beyond currency.
|
||||
|
||||
confirmations::
|
||||
Once a transaction is included in a block, it has one confirmation. As soon as _another_ block is mined on the same blockchain, the transaction has two confirmations, and so on. Six or more confirmations is considered sufficient proof that a transaction cannot be reversed.
|
||||
@ -55,13 +55,13 @@ difficulty retargeting::
|
||||
difficulty target::
|
||||
A difficulty at which all the computation in the network will find blocks approximately every 10 minutes.
|
||||
|
||||
Double spending::
|
||||
Double-spending is the result of successfully spending some money more than once. Bitcoin protects against double spending by verifying each transaction added to the block chain to ensure that the inputs for the transaction had not previously already been spent.
|
||||
double spending::
|
||||
Double spending is the result of successfully spending some money more than once. Bitcoin protects against double spending by verifying each transaction added to the block chain to ensure that the inputs for the transaction had not previously already been spent.
|
||||
|
||||
ECDSA::
|
||||
Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.
|
||||
|
||||
Extra Nonce::
|
||||
extra nonce::
|
||||
As difficulty increased, miners often cycled through all 4 billion values of the nonce without finding a block. Because the coinbase script can store between 2 and 100 bytes of data, miners started using that space as extra nonce space, allowing them to explore a much larger range of block header values to find valid blocks.
|
||||
|
||||
fees::
|
||||
@ -73,27 +73,27 @@ fork::
|
||||
genesis block::
|
||||
The first block in the blockchain, used to initialize the cryptocurrency.
|
||||
|
||||
Hard Fork::
|
||||
Hard Fork, also known as Hard-Forking Change, is a permanent divergence in the blockchain, commonly occurs when non-upgraded nodes can’t validate blocks created by upgraded nodes that follow newer consensus rules.
|
||||
Not to be confused with Fork, Soft fork, Software fork or Git fork.
|
||||
hard fork::
|
||||
Hard fork, also known as Hard-Forking Change, is a permanent divergence in the blockchain, commonly occurs when non-upgraded nodes can’t validate blocks created by upgraded nodes that follow newer consensus rules.
|
||||
Not to be confused with fork, soft fork, software fork or Git fork.
|
||||
|
||||
Hardware Wallet::
|
||||
A hardware Wallet is a special type of bitcoin wallet which stores the user's private keys in a secure hardware device.
|
||||
hardware wallet::
|
||||
A hardware wallet is a special type of bitcoin wallet which stores the user's private keys in a secure hardware device.
|
||||
|
||||
hash::
|
||||
A digital fingerprint of some binary input.
|
||||
|
||||
hashlocks::
|
||||
A Hashlock is a type of encumbrance that restricts the spending of an output until a specified piece of data is publicly revealed. Hashlocks have the useful property that once any hashlock is opened publicly, any other hashlock secured using the same key can also be opened. This makes it possible to create multiple outputs that are all encumbered by the same hashlock and which all become spendable at the same time.
|
||||
A hashlock is a type of encumbrance that restricts the spending of an output until a specified piece of data is publicly revealed. Hashlocks have the useful property that once any hashlock is opened publicly, any other hashlock secured using the same key can also be opened. This makes it possible to create multiple outputs that are all encumbered by the same hashlock and which all become spendable at the same time.
|
||||
|
||||
HD Protocol::
|
||||
HD protocol::
|
||||
The Hierarchical Deterministic (HD) key creation and transfer protocol (BIP32), which allows creating child keys from parent keys in a hierarchy.
|
||||
|
||||
HD Wallet::
|
||||
HD wallet::
|
||||
Wallets using the Hierarchical Deterministic (HD Protocol) key creation and transfer protocol (BIP32).
|
||||
|
||||
HD Wallet Seed::
|
||||
HD Wallet Seed or Root Seed is a potentially-short value used as a seed to generate the master private key and master chain code for an HD wallet.
|
||||
HD wallet seed::
|
||||
HD wallet seed or root seed is a potentially-short value used as a seed to generate the master private key and master chain code for an HD wallet.
|
||||
|
||||
HTLC::
|
||||
A Hashed TimeLock Contract or HTLC is a class of payments that use hashlocks and timelocks to require that the receiver of a payment either acknowledge receiving the payment prior to a deadline by generating cryptographic proof of payment or forfeit the ability to claim the payment, returning it to the payer.
|
||||
@ -104,7 +104,7 @@ KYC::
|
||||
LevelDB::
|
||||
LevelDB is an open source on-disk key-value store. LevelDB is a light-weight, single-purpose library for persistence with bindings to many platforms.
|
||||
|
||||
Lightning networks::
|
||||
Lightning Networks::
|
||||
Lightning Network is a proposed implementation of Hashed Timelock Contracts (HTLCs) with bi-directional payment channels which allows payments to be securely routed across multiple peer-to-peer payment channels. This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other.
|
||||
|
||||
Locktime::
|
||||
@ -113,32 +113,32 @@ Locktime::
|
||||
mempool::
|
||||
The bitcoin Mempool (memory pool) is a collection of all transaction data in a block that have been verified by bitcoin nodes, but are not yet confirmed.
|
||||
|
||||
Merkle Root::
|
||||
merkle root::
|
||||
The root node of a merkle tree, a descendant of all the hashed pairs in the tree. Block headers must include a valid merkle root descended from all transactions in that block.
|
||||
|
||||
Merkle Tree::
|
||||
merkle tree::
|
||||
A tree constructed by hashing paired data (the leaves), then pairing and hashing the results until a single hash remains, the merkle root. In Bitcoin, the leaves are almost always transactions from a single block.
|
||||
|
||||
miner::
|
||||
A network node that finds valid proof of work for new blocks, by repeated hashing.
|
||||
|
||||
Multisignature::
|
||||
Multisignature (multisig) refers to requiring more than one key to authorize a Bitcoin transaction.
|
||||
multisignature::
|
||||
Multisignature (multisig) refers to requiring more than one key to authorize a bitcoin transaction.
|
||||
|
||||
network::
|
||||
A peer-to-peer network that propagates transactions and blocks to every bitcoin node on the network.
|
||||
|
||||
Nonce::
|
||||
The "nonce" in a Bitcoin block is a 32-bit (4-byte) field whose value is set so that the hash of the block will contain a run of leading zeros. The rest of the fields may not be changed, as they have a defined meaning.
|
||||
nonce::
|
||||
The "nonce" in a bitcoin block is a 32-bit (4-byte) field whose value is set so that the hash of the block will contain a run of leading zeros. The rest of the fields may not be changed, as they have a defined meaning.
|
||||
|
||||
Off-Chain Transactions::
|
||||
An off-chain transaction is the movement of value outside of the block chain. While an on-chain transaction - usually referred to as simply 'a transaction' - modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction.
|
||||
off-chain transactions::
|
||||
An off-chain transaction is the movement of value outside of the block chain. While an on-chain transaction—usually referred to as simply __a transaction__—modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction.
|
||||
|
||||
Opcode::
|
||||
opcode::
|
||||
Operation codes from the Bitcoin Script language which push data or perform functions within a pubkey script or signature script.
|
||||
|
||||
Open Assets Protocol::
|
||||
The Open Assets Protocol is a simple and powerful protocol built on top of the Bitcoin Blockchain. It allows issuance and transfer of user-created assets. The Open Assets Protocol is an evolution of the concept of colored coins.
|
||||
Open Assets protocol::
|
||||
The Open Assets Protocol is a simple and powerful protocol built on top of the bitcoin blockchain. It allows issuance and transfer of user-created assets. The Open Assets protocol is an evolution of the concept of colored coins.
|
||||
|
||||
OP_RETURN::
|
||||
An opcode used in one of the outputs in an OP_RETURN transaction. Not to be confused with OP_RETURN transaction.
|
||||
@ -149,44 +149,44 @@ OP_RETURN transaction::
|
||||
Orphan Block::
|
||||
Blocks whose parent block has not been processed by the local node, so they can’t be fully validated yet. Not to be confused with stale block.
|
||||
|
||||
Orphan Transactions::
|
||||
orphan transactions::
|
||||
Transactions that can't go into the pool due to one or more missing input transactions.
|
||||
|
||||
Output::
|
||||
Output, Transaction Output or TxOut is an output in a transaction which contains two fields: a value field for transferring zero or more satoshis and a pubkey script for indicating what conditions must be fulfilled for those satoshis to be further spent.
|
||||
output::
|
||||
Output, transaction output, or TxOut is an output in a transaction which contains two fields: a value field for transferring zero or more satoshis and a pubkey script for indicating what conditions must be fulfilled for those satoshis to be further spent.
|
||||
|
||||
P2PKH::
|
||||
Transactions that pay a bitcoin address contain P2PKH or Pay To PubKey Hash scripts. An output locked by a P2PKH script can be unlocked (spent) by presenting a public key and a digital signature created by the corresponding private key.
|
||||
|
||||
P2SH::
|
||||
P2SH or Pay To Script Hash is a powerful new type of transaction that greatly simplifies the use of complex transaction scripts. With P2SH the complex script that details the conditions for spending the output (redeem script) is not presented in the locking script. Instead, only a hash of it is in the locking script.
|
||||
P2SH or Pay-to-Script-Hash is a powerful new type of transaction that greatly simplifies the use of complex transaction scripts. With P2SH the complex script that details the conditions for spending the output (redeem script) is not presented in the locking script. Instead, only a hash of it is in the locking script.
|
||||
|
||||
P2SH address::
|
||||
P2SH addresses are Base58Check encodings of the 20-byte hash of a script, P2SH addresses use the version prefix "5", which results in Base58Check-encoded addresses that start with a "3". P2SH addresses hide all of the complexity, so that the person making a payment does not see the script.
|
||||
|
||||
P2WPKH::
|
||||
The signature of a P2WPKH (Pay to Witness Public Key Hash) contains the same information as a P2PKH spending, but is located in the witness field instead of the scriptSig field. The scriptPubKey is also modified.
|
||||
The signature of a P2WPKH (Pay-to-Witness-Public-Key-Hash) contains the same information as a P2PKH spending, but is located in the witness field instead of the scriptSig field. The scriptPubKey is also modified.
|
||||
|
||||
P2WSH::
|
||||
The difference between P2SH and P2WSH (Pay to Witness Script Hash) is about the cryptographic proof location change from the scriptSig field to the witness field and the scriptPubKey that is also modified.
|
||||
The difference between P2SH and P2WSH (Pay-to-Witness-Script-Hash) is about the cryptographic proof location change from the scriptSig field to the witness field and the scriptPubKey that is also modified.
|
||||
|
||||
Paper wallet::
|
||||
paper wallet::
|
||||
In the most specific sense, a paper wallet is a document containing all of the data necessary to generate any number of Bitcoin private keys, forming a wallet of keys. However, people often use the term to mean any way of storing bitcoin offline as a physical document. This second definition also includes paper keys and redeemable codes.
|
||||
|
||||
Payment channels::
|
||||
A Micropayment Channel or Payment Channel is class of techniques designed to allow users to make multiple Bitcoin transactions without committing all of the transactions to the Bitcoin block chain. In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimited number of payments can be made between the participants.
|
||||
payment channels::
|
||||
A micropayment channel or payment channel is class of techniques designed to allow users to make multiple bitcoin transactions without committing all of the transactions to the bitcoin blockchain. In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimited number of payments can be made between the participants.
|
||||
|
||||
Pooled mining::
|
||||
pooled mining::
|
||||
Pooled mining is a mining approach where multiple generating clients contribute to the generation of a block, and then split the block reward according the contributed processing power.
|
||||
|
||||
Proof-of-stake::
|
||||
Proof-of-stake (PoS) is a method by which a cryptocurrency blockchain network aims to achieve distributed consensus. Proof of stake asks users to prove ownership of a certain amount of currency (their "stake" in the currency).
|
||||
Proof-of-Stake::
|
||||
Proof-of-Stake (PoS) is a method by which a cryptocurrency blockchain network aims to achieve distributed consensus. Proof-of-Stake asks users to prove ownership of a certain amount of currency (their "stake" in the currency).
|
||||
|
||||
Proof-Of-Work::
|
||||
Proof-of-Work::
|
||||
A piece of data that requires significant computation to find. In bitcoin, miners must find a numeric solution to the SHA256 algorithm that meets a network-wide target, the difficulty target.
|
||||
|
||||
reward::
|
||||
An amount included in each new block as a reward by the network to the miner who found the Proof-Of-Work solution. It is currently 12.5BTC per block.
|
||||
An amount included in each new block as a reward by the network to the miner who found the Proof-of-Work solution. It is currently 12.5 BTC per block.
|
||||
|
||||
RIPEMD-160::
|
||||
RIPEMD-160 is a 160-bit cryptographic hash function. RIPEMD-160 is a strengthened version of RIPEMD with a 160-bit hash result, and is expected to be secure for the next ten years or more.
|
||||
@ -200,24 +200,31 @@ Satoshi Nakamoto::
|
||||
Script::
|
||||
Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.
|
||||
|
||||
ScriptPubKey (aka Pubkey Script)::
|
||||
ScriptPubKey or Pubkey Script, is a script included in outputs which sets the conditions that must be fulfilled for those satoshis to be spent. Data for fulfilling the conditions can be provided in a signature script.
|
||||
ScriptPubKey (aka pubkey script)::
|
||||
ScriptPubKey or pubkey script, is a script included in outputs which sets the conditions that must be fulfilled for those satoshis to be spent. Data for fulfilling the conditions can be provided in a signature script.
|
||||
|
||||
ScriptSig (aka Signature Script)::
|
||||
ScriptSig or Signature Script, is the data generated by a spender which is almost always used as variables to satisfy a pubkey script.
|
||||
ScriptSig (aka signature script)::
|
||||
ScriptSig or signature script, is the data generated by a spender which is almost always used as variables to satisfy a pubkey script.
|
||||
|
||||
secret key (aka private key)::
|
||||
The secret number that unlocks bitcoin sent to the corresponding address. A secret key looks like +5J76sF8L5jTtzE96r66Sf8cka9y44wdpJjMwCxR3tzLh3ibVPxh+.
|
||||
The secret number that unlocks bitcoin sent to the corresponding address. pass:[<span class="keep-together">A secret</span>] key looks like the following:
|
||||
+
|
||||
----
|
||||
5J76sF8L5jTtzE96r66Sf8cka9y44wdpJjMwCxR3tzLh3ibVPxh
|
||||
----
|
||||
|
||||
Segregated Witness::
|
||||
Segregated Witness is a proposed upgrade to the Bitcoin protocol which technological innovation separates signature data from Bitcoin transactions. Segregated Witness is a proposed soft fork; a change that technically makes Bitcoin’s protocol rules more restrictive.
|
||||
Segregated Witness is a proposed upgrade to the Bitcoin protocol which technological innovation separates signature data from bitcoin transactions. Segregated Witness is a proposed soft fork; a change that technically makes Bitcoin’s protocol rules more restrictive.
|
||||
|
||||
SHA::
|
||||
The Secure Hash Algorithm or SHA is a family of cryptographic hash functions published by the National Institute of Standards and Technology (NIST).
|
||||
|
||||
simplified payment verification (SPV)::
|
||||
SPV or simplified payment verification is a method for verifying particular transactions were included in a block without downloading the entire block. The method is used by some lightweight Bitcoin clients.
|
||||
|
||||
Soft Fork::
|
||||
Soft Fork or Soft-Forking Change is a temporary fork in the Blockchain which commonly occurs when miners using non-upgraded nodes don't follow a new consensus rule their nodes don’t know about.
|
||||
Not to be confused with Fork, Hard fork, Software fork or Git fork.
|
||||
soft fork::
|
||||
soft fork or Soft-Forking Change is a temporary fork in the blockchain which commonly occurs when miners using non-upgraded nodes don't follow a new consensus rule their nodes don’t know about.
|
||||
Not to be confused with fork, hard fork, software fork or Git fork.
|
||||
|
||||
SPV (aka Simplified Payment Verification)::
|
||||
SPV or Simplified Payment Verification is a method for verifying particular transactions were included in a block without downloading the entire block. The method is used by some lightweight Bitcoin clients.
|
||||
@ -226,24 +233,24 @@ Stale Block::
|
||||
Block which were successfully mined but which isn’t included on the current best block chain, likely because some other block at the same height had its chain extended first. Not to be confused with orphan block.
|
||||
|
||||
timelocks::
|
||||
A Timelock is a type of encumbrance that restricts the spending of some bitcoin until a specified future time or block height. Timelocks feature prominently in many Bitcoin contracts, including payment channels and hashed timelock contracts.
|
||||
A timelock is a type of encumbrance that restricts the spending of some bitcoin until a specified future time or block height. Timelocks feature prominently in many Bitcoin contracts, including payment channels and hashed timelock contracts.
|
||||
|
||||
transaction::
|
||||
In simple terms, a transfer of bitcoin from one address to another. More precisely, a transaction is a signed data structure expressing a transfer of value. Transactions are transmitted over the bitcoin network, collected by miners, and included into blocks, made permanent on the blockchain.
|
||||
|
||||
Transaction Pool::
|
||||
transaction pool::
|
||||
An unordered collection of transactions that are not in blocks in the main chain, but for which we have input transactions.
|
||||
|
||||
Turing completeness::
|
||||
A program language is called "Turing complete" if it can run any program that a Turing machine can run, given enough time and memory.
|
||||
|
||||
UTXO (aka Unspent Transaction Output)::
|
||||
UTXO is an Unspent Transaction Output that can be spent as an input in a new transaction.
|
||||
unspent transaction output (UTXO)::
|
||||
UTXO is an unspent transaction output that can be spent as an input in a new transaction.
|
||||
|
||||
wallet::
|
||||
Software that holds all your bitcoin addresses and secret keys. Use it to send, receive, and store your bitcoin.
|
||||
|
||||
WIF (aka Wallet Import Format)::
|
||||
Wallet Import Format (WIF)::
|
||||
WIF or Wallet Import Format is a data interchange format designed to allow exporting and importing a single private key with a flag indicating whether or not it uses a compressed public key.
|
||||
|
||||
Some contributed definitions have been sourced under a CC-BY license from the bitcoin Wiki (https://en.bitcoin.it/wiki/Main_Page[https://en.bitcoin.it/wiki/Main_Page]), or from other open-source documentation sources.
|
||||
Some contributed definitions have been sourced under a CC-BY license from the https://en.bitcoin.it/wiki/Main_Page[bitcoin Wiki] or from other open source documentation sources.
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 166 KiB After Width: | Height: | Size: 131 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 66 KiB After Width: | Height: | Size: 66 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 48 KiB |
@ -47,6 +47,17 @@ figure.smallerthirtyfive img { width: 35%; }
|
||||
|
||||
figure.smallerthirty img { width: 30%; }
|
||||
|
||||
/*class to adjust the space of code listings to fix page break*/
|
||||
pre.c_less_space {
|
||||
margin: 0 0 4pt 17pt;
|
||||
line-height: 110%;
|
||||
}
|
||||
|
||||
pre.c_less_space2 {
|
||||
margin: 0 0 4pt 17pt;
|
||||
line-height: 105%;
|
||||
}
|
||||
|
||||
/*----Uncomment to temporarily turn on code-eyballer highlighting (make sure to recomment after you build)
|
||||
|
||||
pre {
|
||||
|
||||
Loading…
Reference in New Issue
Block a user