Further thoughts on how to do childchains w/o an altcoin, only Bitcoin 2-way-peg:

I summarized main points here https://bitcointalk.org/index.php?topic=5214173.0 after writing this and following post in this thread

What's the incentive to burn Bitcoin to commit the childchain tip hash without getting something for it?
Perhaps to secure your own transaction or perhaps fees.

But then what's the incentive to pay more than minimum possible to achieve that?
Maybe competition for fees or only outpaying someone else who's censoring

What if we found a way to recover the costs of burning? Perhaps via child chain fees as a sort of pure fee based 0 new emission similar to endgame Bitcoin design.
Otherwise the reasons not to censor transactions of others or expend costs on validating/committing those become very small if you can't recover value to cover sunk costs.

Let's say for case of mainchain-BTC (Sats = 1e-8 BTC) and childchain-BTC (cSats = 1e-8 cBTC)


Both versions are valid so easiest design is to split all the childchain fees paid in cSats (2/3 to A, 1/3 to B) and Burner A's block version is picked deterministically (bc he burned most or hash of btc block gave him higher chance by burning more).
(but if they are solo committer, they get to recover all their childchain fees, is this an issue? not really. still costs from burning minimums and bitcoin chain fee)

Can't depend on fee market early on so need to have minimum fee rate set 1 cSat/byte (or different but well defined costs for bytes, op codes, so on)
Ofc, like on mainchain, growing larger through competition over capped block size from childchain's choice of bandwidth security considerations.

When they want to withdraw cSats and create childchain tx for it, future burners are required to allocate (let's say) 20% from total to filling withdrawals.

Let's examine a future block that includes earlier withdrawal signal on childchain
where 200 cSats was burned to withdraw 200 Sats on mainchain:


I think over time A would recover his withdrawal.
To deposit 100k Sats to childchain you burn 200k Sats to deposit unspendable address on Bitcoin independently (6x confirms?) and are simply required to be issued 200 cSats by nodes and childchain block commiters in order to be considered valid who are all Bitcoin-aware.
(I wish there was a way to do this by creating provably unspendable and prunable utxo on Bitcoin. There will definitely need to be safely above-dust minimums for Bitcoin utxo)

Like drivechain's truthcoin suggests, requiring long deposit and withdrawal times is acceptable for holding the peg, it's job is to secure the hardest childchain to Bitcoin direction to hold the price.

Trading cBTC vs BTC is separate and can be done via atomic swaps or even sidechain dex's via primites like atomic swaps or simple x-confirmations rules that are all Bitcoin aware and don't need to issue coins, just trade existing coins.

What's the vulnerabilities or attack vectors here?

There's no multisig-federation account to worry about, no oracles to collude, Bitcoin miners or nodes aren't required to do anything different.
Bitcoin miners could censor it like they could censor any account but miss out on fees, could try to obfuscate burning and childchain identifiable features until after confirmations (e.g. BMM work)

Rate of childchain recovery for the peg clearly depends on rate of burning, which itself depends likely on childchain fee income that would grow with popularity.
Hence users should understand the risks of deposits/withdrawals/holders scale inversely proportional to burn rates and childchain fees.

Childchain commiter's censorship of deposits would render those childchain blocks invalid.
Childchain commiter's censorship of withdrawals after the signal would render those childchain blocks invalid.
Childchain commiter's censorship of signaling desire to withdraw is possible
  - a deterministic random function to select burner based on amount burned would allow other burners to get their tx through eventually
  - actively expending mainchain burning costs on censoring a childchain would hurt their ability to recover value from other users fees and burners, worst case rendering cBTC near worthless until they are broke and/or leave
  - source of burning of mainchain Bitcoin is finite so eventually runs out, so can be waited out much like a malicious censorship attack on Bitcoin
  - censoring childchain tx would also cost commiters the childchain fees (i.e. bribes)
  - withdrawals could be signaled on Bitcoin mainchain OP_RETURN that all nodes are aware of and childchain block producer alone can't censor thus forcing attacker to include it or be treated as irrelevant invalid commit missing out on all fees

What if there are no fees because no child chain tx? No need to commit blocks then.
What if there are only fees from 1 party? They can burn minimum amount to commit that block, recovering their child chain fee but still not free from burning main chain.

What if there are multiple versions of childchains bc no nodes were online or got disconnected or eclipsed or withheld?

Probably biggest risk so let's consider what happens after you have both versions of blockchain.

The burn transactions of commits for blocks you didn't have before that were considered invalid/useless before would make sense and the selection rule based on burn amounts will lead you to a single chaintip.
If childchain commits are identifiable, you would be aware if you see commits for your chain that you do not have blocks for and can weight their importance based on amounts burnt.

What if attacker commits blocks with big burn amounts but withholds actual blocks until later?

- the payouts for withdrawals aren't really an issue since overpaying from burning sidestream doesn't cause a shortage

- using N-blocks irreversible checkpoints could cause childchain fragmentation and thus weak subjectivity (e.g. which of 2 valid childchains is real childchain named X? which dev picks? why?)

- using deterministic random functions based on Bitcoin mainchain's header's hash at same height as commit for selection of childchain tip would make the attack less reliable over time as attacker's childchain block is not guaranteed to be the winner and could cause all the burns from that point onward invalid as they would use invalid childchain tip and total loss. Attacker has no way to know bitcoin's future block header hash when burning Bitcoin for a commit transaction. If burning Bitcoin is detectable in general, unclear sources of burnt Bitcoin could be used as an early signal of a threat.
So attacker's best bet is to do a single large burn for a lower childchain blockheight at which ideally there was the least amount of non-attacker Bitcoin burnt? Still costs Bitcoin, and could ruin his chances to recover any childchain value from withdrawals. Consensus over the childchain tip would then be best determined by chaintip with most bitcoin burnt (a running total) and not simply childchain height which can wildly fluctuate in costs block to block.

- using the above, security of the chaintip, much like its ability to hold a peg, could be measured in total accumulated Bitcoin burned of valid commits so not rely on weak subjectivity. Users or businesses accepting assets on such a childchain should consider security significant after the total value of sent assets in that childblock is less than total value burnt at a later point's chaintip.

- the reasons for avoiding subjectivity and thus avoiding the use of N-blocks checkpoints appear similar.

- maybe pre-programmed early phase reliance on N-blocks checkpoints that disappear over time might be acceptable as means to bootstrap the network while it's very small and well connected?
  checkpoints can be triggered to permanently off when some total amount burned hits a number first time as well.
  checkpoints could also be determined using amount of known Bitcoin burnt instead of block height: e.g. after 1 BTC burnt after a block, that block is irreversible. that threshold increases each block by X% until it approaches 21M BTC and thus turns off (X=100% would mean it turns off in ~24 blocks based on 1*2^N=21m)

Basically could go with checkpoint security (similar to what PoS chains are forced to use) where you choose irreversible checkpoints at Z BTC burnt or N blocks thus inheriting reversibility-resistance properties of Bitcoin but face consequences of weak subjectivity if you're not well connected. (i.e. having to subjectively decide which version of irreversible childchain blocks is real one)

OR, more importantly, something PoS cannot do but much like PoW, is avoid weak subjectivity by always using childchain tip with most total Bitcoin burnt - very costly to fake metric from Bitcoin unfakeable costs of doing work in Proof of Work. It also still inherits censorship resistances of Bitcoin that allow permissionless entry into producing childchain blocks via Bitcoin transactions, also something PoS cannot guarantee since it doesn't have any unfakeable external sources of information. It's not going to inherit full Bitcoin resistance against reversibility and depend on it's own total-burn degree of security but it ALREADY relies on that for the peg to work and the ability to have the trust minimized bi-directional peg in the first place should be advantage enough to this method.

XCP-like fully embedded protocols don't have to worry about separate withheld childchain blocks as all data is available on Bitcoin chain and could require burning of bitcoin instead of altcoin for the backwards peg.
Tradeoff is it limits you to only using BTC tx to create separate state with limited space for verbose customizable contract code for programmable money within that state and high costs.

UTXO growth from many small withdrawals and burns would be improved via giving prunable ways to provably burn Bitcoin (like in OP_RETURN outputs) and ways to sign all inputs with a single signature via schnorr softfork to make those inputs far easier to batch.

No altcoin necessary in this design!!

Please poke holes in this!



For future considerations or open question I haven't had time to think through?

- what about reverse checkpoints? childchain blocks are not reversible until chaintip burns X Bitcoin total since that childblock? This would give some minimum cost to reversals and thus increased degree of security guarantees without being reliant on weak subjectivity. Attacker would have to burn either himself or wait for others to burn X Bitcoin before he can double spend where he also has to burn at least X Bitcoin to double spend preventing cheap and low cost reversals. The scale of X could be set always same as (or proportional to) the total amount of childchain cBTC in existence which is most that can be double spent not considering childchain possible tokens or w/e.

- I should include considerations of following for attackers: income from childchain fees, costs of withdrawals where lower withdrawal % sidestream might be better, and how withdrawals can be abused to recover some costs for choices of high withdrawal % sidestream