Add mentions and definitions for bits

_autocrossref.yaml

@@ -19,6 +19,7 @@ bitcoin QR code: URI QR code
 bitcoin QR codes: URI QR code
 '`bitcoin:` URI': bitcoin uri
 '`bitcoin:` URIs': bitcoin uri
+bits:
 block:
 block chain:
 block-chain: block chain
@@ -117,8 +118,8 @@ miner:
 miners: miner
 minimum fee:
 mining: mine
-millibit: millibits
-millibits:
+millibitcoin: millibitcoins
+millibitcoins:
 multisig:
 network:
 null data: 

_includes/guide_contracts.md

@@ -135,14 +135,14 @@ him thousands of satoshis in transaction fees, so Alice suggests they use a
 [micropayment channel][]{:#term-micropayment-channel}{:.term}.
 
 Bob asks Alice for her public key and then creates two transactions.
-The first transaction pays 100 millibits to a P2SH output whose
+The first transaction pays 100 millibitcoins to a P2SH output whose
 2-of-2 multisig redeem script requires signatures from both Alice and Bob.
 This is the bond transaction.
-Broadcasting this transaction would let Alice hold the millibits
+Broadcasting this transaction would let Alice hold the millibitcoins
 hostage, so Bob keeps this transaction private for now and creates a
 second transaction.
 
-The second transaction spends all of the first transaction's millibits
+The second transaction spends all of the first transaction's millibitcoins
 (minus a transaction fee) back to Bob after a 24 hour delay enforced
 by locktime. This is the refund transaction. Bob can't sign the refund transaction by himself, so he gives
 it to Alice to sign, as shown in the
@@ -155,14 +155,14 @@ future, signs it, and gives a copy of it back to Bob. She then asks Bob
 for the bond transaction and checks that the refund transaction spends
 the output of the bond transaction. She can now broadcast the bond
 transaction to the network to ensure Bob has to wait for the time lock
-to expire before further spending his millibits. Bob hasn't actually
+to expire before further spending his millibitcoins. Bob hasn't actually
 spent anything so far, except possibly a small transaction fee, and
 he'll be able to broadcast the refund transaction in 24 hours for a
 full refund.
 
-Now, when Alice does some work worth 1 millibit, she asks Bob to create
+Now, when Alice does some work worth 1 millibitcoin, she asks Bob to create
 and sign a new version of the refund transaction.  Version two of the
-transaction spends 1 millibit to Alice and the other 99 back to Bob; it does
+transaction spends 1 millibitcoin to Alice and the other 99 back to Bob; it does
 not have a locktime, so Alice can sign it and spend it whenever she
 wants.  (But she doesn't do that immediately.)
 
@@ -181,7 +181,7 @@ near the time lock expiry, she could be cheated out of her payment.
 Transaction malleability, discussed above in the Transactions section,
 is another reason to limit the value of micropayment channels.
 If someone uses transaction malleability to break the link between the
-two transactions, Alice could hold Bob's 100 millibits hostage even if she
+two transactions, Alice could hold Bob's 100 millibitcoins hostage even if she
 hadn't done any work.
 
 For larger payments, Bitcoin transaction fees are very low as a
@@ -223,7 +223,7 @@ of them can steal the others' satoshis.
 ![Example CoinJoin Transaction](/img/dev/en-coinjoin.svg)
 
 Each contributor looks through their collection of Unspent Transaction
-Outputs (UTXOs) for 100 millibits they can spend. They then each generate
+Outputs (UTXOs) for 100 millibitcoins they can spend. They then each generate
 a brand new public key and give UTXO details and pubkey hashes to the
 facilitator.  In this case, the facilitator is AnonGirl; she creates
 a transaction spending each of the UTXOs to three equally-sized outputs.
@@ -233,7 +233,7 @@ AnonGirl then signs her inputs using `SIGHASH_ALL` to ensure nobody can
 change the input or output details.  She gives the partially-signed
 transaction to Nemo who signs his inputs the same way and passes it
 to Neminem, who also signs it the same way.  Neminem then broadcasts
-the transaction to the peer-to-peer network, mixing all of the millibits in
+the transaction to the peer-to-peer network, mixing all of the millibitcoins in
 a single transaction.
 
 As you can see in the illustration, there's no way for anyone besides

_includes/guide_payment_processing.md

@@ -145,9 +145,9 @@ You must pay by: 2014-04-01 at 23:00 UTC
 
 {% autocrossref %}
 
-Indicating the [denomination][]{:#term-denomination}{:.term} is critical. As of this writing, all popular
+Indicating the [denomination][]{:#term-denomination}{:.term} is critical. As of this writing, popular
 Bitcoin wallet software defaults to denominating amounts in either [bitcoins][]{:#term-bitcoins}{:.term} (BTC)
-or [millibits][]{:#term-millibits}{:.term} (mBTC). Choosing between BTC and mBTC is widely supported,
+, [millibitcoins][]{:#term-millibitcoins}{:.term} (mBTC) or [bits][]{:#term-bits}{:.term}. Choosing between BTC, mBTC and bits is widely supported,
 but other software also lets its users select denomination amounts from
 some or all of the following options:
 
@@ -155,8 +155,9 @@ some or all of the following options:
 |-------------|---------------------|
 | 1.0         | bitcoin (BTC)       |
 | 0.01        | bitcent (cBTC)      |
-| 0.001       | millibit (mBTC)     |
-| 0.000001    | microbit (uBTC)     |
+| 0.001       | millibitcoin (mBTC) |
+| 0.000001    | microbitcoin (uBTC) |
+| 0.000001    | bit                 |
 | 0.00000001  | [satoshi][]{:#term-satoshi}{:.term}             |
 
 {% endautocrossref %}

_includes/ref_core_rpcs-opqrst.md

@@ -576,7 +576,7 @@ Will be rounded up to the nearest satoshi (0.00000001).
 
 {% autocrossref %}
 
-Set the transaction fee per kilobyte to 100,000 satoshis (1 millibit).
+Set the transaction fee per kilobyte to 100,000 satoshis (1 millibitcoin).
 
 {% endautocrossref %}
 

_includes/references.md

@@ -6,6 +6,7 @@
 [base58Check]: /en/developer-reference#term-base58check "The method used in Bitcoin for converting 160-bit hashes into Bitcoin addresses"
 [bitcoin URI]: /en/developer-guide#term-bitcoin-uri "A URI which allows receivers to encode payment details so spenders don't have to manually enter addresses and other details"
 [bitcoins]: /en/developer-guide#term-bitcoins "A primary accounting unit used in Bitcoin; 100 million satoshis"
+[bits]: /en/developer-guide#term-bits "0.000,001 bitcoins (100 satoshis)"
 [block]: /en/developer-guide#term-block "A block of transactions protected by proof of work"
 [blocks]: /en/developer-guide#term-block "Blocks of transactions protected by proof of work"
 [block chain]: /en/developer-guide#block-chain "A chain of blocks with each block linking to the block that preceded; the most-difficult-to-recreate chain is The Block Chain"
@@ -34,7 +35,7 @@
 [confirmations]: /en/developer-guide#term-confirmation "The number of blocks which would need to be modified to remove or modify a transaction"
 [consensus]: /en/developer-guide#term-consensus "When several nodes (usually most nodes on the network) all have the same blocks in their locally-validated block chain."
 [consensus rules]: /en/developer-guide#term-consensus-rules "The block validation rules that full nodes follow to stay in consensus with other nodes."
-[denomination]: /en/developer-guide#term-denomination "bitcoins (BTC), bitcents (cBTC), millibits (mBTC), microbits (uBTC), or satoshis"
+[denomination]: /en/developer-guide#term-denomination "bitcoins (BTC), bitcents (cBTC), millibitcoins (mBTC), bits (uBTC, microbitcoins), or satoshis"
 [difficulty]: /en/developer-guide#term-difficulty "A number corresponding to the target threshold which indicates how difficult it will be to find the next block"
 [dns seed]: /en/developer-guide#term-dns-seed "A DNS server which returns IP addresses of full nodes on the Bitcoin network to assist in peer discovery."
 [double spend]: /en/developer-guide#term-double-spend "Attempting to spend the same satoshis which were spent in a previous transaction"
@@ -68,7 +69,7 @@
 [message]: /en/developer-guide#term-message "A parameter of bitcoin: URIs which allows the receiver to optionally specify a message to the spender"
 [merkle root]: /en/developer-guide#term-merkle-root "The root node of a merkle tree descended from all the hashed pairs in the tree"
 [merkle tree]: /en/developer-guide#term-merkle-tree "A tree constructed by hashing paired data, then pairing and hashing the results until a single hash remains, the merkle root"
-[millibits]: /en/developer-guide#term-millibits "0.001 bitcoins (100,000 satoshis)"
+[millibitcoins]: /en/developer-guide#term-millibitcoins "0.001 bitcoins (1,000 bits or 100,000 satoshis)"
 [mine]: /en/developer-guide#term-miner "Creating Bitcoin blocks which solve proof-of-work puzzles in exchange for block rewards and transaction fees"
 [miner]: /en/developer-guide#term-miner "Creators of Bitcoin blocks who solve proof-of-work puzzles in exchange for block rewards and transaction fees"
 [miners]: /en/developer-guide#term-miner "Creators of Bitcoin blocks who solve proof-of-work puzzles in exchange for block rewards and transaction fees"

_templates/vocabulary.html

@@ -4,6 +4,7 @@ id: vocabulary
 
 voc:
   - address
+  - bit
   - bitcoin
   - blockchain
   - block

_translations/en.yml

@@ -325,7 +325,7 @@ en:
     earlyadopter: "Doesn't Bitcoin unfairly benefit early adopters?"
     earlyadoptertxt1: "Some early adopters have large numbers of bitcoins because they took risks and invested time and resources in an unproven technology that was hardly used by anyone and that was much harder to secure properly. Many early adopters spent large numbers of bitcoins quite a few times before they became valuable or bought only small amounts and didn't make huge gains. There is no guarantee that the price of a bitcoin will increase or drop. This is very similar to investing in an early startup that can either gain value through its usefulness and popularity, or just never break through. Bitcoin is still in its infancy, and it has been designed with a very long-term view; it is hard to imagine how it could be less biased towards early adopters, and today's users may or may not be the early adopters of tomorrow."
     finitelimitation: "Won't the finite amount of bitcoins be a limitation?"
-    finitelimitationtxt1: "Bitcoin is unique in that only 21 million bitcoins will ever be created. However, this will never be a limitation because bitcoins can be divided up to 8 decimal places ( 0.000 000 01 BTC ) and potentially even smaller units if that is ever required in the future. As the average transaction size decreases, transactions can be denominated in sub-units of a bitcoin, such as millibitcoins ( 1 mBTC or 0.001 BTC )."
+    finitelimitationtxt1: "Bitcoin is unique in that only 21 million bitcoins will ever be created. However, this will never be a limitation because transactions can be denominated in smaller sub-units of a bitcoin, such as bits - there is 1,000,000 bits in 1 bitcoin. Bitcoins can be divided up to 8 decimal places (0.000 000 01) and potentially even smaller units if that is ever required in the future as the average transaction size decreases."
     deflationaryspiral: "Won't Bitcoin fall in a deflationary spiral?"
     deflationaryspiraltxt1: "The deflationary spiral theory says that if prices are expected to fall, people will move purchases into the future in order to benefit from the lower prices. That fall in demand will in turn cause merchants to lower their prices to try and stimulate demand, making the problem worse and leading to an economic depression."
     deflationaryspiraltxt2: "Although this theory is a popular way to justify inflation amongst central bankers, it does not appear to always hold true and is considered controversial amongst economists. Consumer electronics is one example of a market where prices constantly fall but which is not in depression. Similarly, the value of bitcoins has risen over time and yet the size of the Bitcoin economy has also grown dramatically along with it. Because both the value of the currency and the size of its economy started at zero in 2009, Bitcoin is a counterexample to the theory showing that it must sometimes be wrong."
@@ -580,14 +580,16 @@ en:
     table: "Table of contents"
     address: "Address"
     addresstxt: "A Bitcoin address is <b>similar to a physical address or an email</b>. It is the only information you need to provide for someone to pay you with Bitcoin. An important difference, however, is that each address should only be used for a single transaction."
+    bit: "Bit"
+    bittxt: "Bit is a common unit used to designate a sub-unit of a bitcoin - 1,000,000 bits is equal to 1 bitcoin (BTC or B⃦). This unit is usually more convenient for pricing tips, goods and services."
     bitcoin: "Bitcoin"
-    bitcointxt: "Bitcoin - with capitalization, is used when describing the concept of Bitcoin, or the entire network itself. e.g. \"I was learning about the Bitcoin protocol today.\"<br>bitcoin - without capitalization, is used to describe bitcoins as a unit of account. e.g. \"I sent ten bitcoins today.\"; it is also often abbreviated BTC or XBT."
+    bitcointxt: "Bitcoin - with capitalization, is used when describing the concept of Bitcoin, or the entire network itself. e.g. \"I was learning about the Bitcoin protocol today.\"<br>bitcoin - without capitalization, is used to describe bitcoins as a unit of account. e.g. \"I sent ten bitcoins today.\"; it is also often abbreviated BTC or XBT, or replaced by sub-units such as <a href=\"#[vocabulary.bit]\">bits</a>."
     blockchain: "Block Chain"
     blockchaintxt: "The block chain is a <b>public record of Bitcoin transactions</b> in chronological order. The block chain is shared between all Bitcoin users. It is used to verify the permanence of Bitcoin transactions and to prevent <a href=\"#[vocabulary.doublespend]\">double spending</a>."
     block: "Block"
     blocktxt: "A block is a <b>record in the block chain that contains and confirms many waiting transactions</b>. Roughly every 10 minutes, on average, a new block including transactions is appended to the <a href=\"#[vocabulary.blockchain]\">block chain</a> through <a href=\"#[vocabulary.mining]\">mining</a>."
     btc: "BTC"
-    btctxt: "BTC is the common unit of Bitcoin currency. It can be used in a similar way to USD for US dollar instead of B⃦ or $."
+    btctxt: "BTC is a common unit used to designate 1,000,000 <a href=\"#[vocabulary.bit]\">bits</a> or one bitcoin (B⃦)."
     confirmation: "Confirmation"
     confirmationtxt: "Confirmation means that a transaction has been <b>processed by the network and is highly unlikely to be reversed</b>. Transactions receive a confirmation when they are included in a <a href=\"#vocabulary##[vocabulary.block]\">block</a> and for each subsequent block. Even a single confirmation can be considered secure for low value transactions, although for larger amounts like 1000 US$, it makes sense to wait for 6 confirmations or more. Each confirmation <i>exponentially</i> decreases the risk of a reversed transaction."
     cryptography: "Cryptography"
@@ -674,6 +676,7 @@ en:
       non-profit: non-profit
     vocabulary:
       address: address
+      bit: bit
       bitcoin: bitcoin
       blockchain: block-chain
       block: block