Continuous Proof of Bitcoin Burn & Bitcon-peg w/o oracles nor trusted bridges

[gildarts456]

Continuous Proof of Bitcoin Burn for securing separate blockchains, optionally acting as Bitcoin childchains via Bitcoin-pegged tokens without a need for a federated bridge or oracles.

TLDR: Proposing the following that's possible today to use for any existing or new blockchains:

 * arriving at consensus AND distributing coins via burning Bitcoin instead of electricity/equipment to create permissionless, unfakeable, green, and trust minimized childchains.    
 * creating Bitcoin-peg from altcoin chain to mainchain (the hard direction) by allocating small percentage of Bitcoin intended for burning to reimbursing withdrawals

Disclaimer:

This is not an altcoin thread. I'm not making anything. The design discussed options for existing altcoins and new ways to built on top of Bitcoin inheriting some of its security guarantees. 2 parts: First, the design allows any altcoins to switch to securing themselves via Bitcoin instead of their own PoW or PoS with significant benefits to both altcoins and Bitcoin (and environment lol). Second, I explain how to create Bitcoin-pegged assets to turn altcoins into a Bitcoin childchain equivalent. Let me know if this is of interest or if it exists, feel free to use or do anything with this, hopefully I can help.

Issue:

- how to create continuous sunk costs, permissionless entry, high cost of attacks?
- how to do it without needing to build up a new source of hardware capital or energy costs?
- how to peg another chain's token value w/o incentivized collusion risk of federation or oracles?
- how to make childchain use fully optional for all bitcoin parties?
- how to allow programmable Bitcoins w/ unlimited permissionless expressiveness w/o forcing mainchain into additional risks?

Solution to first few points:

- Continuous Proof of Bitcoin Burn (CPoBB) to distribute supply control and childchain consensus control to independent parties
- Distributes an altcoin for permissionless access and childchain-only sybil protection.
- In case of childchain block-producer censorship, Bitcoin's independent data availability makes childchain nodes trivially aware

PoW altcoin switching to CPoBB would trade:

- cost of capital and energy -> cost of burnt bitcoin
- finality of their PoW -> finality of Bitcoin's PoW
- impact on environment -> 0 impact on environment
- unforgeable costliness of work -> unforgeable costliness of burn
- contract logic can include conditions dependent on real Bitcoins as it's Bitcoin-aware

PoS altcoin switching to CPoBB would trade:

- permissioned by coin holders entry -> permissionless entry by anyone with access to Bitcoin
- no incentive to give up control or sell coins -> incentive to sell coins to cover the cost of burnt bitcoin
- incentivized guaranteed centralization of control over time by staking -> PoW guarantees with same 0 environmental impact
- nothing at stake -> recovering sunk costs at stake
- contract logic can include conditions dependent on real Bitcoins as it's Bitcoin-aware

We already have a permissionless, compact, public, high-cost-backed finality base layer to build on top - Bitcoin! It will handle sorting, data availability, finality, and has something of value to use instead of capital or energy that's outside the childchain - the Bitcoin coins. The sunk costs of PoW can be simulated by burning Bitcoin, similar to concept known as Proof of Burn where Bitcoin are sent to unspendable address. Unlike ICO's, no contributors can take out the Bitcoins and get rewards for free. Unlike PoS, entry into supply lies outside the alt-chain and thus doesn't depend on permission of alt-chain stake-coin holders. It's hard to find a more bandwidth or state size protective blockchain to use other than Bitcoin as well so altcoins can be Bitcoin-aware at little marginal difficulty - 10 years of history fully validates in under a day.

What are typical issues with Proof of Burn?

- limited burn time window prevents permissionless entry in the future. how many years did it take for most heavily mined projects to become known and well reviewed? many. thus entry into control of supply that's vital to control of chain cannot be dependent on the earliest stage of the project. (counterparty)
- "land grabs" "rent seeking" - by having limited supply without continuous emission or inflation we encourage holding vs spending (assuming goal is security vs spam/sybil and not SoV which Bitcoin does best already).

Solution:

- These issues can be fixed by having Proof of Burn be permanently accessible and continuous: Continuous Proof of Bitcoin Burn CPoBB

This should be required for any design for it to stay permissionless. Optional is constant fixed emission rate for altcoins not trying to be money if goal is to maximize accessibility. Since it's not depending on brand new PoW for security, they don't have to depend on massive early rewards giving disproportionate fraction of supply at earliest stage either. If 10 coins are created every block, after n blocks, at rate of 10 coins per block, % emission per block is = (100/n)%, an always decreasing number. Childchain coin doesn't need to be scarce money, and could maximize distribution of control by encouraging further distribution. If no burners exist in a block, altcoin block reward is simply added to next block reward making emission predictable.

Childchain block content should be committed in burn transaction via a root of the merkle tree of its transactions. Childchain state will depend on Bitcoin for finality and block time between commitment broadcasts. However, the throughput can be of any size per block, unlimited number of such childchains can exist with their own rules and validation costs are handled only by nodes that choose to be aware of a specific childchain by running its consensus compatible software.

Important design decision is how can protocol determine the "true" side-block and how to distribute incentives. Simplest solution is to always :

1. Agree on the valid childchain block matching the merkle root commitment for the largest amount of Bitcoin burnt, earliest inclusion in the bitcoin block as the tie breaker
2. Distribute block reward during the next side-block proportional to current amounts burnt
3. Bitcoin fee market serves as deterrent for spam submissions of blocks to validate

e.g.

childchain block reward is set always at 10 altcoins per block
Bitcoin block contains the following content embedded and part of its transactions:

tx11: burns 0.01 BTC & OP_RETURN <childchain id> <sha256 root of valid childchain block version 1> <childchain address for reward>
tx56: burns 0.05 BTC & OP_RETURN ... <...root of valid childchain block version 1> ...
tx78: burns 1 BTC & OP_RETURN ... <...root of valid childchain block version 2> ...
tx124: burns 0.2 BTC & OP_RETURN ... <...root of INVALID childchain block version 3> ...

Validity is deterministic by rules in client side node software (e.g. signature validation) so all nodes can independently see version 3 is invalid and thus burner of tx124 gets no reward allocated. The largest valid burn is from tx78 so version 2 is used for the blockchain in childchain. The total valid burn is 1.06 BTC, so 10 altcoins to be distributed in the next block are 0.094, 0.472, 9.434 to owners of first 3 transactions, respectively.

Censorship attack would require continuous costs in Bitcoin on the attacker and can be waited out. Censorship would also be limited to on-childchain specific transactions as emission distribution to others CPoB contributors wouldn't be affected as blocks without matching coin distributions on childchain wouldn't be valid. Additionally, childchains can allow a limited number of childchain transactions to happen via embedding transaction data inside Bitcoin transactions (e.g. OP_RETURN) as a way to use Bitcoin for data availability layer in case childchain transactions are being censored on their network. Since all childchain nodes are Bitcoin aware, it would be trivial to include.

Childchain blocks cannot be reverted without reverting Bitcoin blocks or hard forking the protocol used to derive childchain state. If protocol is forked, the value of childchain coins on each fork of childchain state becomes important but Proof of Burn natively guarantees trust minimized and permissionless distribution of the coins, something inferior methods like obscure early distributions, trusted pre-mines, and trusted ICO's cannot do.

More bitcoins being burnt is parallel to more hash rate entering PoW, with each miner or burner getting smaller amount of altcoins on average making it unprofitable to burn or mine and forcing some to exit. At equilibrium costs of equipment and electricity approaches value gained from selling coins just as at equilibrium costs of burnt coins approaches value of altcoins rewarded. In both cases it incentivizes further distribution to markets to cover the costs making burners and miners dependent on users via markets. In both cases it's also possible to mine without permission and mine at a loss temporarily to gain some altcoins without permission if you want to.

Altcoins benefit by inheriting many of bitcoin security guarantees, bitcoin parties have to do nothing if they don't want to, but will see their coins grow more scarce through burning. The contributions to the fee market will contribute to higher Bitcoin miner rewards even after block reward is gone.

Childchain Bitcoin-pegs:

What is the ideal goal of the childchains? Ideally to have a token that has the bi-directionally pegged value to Bitcoin and tradeable ~1:1 for Bitcoin that gives Bitcoin users an option of a different rule set without compromising the base chain nor forcing base chain participants to do anything different.

Issues with value pegs:

- federation based pegs allow collusion to steal bitcoins stored in multi-party controlled accounts
- even if multisig participants are switched or weighted in some trust minimized manner, there's always incentive to collude and steal more
- smart contract pegs (plasma, rollups) on base chain would require bitcoin nodes and miners to validate childchain transactions and has to provide block content for availability (e.g. call data in rollups), making them not optional.
- bitcoin nodes shouldn't be childchain aware so impossible to peg the value

Let's get rid of the idea of needing Bitcoin collateral to back pegged coins 1:1 as that's never secure, independent, or scalable at same security level. As drive-chain design suggested the peg doesn't have to be fast, can take months, just needs to exist so other methods can be used to speed it up like atomic swaps by volunteers taking on the risk for a fee.

In continuous proof of burn we have another source of Bitcoins, the burnt Bitcoins. Childchain protocols can require some minor percentage (e.g. 20%) of burner tx value coins via another output to go to reimburse those withdrawing side-Bitcoins to Bitcoin chain until they are filled. If withdrawal queue is empty that % is burnt instead. Selection of who receives reimbursement is deterministic per burner. Percentage must be kept small as it's assumed it's possible to get up to that much discount on altcoins emissions.

Let's use a really simple example case where each burner pays 20% of burner tx amount to cover withdrawal in exact order requested with no attempts at other matching, capped at half amount requested per payout. Example:

withdrawal queue:

request1: 0.2 sBTC
request2: 1.0 sBTC
request3: 0.5 sBTC

same block burners:

tx burns 0.8 BTC, 0.1 BTC is sent to request1, 0.1 BTC is sent to request2
tx burns 0.4 BTC, 0.1 BTC is sent to request1
tx burns 0.08 BTC, 0.02 BTC is sent to request 1
tx burns 1.2 BTC, 0.1 BTC is sent to request1, 0.2 BTC is sent to request2

withdrawal queue:

request1: filled with 0.32 BTC instead of 0.2 sBTC, removed from queue
request2: partially-filled with 0.3 BTC out of 1.0 sBTC, 0.7 BTC remaining for next queue
request3: still 0.5 sBTC

Withdrawal requests can either take long time to get to filled due to cap per burn or get overfilled as seen in "request1" example, hard to predict. Overfilling is not a big deal since we're not dealing with a finite source. The risk a user that chooses to use the childchain pegged coin takes on is based on the rate at which they can expect to get paid based on value of altcoin emission that generally matches Bitcoin burn rate. If childchain loses interest and nobody is burning enough bitcoin, the funds might be lost so the scale of risk has to be measured. If Bitcoins burnt per day is 0.5 BTC total and you hope to deposit or withdraw 5000 BTC, it might take a long time or never happen to withdraw it. But for amounts comparable or under 0.5 BTC/day average burnt with 5 side-BTC on childchain outstanding total the risks are more reasonable.

Deposits onto the childchain are far easier - by burning Bitcoin in a separate known unspendable deposit address for that childchain and childchain protocol issuing matching amount of side-Bitcoin. Withdrawn bitcoins are treated as burnt bitcoins for sake of dividing block rewards as long as they followed the deterministic rules for their burn to count as valid and percentage used for withdrawals is kept small to avoid approaching free altcoin emissions by paying for your own withdrawals and ensuring significant unforgeable losses.

Ideally more matching is used so large withdrawals don't completely block everyone else and small withdrawals don't completely block large withdrawals. Better methods should deterministically randomize assigned withdrawals via previous Bitcoin block hash, prioritized by request time (earliest arrivals should get paid earlier), and amount of peg outstanding vs burn amount (smaller burns should prioritize smaller outstanding balances). Fee market on bitcoin discourages doing withdrawals of too small amounts and encourages batching by burners.

The second method is less reliable but already known that uses over-collateralized loans that create a oracle-pegged token that can be pegged to the bitcoin value. It was already used by its inventors in 2014 on bitshares (e.g. bitCNY, bitUSD, bitBTC) and similarly by MakerDAO in 2018. The upside is a trust minimized distribution of CPoB coins can be used to distribute trust over selection of price feed oracles far better than pre-mined single trusted party based distributions used in MakerDAO (100% pre-mined) and to a bit lesser degree on bitshares (~50% mined, ~50% premined before dpos). The downside is 2 fold: first the supply of BTC pegged coin would depend on people opening an equivalent of a leveraged long position on the altcoin/BTC pair, which is hard to convince people to do as seen by very poor liquidity of bitBTC in the past. Second downside is oracles can still collude to mess with price feeds, and while their influence might be limited via capped price changes per unit time and might compromise their continuous revenue stream from fees, the leverage benefits might outweigh the losses. The use of continuous proof of burn to peg withdrawals is superior method as it is simply a minor byproduct of "mining" for altcoins and doesn't depend on traders positions. At the moment I'm not aware of any market-pegged coins on trust minimized platforms or implemented in trust minimized way (e.g. premined mkr on premined eth = 2 sets of trusted third parties each of which with full control over the design).


originally drafted https://pastebin.com/bD7cggF6

Brief issues with current altchain options:

a. PoW: Additional PoW chains require high energy and capital costs to create permissionless entry and trust minimized miners that are forever dependent on markets to hold them accountable. Using same algorithm or equipment as another chain or merge-mining puts you at a disadvantage by allowing some miners to attack and still cover sunk costs on another chain. Using a different algorithm/equipment requires building up the value of sunk costs to protect against attacks with significant energy and capital costs. Drive-chains also require miners to allow it by having to be childchain aware and thus incur additional costs on them and validating nodes if the childchain rewards are of value and importance.
b. PoS: PoS is permissioned (requires permission from internal party to use network or contribute to consensus on permitted scale), allows perpetual control without accountability to others, and incentivizes centralization of control over time. Without continuous source of sunk costs there's no reason to give up control. By having consensus entirely dependent on an internal state, the network, unlike PoW but like private databases, cannot guarantee independent permissionless entry and thus cannot claim trust minimization. Has no built in distribution methods so depends on safe start (snapshot of trust minimized distributions or PoW period) followed by losing that on switch to PoS or starting off dependent on a single trusted party such as case in all significant pre-mines and ICO's.
c. Proof of Capacity: PoC is just shifting costs further to capital over PoW to achieve same guarantees.
d. PoW/PoS: Still require additional PoW chain creation. Strong dependence on PoS can render PoW irrelevant and thus inherit the worst properties of both protocols.
f. Tokens inherit all trust dependencies of parent blockchain and thus depend on the above.
g. Embedded consensus (counterparty, veriblock?, omni): Lacks mechanism for distribution, requires all tx data to be inside scarce Bitcoin block space so high cost to users instead of compensated miners. If you want to build a very expressive scripting language, might very hard & expensive to fit into Bitcoin tx vs CPoBB external content of unlimited size in a committed hash. Same as CPoBB is Bitcoin-aware so can respond to Bitcoin being sent but without source of Bitcoins like burning no way to do any trust minimized Bitcoin-pegs it can control fully.

Few notes from discussions:

- fees must be high to be included in next block (and helps pay and bribe bitcoin miners), RBF use is encouraged to cancel late transactions
- what if not enough burners, just passive nodes? you can burn smallest amount of bitcoin yourself when you have a transaction you want to go through
- using commit hashes on bitcoin to lock altcoin state isn't new (e.g. kmd) but usually those rely on some federation or permissioned proof of stake mechanism with no real costs. this is combination of both.
- this is not exactly like counterparty's embedded consensus as block data and transactions are outside Bitcoin, but consensus is derived with help of embedded on Bitcoin data.
- deterministic randomness (e.g. via that Bitcoin block's hash) could be used to assign winning childchain block weighted by amount burned to allow occasional blocks formed by others curbing success rate of censorship by highest burner
- blockstacks proposed similar methods as I just saw: https://blog.blockstack.org/video-reusing-bitcoins-hashpower-to-launch-the-stacks-blockchain/ https://blockstack.com/tokenpaper.pdf https://blockstack.org/whitepaper.pdf
    with many similarities (probably from where I vaguely got the idea)! but also major differences:
    - wants to transition away from using proof of burn via tunable proofs and native proof of work (whitepaper)
    - a dominant premine (trust maximized) relative to emission that defeats the purpose of distributing control over incentives (figure 3 in tokenpaper suggests premine still ~30%-70% by year 2050)
    - variable emission rate "adaptive mint and burn" makes supply unpredictable (and possibly gameable)
    - additional rewards that aren't trust minimized like "app mining" and "user incentives" possibly gameable with premine
    - election of a leader includes their own PoW to be elected even at start (5% cap), why lol?
    - blockstack also suggested use of randomness that depends on that block so Bitcoin miners that already spent energy mining that block can't just re-do it to get picked at no cost

Main questions to you:

- why not?
    (other than blocktime)

- can this be done without an altcoin?
    (Not sure and don't think so w/o compromising unforgeable costliness and thus trust minimization. At least it's not using an altcoin that's clearly centralized.)

- how to make it less detectable by Bitcoin miners?
    ( BMM could use some techniques described here: https://twitter.com/SomsenRuben/status/1210040270328254464 )
    ( Perhaps since childchain nodes receive proposed blocks independently and can figure out their hash, the commit message ( childchain id + block commit + miner address) can be hashed one more time before its placed on Bitcoin, making miners unaware until after Bitcoin block is found that this is that childchain's burn. Childchain block producers would have to delay childchain block propagation until after Bitcoin block is propagated, 10 minutes blocktime helps here. Hiding the fact that Bitcoin is burnt until after the fact is another possibly important matter. )

- Should reward be split between valid blocks?
    (Blockstacks approach does not reward blocks marked by different from leader chaintip. That seems dangerous since childchain tx sorting would be difficult to match and could take significant time to be compensated for perfectly valid work and coins burned. It doesn't seem as necessary in burning since we're not expending costs based on only one previous block version, the costs are independent of block assembly. Tradeoff is between making it easier for independent "mining" of childchain and making it easier to validate for full nodes on childchain)

open to working on this further with others

[1714879701]

1714879701

[1714879701]

1714879701

[1714879701]

1714879701

[R.I.U. iol]

I didnt read the whole thing, but do you mean something like this: https://www.blockchain.com/btc/address/1CounterpartyXXXXXXXXXXXXXXXUWLpVr ?

[gildarts456]

similar,

but instead of burning for a few weeks only and then allocating tokens,

you do burning and allocating tokens every block continuously

and also use that transaction to commit your sidechain block hash

and use burning of coins as metric for consensus mechanism instead of burning of energy/capital via proof of work.

let bitcoin handle the proof of work, no need to reinvent a wheel in less secure manner.

best part about counterparty distribution is unlike every ICO the costs couldn't be faked.

[OgNasty]

Is this supposed to be the burn address 3CJfFzmiwUmCXUWBXEUCH7jmQRHjKUcVsc? I stopped reading once I saw that.

[gildarts456]

no thats my address with keys of which I can sign stuff if necessary, seemed easier than PGP key

burn addresses should not be spendable (but still checksum correctly) and that clearly is a regular address. I'll mark it as such. removed completely.

disclaimer should probably be next after title to clarify I'm not making a shitcoin, there's no burn address or any shitcoin yet or planned. this is just a design.

[gildarts456]

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)

Block N:
Burner A burns 10k sats to commit his version of childchain block to Bitcoin
Burner B burns 5k sats to commit another version of childchain block to Bitcoin

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:

Block N+4:
Burner C burns 20k sats to commit his version of childchain block to Bitcoin
Burner D burns 10k sats to commit another version of childchain block to Bitcoin

withdrawal queue:
1. 200 sats to address A. Burner C sends 4000 Sats to A within the burning tx. Burner D sends 2000 Sats to A within the burning tx. Remaining withdraw balance = 194k sats.

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

[gildarts456]

Further analysis of various issues and solutions:

Many worries about drivechain design involved them being required to process and mine it for fees to compete against other miners who are getting that side income without expending additional work, some even called it "attack on miners" for incentivising bandwidth costs of being sidechain aware. Since there's no federation to worry about, their ability to steal isn't there. Alternative threats to consider are possibly censorship and taking over the childchains. Let's examine taking over the childchains threat first.

Miners could desire those additional fee revenues and take over chilchains. Since this process relies on burning Bitcoin, it applies to miners like everyone else, and thus has high costs. The only real unique discount they can get is the mainchain fees back, but not the burnt Bitcoin which is most important. Perhaps, since this would still bring some fees to mainchain from burn commits and the childchain tx are likely there in first place to avoid high fees, those accumulated fees on childchain were unlikely to bring revenue to miners either way and the fees that do end up on mainchain are paid for indirectly by the effective batching of childchain fees that attracts burners. Furthermore, if the childchain tx are used for unique rules the child chain has (like virtual machines or stateful smart contracts), that's just another source of demand for mainchain this allows it to get.

Miners could see childchain as a threat to take away their fees, but would only be significant at high rate of childchain use and thus high rate of Bitcoin burn. Fee specific rules are dangerous if they become predictable for miners to detect in case of censorship attack by miners (like if rule is 10% of burn is fee, and miner detects output that paid 10% in fees of its value, they can try to censor all such tx to kill childchain). In fact, hiding childchain interactions with Bitcoin is important and fees are likely to be taken care of by demand.

Here's a strategy to hide childchain transactions on mainchain, use outputs that appear like many others.

For previous examples I suggested using OP_RETURN to be provably unspendable for commits and simple send to address for withdrawal fills.

Hiding from miners like in BMM could be more secure so similar can be achieved in theory by P2SH where all you see is a hash of a script in ScriptPubKey of 1+ outputs in mainchain tx that looks like any other P2SH. (I'll use P2SH terminology but P2WSH would work as well)
That hash could hide all kinds of information.

Burners are best expected to commit to Bitcoin before broadcasting the childchain block. The burn and the withdrawal filling tx could be hidden as P2SH. Withdrawal P2SH would allow recipient to spend it after the childchain block is propagated. When recipient withdraws from that output they would reveal a secret that could be used to determine that the burn output is provably unspendable as script always evaluates to false. To avoid detection by miners via known ratio of burned Bitcoin to withdrawal BItcoin, the exactly 20% example rule diverted to withdrawals should be a flexible range like 10%-20%. The total amount burner spends doesn't change but burner is free to pick a random ratio within a popular range to hide himself. When withdrawal happen and redeemscript and secret are fed into it, secret becomes public knowledge, and it could be a notice that the other is the standard burn output that could be verified with the known secret as unspendable.

secret = hash of ( hash of childchain block header that wasn't broadcast until after a mainchain confirmation of commit + other obvious data like address miner wants to use on childchain for fees + childchain id )

P2SH script for withdrawal output:

op_sha256 <sha256(secret)> op_equalverify
< recepient pub key > op_checksigverify

spender's scriptSig stack: their signature, <secret>

P2SH script for burning

<secret>
op_false

no spending script possible

The secret in burning script helps randomize the hash of that script that's visible in its burn output script, but it always ends up with a false at top of stack and fails.
Feeding withdrawal p2sh the secret makes second derivable based on standards childchain uses. sha256 I believe is less costly than signature validation so it is checked first to save on computation if it fails.
Nodes would still need to know to check for this childchain burn script but they don't have to monitor the childchains to find the secret to prove the burn utxo prunable (so no higher bandwidth use requirement).

What if fees on mainchain are larger than income from fees on childchain?

- Childchain is likely to have capped blocksize or gas limit of some kind, but would allow miners to pick best paying tx to fill childchain blocks. Burners could wait until childchain fees accumulate or rise high enough to make burning worth it - could be 1000s of childchain tx fees to cover the single bitcoin fee and compensating bitcoin burners. Ideally childchain would also have mechanisms to replace fees to let them grow if necessary.

What about issue with some blocks with too many burners and some blocks with too few as it's hard to predict others behavior before the block is mined?

- The fees payouts can be averaged out slightly with a simple formula. All the fees from each block could go into a childchain fee pool state from which payouts to burners are made. The total of 50% of current fee pool can be paid out total each block creating a predictable minimum payout schedule even if all childchain tx were to suddenly stop. Instead of only paying out to the burners in each block, the payout could be to amount burnt by A in previous N (e.g. 6) blocks. At steady state pool consumed would be same as new fees gained.

The payout to burner A for example would be calculated like this each block:

fee payout to burner A in next block = (50% of fee pool) * (Bitcoin burned by A in last 6 blocks) / (total burns in last 6 blocks)

What about projects that already use another coin other than Bitcoin but want to migrate and switch to pure Bitcoin childchain?

- could do a design where you let let's say 20% of fees be paid by the altcoin where it's burnt to phase it out but allows a max of same 20% capacity per block so the additional capacity doesn't take fees away from miner. The value of altcoin could be set to be a specific amount of sBTC, bytes, or gas for those fee considerations depending how chain measures it. Most important is that it doesn't take away from miner sBTC fees hence added capacity just for those tokens. It's more work to pay with it but it's also helpful for those already with them. As they are burnt they become less important on transition to pure sBTC use. This could be used to transition away from unsecure premined coins to trust minimized supply.


I'm not sure this will be a good idea, but if pure fee only childchain scares people, there are things they can do w/o compromising the mainchain - benefit of a well defined base mainchain to add onto:

Let's call this hypothetical coin "Inflation Bitcoin" "IBC" (to avoid confusing people that it's same as non inflationary bitcoin, this doesn't exist, I just made it up for this example).
You can create a block reward that pays in IBC, let's say 0.0002% of total IBC supply per block which should roughly be equal to about 10% inflation per year.
You create those IBC out of nothing (gasp) to give to burners (e.g. via fee pool) which devalues all other IBC. The network tracks total Bitcoin still deposited vs total IBC that exists.
While it starts with those equal, slowly over time total ICB becomes larger, and the ratio between those values can be used for conversion on withdrawals and deposits.
Effectively it simulates the dilution you see from block rewards but that's limited to only the childchain. And while the value of the pegged coin is still proportional to Bitcoin, it's offset by ever changing inflation factor.
I think it's a bit confusing to call it anything resembling Bitcoin when it has permanent inflation but this demonstrates the flexibility with the peg childchains can have if they choose to.
Technically, it might even work in the opposite direction where the peg is changed to increase in value over time (e.g. 5% per year like HERO) with main issue being the withdrawals would take longer to fill.
I haven't thought all the possibilities for this through yet but I welcome discussions.

---
If I forget to credit you after a discussion or forget or don't realize I have to credit someone else, lmk.

[d5000]

I have just read the first part of your first post (the part about the Proof of Burn mechanism) and I don't consider that a bad idea at all. It seems to be a very interesting alternative to mechanisms like Komodo's dPoW or VeriBlock. Above all, I like the aspect that Bitcoin holders also profit from the "spam" they have to "tolerate" because of the potentially shrinking supply due to burning. (I remember the VeriBlock issue at the start of 2019 and earlier discussions about Komodo and Counterparty). However, this could also lead to Bitcoin price stability problems in the future if the mechanism is used massively.

At a first glance, I interpreted that the security model depends on the assumption that the alt-chain must always be significantly weaker (have a lesser "value" of all coins aggregated) than the Bitcoin mainchain, because otherwise there may be problems with collusions between sidechain "minters" (those that issue PoB transactions on Bitcoin) and mainchain miners. For example, if there is significant value stored in the alt-chain, an attacker wanting to double-spend the altcoin could bribe a Bitcoin miner to force a re-org of the Bitcoin blockchain including one of his burn transactions, which would also lead to a re-org in the alt-chain.

The model has also some minor similarities with the Ardor project, it seems (where mainchain and childchains are inside the same "ecosystem").

I'll try to continue to read your contributions in the coming days/weeks (they're not easy to read, but afaik the technicals are solid so far).

[gildarts456]

By the way I wrote up similar design idea without any altcoins - bitcoin peg only which I think is also doable.

What you brought up is important, however.

I have spent a lot of time thinking about scenarios where childchain grows too large compared to main chain.

Unforgeable costliness of proof of burn is most important scale of security when it's the weakest link in security - while burned coin value is smaller than unforgeable costliness of proof of energy burn (PoW).

I believe the at extremely large highly adopted childchain scenario would have most rewards paid on childchain & thus security would approach almost entirely the base layers PoW security.

To ensure pow >= pob costs & rewards, I now think half of all rewards per childchain block should be given to layer 1 miner which would evenly distribute security to avoid weak parent.

It also effectively allows completely voluntary migrations and protocol changes through childchains, although I think it's extremely unlikely.

I think this solution works incentive-wise with any units of rewards including pure bitcoin childchains and in all extremes of scale! Neat.

if there is significant value stored in the alt-chain, an attacker wanting to double-spend the altcoin could bribe a Bitcoin miner to force a re-org of the Bitcoin blockchain including one of his burn transactions

So in case of non-bitcoin-peg coins it seems similar to bitcoin-peg-only case, all security will have to ensure the costs of attacks (i.e. purchasing power from any source - energy or coin based) are still larger than cost of total value transfer which in extreme case is just basic PoW incentives. But we already see that now due to meta tokens like USDT on some chains outgrowing native assets. Before we could ignore the transferred value of non-native assets but as they become statistically significant, they have to be included into attack-cost security considerations. Same with childchains - they can be ignored until they matter. By that point, you're likely to be quite aware of them not to forget.

Ardor child chains are described as `All transactions are processed and secured by the parent chain forgers` which is exact opposite of what's suggested here and I think vitally important for Bitcoin security - we do not want to force parent chain to process every childchain version as it would become no different of a security issue than having unlimited block size & risks with childchain bugs. Additionally without the burn, there's no mechanism to provide an alternative source of Bitcoin for the peg and have to rely on questionable pegs.

One thing that would be really helpful on Bitcoin is signature aggregation to make it easier to combine many small outputs for withdrawals, but that's planned regardless.