Theoretical design possible today presented for review. Please be brutal.

Permissionless Bitcoin Childchains w/ Continuous Proof of Bitcoin Burn (CPoBB) and 2-way-value-pegs (2wvp)

Basic idea:

Childchain consensus on chain-tip is reached via highest total accumulated burn, possible today. Queue of withdrawals from childchain is filled as required for childchain block validity from a fixed fraction of amount burned. Deposits onto childchain require separate independent from consensus Bitcoin burns.  Combined this allows childchains with enforced 1:1 coins value peg in both directions (2WVP).


Summary:

- Bitcoin can be the parent chain - highly secure and light PoW chain as it is today with no changes and no awareness of childchains
- Childchains will arrive at consensus on chain-tip based on total accumulated burned Bitcoin in return for childchain fees (simulating PoW sunk costs via sunk costs of burning Bitcoin)
- The child-to-parent-peg for childchain (cBTC) to Bitcoin (BTC) works by diverting a small fraction of burnt Bitcoins used for block commitments to reimbursing withdrawals over time (burning cBTC).
- The parent-to-child-peg for BTC to cBTC is done via a completely independent from block commitments BTC burns that generate equal number of cBTC.
- Both directions provide long timeframe 2-way-peg of creating/destroying ~1:1 valued assets w/ security on scale of burns over time. Atomic swaps provide short-time frame swaps between existing already 2wp assets.
- With no effect on or risk to mainchain, this would allow any degree of complexity to be anchored into Bitcoin, remain completely optional, and all risks and security scale with its own demand and some of Bitcoin's security.
- This inherits and simulates most of PoW benefits without additional energy costs for any number of childchains or any number of users without any of PoS downsides
- All Bitcoin owners would see Bitcoins becoming more scarce and thus more valuable

Childchain block producers and rewards:

Each childchain producer (burner) that's willing to burn Bitcoin will be assembling blocks and once ready will create a secret they will commit to the Bitcoin mainchain.
The new childchain blocks are not propagated until after there's a confirmation of commits on Bitcoin mainchain to hide the childchain commits from miners.


After the Bitcoin block is created, the childchain blocks are propagated.

The secret is then calculated from childchain block headers and is matched to burn commit transactions.
Chaintip chosen for the childchain is by most amount burnt by a commit for a valid known block, tie break is by first seen by height and further by tx order.
When presented with multiple childchain chaintips (at different bitcoin mainchain blockheight), one is chosen by the highest total amount burnt (simulation of total accumulated work).

Total accumulated burn is easily calculated for each chain tip and provides similar incentives as using total accumulated work, only 1 layer higher.

Most likely tx78 is picked due to most burn at which point the block content is validated. (validating every block version every time is not necessary, only winners)
If the tx78's block is valid, the fees of that block's tx are distributed based on amounts burnt.
If the block is invalid (e.g. if tx124 was picked by hash) it's removed from all consideration and a new block is picked same way as before. (tx124 burner gets nothing)

Let's say tx78's block was picked & tx124 block wasn't so 0.8 cBTC in simplest design are distributed to winner.

However, some fee smoothing is ideal to reduce the load on mainchain and overshooting or undershooting the amounts burnt each Bitcoin block.
This way the burning doesn't have to happen every block and accidentally participating in a block with too many burners can be used to even out the diluted rewards.
Additionally there's then always an expected minimum fee payout for a future block even if there are too few transactions.

With fee smoothing 0.8 cBTC is added to fee pool (can be stored in the header) and let's say 50% of fee pool is distributed each round based on amounts burnt in last 6 blocks (arbitrary number used for example).
At steady state and on average the new tx fees added would be roughly the total fee payout in each block.
The distribution of fees this block would have to be part of next block in order for next block to be considered valid (either implied during this block or as part of coinbase tx in next block)


2-way Bitcoin peg

First of all, the deposits onto the childchain are always simplest: burning Bitcoin (separate from commits) on mainchain is seen as a signal to create equal amount of cBitcoin on childchain for designated recipient.
The withdrawals of Bitcoin to childchain are the hard direction, but as drivechain's design suggested, doesn't have to be fast. Withdrawal's job is to provide the equal value on mainchain to enforce the peg even if it takes a long time to withdraw. Once the value of pegs is fixed in both directions, the trade between existing cBTC and BTC can be done independent of peg process and much faster via atomic swaps, subatomic channel trades, and so on.

There is no multisig pool and thus no people in charge of collaterals to worry about nor any oracles to collude.
Instead, the childchain Bitcoin (cBTC) value is kept by a childchain queue funding those withdrawals over time from the sidestream off burning transactions.

Let's say the childchain validity requires all commits to put between 10 to 20% of Bitcoin intended for burning into paying off the withdrawal queue. The number is a range so that the ratio between burning and fee can't be used to ID the childchain commits & can be picked at random with total spent being same either way. Let's also cap the withdrawals to not payout more than 50% of each withdrawal balance left.

Using those example design parameters this is what might see:

Note how overpaying A is not a big deal since we're not limited by a 1:1 pool to keep the peg. In fact his original withdrawal might've been much higher so wasn't overpaid significantly.

Hiding commits and withdrawals on childchain from miners until they are confirmed:

Simplest burning would just use OP_0 OP_RETURN type transactions with non-0 value.

Obvious burns and commits could be used as means to censor childchains by miners potentially seeking those transaction fees. Since they can't get around burning Bitcoin to access those, miners do not have significant advantage to win burns. To avoid miners censoring the childchain, fraction of the fees paid out on child chain must be paid to winning main chain miners on the childchain (e.g. 50%). This provides incentives to miners to support child chains without having to mine them. Withdrawals from childchain to main chain also requires other burners helping the child chain propagate safety.

If miners see obvious burning they can guess it's a childchain transaction. To hide that, provable burns can be hidden inside scripts. Various ideas of hiding burns are possible including varations on BMM or this:

The withdrawal and commits can be hidden as any P2SH and P2WSH transaction output as such:

BTC withdrawal output:

Provably unspendable burn output:

In other words, when users withdraw btc from 2 way peg on main chain (that are present in every burn whenever there's anyone withdrawing still), they reveal the secret that can be used to determine the output script is just a number and then op_false and that output can be forgotten.

The withdrawal of BTC reveals the secret as part of redeem stack that can be used to prove op_false script in burn output even without having the full blocks from childchains.
Ideally the effective batching of many transactions fees on childchains for paying burners that can then pay higher transaction fees on mainchain will be reason enough for miners to not mind their use.
The outputs for withdrawals can ideally be batched even easier by recipients after schnorr soft fork on BItcoin.

If that's too complicated, just burn by any regular more obvious means. As long as miners get paid, there's little reason to censor childchains.

Transactions on childchain:

The childchain clients would be built on top of or combined with a Bitcoin client and be fully Bitcoin-aware.
The childchain network transactions and childchian blocks containing them would be broadcast in 2 ways:
1) over their independent network of nodes
2) embedded in Bitcoin network as optional backup for data availability

The fees in transactions would be paid in cBTC. To minimize frequency of having to use the Bitcoin chain for commits, all the fees would go into a fee pool and be distributed over a specific period.
The rules for transactions in childchains can be anything they want otherwise. Childchain transactions embedded on Bitcoin would likely have to be at least the most important ones like requests for withdrawals to mainchain to make all childchain nodes aware it was made and render blocks not including them as invalid to avoid burner censorship.

Burning pools:

To avoid the issue of larger burn amounts easily winning over many smaller burn amounts, burning pools can be used. Combine burns with PSBT from many people for child chain commit they agree with. Unlike some mining pools, it's quite obvious what child block hash they are signing.

---

This work was previously written up by me here https://bitcointalk.org/index.php?topic=5212814.msg53482314#msg53482314 but as it started not as a pure Bitcoin peg I didn't feel comfortable posting it here. However, as thought experiment progressed, I would like to see opinions on this method. Please look there for considerations of withholding childchain blocks attacks, measuring security of childchains, avoiding weak subjectivity, censorship, and many other concerns I had.

Please post here if you find major issues or not, possible attacks, let's see if this makes any sense to pursue, a sanity check of sorts. Wanted to get the views for it on a pure Bitcoin board.

I think this might be the best approach to optional infinite complexity and expressiveness on Bitcoin without any security compromises to the main chain nor the countless issues of inferior consensus systems.
Best of all it's possible today.

See you space cowboy

--- edit changes ---

- should pick 1 winner per child height for most burned. pick chain tip by total accumulated burn only.
- paying all burners would cause small burns for same child height revealed/posted later to change fee payouts and makes no sense. only pay winner

--- to review ---

- fee smoothing needs bit of rework
- must show boundary conditions at ~0% adoption and ~100% adoption including paying fraction of fees to main chain miners to keep them vested and paid
- considerations for bmm style single tx chain commits (need ctv or similar soft fork to only allow single output and avoid wasted burns)