Good morning,<br><br>I'm re-sending this message below as it appears to have gotten lost before it reached cc: bitcoin-dev.<br><br>Paul even replied to it and the reply reached on-list, so I'm re-sending it as others might have gotten confused about the discussion.<br><br>So far I've come to realize that sidechain-headers-on-mainchain/SHOM/SHM/driveproofs creates a very weak peg, and that only sidechain-only miners can take advantage of this weak peg.&nbsp; This is because, the fee paid by sidechain-only miners to mainchain miners will approach TRANSFERLIMIT / 288 to protect against theft, and then sidechain miners will be unable to replenish their maincoin stock (to pay for the blind-merge-mine) if they do not transfer *only* their sidecoins earned.<br><br><br>Regards,<br>ZmnSCPxj<br><div>-------- Original Message --------<br></div><div>Subject: Re: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)<br></div><div>Local Time: September 8, 2017 10:56 PM<br></div><div>UTC Time: September 8, 2017 2:56 PM<br></div><div>From: <a href="mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a><br></div><div>To: Chris Stewart &lt;<a href="mailto:chris@suredbits.com">chris@suredbits.com</a>&gt;, CryptAxe &lt;<a href="mailto:cryptaxe@gmail.com">cryptaxe@gmail.com</a>&gt;, Paul Sztorc &lt;<a href="mailto:truthcoin@gmail.com">truthcoin@gmail.com</a>&gt;<br></div><div>Bitcoin Protocol Discussion &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br></div><div><br></div><div>Good morning,<br></div><div><br></div><div>Chris mentioned the use of OP_WITHDRAWPROOFVERIFY.&nbsp; I've come to realize<br></div><div>that this is actually superior to use OP_WITHDRAWPROOFVERIFY with a<br></div><div>sidechain-headers-on-mainchain approach.<br></div><div><br></div><div>Briefly, a payment to OP_WITHDRAWPROOFVERIFY is an instruction to transfer<br></div><div>value from the mainchain to a sidechain.&nbsp; Thus, a payment to<br></div><div>OP_WITHDRAWPROOFVERIFY includes the sidechain to pay to, and a commitment<br></div><div>to a sidechain address (or whatever is the equivalent to a sidechain<br></div><div>address).<br></div><div><br></div><div>Various OP_WITHDRAWPROOFVERIFY explanations exist.&nbsp; Most of them include<br></div><div>OP_REORGPROOFVERIFY.&nbsp; With sidechain-headers-on-mainchain, however, there is<br></div><div>no need for reorg proofs.&nbsp; This is because, the mainchain can see, in real<br></div><div>time, which branch of the sidechain is getting extended.&nbsp; Thus if someone<br></div><div>attempts to defraud a sidechain by forking the sidechain to an invalid<br></div><div>state, sidechainers can immediately detect this on the mainchain and<br></div><div>immediately act to prevent the invalid fork from being advanced.&nbsp; After<br></div><div>all, a reorg proof is really just an SPV proof that is longer than some<br></div><div>previous SPV proof, that shows that the previous SPV proof is incorrect,<br></div><div>by showing that the block at the specified height of the WT is not present<br></div><div>on a longer SPV proof.<br></div><div><br></div><div>Since sidechain-headers-on-mainchain implies merge mining of sidechains,<br></div><div>with no option to have independent proof-of-work of sidechains, the<br></div><div>sidechain's entire history is recorded on the mainchain, visible to all<br></div><div>mainchain nodes.<br></div><div><br></div><div>--<br></div><div><br></div><div>An advantage of sidechain-headers-on-mainchain is a side-to-side peg without<br></div><div>passing through the mainchain.<br></div><div>That is, a 2-way peg between any two chains, whether side or main.<br></div><div><br></div><div>Sidechains supporting side-to-side transfer would require supporting<br></div><div>OP_WITHDRAWPROOFVERIFY, but not any of the other parts of sidechains.<br></div><div><br></div><div>We must consider a WT format (withdrawal transaction) that is compatible<br></div><div>with an OP_WITHDRAWPROOFVERIFY Bitcoin transaction.<br></div><div><br></div><div>***That is, a lockbox UTXO on one chain is a WT on another chain.***<br></div><div><br></div><div>Sidechains need not follow the mainchain format for its normal<br></div><div>transactions, only for WT transactions that move coins across chains.<br></div><div><br></div><div>For this, mainchain should also have its own "sidechain ID".&nbsp; Perhaps a<br></div><div>sidechain ID of 0 would be appropriate for mainchain, as its status as<br></div><div>mainchain.<br></div><div><br></div><div>Suppose we have two sidechains, Ess and Tee, both of which support<br></div><div>side-to-side pegs.<br></div><div><br></div><div>An Ess fullnode is a Bitcoin fullnode, but an Ess fullnode is not<br></div><div>necessarily a Tee fullnode, and vice versa.<br></div><div><br></div><div>A lockbox redemption in sidechain-headers-on-mainchain is simply a spend of<br></div><div>a lockbox, pointing to the sidechain header containing WT, the merkle tree<br></div><div>path to the WT transaction from the h* commitment of the header, the output<br></div><div>which locks, and so on as per usual OP_WITHDRAWPROOFVERIFY.<br></div><div><br></div><div>Then a sidechain can create tokens from nothing, that are locked in a<br></div><div>OP_WITHDRAWPROOFVERIFY lockbox; this is the only way to create sidecoin.<br></div><div>When transferring into a sidechain from mainchain, or anywhere, the<br></div><div>sidechain either creates tokens locked into OP_WITHDRAWPROOFVERIFY, or<br></div><div>looks for an existing UTXO with OP_WITHDRAWPROOFVERIFY from the source<br></div><div>chain and spends them (the latter is preferred as it is fewer<br></div><div>transactions and less space on the sideblock, reducing sidechain fees).<br></div><div><br></div><div>OP_WITHDRAWPROOFVERIFY on a sidechain would query the mainchain fullnodes.<br></div><div>Whatever rules allow lockbox unlocking on mainchain, will also be the same<br></div><div>rules that allow lockbox unlocking on sidechains.<br></div><div>A mainchain RPC can even be made to simplify sidechain verification of<br></div><div>side-to-side pegs, and to ensure that sidechains follow the same consensus<br></div><div>rules for OP_WITHDRAWPROOFVERIFY.<br></div><div><br></div><div>So if we want transfer TeeCoin to EssCoin, we spend into a<br></div><div>OP_WITHDRAWPROOFVERIFY lockbox on Teechain pointing to Esschain (i.e. a<br></div><div>Tee-&gt;Ess lockbox).&nbsp; This lockbox is itself a WT from the point of view of<br></div><div>Esschain.&nbsp; On Esschain, we look for an existing Ess-&gt;Tee lockbox, or<br></div><div>create a Ess-&gt;Tee lockbox of our own for a EssCoin fee.&nbsp; Then we create a<br></div><div>spend of the Ess-&gt;Tee lockbox on Esschain, wait until spending is<br></div><div>possible, and then post that transaction on Esschain.<br></div><div><br></div><div>Again, with sidechain-headers-on-mainchain, reorg proofs are unnecessary,<br></div><div>since any invalid chain should be quickly buried by a valid chain,<br></div><div>unless the economic majority decides that a sidechain is not worth<br></div><div>protecting.<br></div><div><br></div><div>--<br></div><div><br></div><div>All is not well, however.&nbsp; Remember, on a sidechain, we can create new<br></div><div>sidecoin for free, provided they are in a lockbox.&nbsp; Unlocking that<br></div><div>lockbox would require a valid WT on the chain that the lockbox is<br></div><div>dedicated to.&nbsp; However, a lockbox on one chain is a WT on the other<br></div><div>chain.&nbsp; We can create a free lockbox on Ess, then use that lockbox as<br></div><div>a WT on Tee, inflating TeeCoin.<br></div><div><br></div><div>Instead, we add an additional parameter, wtFlag, to<br></div><div>OP_WITHDRAWPROOFVERIFY.<br></div><div>This parameter is ignored by OP_WITHDRAWPROOFVERIFY opcode.<br></div><div><br></div><div>However, this parameter is used to determine if it is a WT.&nbsp; Sidechain<br></div><div>consensus should require that freely-created lockboxes set this<br></div><div>parameter to 0, so that a side block that creates free lockboxes where<br></div><div>this parameter is non-zero is an invalid side block.&nbsp; Then a sidechain<br></div><div>will only treat a lockbox on another chain as a WT if the wtFlag<br></div><div>parameter is nonzero.&nbsp; This way, freely-created lockboxes are not<br></div><div>valid WT.&nbsp; Valid WT must lock actual, already unlocked coins, not<br></div><div>create new locked coins.<br></div><div><br></div><div>On Bitcoin, of course, this parameter must always be nonzero, since<br></div><div>freely-created lockboxes are not allowed on mainchain, as asset<br></div><div>issuance on mainchain is already fixed.<br></div><div><br></div><div>--<br></div><div><br></div><div>Let us now flesh out how WT and lockboxes look like.&nbsp; As we mentioned, a<br></div><div>lockbox on one chain is a WT on the destination chain.&nbsp; Or to be more<br></div><div>precise, what a destination chain sees as a WT, is a lockbox on the source<br></div><div>chain.<br></div><div><br></div><div>Thus, a lockbox is a Bitcoin-formatted transaction output paying to the<br></div><div>scriptPubKey:<br></div><div><br></div><div>&nbsp; &lt;sidechain address commitment&gt; &lt;sidechain ID&gt; OP_WITHDRAWPROOFVERIFY<br></div><div><br></div><div>(assuming a softfork, additional OP_DROP operations may occur after<br></div><div>OP_WITHDRAWPROOFVERIFY)<br></div><div><br></div><div>Suppose the above lockbox is paid to in the Bitcoin mainchain, with the<br></div><div>sidechain ID being the ID of Esschain.&nbsp; This is itself a WT transaction<br></div><div>from the point of view of Esschain, on the principle that a lockbox on<br></div><div>one chain is a WT on another chain.<br></div><div><br></div><div>Assuming Esschain is a brand-new sidechain, it has no EssCoins yet.&nbsp; The<br></div><div>sidechain allows the arbitrary creation of sidecoin provided the new<br></div><div>sidecoins are in a lockbox whose sidechain address commitment is 0.&nbsp; So<br></div><div>in Esschain, we create the same coins on a UTXO paying to the<br></div><div>scriptPubKey:<br></div><div><br></div><div>&nbsp; 0 0 OP_WITHDRAWPROOFVERIFY<br></div><div><br></div><div>The first 0 is the sidechain address commitment, which is 0 since this<br></div><div>output was not created by transferring to a sidechain; we<br></div><div>reuse the sidechain address commitment as the wtFlag.&nbsp; The<br></div><div>second 0 is the mainchain's ID.&nbsp; The above is a lockbox from the point of<br></div><div>view of Esschain.&nbsp; It is not a WT on mainchain, however, because the<br></div><div>sidechain address commitment is 0, which we use also as the wtFlag<br></div><div>parameter.<br></div><div><br></div><div>Now, how does a main-to-side peg work?&nbsp; After creating the above output on<br></div><div>Esschain, we now spend the output with the below scriptSig:<br></div><div><br></div><div>&nbsp; &lt;mainchain output ID&gt; &lt;mainchain WT transaction&gt; &lt;merkle path to WT transaction&gt; &lt;mainchain block hash&gt;<br></div><div><br></div><div>On Esschain, OP_WITHDRAWPROOFVERIFY then verifies that the mainchain block<br></div><div>hash is a valid past block of the mainchain, then locates the mainchain<br></div><div>header.&nbsp; It then checks the merkle tree path to the mainchain WT<br></div><div>transaction,<br></div><div>confirming that the mainchain contains that transaction, and confirms that<br></div><div>the<br></div><div>indicated output is in fact, a payment to an OP_WITHDRAWPROOFVERIFY, which<br></div><div>pushes the Esschain ID, and with a nonzero sidechain address commitment.<br></div><div><br></div><div>(Esschain also needs to ensure that a single WT is not used to unlock<br></div><div>multiple lockboxes on Esschain; the easiest way is to add it to a set,<br></div><div>but this set cannot be pruned; other ways of ensuring only a WT is only<br></div><div>used to unlock once might be designed)<br></div><div><br></div><div>On Esschain, the sidechain does one final check: the transaction that spends<br></div><div>an OP_WITHDRAWPROOFVERIFY must have an output that pays to the sidechain<br></div><div>address committed to, and that output's value must be the same as the value<br></div><div>locked in the mainchain.<br></div><div><br></div><div>(for now, I think all lockboxes must have the same fixed amount, for<br></div><div>simplicity)<br></div><div><br></div><div>Now suppose we want to convert back our EssCoin to Bitcoin.&nbsp; We create a<br></div><div>lockbox on Esschain, paying to the below:<br></div><div><br></div><div>&nbsp; &lt;bitcoin P2SH address&gt; 0 OP_WITHDRAWPROOFVERIFY<br></div><div><br></div><div>The bitcoin P2SH address is mainchain address commitment; for simplicity<br></div><div>we just use P2SH on mainchain as it can encode any address.&nbsp; The 0 is the<br></div><div>mainchain ID.&nbsp; The above Esschain lockbox is itself a WT from Esschain to<br></div><div>mainchain.<br></div><div><br></div><div>Then, we look for an unspent lockbox on Esschain whose sidechain ID is the<br></div><div>Esschain ID.&nbsp; Note that we can select any lockbox with the correct<br></div><div>sidechain ID, regardless of the sidechain address commitment it may have.<br></div><div><br></div><div>Locating an appropriate mainchain lockbox for Esschain coins, we then<br></div><div>provide the below scriptSig, paying out to the bitcoin P2SH address we<br></div><div>selected:<br></div><div><br></div><div>&nbsp; &lt;esschain output ID&gt; &lt;esschain WT tx&gt; &lt;merkle path to WT tx&gt; &lt;esschain block header hash&gt;<br></div><div><br></div><div>On mainchain, we check that the indicated sidechain block header hash is a<br></div><div>block header on the longest chain of Esschain.&nbsp; We check it has sufficient<br></div><div>depth.&nbsp; Then we check if the merkle path to the WT tx is correct and goes<br></div><div>to esschain WT tx.&nbsp; Finally, we check the indicated output ID, and check that<br></div><div>it is indeed an Esschain lockbox dedicated to mainchain.&nbsp; Finally, we check<br></div><div>that the transaction has an output that spends the lockbox amount to the<br></div><div>specified bitcoin P2SH address.<br></div><div><br></div><div>(similarly mainchain nees to ensure that the Esschain WT is only used<br></div><div>once)<br></div><div><br></div><div>The key insight here is that side-to-side pegs are just like side-to-main<br></div><div>pegs.&nbsp; Suppose instead we want to transfer our coins from Esscoin to<br></div><div>Teecoin.&nbsp; We would instead pay to the following lockbox on Esschain:<br></div><div><br></div><div>&nbsp; &lt;teecoin address commitment&gt; &lt;teechain ID&gt; OP_WITHDRAWPROOFVERIFY<br></div><div><br></div><div>Then a Teechain transaction spending some Tee-&gt;Ess lockbox (or a fresh<br></div><div>lockbox if there are no Tee-&gt;Ess lockboxes on Teechain) is created.<br></div><div>We proceed as if it were a side-to-main peg, except it is a peg to<br></div><div>Teechain, either creating or unlocking TeeCoins.&nbsp; Indeed, mainchain<br></div><div>fullnodes may even provide an RPC for checking OP_WITHDRAWPROOFVERIFY,<br></div><div>so as to reduce risk that a sidechain breaks consensus due to buggy<br></div><div>code.<br></div><div><br></div><div>--<br></div><div><br></div><div>All is still not well with side-to-side pegs, however.<br></div><div><br></div><div>Suppose the economic majority decides that Esschain must die.&nbsp; Perhaps it<br></div><div>has some irrecoverable security bug, perhaps it adds features that allow<br></div><div>Esschain fullnodes to kill baby seals, perhaps a successful theft of<br></div><div>Esschain lockboxes was performed and Esscoins are now functionally<br></div><div>worthless.&nbsp; Killing a sidechain is done by bribing miners to put invalid<br></div><div>values into h*, and thus stealing Bitcoin-&gt;Ess lockboxes.<br></div><div><br></div><div>If Esschain dies, however, and the economic majority is not prepared to keep<br></div><div>Esschain dead, it is possible to unlock Tee-&gt;Ess lockboxes on Teechain.<br></div><div>Unlocking existing Tee-&gt;Ess lockboxes on Teechain is safe, since they<br></div><div>represent coins that were locked into Bitcoin-&gt;Tee lockboxes.&nbsp; However,<br></div><div>it is still possible to create "free" Tee-&gt;Ess lockboxes on Teechain, then<br></div><div>provide an invalid Tee-&gt;Ess WT lockbox on the now-moribund Esschain to<br></div><div>unlock the free Tee-&gt;Ess lockbox on Teechain, inflating TeeCoin value.<br></div><div>Thus in the presence of side-to-side pegs, the death of even one sidechain<br></div><div>represents the death of every other sidechain!<br></div><div><br></div><div>Thus, to properly kill Esschain, the economic majority should spam the<br></div><div>Esschain headers slot with a fixed value, say 0, forever.&nbsp; This makes it<br></div><div>very difficult to create a Tee-&gt;Ess WT lockbox on Esschain, as you would<br></div><div>now be able to reverse a one-way hash function.<br></div><div><br></div><div>Alternatively, Teechain can softfork so that Tee-&gt;Ess lockboxes are no<br></div><div>longer creatable or spendable.&nbsp; However, the death of Esschain requires<br></div><div>that all other sidechains, including Youchain, Veechain, Dubyachain, and<br></div><div>so on, to softfork similarly.<br></div><div><br></div><div>Perhaps both can be done: first the economic majority wanting to kill<br></div><div>Esschain starts spamming it with invalid spends of Bitcoin-&gt;Ess lockboxes,<br></div><div>then when all Bitcoin-&gt;Ess lockboxes have been stolen, spam it with 0s<br></div><div>until all other sidechains have banned free Ess lockboxes on their chains.<br></div><div>Then, the economic majority can leave Esschain dead, and a later softfork<br></div><div>of mainchain prevents Esschain from being extended and allows mainchain<br></div><div>fullnodes to prune Esschain headers.<br></div><div><br></div><div>--<br></div><div><br></div><div>Thieves will still have the same difficulty stealing from sidechains, but<br></div><div>now their payoff is increased.&nbsp; If a thief wants to steal Esschain<br></div><div>lockboxes, then it is possible to pack an invalid Esschain block full of<br></div><div>invalid WT to other chains.&nbsp; Even chains that don't have lockboxes to<br></div><div>Esschain can create lockboxes to Esschain for free.&nbsp; Thus, instead of<br></div><div>stealing only one lockbox at a time on mainchain, the thief can steal one<br></div><div>lockbox on mainchain, and on every sidechain that supports side-to-side<br></div><div>pegs, at a time.&nbsp; The risk/reward ratio may shift drastically in that case.<br></div><div><br></div><div>However, this does mean that users of one chain must pay attention to<br></div><div>attacks on other chains, not just the chain they use.&nbsp; If Teechain has no<br></div><div>side-to-side pegs, then Teechain users will not care if Esschain is under<br></div><div>attack.&nbsp; But if side-to-side pegs are allowed on Teechain, then Teechain<br></div><div>users must also care about Esschain's health, as well as the health of<br></div><div>every other sidechain in existence.&nbsp; Mainchain is protected since free<br></div><div>lockboxes are not creatable on mainchain.&nbsp; Each sidechain is not; thus<br></div><div>the user of any sidechain must also stand by users of every other<br></div><div>sidechain, or else they all fall apart.&nbsp; Of course, this could more<br></div><div>simply lead to "I will not use Teechain even if it would be useful to me,<br></div><div>because if I use Teechain, I have to care about Esschain and Youchain and<br></div><div>whatever."<br></div><div><br></div><div>--<br></div><div><br></div><div>Side-to-side pegs are useful to allow better liquidity and provide<br></div><div>arbitrage quickly between sidechains, without having to pass through<br></div><div>mainchain.&nbsp; Otherwise, Esscoin may be valued slightly lower than Bitcoin,<br></div><div>then Teecoin valued slightly higher than Bitcoin, creating a larger<br></div><div>difference between Esscoin and Teecoin values than what a full<br></div><div>side-to-side peg could support.&nbsp; 2-way pegs from mainchain<br></div><div>to sidechain stabilize sidecoin with respect to maincoin.&nbsp; Side-to-side<br></div><div>pegs stabilize all sidecoins to all other sidecoins.<br></div><div><br></div><div>Side-to-side pegs are enabled implicitly by sidechain-headers-on-mainchain,<br></div><div>as all sidechain fullnodes must necessarily be mainchain fullnodes, and<br></div><div>any mainchain fullnode can judge the validity of any WT from any sidechain<br></div><div>without a miner voting period.<br></div><div><br></div><div>Side-to-side pegs are a generalization of main-to-side and side-to-main<br></div><div>pegs.&nbsp; A sidechain can simply implement OP_WITHDRAWPROOFVERIFY and allow<br></div><div>free lockboxes, and that is sufficient for the sidechain to support<br></div><div>imports of bitcoin from mainchain and from any other sidechain.<br></div><div><br></div><div>Side-to-side pegs seem to imply that all pegs must have the same bitcoin<br></div><div>value transferred.&nbsp; What that value must be, is something that may be<br></div><div>debated endlessly.<br></div><div><br></div><div>A side-to-side peg is a cut-through of a side-to-main peg from<br></div><div>one sidechain into a main-to-side peg into another sidechain.&nbsp; If a<br></div><div>withdrawal from side-to-main peg would be accepted by mainchain, then<br></div><div>another sidechain could, in principle, accept a proof that would<br></div><div>authorize a side-to-main peg directly as a side-to-side peg.<br></div><div><br></div><div>Side-to-side pegs make attacks on sidechains more lucrative, as it<br></div><div>becomes possible to print sidecoins by successfully attacking a<br></div><div>different sidechain.<br></div><div><br></div><div>Drivechain cannot implement side-to-side pegs, as WT validity is<br></div><div>voted on by mainchain miners, and asking mainchain miners about<br></div><div>side-to-side pegs requires mainchain miners to be aware of both<br></div><div>sidechains.&nbsp; Sidechain-headers-on-mainchain publishes SPV proofs<br></div><div>continuously to the mainchain, and since any sidechain fullnode is<br></div><div>also a mainchain fullnode (since sidechains are mergemined), then<br></div><div>every sidechain fullnode is automatically capable of accessing<br></div><div>and verifying SPV proofs for every other sidechain.<br></div><div><br></div><div>However, the pegging here seems less flexible than the pegging<br></div><div>supported by drivechain.&nbsp; Drivechain lets pegs be any size, with<br></div><div>miner voting being the basis of knowing how much money is owned<br></div><div>by whom.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div>