Can side-chains be used to achieve optimal network security / transaction fees?

[go1111111]

I am not an expert on side-chains, but I was recently thinking of how they could be used to solve a potential issue with Bitcoin security / transaction fees when block rewards are much lower. Can someone with more technical expertise let me know whether you think my solution below is feasible? I know side-chains are supposed to be able to allow basically anything ("the one change to rule them all", and all that), but I've not seen someone describe how the below could work in detail.

The problems:

Problem #1: The security of the Bitcoin network at time T will depend roughly on the price of Bitcoin, the block reward, the # of transactions, and the average transaction fee. Because the block reward changes on a relatively fixed schedule, and the future price could be any of a wide range of values, the level of network security we'll get in the future might be above or below what is optimal. Here optimal means "enough security so that a successful 51% attack is very unlikely, but not much more than that".

Problem #2: People will generally prefer to transact on networks with lower transaction fees. When Bitcoin block rewards get very small, it's uncertain whether people will want to pay high enough transaction fees to support, rather than move to a different network with higher block rewards and lower transaction fees (for a given level of security).

I'd prefer not to discuss whether these are "real" problems in this thread. I want to stick to the technical feasibility / drawbacks of my proposed solution:

Solution to both:

Suppose in the future the block rewards are super low, people are paying a few cents per transaction, but it's still not enough to provide enough security to the network to make a 51% attack hard enough. Imagine we figure out how much security would be ideal, then we create a side-chain that has a block reward large enough to provide that level of security mostly through block rewards, so transaction fees can remain low. "Now wait a minute -- side chains can't have block rewards! All the coins on the side-chain are supposed to correspond to frozen coins on the main chain!" is what you might be saying. Imagine that when you freeze coins on the main chain, and then unfreeze them 1 year later, you only actually can unfreeze 98% of them because now it takes 102 side-chain coins to unfreeze 100 main-chain coins. Because there has been inflation in the side-chain during that year.

Question #1: has anyone actually worked out concrete details of how something like this "inflating side-chain" could work? It seems plausible in a fuzzy way, although it also seems like there could be issues with timing where someone might trick the main chain into thinking that not much time has passed in the side-chain, and therefore they can redeem more main-chain coins than they should be able to, given the actual inflation in the side-chain.

Question #2: I'm also not a merge-mining expert. The problem with the above is that even if the side-chain has awesome security, the main chain still would have poor security. I imagine having a super-secure side-chain based on an insecure main-chain is not that desirable. I know merge-mining can be used to make a side-chain as secure as Bitcoin (if Bitcoin miners choose to merge-mine), but can merge-mining be used in the reverse way, to make Bitcoin as secure as a side-chain? And can this be done without having to modify the Bitcoin code every time you want it to be merge-mined with a particular new side-chain?

[1715651512]

1715651512

[1715651512]

1715651512

[1715651512]

1715651512

[andytoshi]

When you unlock coins on the mainchain, all that it sees is a SPV proof of ownership on the sidechain. It would look for things like the amount of coins being proven in some standard location. So it'd be easy for the sidechain to put some amount different from the "real" amount to simulate a changing exchange rate. Since this amount would change in a predictable fashion with each block, it could be a consensus rule on the sidechain, so it'd be just as secure as the ordinary case.

So your idea is definitely workable.

But notice the economics here -- users are moving their coins to a sidechain which will cause them to devalue, rather than directly paying fees. I think the effect from a user perspective is actually the same -- so if users don't want to pay fees, they won't want to use this sidechain either. (Maybe there is some economic argument about inflation versus direct fees, I dunno.)

[gmaxwell]

Handling the non-1:1 case when the 1:1 case is solved is trivial, more challenging is figuring out actual applications where users would opt-into it.  There are silly ones, e.g. "ponzi chain"— I guess one metric for an approach being general and supporting of freedom is that it can accommodate things that sound really ill advised too. .. but I've not really found many idea in the non-1:1 space that I'd realistically expect many to play along with.

One argument might be that it's potentially desirable to have a system where lost coins eventually go to support the system somehow... but that very easily runs into issues with bad incentives as miners can censor transactions to make coins seem lost when they're not.

but can merge-mining be used in the reverse way

Depending on what validation rules you choose you can get whatever security "umbrella" you desire. E.g. the sidechain can have consensus rule that their work must also commit to the best valid Bitcoin chain (effectively importing bitcoin validity into the secondary system).  This degrades the tidy isolation that you normally get with no linkage, but it gives full security, complete with incentives (because if you misbehave in the Bitcoin blocks you also lose your blocks in the other system). This is good news, but potentially not a cure all— in the you may still be failing to meet your decentalization objectives even though the hashrate security (ignoring centralization degree) is good (e.g. because the scaling requirements and/or goals of the more profitable secondary system are less decentralization compatible).

[go1111111]

Thanks andytoshi and gmaxwell. The one technical wrinkle that comes to mind is that if you want the side-chain to inflate at say, 5% per year, then the side-chain block reward would vary with the amount of coins currently in the side-chain. So if there are only 1000 coins in the side-chain, then block rewards would be 50/X coins where X is the number of expected block rewards in a full year. If there are one million coins on the side-chain, then block rewards are a thousand times higher than in the previous case. I wonder whether there could be reasons that people would want to move large amounts of coins to and from the side-chain in a purposeful attempt to cause the block rewards to fluctuate wildly, and whether that would be a big problem if it happened.

You both seem skeptical that people will want to move coins to such a side-chain. Since this post is in a technical forum, I'll create a separate post in the Economics subforum for anyone who wants to discuss that issue (I do think people will want to use these side-chains, and depending on the use-case that it could be in their financial interest to do so). That forum post is: https://bitcointalk.org/index.php?topic=801620.0. In the post I attempt to show that at a 5% annual side-chain inflation rate and a one week wait time for unfreezing side-coins, then if I know I'm going to spend $100 worth of bitcoins next week, it's worth moving them to the side-chain if the difference in transaction fees (between doing them in Bitcoin or the side-chain) over all my transactions next week is more than 10 cents.