path: root/6f/2d430808fee0c3c9d0e27a5534212b0548de62

Return-Path: <rsomsen@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2581DC013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 23:39:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 2183E84B08
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 23:39:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 19NQ3gTBS-8W
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 23:39:24 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com
 [209.85.208.52])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 217AD8480D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 23:39:24 +0000 (UTC)
Received: by mail-ed1-f52.google.com with SMTP id dk8so19350457edb.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 15:39:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=AATBq83D2+ywguE0nv59dn0h6WNOb0FPiLV9i1Y1w0U=;
 b=KFA+sYXxizSMXZJgWoht1LIjxRhLni/FUiXHoTjLzMT43+uxKtlFiE3Ynug9nBDBln
 Fh2V1nwS+mAuhj6nq362ZD6a+4djosrQP+Ezdi4ZU1el9hEWfmjbR87YN7APtkfJKZ3g
 KDBxYd1DOrBLfUpAxT7Wi3Anc83e/GT17kWYWrpSo8MElIOnekrD1/Vx0QMMWMN1Kx6Q
 mCfm3F84BPsZS5gZxFn9Xm1jQNdOby8Y1u7S8T9HEHNLjO1EyTe3cHNCAKHV+W1iCmt4
 +/GAewuVrcPZELJwnqTaqSl6ksDYrERY8Dq9fw4h2+CHvHDl7VV6icbqaK0U4wgEuQWU
 IhuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=AATBq83D2+ywguE0nv59dn0h6WNOb0FPiLV9i1Y1w0U=;
 b=R/FMSNAzve0UmZbrHgfwfIBaJG8zD5wR98MoNMfp9qWTzxEjCSQt1P97mWoFhnsFVM
 KY3Rj59gufeB0hOTtKBUYMTY38MThrJKFQuhGhVh9S6aecxldL64wSlnoO6mZpwn7CbP
 NF7VpEc2Zwo3a7+7z6B0OhHda62OMyZkghAX99pHuE7r8xEcxgT9OVKunChhh/POQHp9
 Qy/p+mAtvExuE8QHq6SBGRfyUzcgSJSJHUzhwjRAKV5RC02kt64yLpDkcNMno+YPdoCn
 OY3/IOIKqmRGRaosP0bk0uTtLNqxlvdhSmmqbjfiKEdGVGJvLfKgRl/VDojMAMAKSH6t
 4uPw==
X-Gm-Message-State: AOAM531BalZc/NcuFGViruZ5/Y115GRYh1aOMdblErso5LVvxCnnuu3R
 k89LJ/ZO5Go2LNLepX6L2gFcKDTcTq4N5hRv+9o=
X-Google-Smtp-Source: ABdhPJzr81fPQcsvyafU6YYp60smOzfchNyF0EI+ZW5C+eTPNo2ZkfGD0l8hks2Vf/nLAI+lkTTxoNoFheBcbNK8puA=
X-Received: by 2002:aa7:d916:: with SMTP id a22mr56827214edr.122.1609457962533; 
 Thu, 31 Dec 2020 15:39:22 -0800 (PST)
MIME-Version: 1.0
References: <CAPv7TjaZEPviBw=tAk7eZ1Wc_FCdRuyHB0xK+Wr3QREB75BwHw@mail.gmail.com>
 <6eK97Mb_R3DEEsCsBa7_t2qi8dEiChCRNWFowyTY-hrpDcKcR_lrb8tfWh6jMpzS5tz1GL8odiXRNig5W9F83ryZD2WQ7vjOFxoJatFhhSo=@protonmail.com>
In-Reply-To: <6eK97Mb_R3DEEsCsBa7_t2qi8dEiChCRNWFowyTY-hrpDcKcR_lrb8tfWh6jMpzS5tz1GL8odiXRNig5W9F83ryZD2WQ7vjOFxoJatFhhSo=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Fri, 1 Jan 2021 00:39:10 +0100
Message-ID: <CAPv7TjaZ2zPH33yPrW8hO=M7X8R3rDN+O8-R-JuUs6vRUH1Ovg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000023478505b7cb2291"
X-Mailman-Approved-At: Fri, 01 Jan 2021 00:18:55 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Softchains: Sidechains as a Soft Fork via
 Proof-of-Work Fraud Proofs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Dec 2020 23:39:26 -0000

--00000000000023478505b7cb2291
Content-Type: text/plain; charset="UTF-8"

Happy new morning ZmnSCPxj,

Thanks for taking a look :)

>If sidechains are for experimental new features, then softforking in a new
sidechain with novel untested new features would be additionally risky

There is definitely a risk, but it's one that can be minimized. For
instance, a softchain with Confidential Transactions could be introduced,
which allows for appealing privacy features without introducing a
completely new code base.

>If sidechains are for scaling, then I would like to remind anyone reading
this that ***blockchains do not scale***

I agree, you will still run into limitations, but you do get some scaling
gains from not having to verify each chain, but only the subset that
interests you.

>you would be splitting the global energy budget for blockchain security
among multiple blockchains

Not necessarily if you incorporate Merged Mining, but of course that comes
with the tradeoff of requiring miners to do more validation.

Cheers,
Ruben

On Fri, Jan 1, 2021 at 12:26 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Ruben, and list,
>
> First and foremost --- what is the point of sidechains, in the first place?
>
> If sidechains are for experimental new features, then softforking in a new
> sidechain with novel untested new features would be additionally risky ---
> as you note, a bug in the sidechain consensus may cause non-deterministic
> consensus in the sidechain which would propagate into mainchain.
> Federated sidechains, which already are enabled on current Bitcoin, are
> safer here, as mainchain will only care about the k-of-n signature that the
> federation agrees on, and if the federation is unable to come to consensus
> due to a sidechain consensus bug, "fails safe" in that it effectively
> disables the peg-out back to mainchain and restricts the consensus problem
> to the sidechain.
>
> If sidechains are for scaling, then I would like to remind anyone reading
> this that ***blockchains do not scale***, and adding more blockchains for
> the purpose of scaling is *questionable*.
> "I have a scaling problem.
> I know, I will add a sidechain!
> Now I have two scaling problems."
>
> Ultimately, proof-of-work is about energy expenditure, and you would be
> splitting the global energy budget for blockchain security among multiple
> blockchains, thus making each blockchain easier to 51%.
>
> Regards,
> ZmnSCPxj
>
> > Hi everyone,
> >
> > This post describes a fully decentralized two-way peg sidechain design.
> Activating new sidechains requires a soft fork, hence the name softchains.
> The key aspect is that all softchains are validated by everyone via
> Proof-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus
> mechanism that only requires the validation of disputed blocks. This does
> increase the validation burden of mainchain full nodes, but only by a
> minimal amount (~100MB per chain per year). It's similar to drivechains[0],
> but without the major downside of having to rely on miners, since all
> Bitcoin full node users can efficiently validate each sidechain.
> >
> > Proof-of-Work Fraud Proofs
> >
> > Last year I posted the idea of PoW FP to the Bitcoin mailing list[1][2].
> The idea is that we can use the existence of a fork in Bitcoin's PoW as
> evidence that a block might be invalid (i.e. a proof of potential fraud).
> Whenever this occurs, we download the block in question to verify whether
> it was valid (and available), and reject it if it was not. We forego the
> need for maintaining a UTXO set with UTXO set commitments (such as
> utreexo[3]), by assuming that the commitment inside the last block to exist
> in both forks is valid. As a result, we only need to download as many
> blocks (and their corresponding UTXO set proofs) as there are orphans,
> which lowers the validation costs considerably compared to running a full
> node.
> >
> > In the past 4 months, Forkmonitor has registered 11 stale and invalid
> blocks[4]. Extrapolating from that data, a PoW FP node verifying Bitcoin
> consensus would have to download and verify a little over 100MB per year in
> order to have consensus guarantees that come close to that of a full node:
> > - All PoW headers (~4MB per year)
> > - 3 x 11 = 33 full blocks (~2MB x 33 = 66MB)
> > - UTXO merkle proofs (~1MB x 33 = 33MB with utreexo)
> >
> > The reason consensus is considered slow, is because we need to allow
> time for a honest PoW minority to fork away from an invalid chain. If we
> assume only 1% of all miners are honest, this means consensus slows down by
> 100x. If you are normally satisfied waiting for 6 confirmations, you now
> need to wait 600 confirmations. The longer you wait, the less honest miners
> you need.
> >
> > Softchains
> >
> > In order to have two-way pegged sidechains, you need a succinct method
> for proving to the mainchain that a peg-out is valid. PoW FP provides
> exactly that -- a low-bandwidth way of determining if a chain, and thus a
> peg-out, is valid. The slowness of PoW FP consensus is not an issue, as
> peg-outs can be made arbitrarily slow (e.g. one year).
> >
> > The safest design would be a set of softchains that shares its consensus
> code with Bitcoin Core, with the addition of UTXO set commitments, and
> disabling non-taproot address types to minimize certain resource usage
> issues[5]. All users validate the mainchain as usual with their full node,
> and all softchains are validated with PoW FP consensus. If a user is
> interested in directly using a specific softchain, they should run it as a
> full node in order to get fast consensus.
> >
> > Peg-ins occur by freezing coins on the mainchain and assigning them to a
> softchain. Peg-outs occur by creating a mainchain transaction that points
> to a peg-out transaction on a softchain and waiting for a sufficient number
> of mainchain confirmations. If the peg-out transaction remains part of the
> softchain according to PoW FP consensus, the coins become spendable.
> >
> > The peg-in/peg-out mechanism itself would require a soft fork (the exact
> design is an open question), and subsequently every softchain that gets
> activated will also require a soft fork.
> >
> > Potential dangers
> >
> > Softchain consensus still requires a form of validation from mainchain
> users, which means that consensus bugs can have an adverse effect. In
> particular, if a softchain suffers from a non-deterministic consensus bug,
> it may be the case that a majority accepts a peg-in, while a minority
> rejects it. This specific scenario could cause a chain split in mainchain
> consensus. This is why it would be safest to base softchain designs on
> Bitcoin Core.
> >
> > Similarly, it can theoretically be possible that a softchain gets a
> major reorg, invalidating a peg-out right as it would have become accepted
> on the mainchain, thus splitting consensus. The slow peg-out process makes
> this increasingly unlikely, but not impossible. One thing that might help
> (or perhaps only make it worse) is introducing a consensus rule that
> disallows reorgs that are bigger than half the peg-out time (e.g. half a
> year, if the peg-out is one year). This kind of rule does not actually
> solve this consensus problem, but instead pushes the problem forward so it
> plays out first on the softchain, giving time to take action before the
> problem affects the mainchain.
> >
> > It is also important that each softchain produces a non-trivial amount
> of PoW, because if the difficulty is too low, the cost of creating forks
> and increasing the resource usage of PoW FP consensus goes down. It may
> therefore make sense to have a minimum accepted difficulty for softchain
> blocks (slowing down the chain when fees are not sufficient). Merged Mining
> could also help here, since that would allow the softchains to potentially
> receive the same hashrate as Bitcoin (assuming all miners participate), but
> of course this would also put an additional validation burden on miners.
> >
> > In closing
> >
> > It may turn out that the consensus risks outlined above make this
> prohibitively risky, but at the very least it seems worth exploring the
> possibilities. At a minimum it would provide more opt-in block space, and
> it could potentially open the door to chains with entirely different
> consensus rules.
> >
> > Thank you for taking the time to read and comprehend my work. I will
> happily answer any questions and I look forward to any feedback on issues
> that I might have overlooked, and ideas on mitigating problems to ensure
> maximum safety.
> >
> > Hopefully this will bring decentralized two-way peg sidechains one step
> closer to becoming a reality.
> >
> > Happy new year, everyone.
> >
> > -- Ruben Somsen
> >
> > This post is mirrored and kept up-to-date here:
> > https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1
> >
> > [0] Drivechains
> > https://www.drivechain.info/
> >
> > [1] PoW FP
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016873.html
> >
> > [2] PoW FP without a soft fork
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017287.html
> >
> > [3]: utreexo
> > https://eprint.iacr.org/2019/611.pdf
> >
> > [4]: Forkmonitor
> > https://forkmonitor.info/notifications
> >
> > [5]: Harding on worst-case utreexo
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017298.html
>
>
>

--00000000000023478505b7cb2291
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Happy new morning ZmnSCPxj,<div><br></div><div>Thanks for =
taking a look :)<br><div><br></div><div>&gt;If sidechains are for experimen=
tal new features, then softforking in a new sidechain with novel untested n=
ew features would be additionally risky<br></div></div><div><br></div><div>=
There is definitely a risk, but it&#39;s one that can be minimized. For ins=
tance, a softchain with Confidential Transactions could be introduced, whic=
h allows for appealing privacy features without introducing a completely=C2=
=A0new code base.</div><div><br></div><div>&gt;If sidechains are for scalin=
g, then I would like to remind anyone reading this that ***blockchains do n=
ot scale***</div><div><br></div><div>I agree, you will still run into limit=
ations, but you do get some scaling gains from not having to verify each ch=
ain, but only the subset that interests you.</div><div><br></div><div>&gt;y=
ou would be splitting the global energy budget for blockchain security amon=
g multiple blockchains</div><div><br></div><div>Not necessarily if you inco=
rporate Merged Mining, but of course that comes with the tradeoff of requir=
ing miners to do more validation.</div><div><br></div><div>Cheers,</div><di=
v>Ruben</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Fri, Jan 1, 2021 at 12:26 AM ZmnSCPxj &lt;<a href=3D"mailto=
:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Good morning Ruben, and li=
st,<br>
<br>
First and foremost --- what is the point of sidechains, in the first place?=
<br>
<br>
If sidechains are for experimental new features, then softforking in a new =
sidechain with novel untested new features would be additionally risky --- =
as you note, a bug in the sidechain consensus may cause non-deterministic c=
onsensus in the sidechain which would propagate into mainchain.<br>
Federated sidechains, which already are enabled on current Bitcoin, are saf=
er here, as mainchain will only care about the k-of-n signature that the fe=
deration agrees on, and if the federation is unable to come to consensus du=
e to a sidechain consensus bug, &quot;fails safe&quot; in that it effective=
ly disables the peg-out back to mainchain and restricts the consensus probl=
em to the sidechain.<br>
<br>
If sidechains are for scaling, then I would like to remind anyone reading t=
his that ***blockchains do not scale***, and adding more blockchains for th=
e purpose of scaling is *questionable*.<br>
&quot;I have a scaling problem.<br>
I know, I will add a sidechain!<br>
Now I have two scaling problems.&quot;<br>
<br>
Ultimately, proof-of-work is about energy expenditure, and you would be spl=
itting the global energy budget for blockchain security among multiple bloc=
kchains, thus making each blockchain easier to 51%.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
&gt; Hi everyone,<br>
&gt;<br>
&gt; This post describes a fully decentralized two-way peg sidechain design=
. Activating new sidechains requires a soft fork, hence the name softchains=
. The key aspect is that all softchains are validated by everyone via Proof=
-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus mecha=
nism that only requires the validation of disputed blocks. This does increa=
se the validation burden of mainchain full nodes, but only by a minimal amo=
unt (~100MB per chain per year). It&#39;s similar to drivechains[0], but wi=
thout the major downside of having to rely on miners, since all Bitcoin ful=
l node users can efficiently validate each sidechain.<br>
&gt;<br>
&gt; Proof-of-Work Fraud Proofs<br>
&gt;<br>
&gt; Last year I posted the idea of PoW FP to the Bitcoin mailing list[1][2=
]. The idea is that we can use the existence of a fork in Bitcoin&#39;s PoW=
 as evidence that a block might be invalid (i.e. a proof of potential fraud=
). Whenever this occurs, we download the block in question to verify whethe=
r it was valid (and available), and reject it if it was not. We forego the =
need for maintaining a UTXO set with UTXO set commitments (such as utreexo[=
3]), by assuming that the commitment inside the last block to exist in both=
 forks is valid. As a result, we only need to download as many blocks (and =
their corresponding UTXO set proofs) as there are orphans, which lowers the=
 validation costs considerably compared to running a full node.<br>
&gt;<br>
&gt; In the past 4 months, Forkmonitor has registered 11 stale and invalid =
blocks[4]. Extrapolating from that data, a PoW FP node verifying Bitcoin co=
nsensus would have to download and verify a little over 100MB per year in o=
rder to have consensus guarantees that come close to that of a full node:<b=
r>
&gt; - All PoW headers (~4MB per year)<br>
&gt; - 3 x 11 =3D 33 full blocks (~2MB x 33 =3D 66MB)<br>
&gt; - UTXO merkle proofs (~1MB x 33 =3D 33MB with utreexo)<br>
&gt;<br>
&gt; The reason consensus is considered slow, is because we need to allow t=
ime for a honest PoW minority to fork away from an invalid chain. If we ass=
ume only 1% of all miners are honest, this means consensus slows down by 10=
0x. If you are normally satisfied waiting for 6 confirmations, you now need=
 to wait 600 confirmations. The longer you wait, the less honest miners you=
 need.<br>
&gt;<br>
&gt; Softchains<br>
&gt;<br>
&gt; In order to have two-way pegged sidechains, you need a succinct method=
 for proving to the mainchain that a peg-out is valid. PoW FP provides exac=
tly that -- a low-bandwidth way of determining if a chain, and thus a peg-o=
ut, is valid. The slowness of PoW FP consensus is not an issue, as peg-outs=
 can be made arbitrarily slow (e.g. one year).<br>
&gt;<br>
&gt; The safest design would be a set of softchains that shares its consens=
us code with Bitcoin Core, with the addition of UTXO set commitments, and d=
isabling non-taproot address types to minimize certain resource usage issue=
s[5]. All users validate the mainchain as usual with their full node, and a=
ll softchains are validated with PoW FP consensus. If a user is interested =
in directly using a specific softchain, they should run it as a full node i=
n order to get fast consensus.<br>
&gt;<br>
&gt; Peg-ins occur by freezing coins on the mainchain and assigning them to=
 a softchain. Peg-outs occur by creating a mainchain transaction that point=
s to a peg-out transaction on a softchain and waiting for a sufficient numb=
er of mainchain confirmations. If the peg-out transaction remains part of t=
he softchain according to PoW FP consensus, the coins become spendable.<br>
&gt;<br>
&gt; The peg-in/peg-out mechanism itself would require a soft fork (the exa=
ct design is an open question), and subsequently every softchain that gets =
activated will also require a soft fork.<br>
&gt;<br>
&gt; Potential dangers<br>
&gt;<br>
&gt; Softchain consensus still requires a form of validation from mainchain=
 users, which means that consensus bugs can have an adverse effect. In part=
icular, if a softchain suffers from a non-deterministic consensus bug, it m=
ay be the case that a majority accepts a peg-in, while a minority rejects i=
t. This specific scenario could cause a chain split in mainchain consensus.=
 This is why it would be safest to base softchain designs on Bitcoin Core.<=
br>
&gt;<br>
&gt; Similarly, it can theoretically be possible that a softchain gets a ma=
jor reorg, invalidating a peg-out right as it would have become accepted on=
 the mainchain, thus splitting consensus. The slow peg-out process makes th=
is increasingly unlikely, but not impossible. One thing that might help (or=
 perhaps only make it worse) is introducing a consensus rule that disallows=
 reorgs that are bigger than half the peg-out time (e.g. half a year, if th=
e peg-out is one year). This kind of rule does not actually solve this cons=
ensus problem, but instead pushes the problem forward so it plays out first=
 on the softchain, giving time to take action before the problem affects th=
e mainchain.<br>
&gt;<br>
&gt; It is also important that each softchain produces a non-trivial amount=
 of PoW, because if the difficulty is too low, the cost of creating forks a=
nd increasing the resource usage of PoW FP consensus goes down. It may ther=
efore make sense to have a minimum accepted difficulty for softchain blocks=
 (slowing down the chain when fees are not sufficient). Merged Mining could=
 also help here, since that would allow the softchains to potentially recei=
ve the same hashrate as Bitcoin (assuming all miners participate), but of c=
ourse this would also put an additional validation burden on miners.<br>
&gt;<br>
&gt; In closing<br>
&gt;<br>
&gt; It may turn out that the consensus risks outlined above make this proh=
ibitively risky, but at the very least it seems worth exploring the possibi=
lities. At a minimum it would provide more opt-in block space, and it could=
 potentially open the door to chains with entirely different consensus rule=
s.<br>
&gt;<br>
&gt; Thank you for taking the time to read and comprehend my work. I will h=
appily answer any questions and I look forward to any feedback on issues th=
at I might have overlooked, and ideas on mitigating problems to ensure maxi=
mum safety.<br>
&gt;<br>
&gt; Hopefully this will bring decentralized two-way peg sidechains one ste=
p closer to becoming a reality.<br>
&gt;<br>
&gt; Happy new year, everyone.<br>
&gt;<br>
&gt; -- Ruben Somsen<br>
&gt;<br>
&gt; This post is mirrored and kept up-to-date here:<br>
&gt; <a href=3D"https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed881=
5a02f13d1" rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/Rub=
enSomsen/7ecf7f13dc2496aa7eed8815a02f13d1</a><br>
&gt;<br>
&gt; [0] Drivechains<br>
&gt; <a href=3D"https://www.drivechain.info/" rel=3D"noreferrer" target=3D"=
_blank">https://www.drivechain.info/</a><br>
&gt;<br>
&gt; [1] PoW FP<br>
&gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
9-April/016873.html" rel=3D"noreferrer" target=3D"_blank">https://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2019-April/016873.html</a><br>
&gt;<br>
&gt; [2] PoW FP without a soft fork<br>
&gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
9-September/017287.html" rel=3D"noreferrer" target=3D"_blank">https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017287.html</a><b=
r>
&gt;<br>
&gt; [3]: utreexo<br>
&gt; <a href=3D"https://eprint.iacr.org/2019/611.pdf" rel=3D"noreferrer" ta=
rget=3D"_blank">https://eprint.iacr.org/2019/611.pdf</a><br>
&gt;<br>
&gt; [4]: Forkmonitor<br>
&gt; <a href=3D"https://forkmonitor.info/notifications" rel=3D"noreferrer" =
target=3D"_blank">https://forkmonitor.info/notifications</a><br>
&gt;<br>
&gt; [5]: Harding on worst-case utreexo<br>
&gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
9-September/017298.html" rel=3D"noreferrer" target=3D"_blank">https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017298.html</a><b=
r>
<br>
<br>
</blockquote></div>

--00000000000023478505b7cb2291--