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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
