Elements Project testnet sidechain alpha released

[gmaxwell]

I'm surprised that there isn't a thread on this yet.

I'm pleased to announce the publication of an experimental bitcoin-testnet sidechain and the software that implements it:

There is a fair amount of description and more coming at the Blockstream website: https://blockstream.com/developers/

... Including a video of a talk I prepared for the t the SF Bitcoin 'dev' meetup tonight (the video was pre-recorded, I think the presentation in the meetup went better but I work with what I've got. )

You can get the code and use the sidechain from the github repo: https://github.com/ElementsProject/elements


The sidechain includes some powerful new features... but beyond that, I hope that this opens up new avenues for experimentation and innovation In Bitcoin, providing a way to try things out without either rebooting the network effect or unduly imposing on people who aren't interested in the benefits (or risks) of something new.

[1714833230]

1714833230

[1714833230]

1714833230

[1714833230]

1714833230

[1714833230]

1714833230

[TierNolan]

What happens if you run the node with the -testnet flag ?

Is there a discussion of the various features? 

How does the peg work?  Is it two way (and only to/from testnet)?

The genesis block has 21 million coins (and no minting other than that)?  I assume that is linked to the peg, rather than being a dev fund or something?

Why only relative lock time?  Is that the system with the sequence number field reused?

What are signed blocks?

[BitUsher]

Great Work.

Looks really promising and I finished watching your video and am looking through the documentation now and will start testing.

Backup Video on youtube I found- https://www.youtube.com/watch?v=9pyVvq-vrrM

Slideshow -
https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf

Transcript -
http://diyhpl.us/wiki/transcripts/gmaxwell-sidechains-elements/

Reddit discussion -
https://www.reddit.com/r/Bitcoin/comments/393h73/blockstream_to_release_first_opensource_code_for/
https://www.reddit.com/r/Bitcoin/comments/393u2w/blockstream_unveils_muchawaited_first_sidechain/

More information -
https://www.blockstream.com/2015/06/08/714/
http://www.coindesk.com/blockstream-open-source-code-sidechains/

Some of the press has written some misleading information that this release has anything directly to do with the scalability problems which is at minimum misleading. It will be great to use these tools to test other implementations like the lightning network to address scalability however.

[Pieter Wuille]

Running with -testnet is default. You can run with -notestnet, but this will result in an error, as the "main chain" code is disabled in all but the unit tests.

For the features, look here: https://github.com/ElementsProject/elementsproject.github.io/blob/master/README.md

The peg is two-way, but relies on a federation of functionaries that hold the coins in multisig and verify transfers.

On the sidechain side, a 21M UTXO entry is awarded to the functionaries, who transfer coins out of it whenever transfers on the Bitcoin side into the sidechain happen.

Indeed.

Signed blocks are blocks where the proof-of-work mechanism is replaced with a traditional signature. Block creation, for test purposes, is done by a federation as well, rather than by mining.

[gmaxwell]

On the sidechain side, a 21M UTXO entry is awarded to the functionaries, who transfer coins out of it whenever transfers on the Bitcoin side into the sidechain happen.

Actually that is not the case for the testnet->sidechain direction.

Here is the transaction in the genesis block on elements-alpha:


{
    "txid" : "0377d218c36f5ee90244e660c387002296f3e4d5cac8fac8530b07e4d3241ccf",
    "version" : 1,
    "locktime" : 0,
    "fee" : 0.00000000,
    "vin" : [
        {
            "coinbase" : "04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f7 2206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73",
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 21000000.00000000,
            "serValue" : "00000000000000000000000000000000000000000000000000000775f05a0740000000",
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 9eac001049d5c38ece8996485418421f4a01e2d7 OP_WITHDRAWPROOFVERIFY",
                "hex" : "206fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000149eac001049d 5c38ece8996485418421f4a01e2d7b3",
                "type" : "withdraw"
            }
        }
    ]
}


On the testnet side, the fedpeg is used for lack of enough smart contract support in testnet;  on the alpha side it uses the actual 2WP in the network.

The spend of this output looks like this:


$ ./alpha-cli getrawtransaction eabe26aba6286e1ee439baedeb75094ec0bcdaf54ed9481d9d2183e8a6424755 1
{
    "txid" : "eabe26aba6286e1ee439baedeb75094ec0bcdaf54ed9481d9d2183e8a6424755",
    "version" : 1,
    "locktime" : 0,
    "fee" : 0.00000000,
    "vin" : [
        {
            "txid" : "0377d218c36f5ee90244e660c387002296f3e4d5cac8fac8530b07e4d3241ccf",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "75029000a1 81 5032534894ffbf32c1f1c0d3089b27c98fd991d5d7329ebd7d711223e2cde5a9417a1fa3e852c57 6 0300000042e1a5148148b706b3418aea0e2ed0fe49919439553429a828ed1a000000000091dab31 b6897b3a6e50ce86914ae69e4b7a39a600c128c9df5718a78075f8b32d7707555c0ff3f1abf1e48 92c708000010b163fb32006e22e1956cb50d15d75f55d68b36ce089bf56e8739b72c6b4c1c4910f 7e449e7779bfebe825eea12559dc48ec09633551c9516447be79b84b1113dbb09a75b2bd2031b19 fed231f5c8dda7a4aef7319a9dd6b0bba425bddc270f2c03bb2c3fad7fe303d2fff3adeec4d7771 5d78b642e8b0751346774e0e00f50901dd3779d3a7a7d9f04c3b8853c0fa94e9951fd18ccd2912d fbb53ea243ccc713d0e24e2be9e544119a73807c2188ee3b374bd8eb109537253102b61087b801b f8c9dc00bddca2cf573851222de0915b143c5048c625b515271771a9e19512e6ba455ed29011b2e f070015a2fe10fc4baa5478503e9853733168c240929e0ba05ff5247d55530039e023110c7411ff 46025947347162beff471e1c1ee9086f6b522234147d959379d4c03bd0ef089dbb7352c6bb8c273 4318ea14f3b0fbb04327cb2a0322955ea8b8c2511b62e5e3b055253164243b4572d6580bbda4858 cc00c53306fab6fbde55eea4f43e67a34ec2f461e259c4b2c47835e6d813efec769b8ef2ff38db2 5c32567e191886702a7e49277601465b68fe008b682b1885a20d44ba2021630ec49c17089b794c5 c7d1d5b6ee83f f494d11a11637bb2debec3f4f9d6c7c7efe9995a6a3f35fd46e6ea1edc3315f48115bc6526ca2d1 7b96480e2f065efe8c01d03b378dab1e2eab8da6dfd0a815117f6ff1fcad2597ed7b480dd2d04ff 1f1b00 2 01000000024be4804596920c8de3a710978a90afa750fa25a723e67c1bf2b8e1802aab7f4c00000 0006a47304402200975c7747078f5d6712ab5cb513c0a0eff039595b2a1866d631700fc469162c5 022046322286c516bd02c4f74b24009ee8d74c46778c0f391a0a030e632752be4fde012103eb6fb 439cb6c013f5d167d3a3c3effe4ae6a60a52887889782a24662ce12d789feffffffcaee3571009f f7d46b541350210c4e4b7a131218bb7fb474fb3c93599a2ea424000000007000483045022100b3c c96b65e3ef6887966ef6b65ea901b2259862d93b37e7bbc2cd7ea5f6130f702205107f1b523363c 5fe8488fb50b5c8a7981d8da09a1ddf6ac68e10f9591620a6a0125512102fc960ac6ef2feff9439 275bd187061908e738943c6517180ff954861e12f41d051aefeffffff02c08df602000000001976 a914164c0f03d4c8fe45596d1c67a1f8115196618da088ac00e1f5050000000017a91475e1f5636 6999fa7060d943a45ba42e065b097958759d30600 1 1 01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff270365d3061a4d696e656420627920416e74506f6f6c200f5fbc1620557570d70100000000b3 0800ffffffff0188cfb557000000001976a91424e677cc1018907dc33dc8945aa35d2704ef090a8 8ac00000000 1",
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 1.00000000,
            "serValue" : "000000000000000000000000000000000000000000000000000000000005f5e1000000",
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_IF 447333 bf01b88710b6023125379510ebd84b373bee88217c80739a1144e5e92b4ee2d0 1 0 9eac001049d5c38ece8996485418421f4a01e2d7 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_REORGPROOFVERIFY OP_ELSE 144 OP_NOP3 OP_DROP OP_HASH160 d7329ebd7d711223e2cde5a9417a1fa3e852c576 OP_EQUAL OP_ENDIF",
                "type" : "withdrawout"
            }
        },
        {
            "value" : 20999999.00000000,
            "serValue" : "00000000000000000000000000000000000000000000000000000775f054115f000000",
            "n" : 1,
            "scriptPubKey" : {
                "asm" : "6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 9eac001049d5c38ece8996485418421f4a01e2d7 OP_WITHDRAWPROOFVERIFY",
                "type" : "withdraw"
            }
        }
    ],
    "blockhash" : "a94f95cc47b444c10449c0eed51d895e4970560c4a1a9d15d46124858abc3afe",
    "confirmations" : 1708,
    "time" : 1433792346,
    "blocktime" : 1433792346
}


Which encodes a testnet transaction, which is pay-to-contracting the fedpeg federation, and shows it is a member in a testnet block, most of the separate pushes you see are it walking the hashtree for that membership proof.

[TierNolan]

Why have signed blocks?  Is that just to ensure (roughly) 10 mins per block, without having to worry that someone hammers the experiment with ASIC hashing power?

When you say that this could used to try out other stuff, do you mean that you may try out other hard forking changes or that the framework could be used by other side chains for different hard forking modifications? 

Does the withdraw proof opcode mean that outputs can work as accounts.  The 21 million from the genesis can be drawn down without spending the entire 21 million coins.

[gmaxwell]

Why have signed blocks?  Is that just to ensure (roughly) 10 mins per block, without having to worry that someone hammers the experiment with ASIC hashing power?

Use of the fedpeg results a centralized trust.  OTOH, it gives security properties that are pretty good so long as that trust isn't violated.  Since the system already can't survive a violation of trust there that why not use a similar mechanism for the consensus?-- and gain security against the fact that very small POW secured networks are really only secured by the indifference of attackers.   People do frequently reorg testnet, which can be pretty obnoxious if you're not in the mood for reorg testing.  There are also some interesting ideas in the area of combining both kinds of consensus that haven't been fully explored or implemented yet.

It should be noted that the fedpeg federation and the blocksigning federation don't have to be the same participants, though they are currently in elements-alpha right now. The software implementing the two things is separate apart from sharing some config files.

When you say that this could used to try out other stuff, do you mean that you may try out other hard forking changes or that the framework could be used by other side chains for different hard forking modifications? 

Both.

Does the withdraw proof opcode mean that outputs can work as accounts.  The 21 million from the genesis can be drawn down without spending the entire 21 million coins.

No, the withdraw proof is the sidechain verifying the deposit into it from testnet the fedpeg functionaries are not trusted for that.

[TierNolan]

Use of the fedpeg results a centralized trust.  OTOH, it gives security properties that are pretty good so long as that trust isn't violated.  Since the system already can't survive a violation of trust there that why not use a similar mechanism for the consensus?-- and gain security against the fact that very small POW secured networks are really only secured by the indifference of attackers.   People do frequently reorg testnet, which can be pretty obnoxious if you're not in the mood for reorg testing.  There are also some interesting ideas in the area of combining both kinds of consensus that haven't been fully explored or implemented yet.

Peer coin had a system where they had a centralised block signing server (plus POW and POS for minting).  The plan was to remove the centralised server once the coin had matured sufficiently.  I am not sure if they still have it though.  A quick Google suggests it went from enabled by default to disabled by default.

That could be a reasonable way for altcoins to defend themselves against hash surges.  The normal response is for difficulty to react more quickly.

Speaking of which, was the off-by-one bug in the difficulty code fixed?

When you say that this could used to try out other stuff, do you mean that you may try out other hard forking changes or that the framework could be used by other side chains for different hard forking modifications?  

Both.

So ... 1TB blocks then ?

In seriousness, I think the big one would be UTXO set commitments (or just commitments in general).  That isn't a hard-fork, but would be much nicer if it was implemented that way (with a tweak to the merkle tree).

No, the withdraw proof is the sidechain verifying the deposit into it from testnet the fedpeg functionaries are not trusted for that.

You have to prove that it is buried deeply enough in the testnet chain before accepting?  

Do the signers do any extra checking for re-orgs in testnet?

What is the point of the genesis block then?  This is to simulate minting fees?

Testnet to elements

You spend testnet coins to a special address

Elements to testnet

Federation releases testnet coins?

[gmaxwell]

Peer coin had a system where they had a centralised block signing server (plus POW and POS for minting).  The plan was to remove the centralised server once the coin had matured sufficiently.  I am not sure if they still have it though.  A quick Google suggests it went from enabled by default to disabled by default.

They gave it the unfortunate name "checkpoints" and it's required in the system and can't simply be turned off, and was made much more fundamental over time due to attacks. Also, it's a single key-- not a arbitrary scriptpubkey. 

Speaking of which, was the off-by-one bug in the difficulty code fixed?

well, its difficulty is always 1  sooo in some sense, yes?

In seriousness, I think the big one would be UTXO set commitments (or just commitments in general).  That isn't a hard-fork, but would be much nicer if it was implemented that way (with a tweak to the merkle tree).

Yep, I wanted to avoid a bunch of scaling tools in this first cut to avoid this getting confused as itself some kind of response in the blocksize debate. So the only scaling related thing in it is the witness separation. It would be a fine thing for playing with some kinds of scaling tools; though the scaling ideas that are mostly centered around incentives alignment, not so much.  Things like txo commitments, sure.

You have to prove that it is buried deeply enough in the testnet chain before accepting?  

It's required to be 10 blocks deep in testnet.

Do the signers do any extra checking for re-orgs in testnet?

All nodes that have a local testnet node running (and enabled, e.g. with the blindtrust=false) setting, will watch for reorgs and generate special fraud proof transactions to advise the network of a transfer that got reorged out. They have 144 blocks on the sidechain to get a proof in to abort the transfer.

What is the point of the genesis block then?  This is to simulate minting fees?

It basically fits the "coins can appear magically when a script says so" into the existing Bitcoin Core software framework... (consider handling reorgs and such).  It was _much_ easier to implement was "well the potential coins were there all along, but they were just held in care of this magic script" than coins that appear out of nowhere.

Testnet to elements

You spend testnet coins to a special address

More or less, you perform a little ritual to generate a pay-to-contract p2sh address for the fedpeg functionaries.  Then you pay to that. It's an ordinary (p2sh) testnet address. At this point the only person in the world that can determine you are moving coins to the sidechain is you, because only you know the nonce used in your contract.

Then after its 10 blocks deep on testnet you show up on the sidechain and present a proof that coins were paid on testnet according to the rules, and barring no reorgs that break things; the coins are yours 144 sidechain blocks later.

Elements to testnet
Federation releases testnet coins?

Right, you make a special transaction on the elements chain and the functionaries follow its instructions and pay according to it.

[TierNolan]

well, its difficulty is always 1  sooo in some sense, yes?

Ahh right.

All nodes that have a local testnet node running (and enabled, e.g. with the blindtrust=false) setting, will watch for reorgs and generate special fraud proof transactions to advise the network of a transfer that got reorged out. They have 144 blocks on the sidechain to get a proof in to abort the transfer.

Does the standard client do that?  Could a non-functionary produce the fraud proofs?

It basically fits the "coins can appear magically when a script says so" into the existing Bitcoin Core software framework... (consider handling reorgs and such).  It was _much_ easier to implement was "well the potential coins were there all along, but they were just held in care of this magic script" than coins that appear out of nowhere.

Does the federation just spend to a change address when done?

Then after its 10 blocks deep on testnet you show up on the sidechain and present a proof that coins were paid on testnet according to the rules, and barring no reorgs that break things; the coins are yours 144 sidechain blocks later.

So, 10 blocks is to protected against minor re-orgs on testnet and the 144 blocks is to protect against larger re-orgs and give a guaranteed window to broadcast the fraud proof.  There could be an added protection by requiring that 100 testnet blocks happen too.  That could be a federation rule though.

[gmaxwell]

Does the standard client do that?  Could a non-functionary produce the fraud proofs?

It can! And it was mandatory that it did until right before the release, when we realized that syncing a new testnet node took a really substantial majority of the time it took to set it up and try it out.  Under an assumption that many people who would like to play with it don't already have testnet running, we thought that the ability to try it out trumps security for this application and added a switch and defaulted it off.

You can turn it on if you have testnet running;  in your config for alpha, add rpcconnect=127.0.0.1 rpcconnectport=18332 tracksidechain=all txindex=1 blindtrust=true  (assumes the same rpcuser/rpcpassword).

Does the federation just spend to a change address when done?

Yes, well multisig change.

So, 10 blocks is to protected against minor re-orgs on testnet and the 144 blocks is to protect against larger re-orgs and give a guaranteed window to broadcast the fraud proof.  There could be an added protection by requiring that 100 testnet blocks happen too.  That could be a federation rule though.

Correct. The ten you can think mostly as dos resistance where someone makes one block forks constantly just to force the network to constantly deal with fraud proofs.

Miners (or in this case the blocksigning functionaries) who happen to be watching both networks could also IsStandard-like enforce the integrity of the initial spends, which would prevent most of the potential fraud from showing up in the first place; but the design is such that the two networks don't generally need to be monitoring each other, or only do so in very very loosely coupled way.

[TierNolan]

On the transfers, the functionaries are needed to release the funds back on testnet due to the lack of script support in the default script.

The problem is that testnet has no way to release funds that are transferred from elements to testnet.

Withdrawals requires

  <hash of script for extra check>: extra checks
  <genesis hash of source chain>: Where is the coin coming from
  <SPV proof>: Not done
  <coinbase of source block>: This is used to check block height
  <tx out index>: Claimed output
  <tx out>:  source transaction
  <merkle block>: This proves the transaction is in the block
  <contract>: tweak value (40 bytes)
  <extra check script>: actual extra check script
  <extra check script signature>: Signature to spend extra check script

Anyone can spend the "live" genesis transaction to get their testnet money (1BTC for me and 20999999 BTC as (multisig) change)? 

How are double spends of the genesis transaction handled?  Clients re-issue the claim transaction if someone else gets into the block chain first 

If multiple people per block try to move money to elements, then only one person per block can be handled.  I think the double spend protection 'shadow' would prevent people even receiving the other transactions that double spend.

The extra checks allow the person doing the withdrawal add in extra checks so only they can spend the withdrawn coins.

The system doesn't support hierarchical chains.  There is no way to move coin to a sub-chain and have it released with the withdrawal script? 

There would need to be an  <header1> .... <header100>  <depth> OP_BURIED system. 

Better, miners could be required to track header chains.  There would need to be some kind of DOS protection to prevent to many header chains from needing to be tracked.

What are the SPV proofs?  Is that not covered by the merkle-block?

[jl2012]

Although in the readme says it's not, I can't see why this is not an altcoin --- a pre-mined altcoin (indirectly) controlled by a group of functionaries, who guarantee to exchange the altcoin with real bitcoin in an exchange rate of 1:1. So it's a bitcoin bank like Coinbase, with much more functions and much better transparency, while still nothing could stop the functionaries to run with the real bitcoin.

There is a big difference between being a Bitcoin miner and an Elements functionary. In the latter case, you actively safekeep and distribute clients' money, just like a real bank. Functionaries, unless completely anonymous, may be accused of assisting money laundering. Who would like to be the next DPR or Charlie?

I think the project is really interesting but I can't see how it could work in mainnet due to the aforementioned reasons.

[TierNolan]

I think the project is really interesting but I can't see how it could work in mainnet due to the aforementioned reasons.

The underlying problem is that mainnet doesn't support the operations needed to handle the peg in both directions.

What would be nice would be a general way to handle side chains.

For example, depth checks "the transaction is buried at least 100 blocks deep".

That would be pretty heavy though (3.2kB per transfer). 

A system where miners can SPV monitor side chains would be more efficient in terms of proof length, but then the miners needs to know which chains to monitor.

[TierNolan]

I had a look at moving testnet BTC over and usability is low atm (command line scripts will do that ).

Ideally, there would be a "receive BTC from parent chain" button on alpha-QT and it would give you a testnet address to send to.

This means that the alpha client has the contact string.  It can then do the 2 wait steps without the user having to do it.  It would probably wait 12-15 testnet blocks before trying to claim the BTC.

It looks like all manual until the after the 144 timeout.  It doesn't even show after the accept stage (after 10 blocks).  

On the plus side, you guys seem to be going for more than 1 block per 10 mins?

What happens with the reorg proof?  If someone claims an output from testnet and the source is reorged out, who pays the reorg reward?

[johoe]

What happens with the reorg proof?  If someone claims an output from testnet and the source is reorged out, who pays the reorg reward?

If I understand the question correctly you want to avoid that someone moves money from main chain (testnet) to sidechain, then moves it around and back to the main chain and then double spends and invalidates the original testnet to sidechain transactions.

This could be achieved by having all testnet->sidechain transaction on which the side chain coin depended as input in the payout testnet transaction.  This way, if the testnet chain reorgs and an input transaction is double spent not only the dependent side chain transactions but also the payouts to the testnet are invalid. I'm not sure if sidechain elements does this.  This needs some bookkeeping.