<blockquote>
<p>Are there any &quot;slow&quot; sidechains?</p>
</blockquote>
<p>Softchains fit this definition. Softchains are a type of sidechain that are verified by all mainchain users in a slow but extremely resource-efficient way, by only validating the blocks for which forks occur. It's slow, because you can't assume these forks will occur right away. People who want to actively use the softchain perform full validation, which means consensus will be fast for them.</p>
<blockquote>
<p>What are the tradeoffs?</p>
</blockquote>
<p>These softchains are not fully decoupled from the mainchain. Creating a new softchain requires a soft fork, and softchain consensus could negatively affect mainchain consensus under some scenarios (software bugs, one-year reorgs). Furthermore, mainchain validation cost goes up by roughly 100MB per softchain per year (which could be compensated for with a mainchain block size decrease).</p>
<p>The above is just a high-level overview.</p>
<p>For a relatively easy-to-follow explanation, I recommend listening to this podcast:
<a href="https://youtu.be/4c7cwTts3fo?t=1m45s" rel="nofollow noreferrer">https://youtu.be/4c7cwTts3fo?t=1m45s</a></p>
<p>And the full details are in this write-up:
<a href="https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1" rel="nofollow noreferrer">https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1</a></p>

CC BY-SA 4.0
2021-03-11T22:31:33.260Z
Ruben, thanks for your reply here. I need to better understand your construct but I was really hoping that there was a method which is available on bitcoin today (without needing any sort of soft fork, etc).
philbw4
CC BY-SA 4.0
2021-03-12T23:20:51.973Z
@philbw4 you're welcome, and as for whether such a method is available today without any forks, the answer is simply "no" :)
Ruben Somsen
CC BY-SA 4.0
2021-03-14T03:40:49.620Z
ok, thanks @ruben-somsen. I've accepted your answer for now on the off-chance that someone else is wondering the same sort of thing. Perhaps/hopefully in a post-taproot world we will find ourselves revisiting this :-).
philbw4
CC BY-SA 4.0
2021-03-06T18:44:54.993Z
2021-03-06T18:44:54.993Z
Ruben Somsen
<p>While the idea is interesting, storing the size of the proofin the block itself, it would make the blocks larger, perhaps redundant, but again if we think from the perspective of "light nodes" and other clients, not full nodes this could be beneficial, but in general:
Bigger blocks lead to more time for nodes -> less nodes -> more centralization 
But if you have a particular use case in mind for a 1 week block rate, or bigger blocks, it would be interesting to see how it works and I would love to contribute to your project.</p>

CC BY-SA 4.0
2020-01-20T04:23:12.823Z
Hi, thanks for your answer. However, I'm not suggesting anything about making blocks bigger. In fact, for a "slow" sidechain, and depending on the use case, I think the blocks of the side chain may even end up extremely small. Naturally this would render such a sidechain useless as a "money" for any on-side-chain transactions, but nevertheless such a side chain could still support some off chain (lightning-like) protocols. There may, of course, be other use-cases too.
philbw4
CC BY-SA 4.0
2020-01-21T16:58:56.963Z
Ahhh, My bad, anyways your comment made me think ( with the brain of Google ) and I came across an article by the Vitalik Buterin in 2015, check it out, [On Slow and Fast Block Times](https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/)
It is such an interesting discussion, I'm a little new to the blockchain space and everyday I get to learn something that makes me wonder.
yozaam
CC BY-SA 4.0
2020-01-19T06:02:06.427Z
2020-01-19T06:02:06.427Z
yozaam
<p>We could introduce slow, secure side chains without sacrificing the decentralisation, and without increasing the block size on Bitcoin using Time Locks and Verifiable Delay Functions that can control the block time. In fact, Time Locks are used in some of the Bitcoin Payment Channel implementations. Please find a nice explanation of Time Locks from <a href="https://en.bitcoin.it/wiki/Timelock" rel="nofollow noreferrer">Bitcoin Wiki</a>.</p>

CC BY-SA 4.0
2021-03-16T21:17:40.583Z
Thanks for your answer. Timelocks are definitely a component of what would be necessary to pull this off, but I was hoping for a bit more of a concrete example for creating a slow side chain (preferably without a soft fork).
philbw4
CC BY-SA 4.0
2021-02-01T13:57:38.250Z
2021-02-01T13:57:38.250Z
Gokul Alex
<p>Are there any examples of sidechains which target a block time much longer than bitcoin? Could a sidechain be made "slow enough" such that the size of a proof (SPV proof?) for it could actually fit into and be verified by a mainchain bitcoin transaction with the currently-in-effect mainchain protocol rules?</p>

<p>I'm interested in learning more about how a sidechain with a targeted time between blocks of, say, 1 week, might work and/or if such a chain, if it existed, could be useful.</p>

<p>I'm specifically interested in proof-of-work sidechains that do not rely on any sort of federation (as such, Liquid and RSK would not meet this criteria at the moment, but I'm unaware of any other current examples of bitcoin sidechains), and I'm most interested in "slow sidechains," if any exist.</p>

<sidechains><block-interval>
Are there any "slow" sidechains? What are the tradeoffs?
philbw4
# Are there any "slow" sidechains? What are the tradeoffs?

(Asked by: username_0 on 2019-10-16)

Are there any examples of sidechains which target a block time much longer than bitcoin? Could a sidechain be made "slow enough" such that the size of a proof (SPV proof?) for it could actually fit into and be verified by a mainchain bitcoin transaction with the currently-in-effect mainchain protocol rules?

I'm interested in learning more about how a sidechain with a targeted time between blocks of, say, 1 week, might work and/or if such a chain, if it existed, could be useful.

I'm specifically interested in proof-of-work sidechains that do not rely on any sort of federation (as such, Liquid and RSK would not meet this criteria at the moment, but I'm unaware of any other current examples of bitcoin sidechains), and I'm most interested in "slow sidechains," if any exist.

**Tags:** sidechains, block-interval


---

## 3 answers

### Answer by username_1 on 2021-03-06. Score: 2 | Accepted answer

> Are there any "slow" sidechains?

Softchains fit this definition. Softchains are a type of sidechain that are verified by all mainchain users in a slow but extremely resource-efficient way, by only validating the blocks for which forks occur. It's slow, because you can't assume these forks will occur right away. People who want to actively use the softchain perform full validation, which means consensus will be fast for them.

> What are the tradeoffs?

These softchains are not fully decoupled from the mainchain. Creating a new softchain requires a soft fork, and softchain consensus could negatively affect mainchain consensus under some scenarios (software bugs, one-year reorgs). Furthermore, mainchain validation cost goes up by roughly 100MB per softchain per year (which could be compensated for with a mainchain block size decrease).

The above is just a high-level overview.

For a relatively easy-to-follow explanation, I recommend listening to this podcast:
<https://youtu.be/4c7cwTts3fo?t=1m45s>

And the full details are in this write-up:
<https://gist.github.com/username_1/7ecf7f13dc2496aa7eed8815a02f13d1>

> **Comments:**
> **username_0**: username_1, thanks for your reply here. I need to better understand your construct but I was really hoping that there was a method which is available on bitcoin today (without needing any sort of soft fork, etc).  
> **username_1**: @username_0 you're welcome, and as for whether such a method is available today without any forks, the answer is simply "no" :)  
> **username_0**: ok, thanks @username_1-username_1. I've accepted your answer for now on the off-chance that someone else is wondering the same sort of thing. Perhaps/hopefully in a post-taproot world we will find ourselves revisiting this :-).  

---

### Answer by username_2 on 2020-01-19. Score: 1

While the idea is interesting, storing the size of the proofin the block itself, it would make the blocks larger, perhaps redundant, but again if we think from the perspective of "light nodes" and other clients, not full nodes this could be beneficial, but in general:
Bigger blocks lead to more time for nodes -> less nodes -> more centralization
But if you have a particular use case in mind for a 1 week block rate, or bigger blocks, it would be interesting to see how it works and I would love to contribute to your project.

> **Comments:**
> **username_0**: Hi, thanks for your answer. However, I'm not suggesting anything about making blocks bigger. In fact, for a "slow" sidechain, and depending on the use case, I think the blocks of the side chain may even end up extremely small. Naturally this would render such a sidechain useless as a "money" for any on-side-chain transactions, but nevertheless such a side chain could still support some off chain (lightning-like) protocols. There may, of course, be other use-cases too.  
> **username_2**: Ahhh, My bad, anyways your comment made me think ( with the brain of Google ) and I came across an article by the Vitalik Buterin in 2015, check it out, [On Slow and Fast Block Times](https://blog.ethereum.org/2015/09/14/on-slow-and-fast-block-times/) It is such an interesting discussion, I'm a little new to the blockchain space and everyday I get to learn something that makes me wonder.  

---

### Answer by username_3 on 2021-02-01. Score: 0

We could introduce slow, secure side chains without sacrificing the decentralisation, and without increasing the block size on Bitcoin using Time Locks and Verifiable Delay Functions that can control the block time. In fact, Time Locks are used in some of the Bitcoin Payment Channel implementations. Please find a nice explanation of Time Locks from [Bitcoin Wiki](https://en.bitcoin.it/wiki/Timelock).

> **Comments:**
> **username_0**: Thanks for your answer. Timelocks are definitely a component of what would be necessary to pull this off, but I was hoping for a bit more of a concrete example for creating a slow side chain (preferably without a soft fork).  

---

