Author: Chris Stewart 2017-06-30 14:12:30
Published on: 2017-06-30T14:12:30+00:00
In this email thread, two individuals are discussing the details of their proposed sidechain schemes. One individual is concerned that the other's scheme may have a flaw: if an attacker pays a large fee to include an invalid block hash in the Bitcoin mainchain, would this block have to be included in the sidechain's blockchain forever? The other individual responds that, in their scheme, a sidechain cannot reorganize unless the mainchain reorganizes, so this should not be an issue. They also confirm that their proposal does include a single sidechain's hash twice in the block - once in the coinbase and once in the briber's separate transaction.The first individual asks why they need to explicitly commit to the previous block hash, as it seems it is implicitly committed to via SHA256(SHA256()). They suggest that commitment headers should not dictate the strict ordering of blocks on the sidechain. The second individual responds that they agree, and compares this to headers-first sync in Bitcoin Core. The conversation then shifts back to discussing the two sidechain proposals. The first individual suggests that their proposal is more space-efficient, as they only require one hash to be communicated plus an indicator byte and a ~2 byte counter for the ratchet, whereas the other proposal requires two hashes to be communicated. The second individual confirms that their proposal does include the sidechain's hash twice in the block but argues that there is no need for an indicator byte since the "previous block" hash can indicate which sidechain it is extending. They also ask if the ratchet should only appear in the sidechains currently doing some withdrawal.
Updated on: 2023-06-12T03:05:12.194415+00:00