Our public Slack is the fastest way to get connected with other contributors to the Elements Project. We'll send an invitation to your email address.
- Join the Community - -
-
-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_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 %}
-Our public Slack is the fastest way to get connected with the Elements Project community. We'll send an invitation to your email address.
+Our public Slack is the fastest way to get connected with other contributors to the Elements Project. We'll send an invitation to your email address.
Get an Invite -#irc room, which bridges input directly from the channel on Freenode.
-
-Other resources are listed below.
-
#### Source Code
* https://github.com/ElementsProject/elements - contains isolated feature and dev sidechains braches
* [branch alpha](https://github.com/ElementsProject/bitcoin/tree/alpha) - testnet dev sidechain demo
#### Development Discussion
-* Slack Community: [sidechains.slack.com](https://sidechains.slack.com)
* Development Discussion List: [sidechains-dev list](https://lists.linuxfoundation.org/mailman/listinfo/sidechains-dev)
* Freenode IRC: #sidechains-dev [[webchat](http://webchat.freenode.net/?channels=%23sidechains-dev)]
* Bug Reports: Please submit issues to [github](https://github.com/ElementsProject/elements/issues).
* Pull Requests: Please submit pull requests to [github](https://github.com/ElementsProject/elements/pulls).
+
+
+#### Build Instructions
+```
+# https://github.com/bitcoin/bitcoin/tree/master/doc
+# Please refer to the Bitcoin documentation to install the required build dependencies/
+git clone https://github.com/ElementsProject/elements
+cd elements
+git checkout alpha
+./autogen.sh
+./configure
+make
+# If your build was successful, you will find src/alphad, src/alpha-cli and src/qt/alpha-qt
+
+```
+
+The Data Directory of the alpha testnet dev sidechain lives within your existing Bitcoin [Data Directory](https://en.bitcoin.it/wiki/Data_directory). For example, in Linux `~/.bitcoin/alphatestnet3` contains the Alpha blocks, indicies and wallet.
+
+#### Moving coins between Testnet and Alpha
+See [alpha-README.md](https://github.com/ElementsProject/elements/blob/alpha/alpha-README.md) for instructions on how to transfer testnet coins to the alpha network and back. Note that there is a lengthy confirmation and contest period that you must wait for a peg transfer to complete.
+
+* [testnet-faucet](https://testnet-faucet.elementsproject.org/)
+* [alpha-faucet](https://alpha-faucet.elementsproject.org/)
+
+For your convenience, these faucets allow you to quickly obtain coins on either the testnet or alpha network without the lengthy wait for the confirmation and contest safety periods.
+
+# FAQ
+* **Is this an altcoin?** No. The key thing to understand about sidechains is value is transferred to/from the main chain. No new coins are created and the total money supply remains constant.
+* ADDME
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..6cd44f7 100644
--- a/source/elements/asset-issuance/index.md
+++ b/source/elements/asset-issuance/index.md
@@ -1,99 +1,21 @@
----
-title: Asset Issuance
-description: Create new assets on a sidechain, with optional confidentiality.
-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
----
+#### Basic Asset Issuance
+*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 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 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).
+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).
-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.
+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 opens the door for building trustless exchanges, options, and other
-advanced smart contracts involving those arbitrary assets and a "hostcoin".
-
-### 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..d859e02 100644
--- a/source/elements/bitmask-sighash-modes/index.md
+++ b/source/elements/bitmask-sighash-modes/index.md
@@ -1,11 +1,4 @@
----
-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
----
-
+#### Bitmask Sighash Modes
*Principal Investigator: Glenn Willen*
* [feature-bitmasksighash](https://github.com/ElementsProject/elements/tree/feature_bitmasksighash) - EXAMPLE branch of Bitmask Sighash modes
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.
-
-
\ 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..b40467f 100644
--- a/source/elements/confidential-transactions/index.md
+++ b/source/elements/confidential-transactions/index.md
@@ -1,14 +1,12 @@
---
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
+description: Obscure the transaction value using the Confidential Transactions Element.
+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 +17,344 @@ 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:
-
-
- 
+ 
- 
- 
- 
- 
- 
- 
- -# https://github.com/bitcoin/bitcoin/tree/master/doc -# Please refer to the Bitcoin documentation to install the required build dependencies/ -git clone https://github.com/ElementsProject/elements -cd elements -git checkout alpha -./autogen.sh -./configure -make -# If your build was successful, you will find src/alphad, src/alpha-cli and src/qt/alpha-qt -- -The Data Directory of the alpha testnet dev sidechain lives within your existing Bitcoin [Data Directory](https://en.bitcoin.it/wiki/Data_directory). For example, in Linux `~/.bitcoin/alphatestnet3` contains the Alpha blocks, indicies and wallet. - -[elements-github]: https://github.com/ElementsProject/elements diff --git a/source/sidechains/alpha/getting-started.md b/source/sidechains/alpha/getting-started.md deleted file mode 100644 index e3e0697..0000000 --- a/source/sidechains/alpha/getting-started.md +++ /dev/null @@ -1,308 +0,0 @@ ---- -title: Getting Started with the Alpha Sidechain -edit: https://github.com/ElementsProject/elementsproject.github.io/blob/master/source/sidechains/alpha/getting-started.md -source: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/sidechains/alpha/getting-started.md ---- - -You might have heard of Sidechains by now – a way to test new blockchain ideas, -while still being protected the security of the Bitcoin mining network. -Blockstream has been hard at work [turning this idea into a reality][presentation], -and recently they released [the Elements Project][elements], which puts a huge -list of powerful new tools into the hands of developers. One of those tools is -[alpha, a sidechain pegged to Bitcoin's testnet][alpha], which implements a -majority of the Elements to date. - -So what's the first thing we're going to do? Start playing with it, of course. - -## Compiling -You're going to need to grab a few dependencies before you can compile. If -you've already compiled Bitcoin before (a process I recommend everyone go -through), you probably have most of the required components – you can [skip -ahead to compiling Elements itself](#building-elements). For others, I'm going -to start with one of the most common developer setups, a modern Linux -distribution (Ubuntu in our case) and compiling everything from scratch. - -#### Getting the Compiler -Let's go ahead and get our basics complete. For now, that starts with getting -a compiler and all the build tools. In Ubuntu, this is provided by the -`build-essential` package: - -```bash -sudo apt-get install build-essential -``` - -We're also going to want a few extra tools, perhaps most notably `autoconf`: - -```bash -sudo apt-get install libtool autotools-dev autoconf pkg-config -``` - -#### Installing Dependencies -Bitcoin and Elements also require a list of dependencies you'll need installed -before you're able to compile, including `libssl`, `libboost`, and a number of -other `libboost-*` packages: - -_**Important!** Make sure to use `libdb4.8`, **not** `libdb5.1` or later! 5.1 will break certain functionality in Bitcoin and will not be conducive to a -successful build! An installation candidate for 4.8 can be made available by adding the Bitcoin PPA to your apt sources (see below)._ - -```bash -sudo add-apt-repository ppa:bitcoin/bitcoin && sudo apt-get update -``` - -```bash -sudo apt-get install libssl-dev libboost-all-dev libdb4.8-dev libdb4.8++-dev -``` - -_**Note:** `libboost-all-dev` is available on Ubuntu, but might not be so -convenient on other distributions. Your mileage may vary – try compiling and -simply installing the packages the compiler claims are missing._ - - -## Building Elements -We're ready to download and compile the main body of work that comprises -Elements. Like any other compiled package, we'll first acquire the source code, -then configure it for our environment, and finally compile it into some -executable binaries. - -_**Note:** personally, I prefer keeping everything in a distinct project folder. - To do this, I execute this first: `mkdir sidechains && cd sidechains` – you'll -likely be better organized in the long run if you start this way!_ - -Download the code via Git: -```bash -git clone https://github.com/ElementsProject/elements && cd elements -``` - -If you'd like, you can even fork the above repository on GitHub, and replace the -git URL with your personal one. This is generally my approach. - -You're now in the `elements` directory. Let's compile `bitcoin` itself, which -is a necessary component for any sidechain: -```bash -git checkout mainchain -./autogen.sh && ./configure && make -mv src/bitcoin{d,-cli,-tx} ../ -``` - -Give it a little while to configure and compile – this can take a significant -amount of time, depending on the speed of your computer. Once complete (so long -as there are no errors), you should be able to execute `ls ..` and see three -binaries – `bitcoind`, `bitcoin-cli`, and `bitcoin-tx`. You're ready to move -forward. - -Let's checkout the `alpha` branch, which contains Blockstream's proposed -improvements to Bitcoin to implement sidechains, and complete the same process: -```bash -git checkout alpha -./autogen.sh && ./configure && make -mv src/alpha{d,-cli,-tx} ../ -``` - -Again, provided there are no errors, `ls ..` should now include three additional -binaries: `alphad`, `alpha-cli`, and `alpha-tx` – these are the -Elements-specific binaries that implement sidechains, and expect to be able to -connect directly to the `bitcoind` instance you compiled earlier. - -Let's fire these babies up. - -## Running Elements -Now that we have working binaries for both Bitcoin and Elements, we can start -running them as nodes. We'll be joining them to `testnet3`, the latest testnet -on the Bitcoin network. - -You'll have to run two different binaries at once here - I'll leave that as an -exercise to the reader to manage, if I only insist that `tmux` provides a -wonderful split-screen capability within a single terminal! - -Firstly, it'll help to alias some variables to configure the authentication for -the RPC communication between the Elements and Bitcoin binaries: - -```bash -RPC_USER=user -RPC_PASS=pass -``` - -In screen one, let's get our Bitcoin daemon started: -```bash -./bitcoind -rpcuser=$RPC_USER -rpcpassword=$RPC_PASS -testnet -txindex -``` - -Since this will be the first time we've started our Bitcoin client, it will take -some time to synchronize (generally 2-3 hours). Let's go ahead and fire up the -Elements binary before we go grab some coffee, though – again, very similar to -before, but this time with the `alphad` binary: - -```bash -./alphad -rpcuser=$RPC_USER -rpcpassword=$RPC_PASS -testnet -rpcconnect=127.0.0.1 -rpcconnectport=18332 -tracksidechain=all -txindex -blindtrust=true -``` - -You'll notice some additional parameters, including `-tracksidechain` and -`-blindtrust`, but also some RPC parameters specifying where it can find a -"trustworthy" Bitcoin node. In this case, we're supplying our own node, which we -have compiled ourselves and know to be valid. - -When both clients complete their synchronization, you're now a fully functional Elements/Bitcoin pair on the `testnet3` network! Now's your chance to go grab -a coffee while we wait for that to complete. - -## Moving Money -Hopefully you've given both Elements and Bitcoin enough time to sync by now. -The next natural step is to try moving some money into the network – to do this, -we'll need some `testnet3` Bitcoin to spend into the sidechain to acquire our -sidechain's tokens, and then we can spend those sidechain tokens to re-acquire -our Bitcoin. - -### Compiling Tools -As this is intended as a developer preview, we don't have fancy interfaces for -moving money around – we'll need to build a few for ourselves. - -Up first is the `secp256k1` library, which exposes all of the standard k1 curve -functionality: -```bash -git clone https://github.com/bitcoin/secp256k1 -cd secp256k1 -./autogen.sh && ./configure --with-bignum=no && make -make DESTDIR=`pwd`/install install -cd .. -``` - -The only notable component here is that we're using `make install` with a target -directory – we'll use this now for static linking in `contracthashtool`: -```bash -git clone https://github.com/blockstream/contracthashtool -cd contracthashtool -make CXXFLAGS="-I../secp256k1/install/usr/local/include -L../secp256k1/install/usr/local/lib -static" -cd .. -``` - -One last tool and we're almost ready – let's get a copy of Jeff Garzik's RPC -client: -```bash -git clone https://github.com/jgarzik/python-bitcoinrpc -``` - -Now, we're ready to move money. - -### Magic -Let's generate a new sidechain wallet to store the tokens we're about to create -when we commit our testnet Bitcoin. Go ahead and run `cd elements` to get into -the appropriate folder. - -#### Funding Your Wallet -Since we just installed Bitcoin for the first time above, we probably don't have -any `testnet3` bitcoin. Blockstream has [their own testnet faucet][testnet -faucet] for this purpose; let's get our Bitcoin address and request some funds: -```bash -../bitcoin-cli -testnet -rpcuser=user -rpcpassword=pass getnewaddress -``` -You'll get an output of an address – make sure it starts with an `m` or an `n`, which -designates a testnet address–and plug that into [the `testnet3` bitcoin faucet -][testnet faucet] to request some coins. - -_**Note:** If you set a custom RPCUSER and RPCPASS in the earlier step, you'll -need to edit `./contrib/sidechain-manipulation.py` now to reflect those values somewhere -around lines 9 and 10._ -```bash -./contrib/sidechain-manipulation.py generate-one-of-one-multisig sidechain-wallet -``` - -You'll see something like this as an output: - -```bash -One-of-one address: 22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQa8puPqVNtbNCN61ZUzfy1wDuXM1hS6o82 -P2SH address: 2NFEWvrCjPGFQn6smEAUA8ehVr46PrCc8C5 -``` - -Let's copy that P2SH address and use it to send some money: - -```bash -./contrib/sidechain-manipulation.py send-to-sidechain 2NFEWvrCjPGFQn6smEAUA8ehVr46PrCc8C5 1 -``` -Don't forget to replace the address with the one you generated above, and to -supply the amount you're sending. You should see an output something like this: -```bash -Sending 1 to 2NFEWvrCjPGFQn6smEAUA8ehVr46PrCc8C5... -(nonce: 94ffbf32c1f1c0d3089b27c98fd991d5) -Sent tx with id bf01b88710b6023125379510ebd84b373bee88217c80739a1144e5e92b4ee2d0 -``` -Take note of both the `nonce` and the transaction ID. We'll need them to stake -our claim to the corresponding sidechain tokens in a moment. - -Now, due to the nature of this sidechain implementation, you'll need to wait 10 -blocks on the testnet blockchain for this transaction to be redeemable in the -sidechain. This amounts to around 1.5 hours on `mainnet`, but shouldn't take -nearly this long on `testnet`. - -Once completed, let's go ahead and claim – don't forget to replace the `nonce` -and transaction ID values, in that order: - -```bash -./contrib/sidechain-manipulation.py claim-on-sidechain 2NCs5ufweTL8VHKNT6wrZMTkrnnmpZCy99j 94ffbf32c1f1c0d3089b27c98fd991d5 bf01b88710b6023125379510ebd84b373bee88217c80739a1144e5e92b4ee2d0 -``` - -Again, the output will look something like this: -```bash -Redeeming from utxo 0377d218c36f5ee90244e660c387002296f3e4d5cac8fac8530b07e4d3241ccf:0 (value 21000000, refund 20999999) -Success! -Resulting txid: eabe26aba6286e1ee439baedeb75094ec0bcdaf54ed9481d9d2183e8a6424755 -``` - -You've now got a spendable transaction on your sidechain! Well, it'll be -redeemable in 144 sidechain blocks to make sure any outstanding forks are -resolved, but we've just claimed our first tokens in the sidechain. - -We can now spend it using our 1-of-1 address from earlier: -```bash -./contrib/sidechain-manipulation.py spend-from-claim eabe26aba6286e1ee439baedeb75094ec0bcdaf54ed9481d9d2183e8a6424755 22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQa8puPqVNtbNCN61ZUzfy1wDuXM1hS6o82 - Submitting tx to mempool... - Success! -``` - -## What's Going On Here? -In this initial release of Elements, we've implemented something called -"federated peg". Since the main Bitcoin codebase does not yet support some of -the necessary features to implement a full two-way peg, the `testnet` network -relies on a group of signatories (the "federation" part) to execute and verify -the redemption of testnet coins, while within Elements the network actually -utilizes a full two-way peg to redeem the outputs from testnet. - -Let's take a look at what happens now. - -### Redeeming Sidechain Tokens -To complete the loop, we need to get rid of our sidechain tokens, and restore -the original bitcoin we spent in creating them. In our federated peg, we rely -on the federation to verify these, but once bitcoin supports the types of smart -contracts we need, it'll be completely two-way in both directions. - -Generate yourself a mainchain wallet to receive the restored bitcoin: -```bash -./contrib/sidechain-manipulation.py generate-one-of-one-multisig mainchain-wallet -One-of-one address: mm8UW9YsjeHoVhXbHG4hEFKJt52P5iB7Vi -P2SH address: 2MzqiCCUwtKKEV9Kxiyvk8ZuNCFKbcbneva -``` - -Finally, provide the P2SH address you just created above to the -`send-to-mainchain` command, and the amount you wish to move (this can be any -subset of the amount you moved in earlier, but no more): -```bash -./contrib/sidechain-manipulation.py send-to-mainchain 2MzqiCCUwtKKEV9Kxiyvk8ZuNCFKbcbneva 1 -``` - -That's it! We've spun up both a Bitcoin node on the `testnet3` network, and an -Elements node on the `alpha` network. We've moved `testnet3` bitcoin into the -`alpha` sidechain, moved it around, and finally returned ourselves to `testnet3` -bitcoin. - -There's a ton of other things that Elements provides, including Segregated -Witness and Confidential Transactions. Now that you have an Elements node -running, you can explore these things and more on your own. We'll cover these -in more detail in the future! - -Until then, please share what you build and help us by reporting any issues you -find on [the official Elements GitHub repo][elements github]. We're excited to -see what you build! - -[presentation]: https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf -[elements]: http://elementsproject.github.io -[alpha]: /sidechains/alpha -[testnet faucet]: https://testnet-faucet.elementsproject.org/ -[elements github]: https://github.com/ElementsProject/elements diff --git a/source/sidechains/alpha/index.md b/source/sidechains/alpha/index.md index 6b6478b..7f60fd5 100644 --- a/source/sidechains/alpha/index.md +++ b/source/sidechains/alpha/index.md @@ -1,61 +1,5 @@ ---- -title: Elements Alpha -edit: https://github.com/ElementsProject/elementsproject.github.io/blob/master/source/sidechains/alpha/index.md -source: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/sidechains/alpha/index.md ---- +# Elements: Alpha +## A test network for various Elements. +To make it easy for the community to test the latest Elements, this project combines the best of them into dev sidechains. The first release is Elements Alpha, a developer sidechain and network that introduces several new technologies on a sidechain, pegged to Bitcoin’s testnet. All code is open source, like Bitcoin itself, and others are encouraged to contribute to the project as we work to improve and add additional Elements. Elements Alpha is intended to be a technology demo and testing environment. Proposed Elements were not ready, and as a testnet development sidechain, this blockchain is intended to be short-lived and easily replaced as the technology evolves. -To make it easy for the community to test [the latest -Elements][latest-elements], they are deployed on a public sidechain (pegged to -Bitcoin's `testnet`), Elements Alpha. All code is open source, -like Bitcoin itself, and others are encouraged to contribute to the project as -we work to improve and add additional Elements. Elements Alpha is intended to -be a technology demo and testing environment, but the same tools and practices -used to interact with it will integrate with production networks. - - - - - - - - - -### Introduction - -Elements Alpha functions as a sidechain to Bitcoin’s `testnet`, though the peg -mechanism currently works through a centralized protocol adapter, as described -in [the Sidechains whitepaper][whitepaper]. It relies on an auditable federation -of signers to manage the testnet coins transferred into the sidechain via [the -"Deterministic Pegs" Element][deterministic-peg], and to produce blocks via [the -"Signed Blocks" Element][signed-blocks]. This makes it possible to immediately -explore the new chain’s possibilities, using different security trade-offs. We -plan to, in a later release, upgrade the protocol adapter to support fully -decentralized merge-mining of the sidechain, and ultimately to phase in the full -2-way peg mechanism. - -#### Moving coins between Testnet and Alpha -See [alpha-README.md](https://github.com/ElementsProject/elements/blob/alpha/alpha-README.md) for instructions on how to transfer testnet coins to the alpha network and back. Note that there is a lengthy confirmation and contest period that you must wait for a peg transfer to complete. - -* [testnet-faucet](https://testnet-faucet.elementsproject.org/) -* [alpha-faucet](https://alpha-faucet.elementsproject.org/) - -For your convenience, these faucets allow you to quickly obtain coins on either the testnet or alpha network without the lengthy wait for the confirmation and contest safety periods. - -# FAQ -* **Is this an altcoin?** No. The key thing to understand about sidechains is value is transferred to/from the main chain. No new coins are created and the total money supply remains constant. - -[elements-github]: https://github.com/ElementsProject/elements -[compiling]: /sidechains/alpha/compiling.html -[latest-elements]: /elements#latest -[whitepaper]: https://blockstream.com/sidechains.pdf -[deterministic-peg]: /elements/deterministic-pegs -[signed-blocks]: /elements/signed-blocks +Elements Alpha functions as a sidechain to Bitcoin’s testnet, though the peg mechanism currently works through a centralized protocol adapter, as described in the Sidechains whitepaper in appendix A. It relies on an auditable federation of signers to manage the testnet coins transferred into the sidechain (see the Deterministic Peg feature) and to produce blocks (see the Signed Block feature). This makes it possible to immediately explore the new chain’s possibilities, using different security trade-offs. We plan to, in a later release, upgrade the protocol adapter to support fully decentralized merge-mining of the sidechain, and ultimately to phase in the full 2-way pegging mechanism. diff --git a/source/sidechains/creating-your-own.md b/source/sidechains/creating-your-own.md deleted file mode 100644 index a352339..0000000 --- a/source/sidechains/creating-your-own.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Building A New Sidechain with Elements -edit: https://github.com/ElementsProject/elementsproject.github.io/blob/master/source/sidechains/creating-your-own.md -source: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/sidechains/creating-your-own.md ---- - -This step-by-step guide will walk you through building your own sidechain and -setting up a simple single-signer peg with a `regtest`-powered mainchain. This -configuration works to run a sidechain with a 1-of-1 functionary/blocksigner, -convenient for local development and testing. - -There are several other ways of deriving consensus on a sidechain. See [the -Deterministic Peg Element](/elements/deterministic-peg.html) for more details. - -#### Prerequisites -You'll need a working version of Elements. Follow [the Elements build -instructions](https://github.com/ElementsProject/elements/blob/elements-0.14.1/doc/build-unix.md) -to get set up. - -### Creating your own blockchain -Just like in Bitcoin, Elements can be started in `regtest` mode which allows to -easily create test chains and networks. - -1. Start Elements: - > `elementsd -regtest -daemon` -2. Create an alias for the RPC client: - > `alias ec="elements-cli -regtest"` - -3. Create a chain where we predetermine who is allowed to sign blocks. We start with creating a fresh keypair. - > ADDR=`ec getnewaddress` - > PUBKEY=`ec validateaddress $ADDR | jq -r '.pubkey'` - > PRIVKEY=`ec dumpprivkey $ADDR` -4. Create a 1-of-1 multisig script to use as a block requirement. - > SIGNBLOCKSCRIPT=`ec createmultisig 1 \[\"$PUBKEY\"\] | jq -r '.redeemScript'` -5. Stop the daemon and create a new chain using the blocksigner script - > ec stop - > rm -rf ~/.bitcoin/elementsregtest - > elementsd -regtest -daemon -signblockscript=$SIGNBLOCKSCRIPT - > ec importprivkey $PRIVKEY - > NEW_BLOCK=`ec getnewblockhex` - > BLOCKSIG=`ec signblock $NEW_BLOCK` - - > SIGNED_BLOCK=`ec combineblocksigs $NEW_BLOCK \[\"$BLOCKSIG\"\] | jq -r '.hex'` - * ensure that the output of combineblocksigs has "complete" true - > `ec getblockcount` - * check the current block count - > `ec submitblock $SIGNED_BLOCK` - > `ec getblockcount` - * check that the chain advanced by one block - -Block generation can be easily automated in a shell script. - -#### Congratulations! -Your chain is online and already accessible, just let other nodes connect to you: -``` -ec addnode
Sidechains are independently deployed bundles of Elements in the real world. Sidechains can be used to test new features for Bitcoin, change network and security properties, and even stand alone as production networks.
+### Sidechains are convenient ways to test Elements. -Want to pick your own set of Elements, and deploy your own blockchain?
+The Elements Project, supported by Blockstream, runs and maintains a number of +sidechains. - -
- Alpha is the official Elements testnet. Pegged to Bitcoin's `testnet`, it includes most of [the stable Elements][stable-elements], and is a convenient way of prototyping your application before going to production.
-
- Rootstock is a sidechain that implements robust smart contracts. Rootstock is backwards-compatible with Ethereum, so scripts from the Ethereum ecosystem can run directly on a Bitcoin-backed sidechain.
-
- Gem Health is a network for developing applications and shared infrastructure for healthcare. We are building the fabric of a globally integrated healthcare continuum that’s designed to make healthcare more personal and affordable.
-
- Working on something interesting? Add it here.
-
- Liquid is the first commercial sidechain by Blockstream. It enables instant movement of funds between exchanges, without waiting for the delay of confirmation in the Bitcoin blockchain. It is available to users of participating Bitcoin exchanges.
-
-When it is time to append a new block to the Liquid sidechain, the block is
-signed by the first functionary in the grid, then handed to the next. Each time
-the block is passed to the next functionary, it is checked by the code running
-inside the black box to make sure it follows the rules, then is signed and
-passed on to the next until a supermajority of nodes have signed the block.
+When it is time to append a new block to the Liquid sidechain, the block is signed by the first functionary in the grid, then handed to the next. Each time the block is passed to the next functionary, it is checked by the code running inside the black box to make sure it follows the rules, then is signed and passed on to the next until a supermajority of nodes have signed the block.
-Today, key players in the Bitcoin market, including exchanges, payment
-processors, traders, and remitters, experience delays when moving bitcoin
-between accounts in different locations. We refer to this as Interchange
-Settlement Lag (ISL) – a host of liquidity inefficiencies including latency and
-confirmation times that hinder the overall prospects of the Bitcoin ecosystem.
-Dealing with these issues requires market participants to maintain multiple
-balances and accounts across the market to avoid ISL, increasing overall capital
-requirements and exposure to the possibility of counterparty risk.
+Today, key players in the Bitcoin market, including exchanges, payment processors, traders, and remitters, experience delays when moving bitcoin between accounts in different locations. We refer to this as Interchange Settlement Lag (ISL) – a host of liquidity inefficiencies including latency and confirmation times that hinder the overall prospects of the Bitcoin ecosystem. Dealing with these issues requires market participants to maintain multiple balances and accounts across the market to avoid ISL, increasing overall capital requirements and exposure to the possibility of counterparty risk.
-Liquid is a powerful sidechain with wide-reaching implications. To learn more,
-[read the Liquid announcement](https://www.blockstream.com/2015/10/12/introducing-liquid/).
+Liquid is a powerful sidechain with wide-reaching implications. To learn more, [read the Liquid whitepaper](https://blockstream.io).
-Contact Blockstream To Learn More
-
+Read the Liquid Whitepaper
diff --git a/source/sidechains/rootstock/index.md b/source/sidechains/rootstock/index.md
deleted file mode 100644
index 909b1fc..0000000
--- a/source/sidechains/rootstock/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Rootstock
-description: Smart Contracts on a Bitcoin Sidechain
-source: https://github.com/ElementsProject/elementsproject.github.io/blob/master/source/sidechains/rootstock/index.md
-edit: https://github.com/ElementsProject/elementsproject.github.io/edit/master/source/sidechains/rootstock/index.md
----
-Rootstock is an open-source smart-contract platform that extends Bitcoin. The smart-contracts capability of rootstock enable numerous applications, such as micropayment channels, escrow services, crowdfunding, crypto-asset creation, decentralized remittances, IP protection, asset registry, voting systems, micro-lending, supply chain traceability, online reputation, digital identity, in-game currency, prediction markets and fair-playing.
-
-To create a smart-contract platform, Rootstock implements a Turing-complete deterministic replicated virtual machine. Also Rootstock provides an improved payment experience with near instant payment confirmation: it achieves currently 300 tps and confirms most payments in less than 20 seconds. The security of Rootstock is provided by the Bitcoin miners using the merged-mining technique. To be able to interact with Bitcoin, Rootstock implements a Bitcoin 2-Way peg (2WP).
-
-The 2WP allows bitcoins to be transferred to and from Rootstock at a fixed conversion rate. Rootstock 2WP design is a hybrid drivechain+federation/sidechain. The sidechain functionality is provided by a state-full SPV node (including multisig-wallet) running in a smart-contract. Rootstock is also backwards-compatible with Ethereum, so Ethereum distributed applications (DApps) can be easily ported to Rootstock and achieve greater security, faster execution and greater interoperability with Bitcoin. Rootstock is being actively developed by RSK Labs Ltd., which was founded in 2015 and which has received private funding from key players in the FinTech industry and Bitcoin ecosystem. The platform will be launched in Q3 2016. More information, including founder’s team, and white papers can be downloaded from http://www.rootstock.io/.
diff --git a/themes/elements/layout/blog.jade b/themes/elements/layout/blog.jade
index 0c843e0..3308294 100644
--- a/themes/elements/layout/blog.jade
+++ b/themes/elements/layout/blog.jade
@@ -4,21 +4,26 @@ prepend site-title
| #{page.title} —
block content
+
+ include partials/menu
+
.ui.main.text.container
.ui.cards
- - site.posts.reverse().each(function(page, i) {
- .ui.fluid.card
+ - site.posts.each(function(post, i) {
+ a.ui.fluid.card(href="#{post.path}")
.content
+ .header #{post.title}
.meta
- .right.floated.time #{page.date}
- a.header(href="#{page.path}") #{page.title}
+ .right.floated.time #{post.date}
.description
- p !{page.excerpt}
+ p !{post.excerpt}
.extra.content
- .right.floated.meta
- a.ui.button(href="#{page.path}") Read More
- i.icon.chevron.right
- if (page.author)
- include partials/author
-
+ if (post.author)
+ a.right.floated.author(href="/people/#{post.author}")
+ img.ui.avatar.image(src="/img/#{post.author}.png")
+ | #{post.author}
+
+ .left.floated.star
+ i.icon.star
+
- });
diff --git a/themes/elements/layout/index.jade b/themes/elements/layout/index.jade
index 3313846..b4975ca 100644
--- a/themes/elements/layout/index.jade
+++ b/themes/elements/layout/index.jade
@@ -1,20 +1,14 @@
extends layouts/elements
-block masthead
- style.
- .masthead.segment {
- min-height: 700px;
- }
-
- .ui.inverted.vertical.center.aligned.masthead.segment(style="background: url('/img/hero-image.png'); background-size: 100%;")
- .ui.container
- .ui.large.secondary.inverted.pointing.menu
- include partials/menu
- a.right.toc.item
- i.sidebar.icon
- .ui.text.container(style="margin-top: -6em;")
+block content
+ .pusher
+ .ui.inverted.vertical.masthead.center.aligned.segment
+ .ui.container
+ .ui.large.secondary.inverted.pointing.menu
+
+ .ui.text.container
h1.ui.inverted.header The Elements Project
- h2 Extend Bitcoin with composable building blocks,
- alpha, the first pegged sidechain. alpha includes all "production-ready" Elements, including Segregated Witness and Confidential Transactions.
- a.ui.large.button(href="/sidechains/alpha")
- | Learn About Alpha
- i.icon.right.chevron
- .column
- h3.ui.header ???
- p You could list your sidechain here! If you've deployed your network to the public, you can add it via a simple pull request.
- a.ui.large.button(href="/sidechains")
- | Add Your Sidechain
- i.icon.right.chevron
- //-.column
- h3.ui.header Liquid
- p Liquid is a production-deployed sidechain that focuses on rapid settlement between exchanges. It runs in production, and can be used today.
- a.ui.large.button(href="/sidechains/liquid")
- | Learn About Liquid
- i.icon.right.chevron
+ .ui.vertical.stripe.segment
+ .ui.equal.width.stackable.internally.celled.grid
+ .center.aligned.row
+ .column
+ h3.ui.header alpha
+ p Alpha is the first test sidechain that contains all in-development Elements.
+ a.ui.large.button(href="/sidechains/alpha")
+ | Learn About Alpha
+ i.icon.right.chevron
+ .column
+ h3.ui.header Liquid
+ p Liquid is a production-deployed sidechain that focuses on rapid settlement between exchanges. It runs in production, and can be used today.
+ a.ui.large.button(href="/sidechains/liquid")
+ | Learn About Liquid
+ i.icon.right.chevron
diff --git a/themes/elements/layout/layouts/elements.jade b/themes/elements/layout/layouts/elements.jade
index 72eef7a..460e75f 100644
--- a/themes/elements/layout/layouts/elements.jade
+++ b/themes/elements/layout/layouts/elements.jade
@@ -6,42 +6,17 @@ html(lang="en")
body
block header
- .ui.large.top.fixed.hidden.inverted.menu
+ .ui.large.top.fixed.hidden.menu
.ui.container
- include ../partials/menu
- .ui.vertical.inverted.sidebar.right.large.menu
- .ui.center.aligned.inverted.header
- include ../partials/menu
- .pusher
- block masthead
- .ui.inverted.vertical.masthead.segment
- .ui.container
- .ui.large.secondary.inverted.pointing.menu
- include ../partials/menu
- a.right.toc.item
- i.sidebar.icon
+ .active.item Home
+ .item Elements
+ .item Sidechains
+
+ .right.menu
+ .item
+ a.ui.button test
- .ui.container
- .content
- block content
+ block content
- block footer
- include ../partials/footer
-
- script.
- window.addEventListener('load', function() {
- // fix menu when passed
- $('.masthead').visibility({
- once: false,
- onBottomPassed: function() {
- console.log('.masthead.onBottomPassed()')
- $('.fixed.menu').transition('fade in');
- },
- onBottomPassedReverse: function() {
- $('.fixed.menu').transition('fade out');
- }
- });
-
- // create sidebar and attach to menu open
- $('.ui.sidebar').sidebar('attach events', '.toc.item');
- });
+ block footer
+ include ../partials/footer
diff --git a/themes/elements/layout/page.jade b/themes/elements/layout/page.jade
index 0db1e8a..c61b026 100644
--- a/themes/elements/layout/page.jade
+++ b/themes/elements/layout/page.jade
@@ -4,19 +4,12 @@ prepend site-title
| #{page.title} —
block content
+
+ include partials/menu
+
.ui.main.text.container
- .ui.right.floated.tiny.buttons
- include partials/edit-self
+ include partials/edit-self
- if (page.title)
- h2 #{page.title}
- if (page.image)
- img.ui.image.right.floated.small(src="#{page.image}")
- if (page.description)
- h3 #{page.description}
- if (page.branch)
- a.ui.button.large.primary(href="https://github.com/ElementsProject/elements/tree/#{page.branch}")
- i.icon.code
- code #{page.branch}
+ h2 #{page.title}
.content !{page.content}
diff --git a/themes/elements/layout/partials/author.jade b/themes/elements/layout/partials/author.jade
deleted file mode 100644
index 8747be1..0000000
--- a/themes/elements/layout/partials/author.jade
+++ /dev/null
@@ -1,3 +0,0 @@
-a.author(href="/people/#{page.author}")
- img.ui.avatar.rounded.image(src="/img/#{page.author}.png")
- | #{page.author}
diff --git a/themes/elements/layout/partials/edit-self.jade b/themes/elements/layout/partials/edit-self.jade
index a05f5c8..437806e 100644
--- a/themes/elements/layout/partials/edit-self.jade
+++ b/themes/elements/layout/partials/edit-self.jade
@@ -1,8 +1,9 @@
-if (page && page.edit && page.source)
- a.ui.button.tooltipped(href="#{page.edit}", title="Launch an editor to change content on this page.")
- i.icon.pencil
- | edit this page
- .or
- a.ui.button.tooltipped(href="#{page.source}", title="View the original content used to generate this page.")
- i.icon.code
- | view the source
+.ui.right.floated.buttons
+ if (page && page.edit && page.source)
+ a.ui.button.tooltipped(href="#{page.edit}", title="Launch an editor to change content on this page.")
+ i.icon.pencil
+ | edit this page
+ .or
+ a.ui.button.tooltipped(href="#{page.source}", title="View the original content used to generate this page.")
+ i.icon.code
+ | view the source
diff --git a/themes/elements/layout/partials/footer.jade b/themes/elements/layout/partials/footer.jade
index 3f6a1e0..52a414e 100644
--- a/themes/elements/layout/partials/footer.jade
+++ b/themes/elements/layout/partials/footer.jade
@@ -4,16 +4,16 @@
.three.wide.column
h4.ui.inverted.header About
.ui.inverted.link.list
- a.item(href="https://github.com/ElementsProject") GitHub
- a.item(href="https://github.com/ElementsProject/elementsproject.org") Source Code
-
- .five.wide.column
- a(href="https://chat.elementsproject.org")
- h4.ui.inverted.header Community
- p(style="padding-top: 1em;")
- script(async, defer, src="https://chat.elementsproject.org/slackin.js?large")
-
+ a.item(href="/sitemap") Sitemap
+ a.item Contact Us
+ .three.wide.column
+ h4.ui.inverted.header Services
+ .ui.inverted.link.list
+ a.item(href="") Sidechains
+ a.item(href="") Consulting
+
.seven.wide.column
h4.ui.inverted.header Copyright
- p The Elements Project is a community endeavor, consisting of contributions from numerous crypographers and engineers. To contribute, visit our contribution guide.
+ p The Elements Project is © 2016 The Elements Foundation.
+ p All content is licensed CC-BY NC SA.
diff --git a/themes/elements/layout/partials/head.jade b/themes/elements/layout/partials/head.jade
index b71903e..ba9267b 100644
--- a/themes/elements/layout/partials/head.jade
+++ b/themes/elements/layout/partials/head.jade
@@ -21,18 +21,90 @@ link(rel="alternate", href=theme.rss ? theme.rss : config.root + "rss2.xml", tit
//- Stylesheets
!= css("css/semantic.min.css")
-!= css("css/elements.css")
-
-script(src="/javascript/jquery.js")
-script(src="/javascript/semantic.min.js")
-
-script.
- var _prum = [['id', '58834389f5d03ba702c9f35a'],
- ['mark', 'firstbyte', (new Date()).getTime()]];
- (function() {
- var s = document.getElementsByTagName('script')[0]
- , p = document.createElement('script');
- p.async = 'async';
- p.src = '//rum-static.pingdom.net/prum.min.js';
- s.parentNode.insertBefore(p, s);
- })();
+!= js("js/semantic.min.js")
+
+style.
+ .hidden.menu {
+ display: none;
+ }
+
+ .masthead.segment {
+ min-height: 700px;
+ padding: 1em 0em;
+ }
+ .masthead .logo.item img {
+ margin-right: 1em;
+ }
+ .masthead .ui.menu .ui.button {
+ margin-left: 0.5em;
+ }
+ .masthead h1.ui.header {
+ margin-top: 3em;
+ margin-bottom: 0em;
+ font-size: 4em;
+ font-weight: normal;
+ }
+ .masthead h2 {
+ font-size: 1.7em;
+ font-weight: normal;
+ }
+
+ .ui.vertical.stripe {
+ padding: 8em 0em;
+ }
+ .ui.vertical.stripe h3 {
+ font-size: 2em;
+ }
+ .ui.vertical.stripe .button + h3,
+ .ui.vertical.stripe p + h3 {
+ margin-top: 3em;
+ }
+ .ui.vertical.stripe .floated.image {
+ clear: both;
+ }
+ .ui.vertical.stripe p {
+ font-size: 1.33em;
+ }
+ .ui.vertical.stripe .horizontal.divider {
+ margin: 3em 0em;
+ }
+
+ .quote.stripe.segment {
+ padding: 0em;
+ }
+ .quote.stripe.segment .grid .column {
+ padding-top: 5em;
+ padding-bottom: 5em;
+ }
+
+ .footer.segment {
+ padding: 5em 0em;
+ }
+
+ .secondary.pointing.menu .toc.item {
+ display: none;
+ }
+
+ @media only screen and (max-width: 700px) {
+ .ui.fixed.menu {
+ display: none !important;
+ }
+ .secondary.pointing.menu .item,
+ .secondary.pointing.menu .menu {
+ display: none;
+ }
+ .secondary.pointing.menu .toc.item {
+ display: block;
+ }
+ .masthead.segment {
+ min-height: 350px;
+ }
+ .masthead h1.ui.header {
+ font-size: 2em;
+ margin-top: 1.5em;
+ }
+ .masthead h2 {
+ margin-top: 0.5em;
+ font-size: 1.5em;
+ }
+ }
diff --git a/themes/elements/layout/partials/menu.jade b/themes/elements/layout/partials/menu.jade
index 12de3d9..73e4455 100644
--- a/themes/elements/layout/partials/menu.jade
+++ b/themes/elements/layout/partials/menu.jade
@@ -1,9 +1,100 @@
-a.header.item(href="/") The Elements Project
-a.item(href="/elements") Elements
-a.item(href="/sidechains") Sidechains
-a.item(href="/contributing") Community
-a.item(href="/posts") Blog
-.right.menu
- a.item(href="https://github.com/ElementsProject/elements")
- i.icon.github.alternate
- | GitHub
+script.
+ $(document)
+ .ready(function() {
+
+ // fix main menu to page on passing
+ $('.main.menu').visibility({
+ type: 'fixed'
+ });
+ $('.overlay').visibility({
+ type: 'fixed',
+ offset: 80
+ });
+
+ // lazy load images
+ $('.image').visibility({
+ type: 'image',
+ transition: 'vertical flip in',
+ duration: 500
+ });
+
+ // show dropdown on hover
+ $('.main.menu .ui.dropdown').dropdown({
+ on: 'hover'
+ });
+ })
+ ;
+
+style.
+ body {
+ background-color: #FFFFFF;
+ }
+
+ .main.container {
+ margin-top: 7em;
+ }
+
+ .main.menu {
+ margin-top: 4em;
+ border-radius: 0;
+ border: none;
+ box-shadow: none;
+ transition:
+ box-shadow 0.5s ease,
+ padding 0.5s ease
+ ;
+ }
+ .main.menu .item img.logo {
+ margin-right: 1.5em;
+ }
+
+ .overlay {
+ float: left;
+ margin: 0em 3em 1em 0em;
+ }
+ .overlay .menu {
+ position: relative;
+ left: 0;
+ transition: left 0.5s ease;
+ }
+
+ .main.menu.fixed {
+ background-color: #FFFFFF;
+ border: 1px solid #DDD;
+ box-shadow: 0px 3px 5px rgba(0, 0, 0, 0.2);
+ }
+ .overlay.fixed .menu {
+ left: 800px;
+ }
+
+ .text.container .left.floated.image {
+ margin: 2em 2em 2em -4em;
+ }
+ .text.container .right.floated.image {
+ margin: 2em -4em 2em 2em;
+ }
+
+ .ui.footer.segment {
+ margin: 5em 0em 0em;
+ padding: 5em 0em;
+ }
+
+.ui.fixed.inverted.menu
+ .ui.container
+ a.header.item(href="/") The Elements Project
+ a.item(href="/elements") Elements
+ a.item(href="/sidechains") Sidechains
+ a.item(href="/case-studies") Case Studies
+ a.item(href="/posts") Blog
+ .item
+ script(async, defer, src="https://chat.elementsproject.org/slackin.js")
+
+ .right.menu
+ a.item(href="https://github.com/ElementsProject/elements")
+ i.icon.github.alternate
+ | GitHub
+ i.icon.chevron.right
+
+ .ui.right.floated
+ a.item
+ i.icon
diff --git a/themes/elements/layout/post.jade b/themes/elements/layout/post.jade
index eddc7c8..c61b026 100644
--- a/themes/elements/layout/post.jade
+++ b/themes/elements/layout/post.jade
@@ -4,19 +4,12 @@ prepend site-title
| #{page.title} —
block content
- .ui.main.text.container
- .ui.right.floated.tiny.buttons
- include partials/edit-self
+
+ include partials/menu
.ui.main.text.container
- h2 #{page.title}
- .meta posted
- if (page.author)
- | by
- include partials/author
- | on
- abbr.time #{page.date}
+ include partials/edit-self
- hr
+ h2 #{page.title}
.content !{page.content}
diff --git a/themes/elements/source/css/elements.css b/themes/elements/source/css/elements.css
deleted file mode 100644
index 743dd6e..0000000
--- a/themes/elements/source/css/elements.css
+++ /dev/null
@@ -1,226 +0,0 @@
-.content {
- padding-bottom: 1em;
- padding-top: 1em;
-}
-
-.pusher {
- display: flex;
- min-height: 100vh;
- flex-direction: column;
-}
-
-.pusher > .footer {
- flex: 1;
-}
-
-.masthead .ui.secondary.inverted.pointing.menu {
- border: 0;
-}
-
-.hidden.menu {
- display: none;
-}
-
-.masthead.segment {
- /* min-height: 15em; */
- padding: 1em 0em;
-}
-.ui.secondary.menu .item>img:not(.ui) {
- margin-right: 1em;
- max-height: 2em;
- max-width: 2em;
- margin-top: -1em;
- margin-bottom: -1em;
-}
-.ui.menu .logo.item>img:not(.ui) {
- margin-right:1em;
-}
-.masthead .ui.menu .ui.button {
- margin-left: 0.5em;
-}
-.masthead h1.ui.header {
- margin-top: 0.5em;
- margin-bottom: 0em;
- font-size: 4em;
- font-weight: normal;
-}
-.masthead h2 {
- font-size: 1.7em;
- font-weight: normal;
-}
-.masthead .ui.menu {
- margin: 0;
-}
-.ui.secondary.menu .header.item {
- border-right: 0;
-}
-.ui.inverted.menu .logo.item {
- font-weight: bold;
-}
-.masthead .ui.secondary.pointing.menu {
- border-bottom: 0;
-}
-
-.ui.vertical.stripe h3 {
- font-size: 2em;
-}
-.ui.vertical.stripe .button + h3,
-.ui.vertical.stripe p + h3 {
- margin-top: 3em;
-}
-.ui.vertical.stripe .floated.image {
- clear: both;
-}
-.ui.vertical.stripe p {
- font-size: 1.33em;
-}
-.ui.vertical.stripe .horizontal.divider {
- margin: 3em 0em;
-}
-
-.quote.stripe.segment {
- padding: 0em;
-}
-.quote.stripe.segment .grid .column {
- padding-top: 5em;
- padding-bottom: 5em;
-}
-
-.footer.segment {
- padding: 5em 0em;
-}
-
-.secondary.pointing.menu .toc.item {
- display: none;
-}
-
-.sidebar .header a {
- color: white;
-}
-
-.sidebar .header a img {
- margin: 1em;
-}
-
-@media only screen and (max-width: 700px) {
- .ui.fixed.menu {
- display: none !important;
- }
- .secondary.pointing.menu .item:not(.logo),
- .secondary.pointing.menu .menu {
- display: none;
- }
- .secondary.pointing.menu .toc.item {
- display: block;
- }
- .masthead.segment {
- /*min-height: 350px;*/
- }
- .masthead h1.ui.header {
- font-size: 2em;
- margin-top: 1.5em;
- }
- .masthead h2 {
- margin-top: 0.5em;
- font-size: 1.5em;
- }
-}
-
-pre {
- overflow:inherit;
-}
-
-.hljs {
- padding: inherit;
-}
-
-.sidechains * {
- display: inline-block;
-}
-
-.sidechains * img {
- padding: 0;
- position: absolute;
- top: -22em;
-}
-
-.sidechains * img.spin {
- -webkit-animation: spin 30s infinite linear;
-}
-
-.sidechains * img.backspin {
- -webkit-animation: backspin 30s infinite linear;
-}
-
-@-webkit-keyframes spin {
- 0% {-webkit-transform: rotate(0deg);}
- 100% {-webkit-transform: rotate(360deg);}
-}
-@-webkit-keyframes backspin {
- 0% {-webkit-transform: rotate(360deg);}
- 100% {-webkit-transform: rotate(0deg);}
-}
-
-
-/* old styles */
-/* TODO: remove them */
-td.gutter {
- display: none;
-}
-
-.hidden.menu {
- display: none;
-}
-
-.masthead.segment {
- /*min-height: 700px;*/
- padding: 1em 0em;
-}
-.masthead .logo.item img {
- margin-right: 1em;
-}
-.masthead .ui.menu .ui.button {
- margin-left: 0.5em;
-}
-.masthead h1.ui.header {
- margin-top: 3em;
- margin-bottom: 0em;
- font-size: 4em;
- font-weight: normal;
-}
-.masthead h2 {
- font-size: 1.7em;
- font-weight: normal;
-}
-
-.ui.vertical.stripe {
- padding: 8em 0em;
-}
-.ui.vertical.stripe h3 {
- font-size: 2em;
-}
-.ui.vertical.stripe .button + h3,
-.ui.vertical.stripe p + h3 {
- margin-top: 3em;
-}
-.ui.vertical.stripe .floated.image {
- clear: both;
-}
-.ui.vertical.stripe p {
- font-size: 1.33em;
-}
-.ui.vertical.stripe .horizontal.divider {
- margin: 3em 0em;
-}
-
-.quote.stripe.segment {
- padding: 0em;
-}
-.quote.stripe.segment .grid .column {
- padding-top: 5em;
- padding-bottom: 5em;
-}
-
-.footer.segment {
- padding: 5em 0em;
-}
Our interest is mostly in the asset issuance implementation I've been discussing with Jorge. We're currently prototyping blockchain-based systems that track ownership of arbitrary asset classes. While we're also working with other technologies that apply asset issuance as a protocol on top of a blockchain network like OpenAssets, there are features required for some applications that we can only get out of native, consensus-enforced asset management.
- -Additionally, we use Confidential Transactions for (among other things) implementing a subset of the access controls in those systems, and having a working implementation of CT (which is compatible with asset management) is an huge boon.
- -Finally, we're exploring use of the two-way peg itself, demonstrated by Alpha, to build interoperability into these systems from the beginning. Cross-organizational compatibility of asset tracking systems comes for free as long as those systems are build on a chain with a sufficiently expressive scripting language and that's a big win.
-