Post
Topic
Board Project Development
Re: Continuous Proof of Bitcoin Burn & Bitcon-peg w/o oracles nor trusted bridges
by
gildarts456
on 30/01/2020, 19:07:11 UTC
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.

Quote
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.