diff --git a/_alerts/2015-10-12-upnp-vulnerability.md b/_alerts/2015-10-12-upnp-vulnerability.md index 76d2d43a..aab6b9d0 100644 --- a/_alerts/2015-10-12-upnp-vulnerability.md +++ b/_alerts/2015-10-12-upnp-vulnerability.md @@ -14,7 +14,7 @@ show_toc: true ## Summary -![Disabling UPnP in the GUI](/img/alerts/disable_upnp.png) +![Disabling UPnP in the GUI](/img/alerts/disable_upnp.png?{{site.time | date: '%s'}}) Either diff --git a/_data/devdocs/en/examples/p2p_networking.md b/_data/devdocs/en/examples/p2p_networking.md index 81b0946f..b023f836 100644 --- a/_data/devdocs/en/examples/p2p_networking.md +++ b/_data/devdocs/en/examples/p2p_networking.md @@ -386,19 +386,19 @@ bb3183301d7a1fb3bd174fcfa40a2b65 ... Hash #2 We parse the above `merkleblock` message using the following instructions. Each illustration is described in the paragraph below it. -![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-001.svg) +![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-001.svg?{{site.time | date: '%s'}}) We start by building the structure of a merkle tree based on the number of transactions in the block. -![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-002.svg) +![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-002.svg?{{site.time | date: '%s'}}) The first flag is a 1 and the merkle root is (as always) a non-TXID node, so we will need to compute the hash later based on this node's children. Accordingly, we descend into the merkle root's left child and look at the next flag for instructions. -![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-003.svg) +![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-003.svg?{{site.time | date: '%s'}}) The next flag in the example is a 0 and this is also a non-TXID node, so we apply the first hash from the `merkleblock` message to this node. We @@ -408,43 +408,43 @@ transactions that match our filter, so we don't need them. We go back up to the merkle root and then descend into its right child and look at the next (third) flag for instructions. -![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-004.svg) +![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-004.svg?{{site.time | date: '%s'}}) The third flag in the example is another 1 on another non-TXID node, so we descend into its left child. -![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-005.svg) +![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-005.svg?{{site.time | date: '%s'}}) The fourth flag is also a 1 on another non-TXID node, so we descend again---we will always continue descending until we reach a TXID node or a non-TXID node with a 0 flag (or we finish filling out the tree). -![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-006.svg) +![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-006.svg?{{site.time | date: '%s'}}) Finally, on the fifth flag in the example (a 1), we reach a TXID node. The 1 flag indicates this TXID's transaction matches our filter and that we should take the next (second) hash and use it as this node's TXID. -![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-007.svg) +![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-007.svg?{{site.time | date: '%s'}}) The sixth flag also applies to a TXID, but it's a 0 flag, so this TXID's transaction doesn't match our filter; still, we take the next (third) hash and use it as this node's TXID. -![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-008.svg) +![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-008.svg?{{site.time | date: '%s'}}) We now have enough information to compute the hash for the fourth node we encountered---it's the hash of the concatenated hashes of the two TXIDs we filled out. -![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-009.svg) +![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-009.svg?{{site.time | date: '%s'}}) Moving to the right child of the third node we encountered, we fill it out using the seventh flag and final hash---and discover there are no more child nodes to process. -![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-011.svg) +![Parsing A MerkleBlock](/img/dev/gifs/en-merkleblock-parsing/en-merkleblock-parsing-011.svg?{{site.time | date: '%s'}}) We hash as appropriate to fill out the tree. Note that the eighth flag is not used---this is acceptable as it was required to pad out a flag byte. diff --git a/_data/devdocs/en/examples/payment_processing.md b/_data/devdocs/en/examples/payment_processing.md index 23079ab3..1e1bc8c3 100644 --- a/_data/devdocs/en/examples/payment_processing.md +++ b/_data/devdocs/en/examples/payment_processing.md @@ -55,7 +55,7 @@ not used in this program.) The full sequence of events is illustrated below, starting with the spender clicking a `bitcoin:` URI or scanning a `bitcoin:` QR code. -![BIP70 Payment Protocol](/img/dev/en-payment-protocol.svg) +![BIP70 Payment Protocol](/img/dev/en-payment-protocol.svg?{{site.time | date: '%s'}}) For the script to use the protocol buffer, you will need a copy of Google's Protocol Buffer compiler (`protoc`), which is available in most @@ -221,7 +221,7 @@ www.bitcoin.org X.509 certificate and how each certificate (except the root certificate) would be loaded into the [X509Certificates][]{:#term-x509certificates}{:.term} protocol buffer message. -![X509Certificates Loading Order](/img/dev/en-cert-order.svg) +![X509Certificates Loading Order](/img/dev/en-cert-order.svg?{{site.time | date: '%s'}}) To be specific, the first certificate provided must be the X.509 certificate corresponding to the private SSL key which will make the @@ -469,6 +469,6 @@ because it would add an extraneous newline. The following screenshot shows how the authenticated PaymentDetails created by the program above appears in the GUI from Bitcoin Core 0.9. -![Bitcoin Core Showing Validated Payment Request](/img/dev/en-btcc-payment-request.png) +![Bitcoin Core Showing Validated Payment Request](/img/dev/en-btcc-payment-request.png?{{site.time | date: '%s'}}) {% endautocrossref %} \ No newline at end of file diff --git a/_data/devdocs/en/examples/transactions.md b/_data/devdocs/en/examples/transactions.md index a54a4114..48f2a3c7 100644 --- a/_data/devdocs/en/examples/transactions.md +++ b/_data/devdocs/en/examples/transactions.md @@ -242,7 +242,7 @@ second argument (a JSON object) creates the output with the address (public key hash) and number of bitcoins we want to transfer. We save the resulting raw format transaction to a shell variable. -![Warning icon](/img/icons/icon_warning.svg) +![Warning icon](/img/icons/icon_warning.svg?{{site.time | date: '%s'}}) **Warning:** `createrawtransaction` does not automatically create change outputs, so you can easily accidentally pay a large transaction fee. In this example, our input had 50.0000 bitcoins and our output @@ -462,7 +462,7 @@ Use the `dumpprivkey` RPC to get the private keys corresponding to the public keys used in the two UTXOs out inputs we will be spending. We need the private keys so we can sign each of the inputs separately. -![Warning icon](/img/icons/icon_warning.svg) +![Warning icon](/img/icons/icon_warning.svg?{{site.time | date: '%s'}}) **Warning:** Users should never manually manage private keys on mainnet. As dangerous as raw transactions are (see warnings above), making a mistake with a private key can be much worse---as in the case of a HD @@ -629,7 +629,7 @@ Offline signing is safe. However, in this example we will also be spending an output which is not part of the block chain because the transaction containing it has never been broadcast. That can be unsafe: -![Warning icon](/img/icons/icon_warning.svg) +![Warning icon](/img/icons/icon_warning.svg?{{site.time | date: '%s'}}) **Warning:** Transactions which spend outputs from unconfirmed transactions are vulnerable to transaction malleability. Be sure to read about transaction malleability and adopt good practices before spending @@ -804,7 +804,7 @@ Transaction subsection. If you've read the [Transaction section][transaction] of the guide, you may know why the call fails and leaves the raw transaction hex unchanged. -![Old Transaction Data Required To Be Signed](/img/dev/en-signing-output-to-spend.svg) +![Old Transaction Data Required To Be Signed](/img/dev/en-signing-output-to-spend.svg?{{site.time | date: '%s'}}) As illustrated above, the data that gets signed includes the txid and vout from the previous transaction. That information is included in the @@ -1022,7 +1022,7 @@ redeem script. The P2SH address is returned along with the redeem script which must be provided when we spend satoshis sent to the P2SH address. -![Warning icon](/img/icons/icon_warning.svg) +![Warning icon](/img/icons/icon_warning.svg?{{site.time | date: '%s'}}) **Warning:** You must not lose the redeem script, especially if you don't have a record of which public keys you used to create the P2SH multisig address. You need the redeem script to spend any bitcoins sent @@ -1176,7 +1176,7 @@ transaction, the same way we got private keys in the Complex Raw Transaction subsection. Recall that we created a 2-of-3 multisig pubkey script, so signatures from two private keys are needed. -![Warning icon](/img/icons/icon_warning.svg) +![Warning icon](/img/icons/icon_warning.svg?{{site.time | date: '%s'}}) **Reminder:** Users should never manually manage private keys on mainnet. See the warning in the [complex raw transaction section][devex complex raw transaction]. diff --git a/_data/devdocs/en/guides/block_chain.md b/_data/devdocs/en/guides/block_chain.md index 8e24b15e..94aad406 100644 --- a/_data/devdocs/en/guides/block_chain.md +++ b/_data/devdocs/en/guides/block_chain.md @@ -29,7 +29,7 @@ the consensus rules used by Bitcoin Core. {% autocrossref %} -![Block Chain Overview](/img/dev/en-blockchain-overview.svg) +![Block Chain Overview](/img/dev/en-blockchain-overview.svg?{{site.time | date: '%s'}}) The illustration above shows a simplified version of a block chain. A [block][/en/glossary/block]{:#term-block}{:.term} of one or more new transactions @@ -50,7 +50,7 @@ transaction spends the satoshis previously received in one or more earlier transactions, so the input of one transaction is the output of a previous transaction. -![Transaction Propagation](/img/dev/en-transaction-propagation.svg) +![Transaction Propagation](/img/dev/en-transaction-propagation.svg?{{site.time | date: '%s'}}) A single transaction can create multiple outputs, as would be the case when sending to multiple addresses, but each output of @@ -167,7 +167,7 @@ by their [block height][/en/glossary/block-height]{:#term-block-height}{:.term}- block (block 0, most commonly known as the [genesis block][/en/glossary/genesis-block]{:#term-genesis-block}{:.term}). For example, block 2016 is where difficulty could have first been adjusted. -![Common And Uncommon Block Chain Forks](/img/dev/en-blockchain-fork.svg) +![Common And Uncommon Block Chain Forks](/img/dev/en-blockchain-fork.svg?{{site.time | date: '%s'}}) Multiple blocks can all have the same block height, as is common when two or more miners each produce a block at roughly the same time. This @@ -300,7 +300,7 @@ nodes. This creates permanently divergent chains---one for non-upgraded nodes and one for upgraded nodes---called a [hard fork][/en/glossary/hard-fork]{:#term-hard-fork}{:.term}. -![Hard Fork](/img/dev/en-hard-fork.svg) +![Hard Fork](/img/dev/en-hard-fork.svg?{{site.time | date: '%s'}}) In the second case, rejection by upgraded nodes, it's possible to keep the block chain from permanently diverging if upgraded nodes control a @@ -310,7 +310,7 @@ upgraded nodes can build a stronger chain that the non-upgraded nodes will accept as the best valid block chain. This is called a [soft fork][/en/glossary/soft-fork]{:#term-soft-fork}{:.term}. -![Soft Fork](/img/dev/en-soft-fork.svg) +![Soft Fork](/img/dev/en-soft-fork.svg?{{site.time | date: '%s'}}) Although a fork is an actual divergence in block chains, changes to the consensus rules are often described by their potential to create either diff --git a/_data/devdocs/en/guides/contracts.md b/_data/devdocs/en/guides/contracts.md index 8f486655..0fee4723 100644 --- a/_data/devdocs/en/guides/contracts.md +++ b/_data/devdocs/en/guides/contracts.md @@ -157,7 +157,7 @@ by locktime. This is the refund transaction. Bob can't sign the refund transacti it to Alice to sign, as shown in the illustration below. -![Micropayment Channel Example](/img/dev/en-micropayment-channel.svg) +![Micropayment Channel Example](/img/dev/en-micropayment-channel.svg?{{site.time | date: '%s'}}) Alice checks that the refund transaction's locktime is 24 hours in the future, signs it, and gives a copy of it back to Bob. She then asks Bob @@ -230,7 +230,7 @@ illustration below, makes this decision easy: they create a single transaction which does all of the spending simultaneously, ensuring none of them can steal the others' satoshis. -![Example CoinJoin Transaction](/img/dev/en-coinjoin.svg) +![Example CoinJoin Transaction](/img/dev/en-coinjoin.svg?{{site.time | date: '%s'}}) Each contributor looks through their collection of Unspent Transaction Outputs (UTXOs) for 100 millibitcoins they can spend. They then each generate diff --git a/_data/devdocs/en/guides/mining.md b/_data/devdocs/en/guides/mining.md index 997a88f2..b274e63f 100644 --- a/_data/devdocs/en/guides/mining.md +++ b/_data/devdocs/en/guides/mining.md @@ -37,7 +37,7 @@ transactions from the network. Their mining software periodically polls provides the list of new transactions plus the public key to which the coinbase transaction should be sent. -![Solo Bitcoin Mining](/img/dev/en-solo-mining-overview.svg) +![Solo Bitcoin Mining](/img/dev/en-solo-mining-overview.svg?{{site.time | date: '%s'}}) The mining software constructs a block using the template (described below) and creates a block header. It then sends the 80-byte block header to its mining @@ -70,7 +70,7 @@ done. The mining pool gets new transactions from the network using software connects to the pool and requests the information it needs to construct block headers. -![Pooled Bitcoin Mining](/img/dev/en-pooled-mining-overview.svg) +![Pooled Bitcoin Mining](/img/dev/en-pooled-mining-overview.svg?{{site.time | date: '%s'}}) In pooled mining, the mining pool sets the target threshold a few orders of magnitude higher (less difficult) than the network diff --git a/_data/devdocs/en/guides/operating_modes.md b/_data/devdocs/en/guides/operating_modes.md index 54ecdf88..45292b75 100644 --- a/_data/devdocs/en/guides/operating_modes.md +++ b/_data/devdocs/en/guides/operating_modes.md @@ -23,7 +23,7 @@ The first and most secure model is the one followed by Bitcoin Core, also known For a client to be fooled, an adversary would need to give a complete alternative block chain history that is of greater difficulty than the current “true” chain, which is computationally expensive (if not impossible) due to the fact that the chain with the most cumulative proof of work is by definition the "true" chain. Due to the computational difficulty required to generate a new block at the tip of the chain, the ability to fool a full node becomes very expensive after 6 confirmations. This form of verification is highly resistent to sybil attacks---only a single honest network peer is required in order to receive and verify the complete state of the "true" block chain. -![Block Height Compared To Block Depth](/img/dev/en-block-height-vs-depth.svg) +![Block Height Compared To Block Depth](/img/dev/en-block-height-vs-depth.svg?{{site.time | date: '%s'}}) {% endautocrossref %} diff --git a/_data/devdocs/en/guides/p2p_network.md b/_data/devdocs/en/guides/p2p_network.md index 045e0cee..a8f20dc9 100644 --- a/_data/devdocs/en/guides/p2p_network.md +++ b/_data/devdocs/en/guides/p2p_network.md @@ -178,14 +178,14 @@ Bitcoin Core (up until version [0.9.3][bitcoin core 0.9.3]) uses a simple initial block download (IBD) method we'll call *blocks-first*. The goal is to download the blocks from the best block chain in sequence. -![Overview Of Blocks-First Method](/img/dev/en-blocks-first-flowchart.svg) +![Overview Of Blocks-First Method](/img/dev/en-blocks-first-flowchart.svg?{{site.time | date: '%s'}}) The first time a node is started, it only has a single block in its local best block chain---the hardcoded genesis block (block 0). This node chooses a remote peer, called the sync node, and sends it the `getblocks` message illustrated below. -![First GetBlocks Message Sent During IBD](/img/dev/en-ibd-getblocks.svg) +![First GetBlocks Message Sent During IBD](/img/dev/en-ibd-getblocks.svg?{{site.time | date: '%s'}}) In the header hashes field of the `getblocks` message, this new node sends the header hash of the only block it has, the genesis block @@ -199,7 +199,7 @@ replies with 500 block inventories (the maximum response to a `getblocks` message) starting from block 1. It sends these inventories in the `inv` message illustrated below. -![First Inv Message Sent During IBD](/img/dev/en-ibd-inv.svg) +![First Inv Message Sent During IBD](/img/dev/en-ibd-inv.svg?{{site.time | date: '%s'}}) Inventories are unique identifiers for information on the network. Each inventory contains a type field and the unique identifier for an @@ -214,7 +214,7 @@ is 4860...0000 as seen in the illustration above.) The IBD node uses the received inventories to request 128 blocks from the sync node in the `getdata` message illustrated below. -![First GetData Message Sent During IBD](/img/dev/en-ibd-getdata.svg) +![First GetData Message Sent During IBD](/img/dev/en-ibd-getdata.svg?{{site.time | date: '%s'}}) It's important to blocks-first nodes that the blocks be requested and sent in order because each block header references the header hash of @@ -228,7 +228,7 @@ of the blocks requested. Each block is put into serialized block format and sent in a separate `block` message. The first `block` message sent (for block 1) is illustrated below. -![First Block Message Sent During IBD](/img/dev/en-ibd-block.svg) +![First Block Message Sent During IBD](/img/dev/en-ibd-block.svg?{{site.time | date: '%s'}}) The IBD node downloads each block, validates it, and then requests the next block it hasn't requested yet, maintaining a queue of up to 128 @@ -238,7 +238,7 @@ requesting the inventories of up to 500 more blocks. This second `getblocks` message contains multiple header hashes as illustrated below: -![Second GetBlocks Message Sent During IBD](/img/dev/en-ibd-getblocks2.svg) +![Second GetBlocks Message Sent During IBD](/img/dev/en-ibd-getblocks2.svg?{{site.time | date: '%s'}}) Upon receipt of the second `getblocks` message, the sync node searches its local best block chain for a block that matches one of the header @@ -325,14 +325,14 @@ chain][/en/glossary/header-chain]{:#term-header-chain}{:.term}, partially valida as possible, and then download the corresponding blocks in parallel. This solves several problems with the older blocks-first IBD method. -![Overview Of Headers-First Method](/img/dev/en-headers-first-flowchart.svg) +![Overview Of Headers-First Method](/img/dev/en-headers-first-flowchart.svg?{{site.time | date: '%s'}}) The first time a node is started, it only has a single block in its local best block chain---the hardcoded genesis block (block 0). The node chooses a remote peer, which we'll call the sync node, and sends it the `getheaders` message illustrated below. -![First getheaders message](/img/dev/en-ibd-getheaders.svg) +![First getheaders message](/img/dev/en-ibd-getheaders.svg?{{site.time | date: '%s'}}) In the header hashes field of the `getheaders` message, the new node sends the header hash of the only block it has, the genesis block @@ -346,7 +346,7 @@ replies with 2,000 header (the maximum response) starting from block 1. It sends these header hashes in the `headers` message illustrated below. -![First headers message](/img/dev/en-ibd-headers.svg) +![First headers message](/img/dev/en-ibd-headers.svg?{{site.time | date: '%s'}}) The IBD node can partially validate these block headers by ensuring that all fields follow consensus rules and that the hash of the header is @@ -394,7 +394,7 @@ two things in parallel: during IBD (the same maximum number that blocks-first Bitcoin Core requested from its sync node). -![Simulated Headers-First Download Window](/img/dev/en-headers-first-moving-window.svg) +![Simulated Headers-First Download Window](/img/dev/en-headers-first-moving-window.svg?{{site.time | date: '%s'}}) Bitcoin Core's headers-first mode uses a 1,024-block moving download window to maximize download speed. The lowest-height block in the window @@ -509,7 +509,7 @@ hasn't seen yet. In other words, orphan blocks have no known parent (unlike stale blocks, which have known parents but which aren't part of the best block chain). -![Difference Between Orphan And Stale Blocks](/img/dev/en-orphan-stale-definition.svg) +![Difference Between Orphan And Stale Blocks](/img/dev/en-orphan-stale-definition.svg?{{site.time | date: '%s'}}) When a blocks-first node downloads an orphan block, it will not validate it. Instead, it will send a `getblocks` message to the node which sent diff --git a/_data/devdocs/en/guides/payment_processing.md b/_data/devdocs/en/guides/payment_processing.md index c4ebeff5..3c698c41 100644 --- a/_data/devdocs/en/guides/payment_processing.md +++ b/_data/devdocs/en/guides/payment_processing.md @@ -18,7 +18,7 @@ can, respectively, request and make payments using Bitcoin---and how they can deal with complications such as refunds and recurrent rebilling. -![Bitcoin Payment Processing](/img/dev/en-payment-processing.svg) +![Bitcoin Payment Processing](/img/dev/en-payment-processing.svg?{{site.time | date: '%s'}}) The figure above illustrates payment processing using Bitcoin from a receiver's perspective, starting with a new order. The following @@ -122,7 +122,7 @@ payment requests is recommended. increased security, authentication of a receiver's identity using X.509 certificates, and other important features such as refunds. -![Warning icon](/img/icons/icon_warning.svg) +![Warning icon](/img/icons/icon_warning.svg?{{site.time | date: '%s'}}) **Warning:** Special care must be taken to avoid the theft of incoming payments. In particular, private keys should not be stored on web servers, and payment requests should be sent over HTTPS or other secure methods @@ -239,7 +239,7 @@ parameters---and any other optional parameters---but they were omitted here to keep the QR code small and easy to scan with unsteady or low-resolution mobile cameras. -![Bitcoin QR Codes](/img/dev/en-qr-code.svg) +![Bitcoin QR Codes](/img/dev/en-qr-code.svg?{{site.time | date: '%s'}}) The error correction is combined with a checksum to ensure the Bitcoin QR code cannot be successfully decoded with data missing or accidentally altered, @@ -295,7 +295,7 @@ the other parameters and fetch a PaymentRequest from the URL provided. The browser, QR code reader, or other program processing the URI opens the spender's Bitcoin wallet program on the URI. -![BIP70 Payment Protocol](/img/dev/en-payment-protocol.svg) +![BIP70 Payment Protocol](/img/dev/en-payment-protocol.svg?{{site.time | date: '%s'}}) The Payment Protocol is described in depth in BIP70, BIP71, and BIP72. An example CGI program and description of all the parameters which can @@ -363,7 +363,7 @@ server's X.509 SSL certificate. (The Payment Protocol has been designed to allow other signing methods in the future.) Bob's server sends the payment request to Charlie's wallet in the reply to the HTTP GET. -![Bitcoin Core Showing Validated Payment Request](/img/dev/en-btcc-payment-request.png) +![Bitcoin Core Showing Validated Payment Request](/img/dev/en-btcc-payment-request.png?{{site.time | date: '%s'}}) Charlie's wallet receives the PaymentRequest message, checks its signature, and then displays the details from the PaymentDetails message to Charlie. Charlie diff --git a/_data/devdocs/en/guides/transactions.md b/_data/devdocs/en/guides/transactions.md index 72d59466..850a5b37 100644 --- a/_data/devdocs/en/guides/transactions.md +++ b/_data/devdocs/en/guides/transactions.md @@ -31,7 +31,7 @@ and they're an exception to many of the rules listed below. Instead of pointing out the coinbase exception to each rule, we invite you to read about coinbase transactions in the block chain section of this guide. -![The Parts Of A Transaction](/img/dev/en-tx-overview.svg) +![The Parts Of A Transaction](/img/dev/en-tx-overview.svg?{{site.time | date: '%s'}}) The figure above shows the main parts of a Bitcoin transaction. Each transaction has at least one input and one output. Each [input][/en/glossary/input]{:#term-input}{:.term} spends the @@ -45,7 +45,7 @@ Bitcoin peers and miners which set of rules to use to validate it. This lets developers create new rules for future transactions without invalidating previous transactions. -![Spending An Output](/img/dev/en-tx-overview-spending.svg) +![Spending An Output](/img/dev/en-tx-overview-spending.svg?{{site.time | date: '%s'}}) An output has an implied index number based on its location in the transaction---the index of the first output is zero. The output also has an @@ -68,7 +68,7 @@ type. [P2PKH][/en/glossary/p2pkh-address]{:#term-p2pkh}{:.term} lets Alice spend and then lets Bob further spend those satoshis using a simple cryptographic key pair. -![Creating A P2PKH Public Key Hash To Receive Payment](/img/dev/en-creating-p2pkh-output.svg) +![Creating A P2PKH Public Key Hash To Receive Payment](/img/dev/en-creating-p2pkh-output.svg?{{site.time | date: '%s'}}) Bob must first generate a private/public [key pair][]{:#term-key-pair}{:.term} before Alice can create the first transaction. Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with @@ -122,7 +122,7 @@ Pubkey scripts and signature scripts combine secp256k1 pubkeys and signatures with conditional logic, creating a programmable authorization mechanism. -![Unlocking A P2PKH Output For Spending](/img/dev/en-unlocking-p2pkh-output.svg) +![Unlocking A P2PKH Output For Spending](/img/dev/en-unlocking-p2pkh-output.svg?{{site.time | date: '%s'}}) For a P2PKH-style output, Bob's signature script will contain the following two pieces of data: @@ -139,7 +139,7 @@ Bob's secp256k1 signature doesn't just prove Bob controls his private key; it al makes the non-signature-script parts of his transaction tamper-proof so Bob can safely broadcast them over the peer-to-peer network. -![Some Things Signed When Spending An Output](/img/dev/en-signing-output-to-spend.svg) +![Some Things Signed When Spending An Output](/img/dev/en-signing-output-to-spend.svg?{{site.time | date: '%s'}}) As illustrated in the figure above, the data Bob signs includes the txid and output index of the previous transaction, the previous @@ -205,7 +205,7 @@ and continuing to the end of Alice's pubkey script. The figure below shows the evaluation of a standard P2PKH pubkey script; below the figure is a description of the process. -![P2PKH Stack Evaluation](/img/dev/en-p2pkh-stack.svg) +![P2PKH Stack Evaluation](/img/dev/en-p2pkh-stack.svg?{{site.time | date: '%s'}}) * The signature (from Bob's signature script) is added (pushed) to an empty stack. Because it's just data, nothing is done except adding it to the stack. @@ -274,7 +274,7 @@ wants, hashes the redeem script, and provides the redeem script hash to Alice. Alice creates a P2SH-style output containing Bob's redeem script hash. -![Creating A P2SH Redeem Script And Hash](/img/dev/en-creating-p2sh-output.svg) +![Creating A P2SH Redeem Script And Hash](/img/dev/en-creating-p2sh-output.svg?{{site.time | date: '%s'}}) When Bob wants to spend the output, he provides his signature along with the full (serialized) redeem script in the signature script. The @@ -283,7 +283,7 @@ value as the script hash Alice put in her output; it then processes the redeem script exactly as it would if it were the primary pubkey script, letting Bob spend the output if the redeem script does not return false. -![Unlocking A P2SH Output For Spending](/img/dev/en-unlocking-p2sh-output.svg) +![Unlocking A P2SH Output For Spending](/img/dev/en-unlocking-p2sh-output.svg?{{site.time | date: '%s'}}) The hash of the redeem script has the same properties as a pubkey hash---so it can be transformed into the standard Bitcoin address format diff --git a/_data/devdocs/en/guides/wallets.md b/_data/devdocs/en/guides/wallets.md index afd88afc..98c3ef97 100644 --- a/_data/devdocs/en/guides/wallets.md +++ b/_data/devdocs/en/guides/wallets.md @@ -61,7 +61,7 @@ distribute those public keys as necessary, monitors for outputs spent to those public keys, creates and signs transactions spending those outputs, and broadcasts the signed transactions. -![Full-Service Wallets](/img/dev/en-wallets-full-service.svg) +![Full-Service Wallets](/img/dev/en-wallets-full-service.svg?{{site.time | date: '%s'}}) As of this writing, almost all popular wallets can be used as full-service wallets. @@ -98,7 +98,7 @@ Signing-only wallets programs typically use deterministic key creation (described in a later subsection) to create parent private and public keys which can create child private and public keys. -![Signing-Only Wallets](/img/dev/en-wallets-signing-only.svg) +![Signing-Only Wallets](/img/dev/en-wallets-signing-only.svg?{{site.time | date: '%s'}}) When first run, the signing-only wallet creates a parent private key and transfers the corresponding parent public key to the networked wallet. @@ -234,7 +234,7 @@ webservers, can be designed to distribute public keys (including P2PKH or P2SH addresses) and nothing more. There are two common ways to design these minimalist wallets: -![Distributing-Only Wallets](/img/dev/en-wallets-distributing-only.svg) +![Distributing-Only Wallets](/img/dev/en-wallets-distributing-only.svg?{{site.time | date: '%s'}}) * Pre-populate a database with a number of public keys or addresses, and then distribute on request a pubkey script or address using one of @@ -347,7 +347,7 @@ shows such a point on the elliptic curve used by Bitcoin, y2 = x3 + 7, over a field of contiguous numbers. -![Point On ECDSA Curve](/img/dev/en-ecdsa-compressed-public-key.svg) +![Point On ECDSA Curve](/img/dev/en-ecdsa-compressed-public-key.svg?{{site.time | date: '%s'}}) (Secp256k1 actually modulos coordinates by a large prime, which produces a field of non-contiguous integers and a significantly less clear plot, @@ -476,7 +476,7 @@ code][/en/glossary/master-chain-code-and-private-key]{:#term-master-chain-code}{ even if, for example, a web-based public key distribution program gets hacked. -![Overview Of Hierarchical Deterministic Key Derivation](/img/dev/en-hd-overview.svg) +![Overview Of Hierarchical Deterministic Key Derivation](/img/dev/en-hd-overview.svg?{{site.time | date: '%s'}}) As illustrated above, HD key derivation takes four inputs: @@ -520,7 +520,7 @@ key][/en/glossary/master-chain-code-and-private-key]{:#term-master-private-key}{ code are derived from random data, as illustrated below. -![Creating A Root Extended Key Pair](/img/dev/en-hd-root-keys.svg) +![Creating A Root Extended Key Pair](/img/dev/en-hd-root-keys.svg?{{site.time | date: '%s'}}) A [root seed][/en/glossary/hd-wallet-seed]{:#term-root-seed}{:.term} is created from either 128 bits, 256 bits, or 512 bits of random data. This root seed of as little @@ -528,7 +528,7 @@ as 128 bits is the the only data the user needs to backup in order to derive every key created by a particular wallet program using particular settings. -![Warning icon](/img/icons/icon_warning.svg) +![Warning icon](/img/icons/icon_warning.svg?{{site.time | date: '%s'}}) **Warning:** As of this writing, HD wallet programs are not expected to be fully compatible, so users must only use the same HD wallet program with the same HD-related settings for a particular root seed. @@ -557,7 +557,7 @@ further-descended private key, he can use the chain code to generate all of the extended private keys descending from that private key, as shown in the grandchild and great-grandchild generations of the illustration below. -![Cross-Generational Key Compromise](/img/dev/en-hd-cross-generational-key-compromise.svg) +![Cross-Generational Key Compromise](/img/dev/en-hd-cross-generational-key-compromise.svg?{{site.time | date: '%s'}}) Perhaps worse, the attacker can reverse the normal child private key derivation formula and subtract a parent chain code from a child private @@ -580,7 +580,7 @@ together the index number, the parent chain code, and the parent public key to c child chain code and the integer value which is combined with the parent private key to create the child private key. -![Creating Child Public Keys From An Extended Private Key](/img/dev/en-hd-private-parent-to-private-child.svg) +![Creating Child Public Keys From An Extended Private Key](/img/dev/en-hd-private-parent-to-private-child.svg?{{site.time | date: '%s'}}) The hardened formula, illustrated above, combines together the index number, the parent chain code, and the parent private key to create @@ -618,7 +618,7 @@ key and *M* being a public key. For example, m/0'/0/122' refers to the key. The following hierarchy illustrates prime notation and hardened key firewalls. -![Example HD Wallet Tree Using Prime Notation](/img/dev/en-hd-tree.svg) +![Example HD Wallet Tree Using Prime Notation](/img/dev/en-hd-tree.svg?{{site.time | date: '%s'}}) Wallets following the BIP32 HD protocol only create hardened children of the master private key (*m*) to prevent a compromised child key from diff --git a/_data/devdocs/en/references/block_chain.md b/_data/devdocs/en/references/block_chain.md index 42724211..0ace3199 100644 --- a/_data/devdocs/en/references/block_chain.md +++ b/_data/devdocs/en/references/block_chain.md @@ -133,7 +133,7 @@ hashed to produce the merkle root. sha256(sha256("82501c1178fa0b222c1f3d474ec726b832013f0a532b44bb620cce8624a5feb1169e1e83e930853391bc6f35f605c6754cfead57cf8387639d3b4096c54f18f4".decode("hex")).digest()).digest().encode("hex_codec") --> -![Example Merkle Tree Construction](/img/dev/en-merkle-tree-construction.svg) +![Example Merkle Tree Construction](/img/dev/en-merkle-tree-construction.svg?{{site.time | date: '%s'}}) TXIDs and intermediate hashes are always in internal byte order when they're concatenated, and the resulting merkle root is also in internal byte @@ -153,12 +153,12 @@ However, the header field *nBits* provides only 32 bits of space, so the target number uses a less precise format called "compact" which works like a base-256 version of scientific notation: -![Converting nBits Into A Target Threshold](/img/dev/en-nbits-overview.svg) +![Converting nBits Into A Target Threshold](/img/dev/en-nbits-overview.svg?{{site.time | date: '%s'}}) As a base-256 number, nBits can be quickly parsed as bytes the same way you might parse a decimal number in base-10 scientific notation: -![Quickly Converting nBits](/img/dev/en-nbits-quick-parse.svg) +![Quickly Converting nBits](/img/dev/en-nbits-quick-parse.svg?{{site.time | date: '%s'}}) + diff --git a/_includes/layout/base/head-logo.html b/_includes/layout/base/head-logo.html index 03fa1329..e1660918 100644 --- a/_includes/layout/base/head-logo.html +++ b/_includes/layout/base/head-logo.html @@ -3,4 +3,4 @@ This file is licensed under the MIT License (MIT) available on http://opensource.org/licenses/MIT. {% endcomment %} - + diff --git a/_includes/layout/base/html-head.html b/_includes/layout/base/html-head.html index ae7d10c0..85708d70 100644 --- a/_includes/layout/base/html-head.html +++ b/_includes/layout/base/html-head.html @@ -4,28 +4,28 @@ http://opensource.org/licenses/MIT. {% endcomment %} - + {% capture title %}{% translate title %}{% endcapture %}{% if title != '' %}{{ title }}{% else %}{{ page.title }}{% endif %} {% capture metadescription %}{% translate metadescription %}{% endcapture %}{% if metadescription != '' %}{% endif %} - + -{% if page.lang == 'ar' or page.lang == 'fa' %}{% endif %} -{% if page.lang == 'bg' or page.lang == 'el' or page.lang == 'ko' or page.lang == 'hi' or page.lang == 'pl' or page.lang == 'sl' or page.lang == 'ro' or page.lang == 'ru' or page.lang == 'tr' or page.lang == 'uk' or page.lang == 'zh_CN' or page.lang == 'zh_TW' %}{% endif %} - -{% if page.id != 'download' %}{% endif %} +{% if page.lang == 'ar' or page.lang == 'fa' %}{% endif %} +{% if page.lang == 'bg' or page.lang == 'el' or page.lang == 'ko' or page.lang == 'hi' or page.lang == 'pl' or page.lang == 'sl' or page.lang == 'ro' or page.lang == 'ru' or page.lang == 'tr' or page.lang == 'uk' or page.lang == 'zh_CN' or page.lang == 'zh_TW' %}{% endif %} + +{% if page.id != 'download' %}{% endif %} - - + + - +