* [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)
@ 2017-09-05 8:21 ZmnSCPxj
2017-09-05 17:06 ` Chris Stewart
[not found] ` <CAGL6+mG-jD6L5b0LepyotDd2+POjkrgV98c2fLFGM0ZokD4afA@mail.gmail.com>
0 siblings, 2 replies; 8+ messages in thread
From: ZmnSCPxj @ 2017-09-05 8:21 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 14664 bytes --]
Good morning all,
I have started to consider a unification of drivechains, blind merged mining, and sidechain SPV proofs to form yet another solution for sidechains.
Briefly, below are the starting assumptions:
1. SPV proofs are a short chain of sidechain block headers. This is used to prove to the mainchain that some fund has been locked in the sidechain and the mainchain should unlock an equivalent fund to the redeemer.
2. SPV proofs are large and even in compact form, are still large. We can instead use miner voting to control whether some mainchain fund should be unlocked. Presumably, the mainchain miners are monitoring that the sidechain is operating correctly and can know directly if a side-to-main peg is valid.
3. To maintain mainchain's security, we should use merged mining for sidechain mining rather than have a separate set of miners for mainchain and each sidechain.
4. A blockchain is just a singly-linked list. Genesis block is the NULL of the list. Additional blocks are added at the "front" of the singly-linked list. In Bitcoin, the Merkle tree root is the "pointer to head" and the previous block header ID is the "pointer to tail"; additional data like proof-of-work nonce, timestamp, and version bits exist but are not inherent parts of the blockchain linked list.
5. In addition to SPV proofs, we should also support reorg proofs. Basically, a reorg proof is a longer SPV proof that shows that a previous SPV proof is invalid.
--
With those, I present the idea, "sidechain headers in mainchain".
Let us modify Sztorc's OP_BRIBEVERIFY to require the below SCRIPT to use:
<Previous Sidechain Block Header Hash> <Current Sidechain Block Merkle Tree> <Sidechain ID> OP_BRIBEVERIFY OP_DROP OP_DROP OP_DROP
We also require that <Sidechain ID> be filled only once per mainchain block, as per the "blind" merge mining of Sztorc.
The key insight is that the <Previous Sidechain Block Header Hash> and <Current Sidechain Block Merkle Tree> are, in fact, the sidechain header. Concatenating those data and hashing them is the block header hash. Just as additional information (like extranonce and witness commitment) are put in the mainchain coinbase transaction, any additional information that the sidechain would have wanted to put in its header can be committed to in the sidechain's equivalent of a coinbase transaction (i.e. a sidechain header transaction).
(All three pieces of data can be "merged" into a single very long data push to reduce the number of OP_DROP operations, this is a detail)
Thus, the sidechain header chain (but not the block data) is embedded in the mainchain itself.
Thus, SPV proofs do not need to present new data to the mainchain. Instead, the mainchain already embeds the SPV proof, since the headers are already in the mainchain's blocks. All that is needed to unlock a lockbox is to provide some past sidechain header hash (or possibly just a previous mainchain block that contains the sidechain header hash, to make it easier for mainchain nodes to look up) and the Merkle path to a sidechain-side side-to-main peg transaction. If the sidechain header chain is "long enough" (for example, 288 sidechain block headers) then it is presumably SPV-safe to release the funds on the mainchain side.
--
Suppose a sidechain is reorganized, while a side-to-main peg transaction is in the sidechain that is to be reorganized away.
Let us make our example simpler by requiring an SPV proof to be only 4 sidechain block headers.
In the example below, small letters are sidechain block headers to be reorganized, large letters are sidechain block headers that will be judged valid. The sidechain block header "Aa" is the fork point. b' is the sidechain block containing the side-to-main peg that is lost.
Remember, for each mainchain block, only a single sidechain block header for a particular sidechain ID can be added.
The numbers in this example below are mainchain block height numbers.
0: Aa
1: b'
2: c
4: C
5: d
6: D
7: E
8: F
9: G
10: H <- b' side-to-main is judged as "not valid"
Basically, in case of a sidechain fork, the mainchain considers the longest chain to be valid if it is longer by the SPV proof required length. In the above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E) longer than the other sidechain fork that ended at d.
Mainchain nodes can validate this rule because the sidechain headers are embedded in the mainchain block's coinbase. Thus, mainchain fullnodes can validate this part of the sidechain rule of "longest work chain".
--
Suppose I wish to steal funds from sidechain, by stealing the sidechain lockboxes on the mainchain. I can use the OP_BRIBEVERIFY opcode which Sztorc has graciously provided to cause miners that are otherwise uninterested in the sidechain to put random block headers on a sidechain fork. Since the mainchain nodes are not going to verify the sidechain blocks (and are unaware of sidechain block formats in detail, just the sidechain block headers), I can get away with this on the mainchain.
However, to do so, I need to pay OP_BRIBEVERIFY multiple times. If our rule is 288 sidechain blocks for an SPV proof, then I need to pay OP_BRIBEVERIFY 288 times.
This can then be used to reduce the risk of theft. If lockboxes have a limit in value, or are fixed in value, that maximum/fixed value can be made small enough that paying OP_BRIBEVERIFY 288 times is likely to be more expensive than the lockbox value.
In addition, because only one sidechain header can be put for each mainchain header, I will also need to compete with legitimate users of the sidechain. Those users may devote some of their mainchain funds to keep the sidechain alive and valid by paying OP_BRIBEVERIFY themselves. They will reject my invalid sidechain block and build from a fork point before my theft attempt.
Because the rule is that the longest sidechain must beat the second-longest chain by 288 (or however many) sidechain block headers, legitimate users of the sidechain will impede my progress to successful theft. This makes it less attractive for me to attempt to steal from the sidechain.
The effect is that legitimate users are generating reorg proofs while I try to complete my SPV proof. As the legitimate users increase their fork, I need to keep up and overtake them. This can make it unattractive for me to steal from the sidechain.
Note however that we assume here that a side-to-main peg cannot occur more often than an entire SPV proof period.
--
Suppose I am a major power with influence over >51% of mainchain miners. What happens if I use that influence to cause the greatest damage to the sidechain?
I can simply ask my miners to create invalid side-to-main pegs that unlock the sidechain's lockboxes. With a greater than 51% of mainchain miners, I do not need to do anything like attempt to double-spend mainchain UTXO's. Instead, I can simply ask my miners to operate correctly to mainchain rules, but violate sidechain rules and steal the sidechain's lockboxes.
With greater than 51% of mainchain miners, I can extend my invalid sidechain until we reach the minimum necessary SPV proof. Assuming a two-way race between legitimate users of the sidechain and me, since I have >51% of mainchain miners, I can build the SPV proof faster than the legitimate users can create a reorg proof against me. This is precisely the same situation that causes drivechain to fail.
An alternative is to require that miners participating in sidechains to check the sidechain in full, and to consider mainchain blocks containing invalid sidechain headers as invalid. However, this greatly increases the amount of data that a full miner needs to be able to receive and verify, effectively increasing centralization risk for the mainchain.
--
The central idea of drivechain is simply that miners vote on the validity of sidechain side-to-main pegs. But this is effectively the same as miners - and/or OP_BRIBEVERIFY users - only putting valid sidechain block headers on top of valid sidechain block headers. Thus, if we instead use sidechain-headers-on-mainchain, the "vote" that the sidechain side-to-main peg is valid, is the same as a valid merge-mine of the sidechain.
SPV proofs are unnecessary in drivechain. In sidechain-header-on-mainchain, SPV proofs are already embedded in the mainchain. In drivechain, we ask mainchain fullnodes to trust miners. In sidechain-header-on-mainchain, mainchain fullnodes validate SPV proofs on the mainchain, without trusting anyone and without running sidechain software.
To validate the mainchain, a mainchain node keeps a data structure for each existing sidechain's fork.
When the sidechain is first created (perhaps by some special transaction that creates the sidechain's genesis block header and/or sidechain ID, possibly with some proof-of-burn to ensure that Bitcoin users do not arbitrarily create "useless" sidechains, but still allowing permissionless creation of sidechains), the mainchain node creates that data structure.
The data structure contains:
1. A sidechain block height, a large number initially 0 at sidechain genesis.
2. A side-to-main peg pointer, which may be NULL, and which also includes a block height at which the side-to-main peg is.
3. Links to other forks of the same sidechain ID, if any.
4. The top block header hash of the sidechain (sidechain tip).
If the sidechain's block header on a mainchain block is the direct descendant of the current sidechain tip, we just update the top block header hash and increment the block height.
If there is a side-to-main peg on the sidechain block header, if the side-to-main peg pointer is NULL, we initialize it and store the block height at which the side-to-main peg exists. If there is already a pending side-to-main peg, the mainchain block is judged invalid; thus for a 288-block region only one side-to-main peg can be done.
If, for a mainchain block, the sidechain header does NOT extend the most recent sidechain tip, we have detected a sidechain split condition. We then create a copy of the data structure for the tallest fork, then roll it back until we reach the split point; this rollback should also clear the side-to-main pointer, if we rollback to a blockheight below the side-to-main peg. Rollback is delimited: if after 288 sidechain headers we have not found the split point, the mainchain node rejects the mainchain block as invalid. Thus new sidechain forks cannot be started further back than our SPV proof size on the current longest sidechain. This allows powerful individuals to kill the sidechain by spending sufficient OP_BRIBEVERIFY to put random numbers on the sidechain headers, preventing the sidechain from ever operating correctly unless the sidechain accepts this loss of valid headers specially.
If there is only a single such structure for a sidechain, the sidechain is single-chained and not under attack. If the side-to-main peg pointer is non-null and the block height of the sidechain is 288 higher than the recorded block height, the side-to-main peg is added as a UTXO to our UTXO set.
If there are multiple such structures, the sidechain is in a contentious chainsplit condition (the "under attack" flag). A side-to-main peg is valid (becomes a UTXO) only if it exists (i.e. is the same) on all forks of the sidechain, and the shortest fork is 288 higher than the side-to-main peg height. This allows side-to-main pegs occurring before a contentious fork to be redeemed.
When there are multiple forks of a sidechain, the mainchain node keeps track of all of them. It sorts these forks by blockheight. The tallest chain is the reference. If some fork has height less than the height of the tallest chain minus 288 (the SPV proof size), the mainchain node drops it. Then that sidechain fork can no longer be extended; if it is the only fork lacking a particular side-to-main peg that exists on all the other forks, then the side-to-main peg becomes a UTXO. Once all contentious forks have been dropped, the sidechain returns to normal operation.
Note that this implies that side-to-main pegs that occur after a contentious sidechain fork will be delayed. This is to be expected as there is contention as to which chain is correct.
Note that this implies that sidechains must "run in lockstep" with mainchain. In particular, if the mainchain splits, the sidechain also splits. This allows two-way pegs to be asymmetrical, with sidechain fullnodes also being mainchain fullnodes, and immediate main-to-side pegs.
Finally, mainchain fullnodes validate side-to-main transfers, but do not need to run sidechain software. Users of sidechains are expected to protect themselves by ensuring they have mainchain miners that will do their best to protect the sidechain by only extending the valid longest sidechain, and by spending maincoin on OP_BRIBEVERIFY.
--
Suppose I want to use a sidechain, but I worry some troll will want to attack the sidechain via the OP_BRIBEVERIFY vulnerability. What can I do to protect my investment?
Perhaps a "protector" can be hired. Such a protector will be paid in sidechain funds, at a premium, for use of its mainchain funds. Such a protector will then use OP_BRIBEVERIFY on the mainchain to ensure a valid sidechain is extended on the mainchain. Indeed, this is exactly the "sidechain miner" envisioned by Sztorc in blind merged mining: sidechain users offer a sidecoin fee to these protectors, who spend maincoin to perform OP_BRIBEVERIFY on the mainchain. These protectors are paid in sidecoin in order to encourage them to protect the sidechain; they cannot spend sidecoin if the sidechain is successfully attacked.
Mainchain miners who wish to take on "protector" role can simply act as if they are being paid OP_BRIBEVERIFY for the sidechain they wish to protect. However, in particular mainchain miners should not treat sidechain rules at the same level as mainchain rules: even if a sidechain block header is judged to be invalid, the mainchain miner should not reject the mainchain block. It can only refuse to build a sidechain block header on top of an invalid sidechain block header. Only if a sidechain is sufficiently in use can we propose the sidechain's rules to be added to mainchain as mainchain rules in a softfork. Needless to say, miners taking on this role must have even larger datacenters in order to handle the increased bandwidth, storage, and processing load to handle both mainchain mining and sidechain protection.
--
The number 288 in all cases is a parameter that can be endlessly debated.
Regards,
ZmnSCPxj
[-- Attachment #2: Type: text/html, Size: 16974 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)
2017-09-05 8:21 [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs) ZmnSCPxj
@ 2017-09-05 17:06 ` Chris Stewart
2017-09-05 23:32 ` ZmnSCPxj
[not found] ` <CAGL6+mG-jD6L5b0LepyotDd2+POjkrgV98c2fLFGM0ZokD4afA@mail.gmail.com>
1 sibling, 1 reply; 8+ messages in thread
From: Chris Stewart @ 2017-09-05 17:06 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2361 bytes --]
Hi ZmnSCPxj,
Basically, in case of a sidechain fork, the mainchain considers the longest
> chain to be valid if it is longer by the SPV proof required length. In the
> above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E)
> longer than the other sidechain fork that ended at d.
>
> Mainchain nodes can validate this rule because the sidechain headers are
> embedded in the mainchain block's coinbase. Thus, mainchain fullnodes can
> validate this part of the sidechain rule of "longest work chain".
>
What happens in the case that the provided merkle tree hash has a invalid
transaction in it? Wouldn't this mean that the mainchain nodes would think
the longest work chain is the valid chain, and it would kill off any
consensus valid chain that sidechain miners are trying to construct? It
seems that a malicious miner could extend the chain to whatever the SPV
proof block height is and make it impossible for the chain to reorg after
that. I guess if that is a sufficiently long block waiting period it may
not be a realistic concern, but something to think about any way.
Just a side note -- I think it should be highly recommended that the
coinbase maturity period on the sidechain to be longer than 288 (or
whatever we decide on the parameter). This incentivizes the s:miners to
work together to extend the chain by working with other s:miners (otherwise
they won't be able to claim their bribes). If they do not work together
they will not be able to spend their s:coinbase_tx outputs until they
extend their own sidechain by 288 blocks meaning they need to tie up a
large amount of capital to go rogue on their fork.
Another interesting thing might be to use the OP_WITHDRAWPROOFVERIFY op code
<https://github.com/ElementsProject/elements/blob/elements-0.14.1/src/script/interpreter.cpp#L1420>
used in the elements project. Since the cannonical merkle root hashes are
included in the mainchain, we can provide a merkle proof to the bitcoin
blockchain to initiate a withdrawl from the sidechain. I wrote up a blog
post on how OP_WPV works here
<https://medium.com/@Chris_Stewart_5/what-can-go-wrong-when-transferring-coins-into-a-sidechain-with-op-withdrawproofverify-b2f49b02ab60>.
This allows us to prove that a transaction occurred on the sidechain to
lock up those funds.
-Chris
[-- Attachment #2: Type: text/html, Size: 2681 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)
2017-09-05 17:06 ` Chris Stewart
@ 2017-09-05 23:32 ` ZmnSCPxj
[not found] ` <Imrd8VOoGb1nVRp10RedyHoeJYajcvlhrwZQg9OtTk3vDMpc7DEFgw7CSQR_AiqNDwmMECV_fn53WY2i9NZcJKx2jtyd_psyQf6VNg3S7Gc=@protonmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: ZmnSCPxj @ 2017-09-05 23:32 UTC (permalink / raw)
To: Chris Stewart; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4267 bytes --]
Good morning Chris,
>>Basically, in case of a sidechain fork, the mainchain considers the longest chain to be valid if it is longer by the SPV proof required length. In the above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E) longer than the other sidechain fork that ended at d.
>>
>>Mainchain nodes can validate this rule because the sidechain headers are embedded in the mainchain block's coinbase. Thus, mainchain fullnodes can validate this part of the sidechain rule of "longest work chain".
>>
>What happens in the case that the provided merkle tree hash has a invalid transaction in it? Wouldn't this mean that the mainchain nodes would think the longest work chain is the valid chain, and it would kill off any consensus valid chain that sidechain miners are trying to construct? It seems that a malicious miner could extend the chain to whatever the SPV proof block height is and make it impossible for the chain to reorg after that. I guess if that is a sufficiently long block waiting period it may not be a realistic concern, but something to think about any way.
This is exactly the problem, and one which exists in a different form in any sidechain proposal. In drivechain, malicious mainchain miners may arbitrarily downvote any side-to-main peg even if the side-to-main peg is valid on the sidechain, with mainchain fullnodes unable to gainsay them. In original sidechain's SPV proofs, malicious mainchain miners may provide an invalid SPV proof and then censor any reorg proof against that SPV proof. In both of those cases, trust in the sidechain and the value of sidecoin necessarily takes a hit.
Of course, in both of those two cases, the hit is "temporary" and the sidechain could theoretically recover. In sidechain-headers-on-mainchain, the hit would permanently kill the sidechain.
The fact that sidechains are merge mined and cannot be mined off-mainchain makes sidechains entirely dependent on mainchain miner's support. I agree with Sztorc that sidechains must be merge mined entirely, otherwise the sidechain will effectively reduce mainchain security by pulling away potential miners from mainchain.
OP_BRIBEVERIFY, which is intended to allow sidechain miners/protectors to be a separate datacenter from miners, allows anyone with either enough hashpower or enough maincoin to disrupt a sidechain by spamming its slot with random hash values. With enough disruption, the sidechain may become unusable in drivechains, but may indeed be killed that way in sidechain-headers-on-mainchain.
>
>Just a side note -- I think it should be highly recommended that the coinbase maturity period on the sidechain to be longer than 288 (or whatever we decide on the parameter). This incentivizes the s:miners to work together to extend the chain by working with other s:miners (otherwise they won't be able to claim their bribes). If they do not work together they will not be able to spend their s:coinbase_tx outputs until they extend their own sidechain by 288 blocks meaning they need to tie up a large amount of capital to go rogue on their fork.
Yes, this seems sensible.
>
>Another interesting thing might be to use the OP_WITHDRAWPROOFVERIFY op code used in the elements project. Since the cannonical merkle root hashes are included in the mainchain, we can provide a merkle proof to the bitcoin blockchain to initiate a withdrawl from the sidechain. I wrote up a blog post on how OP_WPV works here. This allows us to prove that a transaction occurred on the sidechain to lock up those funds.
Yes.
Even without sidechain headers on mainchain, one might consider plain blind merged mining to have put even the "previous block hash" in the sidechain block coinbase transaction. Thus, one might consider that in blind merged mining, h' commitments are really merkle tree roots, and the previous block hash is encoded in a special sidechain transaction on one side of the merkle tree, while sidechain block transactions are encoded in the other side of the merkle tree root. This allows OP_WITHDRAWPROOFVERIFY to be used on blind merged mining, but without sidechain headers on mainchain, a compact SPV proof somehow must still be provided, or we are forced to use drivechain miner voting.
Regards,
ZmnSCPxj
[-- Attachment #2: Type: text/html, Size: 4784 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)
[not found] ` <Imrd8VOoGb1nVRp10RedyHoeJYajcvlhrwZQg9OtTk3vDMpc7DEFgw7CSQR_AiqNDwmMECV_fn53WY2i9NZcJKx2jtyd_psyQf6VNg3S7Gc=@protonmail.com>
@ 2017-09-08 20:14 ` Chris Stewart
2017-09-15 4:34 ` [bitcoin-dev] Fw: " ZmnSCPxj
1 sibling, 0 replies; 8+ messages in thread
From: Chris Stewart @ 2017-09-08 20:14 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 19165 bytes --]
Hi ZmnSCPxj,
However, a lockbox on one chain is a WT on the other
> chain. We can create a free lockbox on Ess, then use that lockbox as
> a WT on Tee, inflating TeeCoin.
I'm not sure if I follow what you are saying here. What do you mean by
'free lockbox'? I was assuming that I created an arbitrary blockchain, say
ChrisChain, that is NOT pegged to the bitcoin blockchain? I.e. the tokens
on ChrisChain are worthless. Then I create a lockbox on ChrisChain with my
worthless tokens and attempt to transfer them into TeeCoin's chain? However
this doesn't make sense with
However, this parameter is used to determine if it is a WT. Sidechain
> consensus should require that freely-created lockboxes set this
> parameter to 0, so that a side block that creates free lockboxes where
> this parameter is non-zero is an invalid side block. Then a sidechain
> will only treat a lockbox on another chain as a WT if the wtFlag
> parameter is nonzero. This way, freely-created lockboxes are not
> valid WT. Valid WT must lock actual, already unlocked coins, not
> create new locked coins.
>
because I could arbitrarily set this parameter to 0. It seems that a
sidechain upon inception should pay all of it's tokens to a single UTXO and
prevent minting of coins after that. I'm fairly certain this is what
elements does in it's genesis block.
The is unrelated to the problem above, but it will be a problem in
sidchain-headers-on-mainchain if we have a limited amount of mining slots
in the coinbase_tx output vector.
Let us assume we have a fixed set of sidechain slots in the coinbase output
vector, in this case 10. However there are 15 competing sidechains for
these 10 slots. It may be possible for sidechains (say 15 sidechains) to
compete indefinitely for these 10 slots -- causing indefinite forks. Let us
say sidechain 10 and sidechain 11 alternate block hashes in
coinbase_tx.vout[10] output. This means that a WT^ will never be considered
valid because it will appear to mainchain miners that there are competing
forks of the SAME sidechain, when in reality it is two unique sidechains
competing to mine the the limited coinbase output vector space.
-Chris
On Fri, Sep 8, 2017 at 9:56 AM, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> Good morning,
>
> Chris mentioned the use of OP_WITHDRAWPROOFVERIFY. I've come to realize
> that this is actually superior to use OP_WITHDRAWPROOFVERIFY with a
> sidechain-headers-on-mainchain approach.
>
> Briefly, a payment to OP_WITHDRAWPROOFVERIFY is an instruction to transfer
> value from the mainchain to a sidechain. Thus, a payment to
> OP_WITHDRAWPROOFVERIFY includes the sidechain to pay to, and a commitment
> to a sidechain address (or whatever is the equivalent to a sidechain
> address).
>
> Various OP_WITHDRAWPROOFVERIFY explanations exist. Most of them include
> OP_REORGPROOFVERIFY. With sidechain-headers-on-mainchain, however, there
> is
> no need for reorg proofs. This is because, the mainchain can see, in real
> time, which branch of the sidechain is getting extended. Thus if someone
> attempts to defraud a sidechain by forking the sidechain to an invalid
> state, sidechainers can immediately detect this on the mainchain and
> immediately act to prevent the invalid fork from being advanced. After
> all, a reorg proof is really just an SPV proof that is longer than some
> previous SPV proof, that shows that the previous SPV proof is incorrect,
> by showing that the block at the specified height of the WT is not present
> on a longer SPV proof.
>
> Since sidechain-headers-on-mainchain implies merge mining of sidechains,
> with no option to have independent proof-of-work of sidechains, the
> sidechain's entire history is recorded on the mainchain, visible to all
> mainchain nodes.
>
> --
>
> An advantage of sidechain-headers-on-mainchain is a side-to-side peg
> without
> passing through the mainchain.
> That is, a 2-way peg between any two chains, whether side or main.
>
> Sidechains supporting side-to-side transfer would require supporting
> OP_WITHDRAWPROOFVERIFY, but not any of the other parts of sidechains.
>
> We must consider a WT format (withdrawal transaction) that is compatible
> with an OP_WITHDRAWPROOFVERIFY Bitcoin transaction.
>
> ***That is, a lockbox UTXO on one chain is a WT on another chain.***
>
> Sidechains need not follow the mainchain format for its normal
> transactions, only for WT transactions that move coins across chains.
>
> For this, mainchain should also have its own "sidechain ID". Perhaps a
> sidechain ID of 0 would be appropriate for mainchain, as its status as
> mainchain.
>
> Suppose we have two sidechains, Ess and Tee, both of which support
> side-to-side pegs.
>
> An Ess fullnode is a Bitcoin fullnode, but an Ess fullnode is not
> necessarily a Tee fullnode, and vice versa.
>
> A lockbox redemption in sidechain-headers-on-mainchain is simply a spend of
> a lockbox, pointing to the sidechain header containing WT, the merkle tree
> path to the WT transaction from the h* commitment of the header, the output
> which locks, and so on as per usual OP_WITHDRAWPROOFVERIFY.
>
> Then a sidechain can create tokens from nothing, that are locked in a
> OP_WITHDRAWPROOFVERIFY lockbox; this is the only way to create sidecoin.
> When transferring into a sidechain from mainchain, or anywhere, the
> sidechain either creates tokens locked into OP_WITHDRAWPROOFVERIFY, or
> looks for an existing UTXO with OP_WITHDRAWPROOFVERIFY from the source
> chain and spends them (the latter is preferred as it is fewer
> transactions and less space on the sideblock, reducing sidechain fees).
>
> OP_WITHDRAWPROOFVERIFY on a sidechain would query the mainchain fullnodes.
> Whatever rules allow lockbox unlocking on mainchain, will also be the same
> rules that allow lockbox unlocking on sidechains.
> A mainchain RPC can even be made to simplify sidechain verification of
> side-to-side pegs, and to ensure that sidechains follow the same consensus
> rules for OP_WITHDRAWPROOFVERIFY.
>
> So if we want transfer TeeCoin to EssCoin, we spend into a
> OP_WITHDRAWPROOFVERIFY lockbox on Teechain pointing to Esschain (i.e. a
> Tee->Ess lockbox). This lockbox is itself a WT from the point of view of
> Esschain. On Esschain, we look for an existing Ess->Tee lockbox, or
> create a Ess->Tee lockbox of our own for a EssCoin fee. Then we create a
> spend of the Ess->Tee lockbox on Esschain, wait until spending is
> possible, and then post that transaction on Esschain.
>
> Again, with sidechain-headers-on-mainchain, reorg proofs are unnecessary,
> since any invalid chain should be quickly buried by a valid chain,
> unless the economic majority decides that a sidechain is not worth
> protecting.
>
> --
>
> All is not well, however. Remember, on a sidechain, we can create new
> sidecoin for free, provided they are in a lockbox. Unlocking that
> lockbox would require a valid WT on the chain that the lockbox is
> dedicated to. However, a lockbox on one chain is a WT on the other
> chain. We can create a free lockbox on Ess, then use that lockbox as
> a WT on Tee, inflating TeeCoin.
>
> Instead, we add an additional parameter, wtFlag, to
> OP_WITHDRAWPROOFVERIFY.
> This parameter is ignored by OP_WITHDRAWPROOFVERIFY opcode.
>
> However, this parameter is used to determine if it is a WT. Sidechain
> consensus should require that freely-created lockboxes set this
> parameter to 0, so that a side block that creates free lockboxes where
> this parameter is non-zero is an invalid side block. Then a sidechain
> will only treat a lockbox on another chain as a WT if the wtFlag
> parameter is nonzero. This way, freely-created lockboxes are not
> valid WT. Valid WT must lock actual, already unlocked coins, not
> create new locked coins.
>
> On Bitcoin, of course, this parameter must always be nonzero, since
> freely-created lockboxes are not allowed on mainchain, as asset
> issuance on mainchain is already fixed.
>
> --
>
> Let us now flesh out how WT and lockboxes look like. As we mentioned, a
> lockbox on one chain is a WT on the destination chain. Or to be more
> precise, what a destination chain sees as a WT, is a lockbox on the source
> chain.
>
> Thus, a lockbox is a Bitcoin-formatted transaction output paying to the
> scriptPubKey:
>
> <sidechain address commitment> <sidechain ID> OP_WITHDRAWPROOFVERIFY
>
> (assuming a softfork, additional OP_DROP operations may occur after
> OP_WITHDRAWPROOFVERIFY)
>
> Suppose the above lockbox is paid to in the Bitcoin mainchain, with the
> sidechain ID being the ID of Esschain. This is itself a WT transaction
> from the point of view of Esschain, on the principle that a lockbox on
> one chain is a WT on another chain.
>
> Assuming Esschain is a brand-new sidechain, it has no EssCoins yet. The
> sidechain allows the arbitrary creation of sidecoin provided the new
> sidecoins are in a lockbox whose sidechain address commitment is 0. So
> in Esschain, we create the same coins on a UTXO paying to the
> scriptPubKey:
>
> 0 0 OP_WITHDRAWPROOFVERIFY
>
> The first 0 is the sidechain address commitment, which is 0 since this
> output was not created by transferring to a sidechain; we
> reuse the sidechain address commitment as the wtFlag. The
> second 0 is the mainchain's ID. The above is a lockbox from the point of
> view of Esschain. It is not a WT on mainchain, however, because the
> sidechain address commitment is 0, which we use also as the wtFlag
> parameter.
>
> Now, how does a main-to-side peg work? After creating the above output on
> Esschain, we now spend the output with the below scriptSig:
>
> <mainchain output ID> <mainchain WT transaction> <merkle path to WT
> transaction> <mainchain block hash>
>
> On Esschain, OP_WITHDRAWPROOFVERIFY then verifies that the mainchain block
> hash is a valid past block of the mainchain, then locates the mainchain
> header. It then checks the merkle tree path to the mainchain WT
> transaction,
> confirming that the mainchain contains that transaction, and confirms that
> the
> indicated output is in fact, a payment to an OP_WITHDRAWPROOFVERIFY, which
> pushes the Esschain ID, and with a nonzero sidechain address commitment.
>
> (Esschain also needs to ensure that a single WT is not used to unlock
> multiple lockboxes on Esschain; the easiest way is to add it to a set,
> but this set cannot be pruned; other ways of ensuring only a WT is only
> used to unlock once might be designed)
>
> On Esschain, the sidechain does one final check: the transaction that
> spends
> an OP_WITHDRAWPROOFVERIFY must have an output that pays to the sidechain
> address committed to, and that output's value must be the same as the value
> locked in the mainchain.
>
> (for now, I think all lockboxes must have the same fixed amount, for
> simplicity)
>
> Now suppose we want to convert back our EssCoin to Bitcoin. We create a
> lockbox on Esschain, paying to the below:
>
> <bitcoin P2SH address> 0 OP_WITHDRAWPROOFVERIFY
>
> The bitcoin P2SH address is mainchain address commitment; for simplicity
> we just use P2SH on mainchain as it can encode any address. The 0 is the
> mainchain ID. The above Esschain lockbox is itself a WT from Esschain to
> mainchain.
>
> Then, we look for an unspent lockbox on Esschain whose sidechain ID is the
> Esschain ID. Note that we can select any lockbox with the correct
> sidechain ID, regardless of the sidechain address commitment it may have.
>
> Locating an appropriate mainchain lockbox for Esschain coins, we then
> provide the below scriptSig, paying out to the bitcoin P2SH address we
> selected:
>
> <esschain output ID> <esschain WT tx> <merkle path to WT tx> <esschain
> block header hash>
>
> On mainchain, we check that the indicated sidechain block header hash is a
> block header on the longest chain of Esschain. We check it has sufficient
> depth. Then we check if the merkle path to the WT tx is correct and goes
> to esschain WT tx. Finally, we check the indicated output ID, and check
> that
> it is indeed an Esschain lockbox dedicated to mainchain. Finally, we check
> that the transaction has an output that spends the lockbox amount to the
> specified bitcoin P2SH address.
>
> (similarly mainchain nees to ensure that the Esschain WT is only used
> once)
>
> The key insight here is that side-to-side pegs are just like side-to-main
> pegs. Suppose instead we want to transfer our coins from Esscoin to
> Teecoin. We would instead pay to the following lockbox on Esschain:
>
> <teecoin address commitment> <teechain ID> OP_WITHDRAWPROOFVERIFY
>
> Then a Teechain transaction spending some Tee->Ess lockbox (or a fresh
> lockbox if there are no Tee->Ess lockboxes on Teechain) is created.
> We proceed as if it were a side-to-main peg, except it is a peg to
> Teechain, either creating or unlocking TeeCoins. Indeed, mainchain
> fullnodes may even provide an RPC for checking OP_WITHDRAWPROOFVERIFY,
> so as to reduce risk that a sidechain breaks consensus due to buggy
> code.
>
> --
>
> All is still not well with side-to-side pegs, however.
>
> Suppose the economic majority decides that Esschain must die. Perhaps it
> has some irrecoverable security bug, perhaps it adds features that allow
> Esschain fullnodes to kill baby seals, perhaps a successful theft of
> Esschain lockboxes was performed and Esscoins are now functionally
> worthless. Killing a sidechain is done by bribing miners to put invalid
> values into h*, and thus stealing Bitcoin->Ess lockboxes.
>
> If Esschain dies, however, and the economic majority is not prepared to
> keep
> Esschain dead, it is possible to unlock Tee->Ess lockboxes on Teechain.
> Unlocking existing Tee->Ess lockboxes on Teechain is safe, since they
> represent coins that were locked into Bitcoin->Tee lockboxes. However,
> it is still possible to create "free" Tee->Ess lockboxes on Teechain, then
> provide an invalid Tee->Ess WT lockbox on the now-moribund Esschain to
> unlock the free Tee->Ess lockbox on Teechain, inflating TeeCoin value.
> Thus in the presence of side-to-side pegs, the death of even one sidechain
> represents the death of every other sidechain!
>
> Thus, to properly kill Esschain, the economic majority should spam the
> Esschain headers slot with a fixed value, say 0, forever. This makes it
> very difficult to create a Tee->Ess WT lockbox on Esschain, as you would
> now be able to reverse a one-way hash function.
>
> Alternatively, Teechain can softfork so that Tee->Ess lockboxes are no
> longer creatable or spendable. However, the death of Esschain requires
> that all other sidechains, including Youchain, Veechain, Dubyachain, and
> so on, to softfork similarly.
>
> Perhaps both can be done: first the economic majority wanting to kill
> Esschain starts spamming it with invalid spends of Bitcoin->Ess lockboxes,
> then when all Bitcoin->Ess lockboxes have been stolen, spam it with 0s
> until all other sidechains have banned free Ess lockboxes on their chains.
> Then, the economic majority can leave Esschain dead, and a later softfork
> of mainchain prevents Esschain from being extended and allows mainchain
> fullnodes to prune Esschain headers.
>
> --
>
> Thieves will still have the same difficulty stealing from sidechains, but
> now their payoff is increased. If a thief wants to steal Esschain
> lockboxes, then it is possible to pack an invalid Esschain block full of
> invalid WT to other chains. Even chains that don't have lockboxes to
> Esschain can create lockboxes to Esschain for free. Thus, instead of
> stealing only one lockbox at a time on mainchain, the thief can steal one
> lockbox on mainchain, and on every sidechain that supports side-to-side
> pegs, at a time. The risk/reward ratio may shift drastically in that case.
>
> However, this does mean that users of one chain must pay attention to
> attacks on other chains, not just the chain they use. If Teechain has no
> side-to-side pegs, then Teechain users will not care if Esschain is under
> attack. But if side-to-side pegs are allowed on Teechain, then Teechain
> users must also care about Esschain's health, as well as the health of
> every other sidechain in existence. Mainchain is protected since free
> lockboxes are not creatable on mainchain. Each sidechain is not; thus
> the user of any sidechain must also stand by users of every other
> sidechain, or else they all fall apart. Of course, this could more
> simply lead to "I will not use Teechain even if it would be useful to me,
> because if I use Teechain, I have to care about Esschain and Youchain and
> whatever."
>
> --
>
> Side-to-side pegs are useful to allow better liquidity and provide
> arbitrage quickly between sidechains, without having to pass through
> mainchain. Otherwise, Esscoin may be valued slightly lower than Bitcoin,
> then Teecoin valued slightly higher than Bitcoin, creating a larger
> difference between Esscoin and Teecoin values than what a full
> side-to-side peg could support. 2-way pegs from mainchain
> to sidechain stabilize sidecoin with respect to maincoin. Side-to-side
> pegs stabilize all sidecoins to all other sidecoins.
>
> Side-to-side pegs are enabled implicitly by sidechain-headers-on-
> mainchain,
> as all sidechain fullnodes must necessarily be mainchain fullnodes, and
> any mainchain fullnode can judge the validity of any WT from any sidechain
> without a miner voting period.
>
> Side-to-side pegs are a generalization of main-to-side and side-to-main
> pegs. A sidechain can simply implement OP_WITHDRAWPROOFVERIFY and allow
> free lockboxes, and that is sufficient for the sidechain to support
> imports of bitcoin from mainchain and from any other sidechain.
>
> Side-to-side pegs seem to imply that all pegs must have the same bitcoin
> value transferred. What that value must be, is something that may be
> debated endlessly.
>
> A side-to-side peg is a cut-through of a side-to-main peg from
> one sidechain into a main-to-side peg into another sidechain. If a
> withdrawal from side-to-main peg would be accepted by mainchain, then
> another sidechain could, in principle, accept a proof that would
> authorize a side-to-main peg directly as a side-to-side peg.
>
> Side-to-side pegs make attacks on sidechains more lucrative, as it
> becomes possible to print sidecoins by successfully attacking a
> different sidechain.
>
> Drivechain cannot implement side-to-side pegs, as WT validity is
> voted on by mainchain miners, and asking mainchain miners about
> side-to-side pegs requires mainchain miners to be aware of both
> sidechains. Sidechain-headers-on-mainchain publishes SPV proofs
> continuously to the mainchain, and since any sidechain fullnode is
> also a mainchain fullnode (since sidechains are mergemined), then
> every sidechain fullnode is automatically capable of accessing
> and verifying SPV proofs for every other sidechain.
>
> However, the pegging here seems less flexible than the pegging
> supported by drivechain. Drivechain lets pegs be any size, with
> miner voting being the basis of knowing how much money is owned
> by whom.
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #2: Type: text/html, Size: 24406 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Fwd: Sidechain headers on mainchain (unification of drivechains and spv proofs)
[not found] ` <E-mvls0CjntrzO4fWx84mYQtc0agV4KdP5QvX3ie3fLXC_YaB58OFvRYTRZhwo7vOn5OPQnlITFwOwyFgDAAZpQ2rvtCgsi-FCy95dBEP0s=@protonmail.com>
@ 2017-09-09 15:33 ` Paul Sztorc
2017-09-10 5:32 ` ZmnSCPxj
2017-09-10 5:33 ` ZmnSCPxj
0 siblings, 2 replies; 8+ messages in thread
From: Paul Sztorc @ 2017-09-09 15:33 UTC (permalink / raw)
To: Bitcoin Dev, ZmnSCPxj
Hi everyone,
I have some agreements and disagreements.
I agree with Zmn:
1. That the sidechain's header is fully defined by the bits of data
included in mainchain headers. These bits include "h*" (some hash that
is either of the header itself or side:hashMerkleRoot), something that
forces these hashes into a DAG-like structure (in Zmn's case, it is a
full hashPrevBlock, whereas for us it is just a tiny integer).
2. That "miner-voting" (for lack of better phrase) accomplishes the same
task as any SPV Proof of any kind.
3. That sidechains basically need to be merged-mined; to do otherwise,
there are marginal costs but really no marginal benefits.
However:
On 9/8/2017 12:19 AM, ZmnSCPxj wrote:
> Good morning.
>
> The obvious reply to all this is: what does
> sidechain-headers-on-mainchain do that drivechain cannot do cheaper?
>
> 1. Unifies merge mining (h* commitment) and WT^ validity voting.
> Merge-mined headers increase the vote on a WT^, by increasing the depth
> of the WT^.
1. I think it is a mistake for SHOM ("Sidechain Headers on Mainchain")
to "unify merged-mining and the WT^ validity voting". This causes the
SHOM to regress to mere extension blocks, and they therefore take on
many of the negative properties of extension blocks.
See: http://www.drivechain.info/faq/index.html#usefulness
> 2. Through OP_BRIBEVERIFY, the power to decide the validity of a
> sidechain lies in the economic majority rather than in the miners.
I don't think that this is true. 51% miner-group can pay bribes to
themselves, and orphan any block or txn that disagrees with them.
I also don't think that there is any meaningful difference between "what
the economic majority wants" and "what the miners do". To me it is a
blindingly obvious fact: miners are paid more, only if they increase the
value of { exchange_rate * ([x>=0] + txn_fees) }. This only increases if
Bitcoin is expected to be more objectively useful, and if its users
treasure its use sufficiently to warrant the payment of high tx fees.
When miners disagree with, for example, the bitcoin-dev mailing list,
this is because miners are attempting to guess what the economic
majority wants, and, in making this earnest attempt, miners believe that
the bitcoin-dev interest is different from the economic majority interest.
Obviously, I don't expect to change any minds on this list. After all,
(since no one dares oppose the economic majority), it is a smart
strategy to pretend that the economic majority always agrees with you.
And it is extra smart to avoid examining that belief too carefully.
2.2.1. This seems to imply that sidechains where unified merge-mining
> and WT^ voting are paid for by economic majority, effectively work as
> proof-of-stake. The difference here is that the proof does not have to
> cover itself (i.e. the stake being used to prove is outside the system
> which the proof is proving) and it is really more of a
> proof-of-sacrifice-of-stake, since the economic majority needs to pay
> (and thus lose) the stake for continued operation of the sidechain. One
> can argue that proof-of-work is just an instance of
> proof-of-sacrifice-of-stake anyway.
I agree with most of this, but I think in proof of work and proof of
stake the security guarantee is more reasonable.. In SHOM, there is no
reason to believe that the the quantity "total amount of money available
for withdrawal in a given time" will always be smaller than "sum of 288
bribes".
> 2.2.2. Miner behavior on Bcash and Bitcoin suggests to me that a good
> portion of the miners are interested more in short-term profits than
> long-term.
As long as some critical mass of investors exist, there is no difference
between short and long term profits. It is impossible for an investor to
act in a way that affects the long term, but does not immediately also
affect the short term.
> I have not seen a good explanation of how drivechain WT^ validity voting
> works in detail; my understanding is that a WT^ is presented on the
> mainchain, then a voting period is established during which miners
> somehow vote for whether the WT^ is valid or not, then the voting ends
> and a UTXO is somehow created. If it is in some Sztorc video, I
> apologize, I am unable to usefully view them.
Some documentation is here:
https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md
> --
>
> I think lockboxes should have fixed value. The value should be big
> enough that the cost of OP_WITHDRAWPROOFVERIFY is low. Particularly for
> privacy-oriented sidechains, all lockboxes having the same value will
> help tremendously in continuing obscurity after side-to-main transfers.
> However, I am uncertain whether sidechain or mainchain should enforce
> this fixed value. This parameter is something to be endlessly debated.
> Perhaps it should be sidechain that enforces this, but then mistakes
> could occur on the mainchain where some lockbox on the mainchain is
> deemed invalid on the sidechain, and cannot be unlocked validly except
> by destroying the sidechain.
I don't think this makes any sense, because it implies that the value of
288 block's worth of mainchain BTC transaction fees should always be
worth more than the entire market capitalization of Bitcoin.
Specifically, in this case, the error it introduces is that someone
could get around the fixed value by just using multiple sidechains. Then
the miners would just attack all the sidechains simultaneously. (And
these smaller sidechains would themselves have much smaller fees.)
>
> Sidechains may first be deployed as federated peg, then at some
> sidechain height the federation may announce a move to
> drivechain/sidechain-headers-on-mainchain. The move from federated to
> economic-majority-controlled would involve the federation moving its
> controlled lockboxes to OP_WITHDRAWPROOFVERIFY lockboxes.
Sergio likes this idea, but I think that this attitude represents a lack
of faith in the design. Either the design works or it does not. Either
the federation works or it does not.
>
> Sidechain hardforks would be very contentious, with only one clear
> winner that can unlock lockboxes. I think, part of sidechain design
> must be the understanding that sidechains must never be hardforked, and
> only softforked. Indeed, I am very much convinced that it is impossible
> to safely hardfork mainchain at all, and any block size increase must by
> necessity be softforked in.
This is already the case in what we have done...the only way to
guarantee that all clients report the same WT^ is if they are all
running softforks of the first version.
> The mechanism that supports sidechains supports any financial system,
> including centralized, non blockchain ones. The h* commitments can be
> made into commitments to the financial system's state. Basically, it is
> an implementation of CoinWitness, without using zk-SNARKs and instead
> using some mainchain-voted proof, where validity is judged by how much
> maincoin was sacrified to advance that proof. The supported financial
> system might even allow arbitrary execution of Turing-complete code for
> more vulnerabilities.
This is why I do not want ultra-easy, completely-permissionless creation
of sidechains. Miners (and therefore, users) may NOT desire the EXPECTED
behavior of the sidechain.
> Is there some spec for WT^ layout?
Yes, see above.
Thanks,
Paul
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Fwd: Sidechain headers on mainchain (unification of drivechains and spv proofs)
2017-09-09 15:33 ` [bitcoin-dev] Fwd: " Paul Sztorc
@ 2017-09-10 5:32 ` ZmnSCPxj
2017-09-10 5:33 ` ZmnSCPxj
1 sibling, 0 replies; 8+ messages in thread
From: ZmnSCPxj @ 2017-09-10 5:32 UTC (permalink / raw)
To: Paul Sztorc; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 10103 bytes --]
Good morning Paul,
Thank you for your consideration.
>> 1. Unifies merge mining (h* commitment) and WT^ validity voting.
>> Merge-mined headers increase the vote on a WT^, by increasing the depth
>> of the WT^.
>
>1. I think it is a mistake for SHOM ("Sidechain Headers on Mainchain")
>to "unify merged-mining and the WT^ validity voting". This causes the
>SHOM to regress to mere extension blocks, and they therefore take on
>many of the negative properties of extension blocks.
>
>See: http://www.drivechain.info/faq/index.html#usefulness
I don't see how this regress occurs. Perhaps I need more information on extension blocks.
>> 2. Through OP_BRIBEVERIFY, the power to decide the validity of a
>> sidechain lies in the economic majority rather than in the miners.
>
>I don"t think that this is true. 51% miner-group can pay bribes to
>themselves, and orphan any block or txn that disagrees with them.
Any miner that rejects a bribe from outside the miner-group in order to put their desired hash on the sidechain, values their desired hash more than the bribe to put a different hash. This rejection is a loss of potential proift, and other miners who accept the bribe gain the profit from it.
>I also don"t think that there is any meaningful difference between "what
>the economic majority wants" and "what the miners do". To me it is a
>blindingly obvious fact: miners are paid more, only if they increase the
>value of { exchange_rate * ([x>=0] + txn_fees) }. This only increases if
>Bitcoin is expected to be more objectively useful, and if its users
>treasure its use sufficiently to warrant the payment of high tx fees.
>
>When miners disagree with, for example, the bitcoin-dev mailing list,
>this is because miners are attempting to guess what the economic
>majority wants, and, in making this earnest attempt, miners believe that
>the bitcoin-dev interest is different from the economic majority interest.
>
>Obviously, I don"t expect to change any minds on this list. After all,
>(since no one dares oppose the economic majority), it is a smart
>strategy to pretend that the economic majority always agrees with you.
>And it is extra smart to avoid examining that belief too carefully.
Your last paragraph does not make sense to me. I suspect I have hit upon a nerve and will make no further comment on this sub-topic.
>>2.2.1. This seems to imply that sidechains where unified merge-mining
>> and WT^ voting are paid for by economic majority, effectively work as
>> proof-of-stake. The difference here is that the proof does not have to
>> cover itself (i.e. the stake being used to prove is outside the system
>> which the proof is proving) and it is really more of a
>> proof-of-sacrifice-of-stake, since the economic majority needs to pay
>> (and thus lose) the stake for continued operation of the sidechain. One
>> can argue that proof-of-work is just an instance of
>> proof-of-sacrifice-of-stake anyway.
>
>I agree with most of this, but I think in proof of work and proof of
>stake the security guarantee is more reasonable.. In SHOM, there is no
>reason to believe that the the quantity "total amount of money available
>for withdrawal in a given time" will always be smaller than "sum of 288
>bribes".
This is indeed the problem. SHOM, as it unifies merge mining and WT^ voting, also allows theft attempts, and once the money available for withdrawal exceeds the sum of 288 bribes, we enter a dollar auction game between the thief and the sidechain users: https://en.wikipedia.org/wiki/Dollar_auction
As thieves are expected to follow the simple greedy algorithm, sidechain death can be triggered by a single theft attempt.
Assuming potential thieves understand the dollar-auction irrationality, they may be disincentivized, as presumably there are more sidechain protectors than thieves, and the sidechain protectors can (we hope) all outbid the thief. But the problem is that this require rational behavior from thieves. Mere greedy algorithm, or disruption for the sake of disruption, would still collapse SHOM sidechains.
But given the many parallels between SHOM and drivechains: what happens if 26% of miners disrupt all sidechains by always downvoting WT^? In that case, sidechains still collapse as a whole, with practically the same effect as the SHOM thief.
We could limit the money available for withdrawal, but that weakens the side-to-main peg, reducing the value of the sidecoin relative to the maincoin.
The problem, to my mind, is that blind merge mining is pointless if it does not also allow voting on WT^. In the end, no matter how novel a sidechain may be, what is valued is the maincoin backing the sidecoin; that is the whole point of the two-way peg. A sidechain user may OP_BRIBEVERIFY valid sideblocks onto the mainchain, but if that user cannot vote on WT^ anyway, no matter how valid sideblocks committed on the mainchain, it would be pointless if the sidechain is attacked by mainchain miners. You may as well remove blind merge mining, as miners who must vote on WT^ will need to understand the sidechain validity rules anyway.
>> 2.2.2. Miner behavior on Bcash and Bitcoin suggests to me that a good
>> portion of the miners are interested more in short-term profits than
>> long-term.
>
>As long as some critical mass of investors exist, there is no difference
>between short and long term profits. It is impossible for an investor to
>act in a way that affects the long term, but does not immediately also
>affect the short term.
I do not quite follow. Can you expand more on this?
>> I have not seen a good explanation of how drivechain WT^ validity voting
>> works in detail; my understanding is that a WT^ is presented on the
>> mainchain, then a voting period is established during which miners
>> somehow vote for whether the WT^ is valid or not, then the voting ends
>> and a UTXO is somehow created. If it is in some Sztorc video, I
>> apologize, I am unable to usefully view them.
>Some documentation is here:
>https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md
Thank you.
>> I think lockboxes should have fixed value. The value should be big
>> enough that the cost of OP_WITHDRAWPROOFVERIFY is low. Particularly for
>> privacy-oriented sidechains, all lockboxes having the same value will
>> help tremendously in continuing obscurity after side-to-main transfers.
>> However, I am uncertain whether sidechain or mainchain should enforce
>> this fixed value. This parameter is something to be endlessly debated.
>> Perhaps it should be sidechain that enforces this, but then mistakes
>> could occur on the mainchain where some lockbox on the mainchain is
>> deemed invalid on the sidechain, and cannot be unlocked validly except
>> by destroying the sidechain.
>I don"t think this makes any sense, because it implies that the value of
>288 block"s worth of mainchain BTC transaction fees should always be
>worth more than the entire market capitalization of Bitcoin.
>
>Specifically, in this case, the error it introduces is that someone
>could get around the fixed value by just using multiple sidechains. Then
>the miners would just attack all the sidechains simultaneously. (And
>these smaller sidechains would themselves have much smaller fees.)
In order to attack multiple sidechains, bribing thieves must pay bribes for each sidechain being attacked. Even if a miner attacks, bribes for valid sidechains must be rejected by the miner, effectively reducing the miner's profits, and the bribes to be rejected must be for all the sidechains to be attacked.
If withdrawals have a fixed or maximum value, then the bribe a thief must be prepared to pay (or turn down, in the case of thieving miners) must be no more than the maximum value / 288.
Unfortunately, capping withdrawals weakens the side-to-main peg, which weakens the reason for even using SHOM. This is the true weakness of SHOM: it provides only a very weak side-to-main peg.
>>
>> Sidechains may first be deployed as federated peg, then at some
>> sidechain height the federation may announce a move to
>> drivechain/sidechain-headers-on-mainchain. The move from federated to
>> economic-majority-controlled would involve the federation moving its
>> controlled lockboxes to OP_WITHDRAWPROOFVERIFY lockboxes.
>Sergio likes this idea, but I think that this attitude represents a lack
>of faith in the design. Either the design works or it does not. Either
>the federation works or it does not.
I agree.
>>
>> Sidechain hardforks would be very contentious, with only one clear
>> winner that can unlock lockboxes. I think, part of sidechain design
>> must be the understanding that sidechains must never be hardforked, and
>> only softforked. Indeed, I am very much convinced that it is impossible
>> to safely hardfork mainchain at all, and any block size increase must by
>> necessity be softforked in.
>This is already the case in what we have done...the only way to
>guarantee that all clients report the same WT^ is if they are all
>running softforks of the first version.
Yes.
>> The mechanism that supports sidechains supports any financial system,
>> including centralized, non blockchain ones. The h* commitments can be
>> made into commitments to the financial system"s state. Basically, it is
>> an implementation of CoinWitness, without using zk-SNARKs and instead
>> using some mainchain-voted proof, where validity is judged by how much
>> maincoin was sacrified to advance that proof. The supported financial
>> system might even allow arbitrary execution of Turing-complete code for
>> more vulnerabilities.
>This is why I do not want ultra-easy, completely-permissionless creation
>of sidechains. Miners (and therefore, users) may NOT desire the EXPECTED
>behavior of the sidechain.
I am fine with some economic bond or proof-of-burn to start a sidechain. But I am opposed to any permissioned method of starting sidechains. To my mind, asking miners to install your software is already permissioned.
>> Is there some spec for WT^ layout?
>Yes, see above.
Thank you.
Regards,
ZmnSCPxj
[-- Attachment #2: Type: text/html, Size: 13338 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Fwd: Sidechain headers on mainchain (unification of drivechains and spv proofs)
2017-09-09 15:33 ` [bitcoin-dev] Fwd: " Paul Sztorc
2017-09-10 5:32 ` ZmnSCPxj
@ 2017-09-10 5:33 ` ZmnSCPxj
1 sibling, 0 replies; 8+ messages in thread
From: ZmnSCPxj @ 2017-09-10 5:33 UTC (permalink / raw)
To: Paul Sztorc; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 8004 bytes --]
Sent with [ProtonMail](https://protonmail.com) Secure Email.
> -------- Original Message --------
> Subject: Re: Fwd: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)
> Local Time: September 9, 2017 3:33 PM
> UTC Time: September 9, 2017 3:33 PM
> From: truthcoin@gmail•com
> To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>, ZmnSCPxj <ZmnSCPxj@protonmail•com>
>
> Hi everyone,
>
> I have some agreements and disagreements.
>
> I agree with Zmn:
>
> 1. That the sidechain"s header is fully defined by the bits of data
> included in mainchain headers. These bits include "h*" (some hash that
> is either of the header itself or side:hashMerkleRoot), something that
> forces these hashes into a DAG-like structure (in Zmn"s case, it is a
> full hashPrevBlock, whereas for us it is just a tiny integer).
> 2. That "miner-voting" (for lack of better phrase) accomplishes the same
> task as any SPV Proof of any kind.
> 3. That sidechains basically need to be merged-mined; to do otherwise,
> there are marginal costs but really no marginal benefits.
>
> However:
>
> On 9/8/2017 12:19 AM, ZmnSCPxj wrote:
>> Good morning.
>>
>> The obvious reply to all this is: what does
>> sidechain-headers-on-mainchain do that drivechain cannot do cheaper?
>>
>> 1. Unifies merge mining (h* commitment) and WT^ validity voting.
>> Merge-mined headers increase the vote on a WT^, by increasing the depth
>> of the WT^.
>
> 1. I think it is a mistake for SHOM ("Sidechain Headers on Mainchain")
> to "unify merged-mining and the WT^ validity voting". This causes the
> SHOM to regress to mere extension blocks, and they therefore take on
> many of the negative properties of extension blocks.
>
> See: http://www.drivechain.info/faq/index.html#usefulness
>
>> 2. Through OP_BRIBEVERIFY, the power to decide the validity of a
>> sidechain lies in the economic majority rather than in the miners.
>
> I don"t think that this is true. 51% miner-group can pay bribes to
> themselves, and orphan any block or txn that disagrees with them.
>
> I also don"t think that there is any meaningful difference between "what
> the economic majority wants" and "what the miners do". To me it is a
> blindingly obvious fact: miners are paid more, only if they increase the
> value of { exchange_rate * ([x>=0] + txn_fees) }. This only increases if
> Bitcoin is expected to be more objectively useful, and if its users
> treasure its use sufficiently to warrant the payment of high tx fees.
>
> When miners disagree with, for example, the bitcoin-dev mailing list,
> this is because miners are attempting to guess what the economic
> majority wants, and, in making this earnest attempt, miners believe that
> the bitcoin-dev interest is different from the economic majority interest.
>
> Obviously, I don"t expect to change any minds on this list. After all,
> (since no one dares oppose the economic majority), it is a smart
> strategy to pretend that the economic majority always agrees with you.
> And it is extra smart to avoid examining that belief too carefully.
>
> 2.2.1. This seems to imply that sidechains where unified merge-mining
>> and WT^ voting are paid for by economic majority, effectively work as
>> proof-of-stake. The difference here is that the proof does not have to
>> cover itself (i.e. the stake being used to prove is outside the system
>> which the proof is proving) and it is really more of a
>> proof-of-sacrifice-of-stake, since the economic majority needs to pay
>> (and thus lose) the stake for continued operation of the sidechain. One
>> can argue that proof-of-work is just an instance of
>> proof-of-sacrifice-of-stake anyway.
>
> I agree with most of this, but I think in proof of work and proof of
> stake the security guarantee is more reasonable.. In SHOM, there is no
> reason to believe that the the quantity "total amount of money available
> for withdrawal in a given time" will always be smaller than "sum of 288
> bribes".
>
>> 2.2.2. Miner behavior on Bcash and Bitcoin suggests to me that a good
>> portion of the miners are interested more in short-term profits than
>> long-term.
>
> As long as some critical mass of investors exist, there is no difference
> between short and long term profits. It is impossible for an investor to
> act in a way that affects the long term, but does not immediately also
> affect the short term.
>
>> I have not seen a good explanation of how drivechain WT^ validity voting
>> works in detail; my understanding is that a WT^ is presented on the
>> mainchain, then a voting period is established during which miners
>> somehow vote for whether the WT^ is valid or not, then the voting ends
>> and a UTXO is somehow created. If it is in some Sztorc video, I
>> apologize, I am unable to usefully view them.
> Some documentation is here:
> https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md
>
>> --
>>
>> I think lockboxes should have fixed value. The value should be big
>> enough that the cost of OP_WITHDRAWPROOFVERIFY is low. Particularly for
>> privacy-oriented sidechains, all lockboxes having the same value will
>> help tremendously in continuing obscurity after side-to-main transfers.
>> However, I am uncertain whether sidechain or mainchain should enforce
>> this fixed value. This parameter is something to be endlessly debated.
>> Perhaps it should be sidechain that enforces this, but then mistakes
>> could occur on the mainchain where some lockbox on the mainchain is
>> deemed invalid on the sidechain, and cannot be unlocked validly except
>> by destroying the sidechain.
> I don"t think this makes any sense, because it implies that the value of
> 288 block"s worth of mainchain BTC transaction fees should always be
> worth more than the entire market capitalization of Bitcoin.
>
> Specifically, in this case, the error it introduces is that someone
> could get around the fixed value by just using multiple sidechains. Then
> the miners would just attack all the sidechains simultaneously. (And
> these smaller sidechains would themselves have much smaller fees.)
>
>>
>> Sidechains may first be deployed as federated peg, then at some
>> sidechain height the federation may announce a move to
>> drivechain/sidechain-headers-on-mainchain. The move from federated to
>> economic-majority-controlled would involve the federation moving its
>> controlled lockboxes to OP_WITHDRAWPROOFVERIFY lockboxes.
> Sergio likes this idea, but I think that this attitude represents a lack
> of faith in the design. Either the design works or it does not. Either
> the federation works or it does not.
>>
>> Sidechain hardforks would be very contentious, with only one clear
>> winner that can unlock lockboxes. I think, part of sidechain design
>> must be the understanding that sidechains must never be hardforked, and
>> only softforked. Indeed, I am very much convinced that it is impossible
>> to safely hardfork mainchain at all, and any block size increase must by
>> necessity be softforked in.
> This is already the case in what we have done...the only way to
> guarantee that all clients report the same WT^ is if they are all
> running softforks of the first version.
>
>> The mechanism that supports sidechains supports any financial system,
>> including centralized, non blockchain ones. The h* commitments can be
>> made into commitments to the financial system"s state. Basically, it is
>> an implementation of CoinWitness, without using zk-SNARKs and instead
>> using some mainchain-voted proof, where validity is judged by how much
>> maincoin was sacrified to advance that proof. The supported financial
>> system might even allow arbitrary execution of Turing-complete code for
>> more vulnerabilities.
> This is why I do not want ultra-easy, completely-permissionless creation
> of sidechains. Miners (and therefore, users) may NOT desire the EXPECTED
> behavior of the sidechain.
>> Is there some spec for WT^ layout?
> Yes, see above.
>
> Thanks,
> Paul
[-- Attachment #2: Type: text/html, Size: 8873 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* [bitcoin-dev] Fw: Re: Sidechain headers on mainchain (unification of drivechains and spv proofs)
[not found] ` <Imrd8VOoGb1nVRp10RedyHoeJYajcvlhrwZQg9OtTk3vDMpc7DEFgw7CSQR_AiqNDwmMECV_fn53WY2i9NZcJKx2jtyd_psyQf6VNg3S7Gc=@protonmail.com>
2017-09-08 20:14 ` Chris Stewart
@ 2017-09-15 4:34 ` ZmnSCPxj
1 sibling, 0 replies; 8+ messages in thread
From: ZmnSCPxj @ 2017-09-15 4:34 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 17467 bytes --]
Good morning,
I'm re-sending this message below as it appears to have gotten lost before it reached cc: bitcoin-dev.
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.
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. 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.
Regards,
ZmnSCPxj
-------- Original Message --------
Subject: Re: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)
Local Time: September 8, 2017 10:56 PM
UTC Time: September 8, 2017 2:56 PM
From: ZmnSCPxj@protonmail•com
To: Chris Stewart <chris@suredbits•com>, CryptAxe <cryptaxe@gmail•com>, Paul Sztorc <truthcoin@gmail•com>
Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Good morning,
Chris mentioned the use of OP_WITHDRAWPROOFVERIFY. I've come to realize
that this is actually superior to use OP_WITHDRAWPROOFVERIFY with a
sidechain-headers-on-mainchain approach.
Briefly, a payment to OP_WITHDRAWPROOFVERIFY is an instruction to transfer
value from the mainchain to a sidechain. Thus, a payment to
OP_WITHDRAWPROOFVERIFY includes the sidechain to pay to, and a commitment
to a sidechain address (or whatever is the equivalent to a sidechain
address).
Various OP_WITHDRAWPROOFVERIFY explanations exist. Most of them include
OP_REORGPROOFVERIFY. With sidechain-headers-on-mainchain, however, there is
no need for reorg proofs. This is because, the mainchain can see, in real
time, which branch of the sidechain is getting extended. Thus if someone
attempts to defraud a sidechain by forking the sidechain to an invalid
state, sidechainers can immediately detect this on the mainchain and
immediately act to prevent the invalid fork from being advanced. After
all, a reorg proof is really just an SPV proof that is longer than some
previous SPV proof, that shows that the previous SPV proof is incorrect,
by showing that the block at the specified height of the WT is not present
on a longer SPV proof.
Since sidechain-headers-on-mainchain implies merge mining of sidechains,
with no option to have independent proof-of-work of sidechains, the
sidechain's entire history is recorded on the mainchain, visible to all
mainchain nodes.
--
An advantage of sidechain-headers-on-mainchain is a side-to-side peg without
passing through the mainchain.
That is, a 2-way peg between any two chains, whether side or main.
Sidechains supporting side-to-side transfer would require supporting
OP_WITHDRAWPROOFVERIFY, but not any of the other parts of sidechains.
We must consider a WT format (withdrawal transaction) that is compatible
with an OP_WITHDRAWPROOFVERIFY Bitcoin transaction.
***That is, a lockbox UTXO on one chain is a WT on another chain.***
Sidechains need not follow the mainchain format for its normal
transactions, only for WT transactions that move coins across chains.
For this, mainchain should also have its own "sidechain ID". Perhaps a
sidechain ID of 0 would be appropriate for mainchain, as its status as
mainchain.
Suppose we have two sidechains, Ess and Tee, both of which support
side-to-side pegs.
An Ess fullnode is a Bitcoin fullnode, but an Ess fullnode is not
necessarily a Tee fullnode, and vice versa.
A lockbox redemption in sidechain-headers-on-mainchain is simply a spend of
a lockbox, pointing to the sidechain header containing WT, the merkle tree
path to the WT transaction from the h* commitment of the header, the output
which locks, and so on as per usual OP_WITHDRAWPROOFVERIFY.
Then a sidechain can create tokens from nothing, that are locked in a
OP_WITHDRAWPROOFVERIFY lockbox; this is the only way to create sidecoin.
When transferring into a sidechain from mainchain, or anywhere, the
sidechain either creates tokens locked into OP_WITHDRAWPROOFVERIFY, or
looks for an existing UTXO with OP_WITHDRAWPROOFVERIFY from the source
chain and spends them (the latter is preferred as it is fewer
transactions and less space on the sideblock, reducing sidechain fees).
OP_WITHDRAWPROOFVERIFY on a sidechain would query the mainchain fullnodes.
Whatever rules allow lockbox unlocking on mainchain, will also be the same
rules that allow lockbox unlocking on sidechains.
A mainchain RPC can even be made to simplify sidechain verification of
side-to-side pegs, and to ensure that sidechains follow the same consensus
rules for OP_WITHDRAWPROOFVERIFY.
So if we want transfer TeeCoin to EssCoin, we spend into a
OP_WITHDRAWPROOFVERIFY lockbox on Teechain pointing to Esschain (i.e. a
Tee->Ess lockbox). This lockbox is itself a WT from the point of view of
Esschain. On Esschain, we look for an existing Ess->Tee lockbox, or
create a Ess->Tee lockbox of our own for a EssCoin fee. Then we create a
spend of the Ess->Tee lockbox on Esschain, wait until spending is
possible, and then post that transaction on Esschain.
Again, with sidechain-headers-on-mainchain, reorg proofs are unnecessary,
since any invalid chain should be quickly buried by a valid chain,
unless the economic majority decides that a sidechain is not worth
protecting.
--
All is not well, however. Remember, on a sidechain, we can create new
sidecoin for free, provided they are in a lockbox. Unlocking that
lockbox would require a valid WT on the chain that the lockbox is
dedicated to. However, a lockbox on one chain is a WT on the other
chain. We can create a free lockbox on Ess, then use that lockbox as
a WT on Tee, inflating TeeCoin.
Instead, we add an additional parameter, wtFlag, to
OP_WITHDRAWPROOFVERIFY.
This parameter is ignored by OP_WITHDRAWPROOFVERIFY opcode.
However, this parameter is used to determine if it is a WT. Sidechain
consensus should require that freely-created lockboxes set this
parameter to 0, so that a side block that creates free lockboxes where
this parameter is non-zero is an invalid side block. Then a sidechain
will only treat a lockbox on another chain as a WT if the wtFlag
parameter is nonzero. This way, freely-created lockboxes are not
valid WT. Valid WT must lock actual, already unlocked coins, not
create new locked coins.
On Bitcoin, of course, this parameter must always be nonzero, since
freely-created lockboxes are not allowed on mainchain, as asset
issuance on mainchain is already fixed.
--
Let us now flesh out how WT and lockboxes look like. As we mentioned, a
lockbox on one chain is a WT on the destination chain. Or to be more
precise, what a destination chain sees as a WT, is a lockbox on the source
chain.
Thus, a lockbox is a Bitcoin-formatted transaction output paying to the
scriptPubKey:
<sidechain address commitment> <sidechain ID> OP_WITHDRAWPROOFVERIFY
(assuming a softfork, additional OP_DROP operations may occur after
OP_WITHDRAWPROOFVERIFY)
Suppose the above lockbox is paid to in the Bitcoin mainchain, with the
sidechain ID being the ID of Esschain. This is itself a WT transaction
from the point of view of Esschain, on the principle that a lockbox on
one chain is a WT on another chain.
Assuming Esschain is a brand-new sidechain, it has no EssCoins yet. The
sidechain allows the arbitrary creation of sidecoin provided the new
sidecoins are in a lockbox whose sidechain address commitment is 0. So
in Esschain, we create the same coins on a UTXO paying to the
scriptPubKey:
0 0 OP_WITHDRAWPROOFVERIFY
The first 0 is the sidechain address commitment, which is 0 since this
output was not created by transferring to a sidechain; we
reuse the sidechain address commitment as the wtFlag. The
second 0 is the mainchain's ID. The above is a lockbox from the point of
view of Esschain. It is not a WT on mainchain, however, because the
sidechain address commitment is 0, which we use also as the wtFlag
parameter.
Now, how does a main-to-side peg work? After creating the above output on
Esschain, we now spend the output with the below scriptSig:
<mainchain output ID> <mainchain WT transaction> <merkle path to WT transaction> <mainchain block hash>
On Esschain, OP_WITHDRAWPROOFVERIFY then verifies that the mainchain block
hash is a valid past block of the mainchain, then locates the mainchain
header. It then checks the merkle tree path to the mainchain WT
transaction,
confirming that the mainchain contains that transaction, and confirms that
the
indicated output is in fact, a payment to an OP_WITHDRAWPROOFVERIFY, which
pushes the Esschain ID, and with a nonzero sidechain address commitment.
(Esschain also needs to ensure that a single WT is not used to unlock
multiple lockboxes on Esschain; the easiest way is to add it to a set,
but this set cannot be pruned; other ways of ensuring only a WT is only
used to unlock once might be designed)
On Esschain, the sidechain does one final check: the transaction that spends
an OP_WITHDRAWPROOFVERIFY must have an output that pays to the sidechain
address committed to, and that output's value must be the same as the value
locked in the mainchain.
(for now, I think all lockboxes must have the same fixed amount, for
simplicity)
Now suppose we want to convert back our EssCoin to Bitcoin. We create a
lockbox on Esschain, paying to the below:
<bitcoin P2SH address> 0 OP_WITHDRAWPROOFVERIFY
The bitcoin P2SH address is mainchain address commitment; for simplicity
we just use P2SH on mainchain as it can encode any address. The 0 is the
mainchain ID. The above Esschain lockbox is itself a WT from Esschain to
mainchain.
Then, we look for an unspent lockbox on Esschain whose sidechain ID is the
Esschain ID. Note that we can select any lockbox with the correct
sidechain ID, regardless of the sidechain address commitment it may have.
Locating an appropriate mainchain lockbox for Esschain coins, we then
provide the below scriptSig, paying out to the bitcoin P2SH address we
selected:
<esschain output ID> <esschain WT tx> <merkle path to WT tx> <esschain block header hash>
On mainchain, we check that the indicated sidechain block header hash is a
block header on the longest chain of Esschain. We check it has sufficient
depth. Then we check if the merkle path to the WT tx is correct and goes
to esschain WT tx. Finally, we check the indicated output ID, and check that
it is indeed an Esschain lockbox dedicated to mainchain. Finally, we check
that the transaction has an output that spends the lockbox amount to the
specified bitcoin P2SH address.
(similarly mainchain nees to ensure that the Esschain WT is only used
once)
The key insight here is that side-to-side pegs are just like side-to-main
pegs. Suppose instead we want to transfer our coins from Esscoin to
Teecoin. We would instead pay to the following lockbox on Esschain:
<teecoin address commitment> <teechain ID> OP_WITHDRAWPROOFVERIFY
Then a Teechain transaction spending some Tee->Ess lockbox (or a fresh
lockbox if there are no Tee->Ess lockboxes on Teechain) is created.
We proceed as if it were a side-to-main peg, except it is a peg to
Teechain, either creating or unlocking TeeCoins. Indeed, mainchain
fullnodes may even provide an RPC for checking OP_WITHDRAWPROOFVERIFY,
so as to reduce risk that a sidechain breaks consensus due to buggy
code.
--
All is still not well with side-to-side pegs, however.
Suppose the economic majority decides that Esschain must die. Perhaps it
has some irrecoverable security bug, perhaps it adds features that allow
Esschain fullnodes to kill baby seals, perhaps a successful theft of
Esschain lockboxes was performed and Esscoins are now functionally
worthless. Killing a sidechain is done by bribing miners to put invalid
values into h*, and thus stealing Bitcoin->Ess lockboxes.
If Esschain dies, however, and the economic majority is not prepared to keep
Esschain dead, it is possible to unlock Tee->Ess lockboxes on Teechain.
Unlocking existing Tee->Ess lockboxes on Teechain is safe, since they
represent coins that were locked into Bitcoin->Tee lockboxes. However,
it is still possible to create "free" Tee->Ess lockboxes on Teechain, then
provide an invalid Tee->Ess WT lockbox on the now-moribund Esschain to
unlock the free Tee->Ess lockbox on Teechain, inflating TeeCoin value.
Thus in the presence of side-to-side pegs, the death of even one sidechain
represents the death of every other sidechain!
Thus, to properly kill Esschain, the economic majority should spam the
Esschain headers slot with a fixed value, say 0, forever. This makes it
very difficult to create a Tee->Ess WT lockbox on Esschain, as you would
now be able to reverse a one-way hash function.
Alternatively, Teechain can softfork so that Tee->Ess lockboxes are no
longer creatable or spendable. However, the death of Esschain requires
that all other sidechains, including Youchain, Veechain, Dubyachain, and
so on, to softfork similarly.
Perhaps both can be done: first the economic majority wanting to kill
Esschain starts spamming it with invalid spends of Bitcoin->Ess lockboxes,
then when all Bitcoin->Ess lockboxes have been stolen, spam it with 0s
until all other sidechains have banned free Ess lockboxes on their chains.
Then, the economic majority can leave Esschain dead, and a later softfork
of mainchain prevents Esschain from being extended and allows mainchain
fullnodes to prune Esschain headers.
--
Thieves will still have the same difficulty stealing from sidechains, but
now their payoff is increased. If a thief wants to steal Esschain
lockboxes, then it is possible to pack an invalid Esschain block full of
invalid WT to other chains. Even chains that don't have lockboxes to
Esschain can create lockboxes to Esschain for free. Thus, instead of
stealing only one lockbox at a time on mainchain, the thief can steal one
lockbox on mainchain, and on every sidechain that supports side-to-side
pegs, at a time. The risk/reward ratio may shift drastically in that case.
However, this does mean that users of one chain must pay attention to
attacks on other chains, not just the chain they use. If Teechain has no
side-to-side pegs, then Teechain users will not care if Esschain is under
attack. But if side-to-side pegs are allowed on Teechain, then Teechain
users must also care about Esschain's health, as well as the health of
every other sidechain in existence. Mainchain is protected since free
lockboxes are not creatable on mainchain. Each sidechain is not; thus
the user of any sidechain must also stand by users of every other
sidechain, or else they all fall apart. Of course, this could more
simply lead to "I will not use Teechain even if it would be useful to me,
because if I use Teechain, I have to care about Esschain and Youchain and
whatever."
--
Side-to-side pegs are useful to allow better liquidity and provide
arbitrage quickly between sidechains, without having to pass through
mainchain. Otherwise, Esscoin may be valued slightly lower than Bitcoin,
then Teecoin valued slightly higher than Bitcoin, creating a larger
difference between Esscoin and Teecoin values than what a full
side-to-side peg could support. 2-way pegs from mainchain
to sidechain stabilize sidecoin with respect to maincoin. Side-to-side
pegs stabilize all sidecoins to all other sidecoins.
Side-to-side pegs are enabled implicitly by sidechain-headers-on-mainchain,
as all sidechain fullnodes must necessarily be mainchain fullnodes, and
any mainchain fullnode can judge the validity of any WT from any sidechain
without a miner voting period.
Side-to-side pegs are a generalization of main-to-side and side-to-main
pegs. A sidechain can simply implement OP_WITHDRAWPROOFVERIFY and allow
free lockboxes, and that is sufficient for the sidechain to support
imports of bitcoin from mainchain and from any other sidechain.
Side-to-side pegs seem to imply that all pegs must have the same bitcoin
value transferred. What that value must be, is something that may be
debated endlessly.
A side-to-side peg is a cut-through of a side-to-main peg from
one sidechain into a main-to-side peg into another sidechain. If a
withdrawal from side-to-main peg would be accepted by mainchain, then
another sidechain could, in principle, accept a proof that would
authorize a side-to-main peg directly as a side-to-side peg.
Side-to-side pegs make attacks on sidechains more lucrative, as it
becomes possible to print sidecoins by successfully attacking a
different sidechain.
Drivechain cannot implement side-to-side pegs, as WT validity is
voted on by mainchain miners, and asking mainchain miners about
side-to-side pegs requires mainchain miners to be aware of both
sidechains. Sidechain-headers-on-mainchain publishes SPV proofs
continuously to the mainchain, and since any sidechain fullnode is
also a mainchain fullnode (since sidechains are mergemined), then
every sidechain fullnode is automatically capable of accessing
and verifying SPV proofs for every other sidechain.
However, the pegging here seems less flexible than the pegging
supported by drivechain. Drivechain lets pegs be any size, with
miner voting being the basis of knowing how much money is owned
by whom.
Regards,
ZmnSCPxj
[-- Attachment #2: Type: text/html, Size: 23055 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-09-15 4:34 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-05 8:21 [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs) ZmnSCPxj
2017-09-05 17:06 ` Chris Stewart
2017-09-05 23:32 ` ZmnSCPxj
[not found] ` <Imrd8VOoGb1nVRp10RedyHoeJYajcvlhrwZQg9OtTk3vDMpc7DEFgw7CSQR_AiqNDwmMECV_fn53WY2i9NZcJKx2jtyd_psyQf6VNg3S7Gc=@protonmail.com>
2017-09-08 20:14 ` Chris Stewart
2017-09-15 4:34 ` [bitcoin-dev] Fw: " ZmnSCPxj
[not found] ` <CAGL6+mG-jD6L5b0LepyotDd2+POjkrgV98c2fLFGM0ZokD4afA@mail.gmail.com>
[not found] ` <wkUkYK_kYwSQx7JKzvgrfUiZYPLPrORMT_zBL5Tg-Spnr8tOyC_o4nZT4yFOD-FE86FvshRhWTfPblYqVmaZHi-VnMbKwpDDkAOjI8b9ap8=@protonmail.com>
[not found] ` <CAGL6+mGy7nTK1yA8YZcG59r9GZmVb+XWgQ1HjuPD4_pD7ZWThw@mail.gmail.com>
[not found] ` <6S1lfiXnljmQiZLorMOenBXGeve0K_LHKiCIZ75Gfc8LZieB7sq_bV_UWV-kJ197FYWywzDaQE7kOEqguYxlDFWZnLdzONhFZ7OAaWFgn64=@protonmail.com>
[not found] ` <CAGL6+mHqKXbm5nAHq+ghaTihCQQe0Rs1sd82ff2NiFKSq6Be+A@mail.gmail.com>
[not found] ` <yDICafWAbOJEbNvT9o8fltfCuJry5ZOLGwjQ-Ji6xfLjTP3XI_DXb8UbFJ6tA8jclqIEudFABAVEbXuLN9HLnN2nv-WTDE7q9vyjcALtufc=@protonmail.com>
[not found] ` <CAGL6+mGrN1m_zWs0KM4sfPHCdYUjuJ+E6hjVCFOtz2RoBDZyoQ@mail.gmail.com>
[not found] ` <E-mvls0CjntrzO4fWx84mYQtc0agV4KdP5QvX3ie3fLXC_YaB58OFvRYTRZhwo7vOn5OPQnlITFwOwyFgDAAZpQ2rvtCgsi-FCy95dBEP0s=@protonmail.com>
2017-09-09 15:33 ` [bitcoin-dev] Fwd: " Paul Sztorc
2017-09-10 5:32 ` ZmnSCPxj
2017-09-10 5:33 ` ZmnSCPxj
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox