diff --git a/LICENSE b/LICENSE
deleted file mode 100644
index bec5015..0000000
--- a/LICENSE
+++ /dev/null
@@ -1,21 +0,0 @@
-The MIT License (MIT)
-
-Copyright (c) 2016 The ELements Project
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
diff --git a/README.md b/README.md
index bf310e2..ca760e4 100644
--- a/README.md
+++ b/README.md
@@ -9,17 +9,17 @@ utility in their use.
ElementsProject.org is a static website powered by [Hexo](https://hexo.io).
You'll need `npm` (which comes with Node.js) to get started.
+First, install hexo: `npm install hexo-cli -g`
+
Fork the repository (top right hand corner on GitHub), and get a local copy:
```
git clone git@github.com:YOUR_USERNAME/elementsproject.org # clone the repo
cd elementsproject.org # move into the directory
```
-Next, install the dependancies using `npm install`
-
Now, you can use Hexo to run a local copy to preview your changes:
```
-npm start
+hexo server
```
That's it. Make modifications, commit them, and submit a pull request.
diff --git a/javascripts/scale.fix.js b/javascripts/scale.fix.js
deleted file mode 100644
index 08716c0..0000000
--- a/javascripts/scale.fix.js
+++ /dev/null
@@ -1,20 +0,0 @@
-fixScale = function(doc) {
-
- var addEvent = 'addEventListener',
- type = 'gesturestart',
- qsa = 'querySelectorAll',
- scales = [1, 1],
- meta = qsa in doc ? doc[qsa]('meta[name=viewport]') : [];
-
- function fix() {
- meta.content = 'width=device-width,minimum-scale=' + scales[0] + ',maximum-scale=' + scales[1];
- doc.removeEventListener(type, fix, true);
- }
-
- if ((meta = meta[meta.length - 1]) && addEvent in doc) {
- fix();
- scales = [.25, 1.6];
- doc[addEvent](type, fix, true);
- }
-
-};
\ No newline at end of file
diff --git a/package.json b/package.json
index ada1887..717e84c 100644
--- a/package.json
+++ b/package.json
@@ -1,16 +1,12 @@
{
- "name": "elementsproject.org",
+ "name": "hexo-site",
"version": "2.8.3",
"private": true,
- "scripts": {
- "start": "hexo server"
- },
"hexo": {
- "version": "3.2.2"
+ "version": "3.1.1"
},
"dependencies": {
"hexo": "^3.1.0",
- "hexo-browsersync": "^0.2.0",
"hexo-generator-archive": "^0.1.2",
"hexo-generator-category": "^0.1.2",
"hexo-generator-index": "^0.1.2",
@@ -21,14 +17,5 @@
"hexo-renderer-marked": "^0.2.4",
"hexo-renderer-stylus": "^0.3.0",
"hexo-server": "^0.1.2"
- },
- "license": "MIT",
- "bugs": {
- "url": "https://github.com/ElementsProject/elementsproject.org/issues"
- },
- "homepage": "https://github.com/ElementsProject/elementsproject.org#readme",
- "repository": {
- "type": "git",
- "url": "git+https://github.com/ElementsProject/elementsproject.org.git"
}
}
\ No newline at end of file
diff --git a/source/_posts/announcing-elements.md b/source/_posts/announcing-elements.md
index 9b24199..6ae7c69 100644
--- a/source/_posts/announcing-elements.md
+++ b/source/_posts/announcing-elements.md
@@ -1,8 +1,8 @@
---
title: Announcing the New Elements Project
subtitle: Open source code and developer sidechains for advancing Bitcoin.
-source: https://github.com/ElementsProject/elementsproject.github.io/blob/master/source/_posts/announcing-elements.md
-edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/_posts/announcing-elements.md
+source: https://github.com/ElementsProject/elementsproject.github.io/blob/hexo/source/_posts/announcing-elements.md
+edit: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/_posts/announcing-elements.md
author: martindale
---
diff --git a/source/_posts/the-federated-peg-in-elements-alpha.md b/source/_posts/the-federated-peg-in-elements-alpha.md
deleted file mode 100644
index 3c42853..0000000
--- a/source/_posts/the-federated-peg-in-elements-alpha.md
+++ /dev/null
@@ -1,159 +0,0 @@
-title: The Federated Peg in Elements Alpha
-date: 2016-02-29 23:30:04
----
-The federated peg is the mechanism we use in Elements Alpha and Liquid to transfer coins from Bitcoin to sidechain and back.
-While the high level design has been described in the [sidechains whitepaper](https://blockstream.com/sidechains.pdf) this post focuses on the actual implementation.
-
-The federated component means that the transferred coins are locked on the main chain using a multisig output controlled by a federation of signers instead of an SPV-lock.
-The peg mechanism doesn't require more than introducing two new opcodes to the Script language and is
-designed to ensure that it can be easily soft-forked into Bitcoin in order to evolve to the full SPV peg.
-
-
-
-### OP_WITHDRAWPROOFVERIFY (OP_WPV)
-Let's start with Alpha's genesis block.
-It looks very much unlike Bitcoin's genesis block because it creates exactly one output with a value of 21 million.
-The output has the following scriptPubKey:
-
-{% codeblock %}
-6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
-9eac001049d5c38ece8996485418421f4a01e2d7
-OP_WITHDRAWPROOFVERIFY
-{% endcodeblock %}
-
-This output is called *withdraw lock* because it represents the coins in the main chain which can be unlocked with a withdrawal.
-OP_WITHDRAWPROOFVERIFY (OP_WPV) is a new opcode.
-Note that there is no mining block reward in Alpha, so our only chance to obtain coins in Alpha at this point is to spend this withdraw lock.
-Let's create a transaction we call *withdrawal transaction* that does just that.
-
-OP_WPV expects the following elements on the stack:
-1. HASH160(secondScriptPubKey), the secondScriptPubKey is used to extend checks
-2. genesis block hash of the chain the withdraw is coming from
-3. the coinbase tx within the locking block
-4. the index within the locking tx's outputs we are claiming
-5. the locking tx itself
-6. the merkle block structure which contains the block in which the locking transaction is present
-7. The contract which we are expected to send coins to
-8. The scriptSig used to satisfy the secondScriptPubKey
-9. secondScriptPubKey
-
-The first two arguments are already provided by the scriptPubKey. They add chain specific information - in this case a scripthash we will explain later and bitcoin's genesis block hash.
-
-The next arguments provide a 'locking transaction'.
-This is the main chain transaction that locks coins in order to withdraw them on the sidechain.
-Figure 1 shows the relationship between the transaction types we've seen so far.
-
-
-
-The withdrawal transaction spends OP_WPV locked coins by referring to a lock on the other chain.
-Instead of using OP_WPV, the main chain lock is a multisig output controlled by the federation.
-Note the symmetry of vocabulary: coins which are currently unlocked in the main chain are locked in the sidechain and vice versa.
-
-The script interpreter tests if the destination of the locking transaction is really the federation. It further checks that the locking tx and coinbase tx are contained in the merkle block structure and reads the block height from the coinbase.
-Elements Alpha uses an asymmetric peg and therefore a full Alpha node is expected to be a full validator of the parent chain as well.
-In order to verify that the locking transaction is in the Bitcoin blockchain, Alpha connects to bitcoind via RPC (this is turned on with command line argument `-blindtrust=false`) and calls `getblock` with the merkle block's hash to check if it is has at least 10 confirmations (*confirmation period*).
-In the future, OP_WPV will in addition accept an SPV proof to check without relying on bitcoind if the block has received enough confirmations (under some assumptions about the distribution of hash rate).
-
-Next, OP_WPV expects the destination *contract* consisting of a 16 byte nonce and a 20 byte script hash that represents the receiver of the withdrawal transaction.
-The interpreter checks that the locking transaction commits to the contract using the [pay-to-contract (P2C)](https://arxiv.org/pdf/1212.3257.pdf) construction.
-P2C allows the sender of the locking tx to transparently specify the destination script hash, such that the validators can check the intended recipient of the withdraw. This works by deriving a new keypair for contract `x`: `privkey = old_privkey + H(x), pubkey = old_pubkey + H(x)*G`.
-
-So, in summary, a user who wants to spend an OP_WPV locked output would first create a P2SH address on the side chain and assemble a main chain locking tx that sends the desired value to the federation. Then the user would embed her script hash (in the form of a contract) into the locking transaction and broadcast it. As soon as the confirmation period is over, the user can spend OP_WPV by providing the locking tx and the contract.
-
-
-### Withdraw output
-OP_WPV is a new type of opcode which has access to the outputs of the transaction that spends it.
-In the case of OP_WPV, it checks that the transaction has two outputs: an output we call *withdraw output* and a OP_WPV-locked output to represent the change.
-Next, the interpreter compares the output values, verifies that there is no more value in the
-withdraw output than in the parent chain lock and that the remaining value goes back into
-the lock output.
-This change can then be unlocked later with another withdrawal transaction similar to the transaction we are creating here.
-
-A withdraw output has the following scriptPubKey:
-{% codeblock %}
-OP_IF
-
-
-
-
-
-
- OP_REORGPROOFVERIFY
-OP_ELSE
- 144
- OP_CHECKSEQUENCEVERIFY
- OP_DROP
- OP_HASH160
-
- OP_EQUAL
-OP_ENDIF
-{% endcodeblock %}
-
-Let's first look at the ELSE branch.
-[OP_CHECKSEQUENCEVERIFY](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) ensures that this branch is only executable if the withdraw output is buried at least 144 blocks deep in the blockchain (*contest period*).
-After the contest period the withdraw output effectively becomes a regular P2SH script.
-The interpreter additionally makes sure that the destination scriptHash is exactly the scriptHash from the contract that was committed to in the locking transaction.
-
-Successful execution of the first branch requires providing a *fraud proof* to the second new opcode, OP_REORGPROOFVERIFY (OP_RPV).
-Therefore, during the contest period the withdraw output allows any node to provide a fraud proof, spend the output and consequently collect a fraud bounty.
-
-### OP_REORGPROOFVERIFY (OP_RPV)
-OP_RPV is intended to correct invalid states of two types: double spends of a parent chain lock and parent chain reorganisations.
-You might have realized already that the former situation is indeed not covered by OP_WPV alone. In fact, it is possible that withdrawal transactions which refer to the same parent chain lock make it into the chain.
-Figure 2 shows the resolution of such a double spend attempt.
-
-
-
-OP_RPV allows to spend the withdraw output when a fraud proof is provided. It consists of the original withdraw transaction, the double spending withdraw transaction and a merkle block for each. The reference to the main chain lock is already given by the withdraw output.
-In consequence, the interpreter then checks that there is indeed a double spend, both merkle blocks are valid and contain the transactions, and that the double spending withdraw transaction is newer than the original withdraw transaction.
-Because blockchain consensus in Elements Alpha is determined by a federation of signers, the interpreter only requires the blocks to have valid signatures.
-If Alpha was backed by PoW, OP_RPV would require SPV proofs to verify that the blocks are at the specified height similar to the SPV extension in OP_WPV's case.
-
-Just like OP_WPV, OP_RPV peeks into the outputs of the transaction spending it. The transaction must have one output that uses OP_WPV to re-lock the withdraw output value minus the fraud bounty. The fraud bounty can be claimed by the prover.
-
-As the name implies, OP_RPV does not only come into play when there is a double spend, but also when the parent chain reorganizes.
-In such a situation, the locking transaction is either in another block or completely missing in the chain.
-In any case, the withdraw output should be invalidated by a reorganisation proof.
-This is not yet implemented in Alpha, but in principle the prover would provide an SPV proof that there exists a chain with sufficiently more work which does *not* include the block the withdrawal was coming from.
-
-If alphad is started with the `tracksidechain=all` command line argument it stores all previously spent main chain lock outputs in order to issue fraud proofs if a double spend occurs.
-
-Lastly, let's have a look at the curious secondScriptPubKey, which is expected to be the 9th argument to OP_WPV and is committed to in a withdraw lock (1st argument).
-The secondScriptPubKey is executed with a stack that contains the result of the scriptSig execution and information about the withdrawal transaction, i.e. transaction fee, fraud bounty, the OP_CSV locktime (from the withdrawoutput’s scriptPubKey ELSE case) and a constant dummy byte string.
-In Elements Alpha, the secondScriptPubKey for the Bitcoin lock is `OP_DROP 144 OP_LESSTHANOREQUAL`, which effectively ensures that contest period has passed.
-The secondScriptPubKey does not inspect the result the of the secondScriptSig, so the default scriptSig in this case is just a one byte push.
-This mechanism could in principle enforce additional chain specific limits on transaction fee and fraud bounty or more complex rules.
-
-
-### Withdrawing from the sidechain
-The mechanism behind sending coins from the sidechain to the main chain is - as far as the Alpha code is concerned - relatively simple.
-Figure 3 shows the sequence of transactions during a withdrawal to the main chain.
-
-
-
-The federated lock on the main chain is a m of n multisignature output.
-Functionaries who hold the lock run a program we call *watchman* which communicates to alphad via RPC and is responsible for releasing the lock when a withdraw request appears on the sidechain.
-Note that due to the P2C payments, the federation is is not aware of a lock as long as the corresponding withdraw transaction has not taken place. This is because only the withdraw transaction reveals the data necessary - the contract - to derive pub- and privkey of the lock.
-
-Withdraw requests take the form of a lock output, so a transfer from side- to main chain would be initiated by a new transaction with the following scriptPubKey:
-{% codeblock %}
-
-OP_DROP
-
-
-OP_WITHDRAWPROOFVERIFY
-{% endcodeblock %}
-The script puts the coin in a regular sidechain lock and additionally communicates the main chain destination. This instructs the functionaries to spend their lock and credit the intended receiver.
-
-Behind the scenes watchman follows a round-based distributed protocol (using a separate network) to select a round-leader, who is responsible for collecting withdraw requests and creating a corresponding main chain withdraw transaction.
-The other functionaries check that the transaction correctly spends the withdraw requests (i.e. it goes to the correct destination, the sidechain lock has at least n confirmations, etc.) and sign it.
-If enough signatures can be collected, the withdrawal transaction is valid and broadcast to the bitcoin network.
-
-The federation has to pay the transaction fees, so there are several ways for users to donate, like creating OP_RETURN outputs on the sidechain or sending coins directly to the federation's address (instead of P2C).
-
-
-### Conclusion
-Alpha's peg mechanism allows to freely transfer coins between Bitcoin and federated sidechains. Main chain locks are controlled by a federation whereas sidechain locks are secured by main chain consensus ("asymmetric peg") and sidechain consensus.
-
-The new opcodes OP_WPV and OP_RPV can be easily adapted to allow a symmetric peg instead of requiring full validation of the main chain and additionally to support PoW as the sidechain consensus algorithm.
-This capability and the fundamental design decision to follow the 'Zen of Bitcoin' by avoiding non-local state in the script interpreter opens the door to soft-forking the peg mechanism into Bitcoin itself.
diff --git a/source/case-studies/gem.md b/source/case-studies/gem.md
index 459578f..ed8529a 100644
--- a/source/case-studies/gem.md
+++ b/source/case-studies/gem.md
@@ -1,8 +1,8 @@
---
title: Gem's Use of Elements & Sidechains
description: Learn about how Gem is using Elements in their sidechain implementation.
-source: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/case-studies/gem.md
-edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/case-studies/gem.md
+source: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/case-studies/gem.md
+edit: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/case-studies/gem.md
---
diff --git a/source/case-studies/index.md b/source/case-studies/index.md
index 19cbed1..27f9aef 100644
--- a/source/case-studies/index.md
+++ b/source/case-studies/index.md
@@ -1,8 +1,8 @@
---
title: Who is using Elements?
description: Case studies of Elements Project users and deployments.
-source: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/case-studies/index.md
-edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/case-studies/index.md
+source: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/case-studies/index.md
+edit: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/case-studies/index.md
---
### Gem
diff --git a/source/contributing/index.md b/source/contributing/index.md
index 89b76bd..4abb181 100644
--- a/source/contributing/index.md
+++ b/source/contributing/index.md
@@ -1,8 +1,8 @@
---
title: Get Involved.
subtitle: Contributing to the Elements Project
-source: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/contributing/index.md
-edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/contributing/index.md
+source: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/contributing/index.md
+edit: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/contributing/index.md
---
diff --git a/source/elements/asset-issuance/confidential-assets.md b/source/elements/asset-issuance/confidential-assets.md
deleted file mode 100644
index 1a400c4..0000000
--- a/source/elements/asset-issuance/confidential-assets.md
+++ /dev/null
@@ -1,180 +0,0 @@
----
-title: Confidential Assets
-description: Extend security to multiple asset types while obscuring which ones are in use in specific transactions.
----
-
-## Summary
-
-*Principal Investigator: Andrew Poelstra*
-
-The security of any blockchain ledger comes down to public verifiability of
-two properties of every transaction: that they are authorized by all required
-parties, and that they do not affect the total currency supply. In Bitcoin,
-the latter property is so simple to check that it often goes unremarked: add
-up the total output amount and total input amount and compare them. With the
-development of [Confidential Transactions (CT)](/confidential-transactions/),
-however, this security property is front and center, as it must be preserved
-despite all amounts being cryptographically blinded.
-
-Several blockchain technologies have gone beyond Bitcoin to support multiple
-asset types on the same chain. This allows a wider set of users to share the
-security properties of the same chain, and also enables new use cases, such
-as multi-asset transactions which effect atomic exchanges. Enabling this is
-as simple as labelling each transaction output with a publicly visible "asset
-tag"; however, this would expose information about users' financial behavior,
-undermining the privacy benefits of CT. **Confidential Assets (CA)** is a
-technology to support for multiple asset types while blinding all asset tags,
-preserving the privacy of CT while extending the power and expressibility of
-blockchain transactions.
-
-As in CT, Confidential Assets allows anybody to cryptographically verify that
-a transaction is secure: the transaction is authorized by all required parties
-and no asset is created, destroyed or transmuted. However, only the
-participants in the transaction are able to see which asset types were used
-and in what amounts.
-
-In a multi-asset chain, it may make sense in some contexts for assets of a
-specific type to be created or destroyed. This is accomplished by means of
-*issuance transactions*, which create new asset tags and a specified amount
-of this asset. Later reissuance or deissuance may be done by proving ownership
-of *issuance tokens*, which are related (but distinct) assets. Issuance tokens
-may be created alongside a given asset type, or not, if the asset should not
-support reissuance.
-
-Issuance transactions are unique in that they are not required to balance to
-zero. However, if they issue a public amount, it is still verifiable that
-exactly this amount, no more and no less, was actually issued.
-
-## Technology Behind Confidential Assets
-
-### Asset Tags and Rangeproofs
-
-To describe the technology behind CA, we start with the (Pedersen commitments
-that [form the basis of Confidential Transactions](/confidential-transactions/):
-```
-commitment = xG + aH
-```
-where `G` is a standard generator of an elliptic curve and `H` is a second
-generator for which nobody knows the discrete log with respect to `G`. We call
-such a generator nothing-up-my-sleeve, or NUMS.
-
-In CT, this was described as committing to `a` coins with a blinding factor of
-`x`. We observe that if we refer to the generator `H` as a coin we can read the
-term `aH` algebraically as "`a` coins". When `H` is our only generator this is
-merely a semantic trick. But suppose we add another NUMS generator `I`, and
-consider the two commitments
-```
-commitment_1 = xG + aH
-commitment_2 = xG + aI
-```
-Now we can think of `H` and `I` as representing two distinct assets, and we see
-that these two commitments, while committing to the same amount, are commitments
-to different assets.
-
-Consider now a complete transaction with two inputs of distinct asset types
-and two outputs, like so
-
-```
-in1 = xG + aH, H --\ /-- uG + cH, H = out1
- |---|
-in2 = yG + bI, I --/ \-- vG + dI, I = out2
-```
-In CT, where we had only one generator, we required the equation
-```
-out1 + out2 - in1 - in1 = 0
-```
-to hold, which it would if and only if the transaction balanced. As it turns
-out, this same equation works even with multiple assets:
-```
-0 = out1 + out2 - in1 - in1
- = (uG + cH) + (vG + dI) - (xG + aH) - (yG + bI)
- = (u + v - x - y)G + (c - a)H + (d - b)I
-```
-Since `H` and `I` are both NUMS points, the only way for this equation to hold
-is if each individual term is 0, and in particular, if `c = a` and `b = d`. In
-other words, this equation holds only if the total amount of asset `H` is the
-same on the input side as on the output side **and** the total amount of asset
-`I` is the same on the input and output side.
-
-This extends naturally to more than two asset tags; in fact, it is possible to
-support an unlimited number of distinct asset types, as long as each one can
-be assigned a unique NUMS generator.
-
-As in CT, this simple equation is insufficient because it is possible for amounts
-to overflow, effectively allowing negative-valued outputs. As in CT, this can be
-solved by attaching a rangeproof to each output, in exactly the same way. The only
-difference is that the verifier must use the appropriate asset tag in place of
-the fixed generator `H`.
-
-### Blinded Asset Tags and Asset Surjection Proofs
-
-The above discussion assumed every transaction output had a NUMS generator, or
-asset tag, associated to it, and that outputs of the same asset type would use
-the same tag. This does not satisfy our privacy goals because it is visible
-what type of asset every output represents.
-
-This can be solved by replacing each asset tag with a _blinded asset tag_ of
-the form
-```
-A = H + rG
-```
-Here `H` is an asset tag from above and `r` is a secret random value. Anybody
-who knows `r` can tell what asset this tag represents, but to anyone else it
-will appear to be a uniformly random elliptic curve point. We see that any
-commitment to a value with `A` is also a commitment to the same value with
-`H`, so our "outputs minus inputs equals zero" rule will continue to work
-when validating transactions:
-```
-commitment_A = xG + aA = xG + a(H + rG) = (x + ra)G + aH = commitment_H
-```
-The introduction of this blinding factor does not affect the user's ability
-to produce a rangeproof, though it does make the algebra slightly more
-complicated when constructing the transaction to balance out to zero.
-
-However, since every blinded asset tag looks uniformly random, how can
-verifiers be sure that the underlying asset tags are legitimate? It turns
-out that the "sum to zero" rule is not sufficient to prevent abuse. For
-example, consider the "blinded asset tag"
-```
-A' = -H + rG
-```
-Any amount of the blinded asset `A'` will actually correspond to a _negative_
-amount of asset `H`, which an attacker could use to offset an illegal
-increase of the money supply.
-
-To solve this problem we introduce an _asset surjection proof_, which is a
-cryptographic proof that within a transaction, every output asset type is
-the same as some input asset type, while blinding which outputs correspond
-to which inputs.
-
-The way this works is simple. If `A` and `B` are blinded asset tags which
-commit to the same asset tag `H`, say, then
-```
-A - B = (H + aG) - (H + bG) = (a - b)G
-```
-will be a signature key with corresponding secret key `a - b`. So for a
-transaction output `out1`, we can use a ring signature (proof that one of
-several secret keys is known that keeps secret which one) with the keys
-`out1 - in1`, `out1 - in2`, and so on for every input in the transaction.
-If `out1` has the same asset tag as one of the inputs, the transaction
-signer will know the secret key corresponding to one of these differences,
-and be able to produce the ring signature.
-
-The asset surjection proof consists of this ring signature.
-
-### Future Work
-
-Because algebraically, Confidential Assets is such a straightforward
-extension of Confidential Transactions, many of the tools developed for
-use with CT can be used with few modifications with CA, giving them the
-power to confidently and confidentially handle multi-asset transactions.
-Examples of such technologies are
-
-- ValueShuffle (add link, also check with Tim if the name has changed)
-- [MimbleWimble](http://diyhpl.us/~bryan/papers2/bitcoin/mimblewimble.txt)
-- [Scriptless Scripts](https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-03-mit-bitcoin-expo/slides.pdf)
-
-We are looking forward to the future, as many exciting developments
-continue to appear.
-
-
diff --git a/source/elements/asset-issuance/index.md b/source/elements/asset-issuance/index.md
index 6028064..3b124be 100644
--- a/source/elements/asset-issuance/index.md
+++ b/source/elements/asset-issuance/index.md
@@ -1,99 +1,29 @@
---
-title: Asset Issuance
-description: Create new assets on a sidechain, with optional confidentiality.
+title: Basic Asset Issuance
+description: Create new assets on a sidechain by using Bitcoin as a bond.
image: /img/asset-issuance.svg
-branch: elements-0.14.1
-source: https://github.com/ElementsProject/elementsproject.github.io/blob/master/source/elements/asset-issuance/index.md
-edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/elements/asset-issuance/index.md
+branch: multi-asset-0.11
+source: https://github.com/ElementsProject/elementsproject.github.io/blob/hexo/source/elements/asset-issuance/index.md
+edit: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/elements/asset-issuance/index.md
---
-
+*Principal Investigator: Jorge Timón*
+ * [feature branch multi-asset-0.10](https://github.com/ElementsProject/elements/tree/multi-asset-0.10) - branch of ongoing assets dev
-Users can issue their own confidential assets which represent fungible ownership
-of the underlying asset type representing by the newly created units, which
-could theoretically represent any asset including vouchers, coupons, currencies,
-deposits, bonds, shares, etc. (subject to the respective jurisdiction’s
-regulatory requirements).
+Users can issue their own assets which represent fungible ownership of the underlying asset type representing by the newly created units, which could theoretically represent any asset including vouchers, coupons, currencies, deposits, bonds, shares, etc (subject to the respective jurisdiction’s regulatory requirements.
-These assets can optionally be "blinded", causing the data in the transactions
-(including amount and asset type) to be cryptographically obfuscated in such a
-way that only the participating parties can see. Participants may choose to
-reveal a "blinding key", which grants visibility into the transaction.
+This opens the door for building trustless exchanges, options, and other advanced smart contracts involving those arbitrary assets and the “hostcoin” (a native asset whose ID is equal to the hash of the genesis block or chain ID; in Alpha’s case, it is the federated-peg coin which is backed by testnet coins, see “Deterministic peg” section).
-This opens the door for building trustless exchanges, options, and other
-advanced smart contracts involving those arbitrary assets and a "hostcoin".
+All outputs are tagged with their asset identifier. Consensus rules are modified so that the total inputs and outputs are checked separately per asset.
+A new transaction type is added for creating issued assets (asset definition transactions). Like coinbase transactions, asset definition transactions (the new transaction type) have a null input, but unlike coinbases, asset definition transactions have more inputs in addition to that first null input. This difference not only helps us distinguish between the two: it also guarantees a source of entropy for the asset id (which is the sha256d hash of the transaction). Within an asset definition transaction, any number of outputs with 0 as asset ID can be included with any amount and they will be treated as the initial unspent outputs for the newly created asset.
-### Issuing Assets
-Use the all-new `issueasset` RPC command. Here, we're issuing 1000 new tokens,
-and creating 200 "reissuance" tokens.
-```
-$ elements-cli issueasset 1000 200
-> {
- "txid": "13a2357b0a51114fae92127f7afc74847acf07f87e1bb4849715d1c75dbc9a92",
- "vin": "0",
- "entropy": "4dcc890a6fc4f593c609ffaa295940acb244904c1439aa9cb9d8192440b41da4",
- "asset": "8854427e5ffcb0b837e85832b901b1135cc4ac766f537e2a7f07b71a76c5b9cf",
- "token": "ca270d5552e81d15e4f45e41ff2d9c7e456599a7678286b80f8b41cae179b26a"
-}
-```
-
-You can add convenient names for these assets by passing `-assetdir` to Elements
-Core, which accepts a `hexidstring:label` map of the assets to their labels.
-
-#### Re-issuance
-Re-issuing an asset is effectively a provable inflation in the asset type. To
-do this, use `reissueasset`. Let's issue 20 of our tokens:
-
-```
-elements-cli reissueasset 8854427e5ffcb0b837e85832b901b1135cc4ac766f537e2a7f07b71a76c5b9cf 20
-{
- "txid": "6b20c853521346d5bda3fe9e006292260cf409054224f920f3abf6297aca8176",
- "vin": 1
-}
-
-$ elements-cli getwalletinfo
-> {
- "walletversion": 130000,
- "balance": {
- "funcoin": 1020.00000000
- },
- "unconfirmed_balance": {
- },
- "immature_balance": {
- },
- "txcount": 1117,
- "keypoololdest": 1490389457,
- "keypoolsize": 100,
- "paytxfee": 0.00000000,
- "hdmasterkeyid": "f5ff0a90ac04830fde2f952cae9e076f9c2b4d39"
-}
-```
-
-### How it works
-All outputs are tagged with an asset commitment. Like CT, the consensus rules
-are such that instead of checking that amounts are balanced, the value
-commitments are checked for balance. A new transaction type is added for
-creating issued assets (asset definition transactions). Asset definition
-transactions have explicit `assetIssuance` fields embedded within transaction
-inputs, up to one issuance per input, which denote the issuance of both the
-asset itself and the reissuance tokens if desired. Embedding issuances within an
-input allows us to re-use the entropy as a NUMS for the asset type itself.
-
-This technology is similar to colored coins in many ways, but explicit and
-consensus-enforced tagging has many advantages:
+This technology is similar to colored coins in many ways, but explicit and consensus-enforced tagging has many advantages:
* Supports SPV wallets much more efficiently.
* Allows more complex consensus-enforced contracts.
* Benefits from other consensus-enforced extensions (ie confidential transactions would not be compatible with colored coins on top of Alpha).
* Opens the door for further consensus-enforced extensions that rely on the chain being able to operate with multiple assets.
-Currently only the hostcoin can be used to pay fees, but it should be possible
-to pay fees of different asset types simultaneously.
-
-
+Currently only the hostcoin can be used to pay fees, but it should be possible to pay fees of different asset types simultaneously.
+In this first version all units of a given type must be issued within the asset definition transaction. In future versions it will be possible to define assets with a dynamic supply that can be increased after the definition, allowing the issuer to create new units.
+Future versions can also implement consensus enforced interest that would be interesting for p2p lending and issuance of assets with built-in demurrage (negative interest) among other things.
diff --git a/source/elements/asset-issuance/investigation.md b/source/elements/asset-issuance/investigation.md
deleted file mode 100644
index e14eb32..0000000
--- a/source/elements/asset-issuance/investigation.md
+++ /dev/null
@@ -1,20 +0,0 @@
-*Principal Investigator: Jorge Timón*
- * [alpha-0.10-multi-asset](https://github.com/ElementsProject/elements/tree/alpha-0.10-multi-asset) - branch of ongoing assets dev
-
-Users can issue their own assets which represent fungible ownership of the underlying asset type representing by the newly created units, which could theoretically represent any asset including vouchers, coupons, currencies, deposits, bonds, shares, etc (subject to the respective jurisdiction’s regulatory requirements.
-
-This opens the door for building trustless exchanges, options, and other advanced smart contracts involving those arbitrary assets and the “hostcoin” (a native asset whose ID is equal to the hash of the genesis block or chain ID; in Alpha’s case, it is the federated-peg coin which is backed by testnet coins, see “Deterministic peg” section).
-
-All outputs are tagged with their asset identifier. Consensus rules are modified so that the total inputs and outputs are checked separately per asset.
-A new transaction type is added for creating issued assets (asset definition transactions). Like coinbase transactions, asset definition transactions (the new transaction type) have a null input, but unlike coinbases, asset definition transactions have more inputs in addition to that first null input. This difference not only helps us distinguish between the two: it also guarantees a source of entropy for the asset id (which is the sha256d hash of the transaction). Within an asset definition transaction, any number of outputs with 0 as asset ID can be included with any amount and they will be treated as the initial unspent outputs for the newly created asset.
-
-This technology is similar to colored coins in many ways, but explicit and consensus-enforced tagging has many advantages:
-
-* Supports SPV wallets much more efficiently.
-* Allows more complex consensus-enforced contracts.
-* Benefits from other consensus-enforced extensions (ie confidential transactions would not be compatible with colored coins on top of Alpha).
-* Opens the door for further consensus-enforced extensions that rely on the chain being able to operate with multiple assets.
-
-Currently only the hostcoin can be used to pay fees, but it should be possible to pay fees of different asset types simultaneously.
-In this first version all units of a given type must be issued within the asset definition transaction. In future versions it will be possible to define assets with a dynamic supply that can be increased after the definition, allowing the issuer to create new units.
-Future versions can also implement consensus enforced interest that would be interesting for p2p lending and issuance of assets with built-in demurrage (negative interest) among other things.
\ No newline at end of file
diff --git a/source/elements/bitmask-sighash-modes/index.md b/source/elements/bitmask-sighash-modes/index.md
index 03f0b24..a601c42 100644
--- a/source/elements/bitmask-sighash-modes/index.md
+++ b/source/elements/bitmask-sighash-modes/index.md
@@ -2,8 +2,8 @@
title: Bitmask Sighash Modes
description: Allow arbitrary, miner-rewritable bitmasks of transaction inputs and outputs.
image: /img/bitmask-sighash-modes.svg
-source: https://github.com/ElementsProject/elementsproject.github.io/blob/master/source/elements/bitmask-sighash-modes/index.md
-edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/elements/bitmask-sighash-modes/index.md
+source: https://github.com/ElementsProject/elementsproject.github.io/blob/hexo/source/elements/bitmask-sighash-modes/index.md
+edit: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/elements/bitmask-sighash-modes/index.md
---
*Principal Investigator: Glenn Willen*
diff --git a/source/elements/confidential-transactions/addresses.md b/source/elements/confidential-transactions/addresses.md
index 88711f6..3a8b8d9 100644
--- a/source/elements/confidential-transactions/addresses.md
+++ b/source/elements/confidential-transactions/addresses.md
@@ -2,53 +2,5 @@
title: Confidential Addresses
---
-The most visible implication of Confidential Transactions is the introduction of
-a new default address type, confidential addresses:
-```
-CTEwQjyErENrxo8dSQ6pq5atss7Ym9S7P6GGK4PiGAgQRgoh1iPUkLQ168Kqptfnwmpxr2Bf7ipQsagi
-```
-
-The most obvious differences are that it starts with ``CT`` and is longer than
-usual. This is due to the inclusion of a public blinding key prepended to the
-base address. In the Elements Wallet, the blinding key is derived by using the
-wallet's master blinding key and unblinded P2PKH address. Therefore the receiver
-alone can decrypt the sent amount, and can hand it to auditors if needed. On the
-sender's side, ``sendtoaddress`` will use this pubkey to transmit the necessary
-info to the receiver, encrypted, and inside the transaction itself. The sender's
-wallet will also record the amount and hold this in the ``wallet.dat`` metadata
-as well as the ``audit.log`` file.
-
-```
-$ elements-cli validateaddress CTEwQjyErENrxo8dSQ6pq5atss7Ym9S7P6GGK4PiGAgQRgoh1iPUkLQ168Kqptfnwmpxr2Bf7ipQsagi
-> {
- "isvalid": true,
- "address": "CTEwQjyErENrxo8dSQ6pq5atss7Ym9S7P6GGK4PiGAgQRgoh1iPUkLQ168Kqptfnwmpxr2Bf7ipQsagi",
- "scriptPubKey": "76a91448a67bbdaf57b6f55b50f02fcaacfa079900853588ac",
- "confidential_key": "02483237addc73befdb9b851f948c1488cbb7cf1a59ba8af36be1c479e0f6e8bc7",
- "unconfidential": "QTE8CaT6FcJEqkCR4ZGdoUJfas57eDqY6q",
- "ismine": true,
- "iswatchonly": false,
- "isscript": false,
- "pubkey": "0347b013d415f7dc964cfadd0bb0627c48ae6ae27a58cdd37d71990eaf8f38c60c",
- "iscompressed": true,
- "account": ""
-}
-```
-
-As you can see the unconfidential P2PKH address starts with a `Q`. P2SH start
-with `H`. Most RPC calls outside of ``getnewaddress`` (e.g., ``listunspent``)
-will return the unblinded version of addresses. If you provide an unconfidential
-address to ``validateaddress`` it will show the confidential address.
-
-You **must** use the confidential address in ``sendtoaddress``, ``sendfrom``,
-``sendmany`` and ``createrawtransaction`` if you want to create confidential
-transactions. Therefore, when you want to receive confidential transactions you
-must give the *confidential* address to the sender. For all other RPC's except
-``dumpblindingkey`` it does not matter whether the confidential or
-unconfidential address is provided.
-
-
-
Did you know?
-
By sharing the blinding key used in the construction of a single confidential transaction, users can share access to the transaction's details. Read more about selective disclosure »
-
\ No newline at end of file
+TODO: explain them.
diff --git a/source/elements/confidential-transactions/index.md b/source/elements/confidential-transactions/index.md
index eee10cd..a1c0d76 100644
--- a/source/elements/confidential-transactions/index.md
+++ b/source/elements/confidential-transactions/index.md
@@ -2,13 +2,13 @@
title: Confidential Transactions
description: Preserve security while simultaneously obscuring transaction values.
image: /img/confidential-transactions.svg
-source: https://github.com/ElementsProject/elementsproject.github.io/blob/master/source/elements/confidential-transactions/index.md
-edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/elements/confidential-transactions/index.md
+source: https://github.com/ElementsProject/elementsproject.github.io/blob/hexo/source/elements/confidential-transactions/index.md
+edit: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/elements/confidential-transactions/index.md
---
One of the most powerful new features being explored in Elements is Confidential
-Transactions. This keeps the amounts transferred visible only to participants
-in the transaction (and those they designate), while still guaranteeing that no
+Transactions. This keeps the amounts transferred visible only to participants in
+the transaction (and those they designate), while still guaranteeing that no
more coins can be spent than are available in a cryptographic way.
This goes a step beyond the usual privacy offered by Bitcoin's blockchain, which
@@ -19,93 +19,371 @@ protection, thieves and scammers can focus their efforts on known high-value
targets, competitors can learn business details, and negotiating positions can
be undermined.
-Watch Blockstream CTO Gregory Maxwell explaining Confidential Transactions at Coinbase:
+The most visible implication of Confidential Transactions is the introduction of
+a new address type, [confidential
+addresses](/confidential-transactions/addresses). These are longer than usual as
+they also includes a blinding key for the values. Several sidechains, including
+[alpha](/sidechains/alpha), use this address type as the default.
-
+### Designated Access
+By sharing the blinding key used in the construction of a single confidential
+transaction, users can share access to the details of an individual transaction.
-Read on to see how Confidential Transactions can be used, or jump straight to the math.
+---
+
+### Investigation
+*Principal Investigator: [Gregory Maxwell](/contributors/gmaxwell)*
+
+The security of the Bitcoin ledger is made possible by universal verification:
+each participant individually and autonomously verifies that each transaction is
+valid, without trusting any third party. An unfortunate side effect is that all
+the transaction data must be conspicuously public so it can be verified, which
+is at odds with the normal expectation of privacy for traditional monetary
+instruments.
+
+Insufficient financial privacy can have serious security and privacy
+implications for both commercial and personal transactions. Without adequate
+protection, thieves and scammers can focus their efforts on known high-value
+targets, competitors can learn business details, and negotiating positions can
+be undermined. Since publishing often requires spending money, lack of privacy
+can chill free speech. Insufficient privacy can also result in a loss of
+fungibility--where some coins are treated as more acceptable than others--which
+would further undermine Bitcoin's utility as money.
+
+Bitcoin partially addresses the privacy problem by using pseudonymous
+addresses. If someone does not know which users own which addresses,
+the privacy impact is reduced. But any time you transact with someone
+you learn at least one of their addresses. From there, you can trace out
+other connected addresses and estimate the values of their transactions
+and holdings. For example, suppose your employer pays you with Bitcoin
+and you later spend those coins on your rent and groceries. Your landlord
+and the supermarket will both learn your income, and could charge you
+higher prices as your income changes or target you for theft.
+
+There are existing deployed techniques that further improve privacy
+in Bitcoin (such as CoinJoin, which merges the transaction history of
+users by making joint payments), but the utility of these techniques is
+reduced by the fact that it's possible to track amounts.
+
+There have been proposed cryptographic techniques to improve privacy
+in Bitcoin-like systems, but so far all of them result in breaking
+"pruning" (section 7 of Bitcoin.pdf) and result in participants
+needing a perpetually growing database to verify new transactions,
+because these systems prevent learning which coins have been spent. Most
+proposed cryptographic privacy systems also have poor performance, high
+overhead, and/or require new and very strong (and less well understood)
+cryptographic assumptions.
+
+Confidential Transactions improves the situation by making the transaction
+amounts private, while preserving the ability of the public network
+to verify that the ledger entries still add up. It does this without
+adding any new basic cryptographic assumptions to the Bitcoin system,
+and with a manageable level of overhead.
+
+CT is possible due to the cryptographic technique of additively
+homomorphic commitments. As a side-effect of its design, CT also enables
+the additional exchange of private "memo" data (such as invoice numbers
+or refund addresses) without any further increase in transaction size,
+by reclaiming most of the overhead of the CT cryptographic proofs.
+
+
+## The technology behind Confidential Transactions: A high level technical primer
+
+
+This work was originally proposed by Adam Back on
+Bitcointalk in his 2013 thread "bitcoins with homomorphic value"
+[https://bitcointalk.org/index.php?topic=305791.0]. To build CT I had to
+implement several new cryptosystems which work in concert, and invented
+a generalization of ring signatures and several novel optimizations to
+make the result reasonably efficient.
+
+The basic tool that CT is based on is a Pedersen commitment.
+
+A commitment scheme lets you keep a piece of data secret but commit to
+it so that you cannot change it later. A simple commitment scheme can
+be constructed using a cryptographic hash:
+
+```
+commitment = SHA256( blinding_factor || data )
+```
+
+If you tell someone only the commitment then they cannot determine
+what data you are committing to (given certain assumptions about the
+properties of the hash), but you can later reveal both the data and the
+blinding factor and they can run the hash and verify that the data you
+committed to matches. The blinding factor is present because without one,
+someone could try guessing at the data; if your data is small and simple,
+it might be easy to just guess it and compare the guess to the commitment.
+
+A Pedersen commitment works like the above but with an additional
+property: commitments can be added, and the sum of a set of commitments
+is the same as a commitment to the sum of the data (with a blinding key
+set as the sum of the blinding keys):
+
+```
+C(BF1, data1) + C(BF2, data2) == C(BF1 + BF2, data1 + data2) C(BF1, data1) -
+C(BF1, data1) == 0
+```
+
+In other words, the commitment preserves addition and the commutative
+property applies.
+
+If data_n = {1,1,2} and BF_n = {5,10,15} then:
+
+```
+C(BF1, data1) + C(BF2, data2) - C(BF3, data3) == 0
+```
+
+and so on.
+
+Our specific Pedersen commitments are constructed using elliptic curve
+points. [The reader need not understand elliptic curve cryptography,
+beyond accepting the black box behaviors I describe here.]
+
+Normally an ECC pubkey is created by multiplying a generator for the group
+(G) with the secret key (x):
+
+```
+Pub = xG
+```
+
+The result is usually serialized as a 33-byte array.
+
+ECC public keys obey the additively homomorphic property mentioned before:
+
+```
+Pub1 + Pub2 = (x1 + x2 (mod n))G.
+```
+
+(This fact is used by the BIP32 HD wallet scheme to allow third parties
+to generate fresh Bitcoin addresses for people.)
+
+The Pedersen commitment is created by picking an additional generator
+for the group (which we'll call H) such that no one knows the discrete
+log for H with respect to G (or vice versa), meaning no one knows an
+x such that xG = H. We can accomplish this by using the cryptographic
+hash of G to pick H:
-
-
Did you know?
-
By sharing the blinding key used in the construction of a single confidential transaction, users can share access to the transaction's details. Read more about selective disclosure »
-
+```
+H = to_point(SHA256(ENCODE(G)))
+```
+
+Given our two generators we can build a commitment scheme like this:
+
+```
+commitment = xG + aH
+```
+
+Here x is our secret blinding factor, and a is the amount that we're
+committing to. You can verify just using the commutative property of
+addition that all the relationships given for an additively homomorphic
+commitment scheme hold.
+
+The Pedersen commitments are information-theoretically private: for any
+commitment you see, there exists some blinding factor which would make
+any amount match the commitment. Even an attacker with infinite computing
+power could not tell what amount you committed to, if your blinding factor
+was truly random. They are computationally secure against fake commitment,
+in that you can't actually compute that arbitrary mapping; if you can
+it means you can find the discrete log of the generators with respect
+to each other, which means that the security of the group is compromised.
+
+With this tool in hand we can go and replace the normal 8-byte integer
+amounts in Bitcoin transactions with 33-byte Pedersen commitments.
+
+If the author of a transaction takes care in picking their blinding
+factors so that they add up correctly, then the network can still verify
+the transaction by checking that its commitments add up to zero:
+
+```
+(In1 + In2 + In3 + plaintext_input_amount*H...) -
+ (Out1 + Out2 + Out3 + ... fees*H) == 0.
+```
+
+This requires making the fees in a transaction explicit, but that's
+generally desirable.
+
+The commitment and its checking are quite simple. Unfortunately, without
+additional measures this scheme is insecure.
+
+The problem is that the group is cyclic, and addition is mod P (a 256-bit
+prime number that defines the order of the group). As a result, addition
+of large values can 'overflow' and behave like negative amounts. This
+means that a sums-to-zero behavior still holds when some outputs are
+negative, effectively allowing the creation of 5 coins from nothing:
+
+```
+(1 + 1) - (-5 + 7) == 0
+```
+
+This would be interpreted as "someone spends two bitcoins, gets a '-5'
+bitcoin out that they discard out, and a 7 bitcoin output".
+
+In order to prevent this, when there are multiple outputs we must prove
+that each committed output is within a range which cannot overflow
+(e.g. [0, 2^64)).
+
+We could just disclose the amounts and blinding factors so that the
+network could check, but this would lose all of the privacy. So,
+instead, we need to prove that a committed amount is within the range
+but reveal nothing else about it: we need an additional cryptosystem
+to prove the range of a Pedersen commitment. We use a scheme similar
+to Schoenmakers' binary decomposition but with many optimizations
+(including not using binary).
-### Using Confidential Transactions
-The payment flow when using the Confidential Transactions Element is nearly
-identical to Bitcoin Core on the surface:
+To build this we start with a basic EC signature. If a signature is
+constructed so that the 'message' is the hash of the pubkey, the signature
+proves that the signer knew the private key, which is the discrete log
+of the pubkey with respect to some generator.
+
+For a 'pubkey' like P = xG + aH, no one knows the discrete log of P
+with respect to G because of the addition of H, because no one knows
+an x for xG = H----_unless_ a is 0. If a is zero then P = xG and the
+discrete log is just x; someone could sign for that pubkey.
+
+A pedersen commitment can be proven to be a commitment to a zero by
+just signing a hash of the commitment with the commitment as the public
+key. Using the public key in the signature is required to prevent setting
+the signature to arbitrary values and solving for the commitment. The
+private key used for the signature is just the blinding factor.
+
+Going further, let's say I want to prove C is a commitment to 1 without
+telling you the blinding factor. All you do is compute
```
-$ elements-cli getnewaddress
-> CTEwQjyErENrxo8dSQ6pq5atss7Ym9S7P6GGK4PiGAgQRgoh1iPUkLQ168Kqptfnwmpxr2Bf7ipQsagi
+C' = C - 1H
+```
+
+and ask me to provide a signature (with respect to G) with pubkey C'. If
+I can do that, the C must be a commitment to 1 (or else I've broken the
+EC discrete log security).
+
+To avoid giving away the amount we need yet another cryptographic
+construct: a ring signature. A ring signature is a signature scheme
+where there are two (or more) pubkeys and the signature proves that the
+signer knows the discrete log of at least one of the pubkeys.
-$ elements-cli sendtoaddress CTEwQjyErENrxo8dSQ6pq5atss7Ym9S7P6GGK4PiGAgQRgoh1iPUkLQ168Kqptfnwmpxr2Bf7ipQsagi 0.005
-> 82b2c5122207e5f33e7adadc6a4aab16a170e16028f0b0cf2c04f9d17d6f0321
-// ^ this is the transaction id
+So with that we can construct a scheme where I prove a commitment that
+C is either 0 or 1--we call this an "OR proof".
+
+First, I give you C, and you compute C':
+
+```
+C' = C - 1H
```
-The key difference from Bitcoin is the addition of cryptographic privacy. These
-transactions differ in that the the amounts transferred are kept visible only to
-participants in the transaction (and those they designate).
-
+Then I provide a ring signature over {C, C'}.
-The ``createrawtransaction`` API in Elements works similar to Bitcoin's raw
-transactions with the following differences:
+If C was a commitment to 1 then I do not know its discrete log, but
+C' becomes a commitment to 0 and I do know its discrete log (just the
+blinding factor). If C was a commitment to 0 I know its discrete log,
+and I don't for C'. If it was a commitment to any other amount, none
+of the result will be zero and I won't be able to sign.
-1. The intent to create a confidential output is indicated by using a confidential address for the destination.
-2. The ``createrawtransaction`` RPC has the additional key ``nValue`` per input which must be set to the value of the input. The value can be determined for example with the ``listunspent`` RPC.
-3. After calling ``createrawtransaction`` the user must call ``blindrawtransaction`` on the transaction if a confidential input or output address is involved.
-4. If at least one of the inputs is confidential, at least one of the outputs must be confidential. Note that it is perfectly fine to create a 0-valued confidential output if otherwise there would be no confidential output.
-5. If all inputs are unconfidential, the number of confidential outputs must be ``0`` or ``>= 2``. Again, it's fine to create a 0-valued confidential output.
+This works for any pair of numbers, just by suitably pre-processing the
+amounts that are put into the ring... or even for more than two numbers.
-The following example spends a confidential and an unconfidential output and
-creates a confidential and unconfidential output. Due to the size of the
-transaction it is not displayed here but saved in the variable ``TX``
+Say I want to prove to you that C is in the range [0, 32). Now that we
+have an OR proof, imagine I send you a collection of commitments and OR
+proofs for each of them:
```
-TX=`elements-cli createrawtransaction '[{"txid": "421079661b117b659af3431096ce2118043396e3647e523e413cd626fa798df7", "vout": 0, "nValue": 0.001}, {"txid": "17aa26d29582a9a26f02033918aaf9823d33458239074a0d7ee638b247f1fa2c", "vout": 0, "nValue": 0.001}]' '{"XoRDiv9z12ECsYCNjtHjDvV1Nn4KSBa6xRfHT1c3nKY1CwDiz5rzSMZL7QCgvuF1T5Kq43o1fMqBxbWQ": 0.001, "QLsHc5DgnpMjPaDSuEF5gXt7ccgmLtgh2N": 0.0005}'`
-TX=`elements-cli blindrawtransaction $TX`
-TX=`elements-cli signrawtransaction $TX | jq -r '.hex'`
-elements-cli sendrawtransaction $TX
+C1 is 0 or 1 C2 is 0 or 2 C3 is 0 or 4 C4 is 0 or 8 C5 is 0 or 16.
```
-### Limitations
-The implementation of Confidential Transactions as it appears in Elements has
-some important limitations to be aware of.
+If I pick the blinding factors for C1..5 correctly then I can arrange
+it so that C1 + C2 + C3 + C4 + C5 == C. Effectively I have built up
+the number in binary, and a 5-bit number can only be in the range [0,32).
+
+Numerous optimizations are required to make this more efficient:
+
+First, I propose a new ring
+signature formulation, a Borromean ring signature[*], which is especially
+efficient: it requires only 32 bytes per pubkey, plus 32 bytes which
+can be shared by many separate rings. This is has twice the asymptotic
+efficiency of previously proposed constructions for this application.
+
+[*] https://github.com/Blockstream/borromean_paper/raw/master/borromean_draft_0.01_34241bb.pdf
+
+Instead of expressing the amount directly, CT amounts are expressed
+using a decimal floating point where the digits are multiplied by a
+base 10 exponent. This means that you can prove large amounts with
+small proofs, so long as they have few significant digits in base 10:
+e.g., 11.2345 and .0112345 can have the same size proof, even though
+one number is a thousand times larger.
+
+There is also a non-private "minimum amount" sent, which allows a smaller
+proof to cover a larger range if the user doesn't mind leaking some
+information about the minimum amount (which might already be public for
+external reasons); this also allows the least significant digits to be
+non-zero when an exponent is used. Minimum amounts are supported by first
+subtracting the minimum, then proving that the result is non-negative.
+
+The mantissa of the floating point is encoded using rings of size 4 (base
+4) rather than binary, because this minimizes the number of commitments
+sent while not using any more signature data than base 2.
+
+The final mantissa digit commitment can be skipped, backwards constructing
+it from the value being proven and the other digits, etc.
+
+Finally, by careful use of derandomized signing in the prover, it's
+possible for the receiver of the coins--who shares a secret with the
+sender, due to ECDH key agreement with the receivers pubkey--to 'rewind'
+the proof and use it to extract a message sent by the sender which is 80%
+of the size of the proof. We use this to signal the value and blinding
+factor to the receiver, but it could also be used to carry things like
+reference numbers or refund addresses.
+
+The result is that a proof for a 32-bit value is 2564 bytes, and
+simultaneously may convey 2048 bytes of message. A 32-bit proof can
+cover a range of 42.94967296 BTC with 1e-8 precision, or 429.4967296
+BTC with 1e-7 precision, and so on. My implementation is able to verify
+over 1300 32-bit range proofs per second on an i7-4770R, and there are
+many performance optimizations still possible.
+
+The implementation supports proofs of any mantissa size or exponent, with
+the parameters controlled by the sender. Performance and size are linear
+in the number of mantissa bits, and odd numbers of bits are supported
+(by switching to radix-2 for the last digit).
+
+In Elements, the range proofs are only required in cases where there are
+multiple confidential value outputs (including fees). Transactions that
+merge multiple confidential amounts into a single output do not need range
+proofs since the fact that all the inputs were in range is sufficient.
+
+By sharing the scanning key used to establish the shared secret used by
+the rewindable range proofs, this approach is completely compatible with
+watching wallets; users can share these keys with auditors to enable
+them to view their transaction amounts.
+
+Future work may use the fact that proofs can support a minimum value to
+also allow skipping the range proofs when there is a single confidential
+output even when fees are being paid, or allow nodes to skip or delay
+verifying most range proofs by using fraud proofs.
-For example, the implementation only hides a certain number of the digits of the
-amount of each transaction output, dependent on the range proof's "blinding
-coverage" at a desired precision level. Subsequently, there is a 'minimum
-confidential amount' that around 0.0001 BTC, and a 'maximum confidential amount'
-that is 232 times the minimum amount.
+The system presented here depends on no new fundamental cryptographic
+assumptions, only the hardness of the discrete log problem in the
+secp256k1 group and a random oracle assumption, just like the normal
+signatures in Bitcoin.
-Digits smaller than the minimum will be revealed to observers; for example, if
-the minimum is 0.0001 BTC, a transaction output of 123.456789 BTC will look like
-"?.????89 BTC". The tiny amount of information about the value leaked in this
-way is unlikely to be important, but be aware that this could allow observers to
-'follow' coins by linking subsequent transactions with identical amounts. All
-values can be rounded to the minimum to avoid revealing information in this way
-if preferred.
+While the size of the range proofs are non-trivial, they are still an
+order of magnitude smaller and faster to verify than some alternatives
+(like Zerocoin), and most of their space can be reclaimed to communicate
+additional data between users, a feature which is often requested but
+hard to justify in a public broadcast network. Similar to signatures,
+the range proofs can be placed on separate tree branches in blocks to
+allow clients that don't care about (e.g. historical ones) to skip
+receiving them.
-A transaction output larger than the maximum will reveal the order of magnitude
-of the amount to observers, _and_ will reveal additional digits at the bottom of
-the amount.
+Most importantly, this scheme is compatible with pruning and does not make
+the verification state for Bitcoin grow forever. It is also compatible
+with CoinJoin and CoinSwap, allowing for transaction graph privacy as
+well while simultaneously fixing the most severe limitation of these
+approaches to privacy (that transaction amounts compromise their privacy).
-For example, if the maximum is 500k BTC, then all outputs under
-that amount will look the same, but an output between 500k and 5M BTC will be
-visible as such to observers (but not the exact amount within that range), and
-will also reveal one additional digit of the low end of the amount. Revealing
-the range in this way could be a very significant privacy leak; splitting such
-extremely large transactions to keep them under the maximum confidential amount
-is strongly recommended.
+Unlike some other proposals, this system is not just speculation or pure
+cryptography without integration with the Bitcoin system.
-
+Confidential Transactions is enabled in Elements and used by default by
+all ordinary transactions.
diff --git a/source/elements/confidential-transactions/investigation.md b/source/elements/confidential-transactions/investigation.md
deleted file mode 100644
index 3824506..0000000
--- a/source/elements/confidential-transactions/investigation.md
+++ /dev/null
@@ -1,359 +0,0 @@
----
-title: Confidential Transaction, the Initial Investigation
----
-### Investigation
-Principal Investigator: [Gregory Maxwell](/contributors/gmaxwell)
-
-The security of the Bitcoin ledger is made possible by universal verification:
-each participant individually and autonomously verifies that each transaction is
-valid, without trusting any third party. An unfortunate side effect is that all
-the transaction data must be conspicuously public so it can be verified, which
-is at odds with the normal expectation of privacy for traditional monetary
-instruments.
-
-Insufficient financial privacy can have serious security and privacy
-implications for both commercial and personal transactions. Without adequate
-protection, thieves and scammers can focus their efforts on known high-value
-targets, competitors can learn business details, and negotiating positions can
-be undermined. Since publishing often requires spending money, lack of privacy
-can chill free speech. Insufficient privacy can also result in a loss of
-fungibility--where some coins are treated as more acceptable than others--which
-would further undermine Bitcoin's utility as money.
-
-Bitcoin partially addresses the privacy problem by using pseudonymous
-addresses. If someone does not know which users own which addresses,
-the privacy impact is reduced. But any time you transact with someone
-you learn at least one of their addresses. From there, you can trace out
-other connected addresses and estimate the values of their transactions
-and holdings. For example, suppose your employer pays you with Bitcoin
-and you later spend those coins on your rent and groceries. Your landlord
-and the supermarket will both learn your income, and could charge you
-higher prices as your income changes or target you for theft.
-
-There are existing deployed techniques that further improve privacy
-in Bitcoin (such as CoinJoin, which merges the transaction history of
-users by making joint payments), but the utility of these techniques is
-reduced by the fact that it's possible to track amounts.
-
-There have been proposed cryptographic techniques to improve privacy
-in Bitcoin-like systems, but so far all of them result in breaking
-"pruning" (section 7 of Bitcoin.pdf) and result in participants
-needing a perpetually growing database to verify new transactions,
-because these systems prevent learning which coins have been spent. Most
-proposed cryptographic privacy systems also have poor performance, high
-overhead, and/or require new and very strong (and less well understood)
-cryptographic assumptions.
-
-Confidential Transactions improves the situation by making the transaction
-amounts private, while preserving the ability of the public network
-to verify that the ledger entries still add up. It does this without
-adding any new basic cryptographic assumptions to the Bitcoin system,
-and with a manageable level of overhead.
-
-CT is possible due to the cryptographic technique of additively
-homomorphic commitments. As a side-effect of its design, CT also enables
-the additional exchange of private "memo" data (such as invoice numbers
-or refund addresses) without any further increase in transaction size,
-by reclaiming most of the overhead of the CT cryptographic proofs.
-
-
-## The technology behind Confidential Transactions: A high level technical primer
-
-
-This work was originally proposed by Adam Back on
-Bitcointalk in his 2013 thread "[bitcoins with homomorphic value]
-(https://bitcointalk.org/index.php?topic=305791.0)". To build CT I had to
-implement several new cryptosystems which work in concert, and invented
-a generalization of ring signatures and several novel optimizations to
-make the result reasonably efficient.
-
-The basic tool that CT is based on is a Pedersen commitment.
-
-A commitment scheme lets you keep a piece of data secret but commit to
-it so that you cannot change it later. A simple commitment scheme can
-be constructed using a cryptographic hash:
-
-```
-commitment = SHA256( blinding_factor || data )
-```
-
-If you tell someone only the commitment then they cannot determine
-what data you are committing to (given certain assumptions about the
-properties of the hash), but you can later reveal both the data and the
-blinding factor and they can run the hash and verify that the data you
-committed to matches. The blinding factor is present because without one,
-someone could try guessing at the data; if your data is small and simple,
-it might be easy to just guess it and compare the guess to the commitment.
-
-A Pedersen commitment works like the above but with an additional
-property: commitments can be added, and the sum of a set of commitments
-is the same as a commitment to the sum of the data (with a blinding key
-set as the sum of the blinding keys):
-
-```
-C(BF1, data1) + C(BF2, data2) == C(BF1 + BF2, data1 + data2)
-C(BF1, data1) - C(BF1, data1) == 0
-```
-
-In other words, the commitment preserves addition and the commutative
-property applies.
-
-If data_n = {1,1,2} and BF_n = {5,10,15} then:
-
-```
-C(BF1, data1) + C(BF2, data2) - C(BF3, data3) == 0
-```
-
-and so on.
-
-Our specific Pedersen commitments are constructed using elliptic curve
-points. [The reader need not understand elliptic curve cryptography,
-beyond accepting the black box behaviors I describe here.]
-
-Normally an ECC pubkey is created by multiplying a generator for the group
-(G) with the secret key (x):
-
-```
-Pub = xG
-```
-
-The result is usually serialized as a 33-byte array.
-
-ECC public keys obey the additively homomorphic property mentioned before:
-
-```
-Pub1 + Pub2 = (x1 + x2 (mod n))G.
-```
-
-(This fact is used by the BIP32 HD wallet scheme to allow third parties
-to generate fresh Bitcoin addresses for people.)
-
-The Pedersen commitment is created by picking an additional generator
-for the group (which we'll call H) such that no one knows the discrete
-log for H with respect to G (or vice versa), meaning no one knows an
-x such that xG = H. We can accomplish this by using the cryptographic
-hash of G to pick H:
-
-```
-H = to_point(SHA256(ENCODE(G)))
-```
-
-Given our two generators we can build a commitment scheme like this:
-
-```
-commitment = xG + aH
-```
-
-Here x is our secret blinding factor, and a is the amount that we're
-committing to. You can verify just using the commutative property of
-addition that all the relationships given for an additively homomorphic
-commitment scheme hold.
-
-The Pedersen commitments are information-theoretically private: for any
-commitment you see, there exists some blinding factor which would make
-any amount match the commitment. Even an attacker with infinite computing
-power could not tell what amount you committed to, if your blinding factor
-was truly random. They are computationally secure against fake commitment,
-in that you can't actually compute that arbitrary mapping; if you can
-it means you can find the discrete log of the generators with respect
-to each other, which means that the security of the group is compromised.
-
-With this tool in hand we can go and replace the normal 8-byte integer
-amounts in Bitcoin transactions with 33-byte Pedersen commitments.
-
-If the author of a transaction takes care in picking their blinding
-factors so that they add up correctly, then the network can still verify
-the transaction by checking that its commitments add up to zero:
-
-```
-(In1 + In2 + In3 + plaintext_input_amount*H...) -
- (Out1 + Out2 + Out3 + ... fees*H) == 0.
-```
-
-This requires making the fees in a transaction explicit, but that's
-generally desirable.
-
-The commitment and its checking are quite simple. Unfortunately, without
-additional measures this scheme is insecure.
-
-The problem is that the group is cyclic, and addition is mod P (a 256-bit
-prime number that defines the order of the group). As a result, an addition
-of large values can 'overflow' and behave like negative amounts. This
-means that a sums-to-zero behavior still holds when some outputs are
-negative, effectively allowing the creation of 5 coins from nothing:
-
-```
-(1 + 1) - (-5 + 7) == 0
-```
-
-This would be interpreted as "someone spends two bitcoins, gets a '-5'
-bitcoin out that they discard out, and a 7 bitcoin output".
-
-In order to prevent this, when there are multiple outputs we must prove
-that each committed output is within a range which cannot overflow
-(e.g. [0, 2^64)).
-
-We could just disclose the amounts and blinding factors so that the
-network could check, but this would lose all of the privacy. So,
-instead, we need to prove that a committed amount is within the range
-but reveal nothing else about it: we need an additional cryptosystem
-to prove the range of a Pedersen commitment. We use a scheme similar
-to Schoenmakers' binary decomposition but with many optimizations
-(including not using binary).
-
-To build this we start with a basic EC signature. If a signature is
-constructed so that the 'message' is the hash of the pubkey, the signature
-proves that the signer knew the private key, which is the discrete log
-of the pubkey with respect to some generator.
-
-For a 'pubkey' like P = xG + aH, no one knows the discrete log of P
-with respect to G because of the addition of H, because no one knows
-an x for xG = H----_unless_ a is 0. If a is zero then P = xG and the
-discrete log is just x; someone could sign for that pubkey.
-
-A pedersen commitment can be proven to be a commitment to a zero by
-just signing a hash of the commitment with the commitment as the public
-key. Using the public key in the signature is required to prevent setting
-the signature to arbitrary values and solving for the commitment. The
-private key used for the signature is just the blinding factor.
-
-Going further, let's say I want to prove C is a commitment to 1 without
-telling you the blinding factor. All you do is compute
-
-```
-C' = C - 1H
-```
-
-and ask me to provide a signature (with respect to G) with pubkey C'. If
-I can do that, the C must be a commitment to 1 (or else I've broken the
-EC discrete log security).
-
-To avoid giving away the amount we need yet another cryptographic
-construct: a ring signature. A ring signature is a signature scheme
-where there are two (or more) pubkeys and the signature proves that the
-signer knows the discrete log of at least one of the pubkeys.
-
-So with that we can construct a scheme where I prove a commitment that
-C is either 0 or 1--we call this an "OR proof".
-
-First, I give you C, and you compute C':
-
-```
-C' = C - 1H
-```
-
-
-Then I provide a ring signature over {C, C'}.
-
-If C was a commitment to 1 then I do not know its discrete log, but
-C' becomes a commitment to 0 and I do know its discrete log (just the
-blinding factor). If C was a commitment to 0 I know its discrete log,
-and I don't for C'. If it was a commitment to any other amount, none
-of the result will be zero and I won't be able to sign.
-
-This works for any pair of numbers, just by suitably pre-processing the
-amounts that are put into the ring... or even for more than two numbers.
-
-Say I want to prove to you that C is in the range [0, 32). Now that we
-have an OR proof, imagine I send you a collection of commitments and OR
-proofs for each of them:
-
-```
-C1 is 0 or 1 C2 is 0 or 2 C3 is 0 or 4 C4 is 0 or 8 C5 is 0 or 16.
-```
-
-If I pick the blinding factors for C1..5 correctly then I can arrange
-it so that C1 + C2 + C3 + C4 + C5 == C. Effectively I have built up
-the number in binary, and a 5-bit number can only be in the range [0,32).
-
-Numerous optimizations are required to make this more efficient:
-
-First, I propose a new ring
-signature formulation, a Borromean ring signature[*](https://github.com/Blockstream/borromean_paper/raw/master/borromean_draft_0.01_34241bb.pdf), which is especially
-efficient: it requires only 32 bytes per pubkey, plus 32 bytes which
-can be shared by many separate rings. This is has twice the asymptotic
-efficiency of previously proposed constructions for this application.
-
-Instead of expressing the amount directly, CT amounts are expressed
-using a decimal floating point where the digits are multiplied by a
-base 10 exponent. This means that you can prove large amounts with
-small proofs, so long as they have few significant digits in base 10:
-e.g., 11.2345 and .0112345 can have the same size proof, even though
-one number is a thousand times larger.
-
-There is also a non-private "minimum amount" sent, which allows a smaller
-proof to cover a larger range if the user doesn't mind leaking some
-information about the minimum amount (which might already be public for
-external reasons); this also allows the least significant digits to be
-non-zero when an exponent is used. Minimum amounts are supported by first
-subtracting the minimum, then proving that the result is non-negative.
-
-The mantissa of the floating point is encoded using rings of size 4 (base
-4) rather than binary, because this minimizes the number of commitments
-sent while not using any more signature data than base 2.
-
-The final mantissa digit commitment can be skipped, backwards constructing
-it from the value being proven and the other digits, etc.
-
-Finally, by careful use of derandomized signing in the prover, it's
-possible for the receiver of the coins--who shares a secret with the
-sender, due to ECDH key agreement with the receivers pubkey--to 'rewind'
-the proof and use it to extract a message sent by the sender which is 80%
-of the size of the proof. We use this to signal the value and blinding
-factor to the receiver, but it could also be used to carry things like
-reference numbers or refund addresses.
-
-The result is that a proof for a 32-bit value is 2564 bytes, and
-simultaneously may convey 2048 bytes of message. A 32-bit proof can
-cover a range of 42.94967296 BTC with 1e-8 precision, or 429.4967296
-BTC with 1e-7 precision, and so on. My implementation is able to verify
-over 1300 32-bit range proofs per second on an i7-4770R, and there are
-many performance optimizations still possible.
-
----
-
-The implementation supports proofs of any mantissa size or exponent, with
-the parameters controlled by the sender. Performance and size are linear
-in the number of mantissa bits, and odd numbers of bits are supported
-(by switching to radix-2 for the last digit).
-
-In Elements, the range proofs are only required in cases where there are
-multiple confidential value outputs (including fees). Transactions that
-merge multiple confidential amounts into a single output do not need range
-proofs since the fact that all the inputs were in range is sufficient.
-
-By sharing the scanning key used to establish the shared secret used by
-the rewindable range proofs, this approach is completely compatible with
-watching wallets; users can share these keys with auditors to enable
-them to view their transaction amounts.
-
-Future work may use the fact that proofs can support a minimum value to
-also allow skipping the range proofs when there is a single confidential
-output even when fees are being paid, or allow nodes to skip or delay
-verifying most range proofs by using fraud proofs.
-
-The system presented here depends on no new fundamental cryptographic
-assumptions, only the hardness of the discrete log problem in the
-secp256k1 group and a random oracle assumption, just like the normal
-signatures in Bitcoin.
-
-While the size of the range proofs are non-trivial, they are still an
-order of magnitude smaller and faster to verify than some alternatives
-(like Zerocoin), and most of their space can be reclaimed to communicate
-additional data between users, a feature which is often requested but
-hard to justify in a public broadcast network. Similar to signatures,
-the range proofs can be placed on separate tree branches in blocks to
-allow clients that don't care about (e.g. historical ones) to skip
-receiving them.
-
-Most importantly, this scheme is compatible with pruning and does not make
-the verification state for Bitcoin grow forever. It is also compatible
-with CoinJoin and CoinSwap, allowing for transaction graph privacy as
-well while simultaneously fixing the most severe limitation of these
-approaches to privacy (that transaction amounts compromise their privacy).
-
-Unlike some other proposals, this system is not just speculation or pure
-cryptography without integration with the Bitcoin system.
-
-Confidential Transactions is enabled in Elements and used by default by
-all ordinary transactions.
\ No newline at end of file
diff --git a/source/elements/confidential-transactions/selective-disclosure.md b/source/elements/confidential-transactions/selective-disclosure.md
deleted file mode 100644
index d343d07..0000000
--- a/source/elements/confidential-transactions/selective-disclosure.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: Using Confidential Transactions for Selective Disclosure
----
-
-The [Confidential Transactions][confidential-transactions] element offers cryptographic privacy over the amounts of an asset used in
-transactions on a sidechain. There are many use cases for selectively disclosure some parts of
-a transaction, for example to an auditor.
-
-### The Blinding Key
-The "Blinding Key" is a shared value between the participants that grants them
-access to the cryptographically-concealed amount. By sharing this key (out of
-band), external parties will have the ability to "decrypt" the transaction.
-
-In order to execute a third-party audit of transaction amounts, the blinding key
-can be exported by the receiver and passed on to the auditor.
-
-#### Retrieving the Blinding Key for a Particular Address
-```
-$ elements-cli dumpblindingkey CTEwQjyErENrxo8dSQ6pq5atss7Ym9S7P6GGK4PiGAgQRgoh1iPUkLQ168Kqptfnwmpxr2Bf7ipQsagi
-> 5fd02f714d52b68bbbfef3b8e6d83be646fad1de5150e83d26a28496e00a2146
-```
-
-An auditor may then import the address and blinding key with
-``importblindingkey`` to observe watch-only amounts.
-
-```
-$ elements-cli importaddress CTEwQjyErENrxo8dSQ6pq5atss7Ym9S7P6GGK4PiGAgQRgoh1iPUkLQ168Kqptfnwmpxr2Bf7ipQsagi
-$ elements-cli listtransactions "*" 1 0 true
-> []
-
-$ elements-cli importblindingkey CTEwQjyErENrxo8dSQ6pq5atss7Ym9S7P6GGK4PiGAgQRgoh1iPUkLQ168Kqptfnwmpxr2Bf7ipQsagi 5fd02f714d52b68bbbfef3b8e6d83be646fad1de5150e83d26a28496e00a2146
-$ elements-cli listtransactions "*" 1 0 true
-> [
- {
- "involvesWatchonly": true,
- "account": "",
- "address": "QTE8CaT6FcJEqkCR4ZGdoUJfas57eDqY6q",
- "category": "receive",
- "amount": 0.00500000,
- "label": "",
- "vout": 1,
- "confirmations": 35,
- "blockhash": "708f969b4fb1c705b82fa3ed309abc7a3d9b0e87aa6e5d17542bb7ee04c8e1f1",
- "blockindex": 1,
- "blocktime": 1488223140,
- "txid": "82b2c5122207e5f33e7adadc6a4aab16a170e16028f0b0cf2c04f9d17d6f0321",
- "walletconflicts": [
- ],
- "time": 1488223140,
- "timereceived": 1488225018,
- "bip125-replaceable": "no",
- "blindingfactors": "0000000000000000000000000000000000000000000000000000000000000000:71260137a80039dd8cee330d9f7bba625697dc53098cf54d625242946f26997b:"
- }
-]
-```
-
-You may also inspect an address in full:
-```
-$ elements-cli validateaddress CTEwQjyErENrxo8dSQ6pq5atss7Ym9S7P6GGK4PiGAgQRgoh1iPUkLQ168Kqptfnwmpxr2Bf7ipQsagi
-> {
- "isvalid": true,
- "address": "CTEwQjyErENrxo8dSQ6pq5atss7Ym9S7P6GGK4PiGAgQRgoh1iPUkLQ168Kqptfnwmpxr2Bf7ipQsagi",
- "scriptPubKey": "76a91405d5c237c5f2d90cfa22a22b75a1d1c1ede021a088ac",
- "confidential_key": "03b0f93d729839d3d96bfd7e20f11c7c6ae2016644d0d4cded6332dbfb61ed9067",
- "unconfidential": "2dZxbqgzXvANyj9SmyRR9LX3R2k8hg4iUWa",
- "ismine": true,
- "iswatchonly": false,
- "isscript": false,
- "pubkey": "031f17ad1acce63acf2d04cc59cb24423ab30f9345dd17476fd2380b02f878295d",
- "iscompressed": true,
- "account": "",
- "hdkeypath": "m/0'/0'/10'",
- "hdmasterkeyid": "f5ff0a90ac04830fde2f952cae9e076f9c2b4d39"
-}
-
-```
-
-[confidential-transactions]: /elements/confidential-transactions
-
diff --git a/source/elements/deterministic-pegs/index.md b/source/elements/deterministic-pegs/index.md
index 40a52fe..43755aa 100644
--- a/source/elements/deterministic-pegs/index.md
+++ b/source/elements/deterministic-pegs/index.md
@@ -2,8 +2,8 @@
title: Deterministic Pegs
description: Deterministic Pegs allow cross-chain transactions to be constructed in a decentralized fashion. Tokens can be moved from one blockchain to another.
image: /img/deterministic-pegs.svg
-source: https://github.com/ElementsProject/elementsproject.github.io/blob/master/source/elements/deterministic-pegs/index.md
-edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/elements/deterministic-pegs/index.md
+source: https://github.com/ElementsProject/elementsproject.github.io/blob/hexo/source/elements/deterministic-pegs/index.md
+edit: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/elements/deterministic-pegs/index.md
---
*Principal Investigator: Matt Corallo*
@@ -11,5 +11,3 @@ edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/s
Deterministic pegs allow Elements Alpha to carry redeemable testnet coins without any modifications to testnet itself. Transfers into Alpha are validated by all full nodes, optionally with the assistance of an RPC call to a testnet node to validate blockchain membership without the presence of compressed SPV proofs in testnet. Transfers out of Alpha are performed by a federation of functionaries which are trusted to hold the coins for Alpha.
Sidechains, like other alternative chains, can also be secured by merge-mining. However during a bootstrap period of introduction of a new chain, unless the start of merge mining were very well synchronised, there will be a period of lower hashrate. During the early stages of this bootstrap the chain could have low enough hashrate to present a security risk even against a modest powered attacker. Given the challenges of synchronising something as organic and decentralised by design as bitcoin mining, we therefore need a mechanism to bootstrap chain security. We start in this release with a threshold of functionaries and are plan for a later version to phase in merge-mining.
-
-A detailed explanation of the implementation in Elements Alpha can be found in the [blog](/posts/the-federated-peg-in-elements-alpha/).
diff --git a/source/elements/index.md b/source/elements/index.md
index 1030d6d..6718a8e 100644
--- a/source/elements/index.md
+++ b/source/elements/index.md
@@ -1,14 +1,14 @@
---
title: "The Periodic Table of Elements"
-source: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/elements/index.md
-edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/elements/index.md
+source: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/elements/index.md
+edit: https://github.com/ElementsProject/elementsproject.github.io/edit/hexo/source/elements/index.md
---
-
-
-OP_RPV allows to spend the withdraw output when a fraud proof is provided. It consists of the original withdraw transaction, the double spending withdraw transaction and a merkle block for each. The reference to the main chain lock is already given by the withdraw output.
-In consequence, the interpreter then checks that there is indeed a double spend, both merkle blocks are valid and contain the transactions, and that the double spending withdraw transaction is newer than the original withdraw transaction.
-Because blockchain consensus in Elements Alpha is determined by a federation of signers, the interpreter only requires the blocks to have valid signatures.
-If Alpha was backed by PoW, OP_RPV would require SPV proofs to verify that the blocks are at the specified height similar to the SPV extension in OP_WPV's case.
-
-Just like OP_WPV, OP_RPV peeks into the outputs of the transaction spending it. The transaction must have one output that uses OP_WPV to re-lock the withdraw output value minus the fraud bounty. The fraud bounty can be claimed by the prover.
-
-As the name implies, OP_RPV does not only come into play when there is a double spend, but also when the parent chain reorganizes.
-In such a situation, the locking transaction is either in another block or completely missing in the chain.
-In any case, the withdraw output should be invalidated by a reorganisation proof.
-This is not yet implemented in Alpha, but in principle the prover would provide an SPV proof that there exists a chain with sufficiently more work which does *not* include the block the withdrawal was coming from.
-
-If alphad is started with the `tracksidechain=all` command line argument it stores all previously spent main chain lock outputs in order to issue fraud proofs if a double spend occurs.
-
-Lastly, let's have a look at the curious secondScriptPubKey, which is expected to be the 9th argument to OP_WPV and is committed to in a withdraw lock (1st argument).
-The secondScriptPubKey is executed with a stack that contains the result of the scriptSig execution and information about the withdrawal transaction, i.e. transaction fee, fraud bounty, the OP_CSV locktime (from the withdrawoutput’s scriptPubKey ELSE case) and a constant dummy byte string.
-In Elements Alpha, the secondScriptPubKey for the Bitcoin lock is `OP_DROP 144 OP_LESSTHANOREQUAL`, which effectively ensures that contest period has passed.
-The secondScriptPubKey does not inspect the result the of the secondScriptSig, so the default scriptSig in this case is just a one byte push.
-This mechanism could in principle enforce additional chain specific limits on transaction fee and fraud bounty or more complex rules.
-
-
-### Withdrawing from the sidechain
-The mechanism behind sending coins from the sidechain to the main chain is - as far as the Alpha code is concerned - relatively simple.
-Figure 3 shows the sequence of transactions during a withdrawal to the main chain.
-
- 
-
-The federated lock on the main chain is a m of n multisignature output.
-Functionaries who hold the lock run a program we call *watchman* which communicates to alphad via RPC and is responsible for releasing the lock when a withdraw request appears on the sidechain.
-Note that due to the P2C payments, the federation is is not aware of a lock as long as the corresponding withdraw transaction has not taken place. This is because only the withdraw transaction reveals the data necessary - the contract - to derive pub- and privkey of the lock.
-
-Withdraw requests take the form of a lock output, so a transfer from side- to main chain would be initiated by a new transaction with the following scriptPubKey:
-{% codeblock %}
-