path: root/39/5d6b7f6bcfbd4aa5baa8a868aaa2cbf0d53eec

Return-Path: <sergio.d.lerner@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C9D72C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 23:38:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 8D05C86C06
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 23:38:37 +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 5AQ7affyZTnG
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 23:38:36 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com
 [209.85.216.51])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id EEDD286BF7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 23:38:35 +0000 (UTC)
Received: by mail-pj1-f51.google.com with SMTP id hk16so5974456pjb.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 15:38:35 -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;
 bh=8fi1Klo6RONc/JcA4KH7l5ygABOHuTRxDQoU79uJPOI=;
 b=n4437MhVRkukzW/VX6zbIrDQxuNr1Hh4Qgi31KNILWbpB1lMZuX64V8ThI53FaQWp0
 x9TXYH4uXW1MywfiBTeCP7xX7pmgEsiFYl/RmRmQ/1KJwLK7T0goBPtODvQiyPyqph/6
 0EiXaZp1BvYwyQhiTNo5LyZr0JTZzI+NpICFmKVMj8YtGCmFFjo0yvHfR59lS2ZZi7jL
 Cxn47cG7AAKJY5b3vOUVAPUw4wKMOew3pRYLHetUqonpeUeUZU6SCQE1DDItozcW1n+P
 l+FykUBg8Jf5O+CQ6ze2xKE8m2PXN+0TaGMFKWisyP+ZD5CVm+93shyehcuDumAPsql0
 2RSw==
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;
 bh=8fi1Klo6RONc/JcA4KH7l5ygABOHuTRxDQoU79uJPOI=;
 b=l/AmkR/zvSRCY4iJg5GBAdcuppY7UBpPM4G8a4/cqns8Ld27kuqHGmOYqcixW3g9s3
 5Nigzai3OthynSzF0QMfXx7Da6xIqHb7apPGeZ1HnWDuJlJ8tO0j1CmFRloC9tB/vsxP
 U5A39cXgYOG+ENW3lX6rZbFjn7vEhv1tTttqw7DNXhJFbtgfqa6LQ1jz/wcK1FHsdBRw
 fZuuNFY4fXcCAaKBpkBVsrSUpMch3yeB/myFHpGnQPnQkPIQAjGHNKKJC9CFEVz+IiDi
 KoCmiPJo2IuUfw7+xw2dtEvn5Rl6sbcmeeeX1rxa+2mm/7RmdVfx50bhrFbLASzJhGPr
 I3wg==
X-Gm-Message-State: AOAM532EF55eiiGw46gL/qCaPsCeRMFsQY81khJCDQbYh5St6VHFop5b
 bVsINkqURwYeATNDb4OBH+QRqw+F+9xecShFwa4=
X-Google-Smtp-Source: ABdhPJxumktT63JeM3C8e5+OFgR0W/QfMjPK9LZAtvHsnN9ZcgMVTC2HPNL/cAeznclNo8WlEBfcKFGi2Zl9WCByaw8=
X-Received: by 2002:a17:90a:d48f:: with SMTP id
 s15mr15254508pju.137.1609457915334; 
 Thu, 31 Dec 2020 15:38:35 -0800 (PST)
MIME-Version: 1.0
References: <CAPv7TjaZEPviBw=tAk7eZ1Wc_FCdRuyHB0xK+Wr3QREB75BwHw@mail.gmail.com>
In-Reply-To: <CAPv7TjaZEPviBw=tAk7eZ1Wc_FCdRuyHB0xK+Wr3QREB75BwHw@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Thu, 31 Dec 2020 20:37:58 -0300
Message-ID: <CAKzdR-rWe6ecFV6AjxEzBKnH=+PYdfkuuo0-Su8-SPj=SQrS9A@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005315e705b7cb1f6a"
X-Mailman-Approved-At: Fri, 01 Jan 2021 00:18:55 +0000
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:38:38 -0000

--0000000000005315e705b7cb1f6a
Content-Type: text/plain; charset="UTF-8"

Hi Roben,
 It's an interesting proposal, but I have two issues with it, one technical
and one philosophical.

On the technical side, I don't understand how your proposal prevents miners
proposing a peg-out for an invalid sidechain fork which is not made
available to the nodes (there are missing blocks). It seems that the system
would need to allow users to challenge miners to make available full
sidechain blocks that are missing, which really complicates the protocol.

On the philosophical side, as you mentioned, it is very limited in the
types of sidechains it can verify. I won't be able to verify RSK
(merge-mined with Bitcoin, but with different block format and different
functionality). It cannot verify a zCash-like sidechain for the same
reasons. Therefore it is strictly a payment scalability solution.
Drivechains, on the other hand, enable many new use cases apart from
scaling, which have a much lower level of complexity (if implemented
correctly).

Since the inception of RSK sidechain, I suggested in its white-paper that
sidechains should be designed to support an hybrid peg-out system, based on
both a large multisig AND a drivechain, where both groups need to agree for
the peg-out to occur.  It's a censorship/security trade-off that most users
would be willing to accept until a trusted-setup-free SNARK-like based
solution is finally available.
Until we have a sidechain-selectable SNARK-like succinct verification of
any block state transition function, having a single succint proof to cover
the whole sidechain validity, as in Coda (now renamed Mina), drivechains
are the low-hanging-fruit.

regards

On Thu, Dec 31, 2020 at 7:01 PM Ruben Somsen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi Roben,<div>=C2=A0It&#39;s an interesti=
ng=C2=A0proposal, but I have two issues with it, one technical and one phil=
osophical.</div><div><br></div><div>On the technical side, I don&#39;t unde=
rstand how your proposal prevents miners proposing a peg-out for an invalid=
 sidechain fork which is not made available to the nodes (there are missing=
 blocks). It seems that the system would need to allow users to challenge m=
iners to make available full sidechain blocks that are missing, which reall=
y complicates the protocol.=C2=A0</div><div><br></div><div>On the philosoph=
ical side, as you mentioned, it is very limited in the types of sidechains =
it can verify. I won&#39;t be able to verify RSK (merge-mined with Bitcoin,=
 but with different block format and different functionality). It cannot ve=
rify a zCash-like sidechain for the same reasons. Therefore it is strictly =
a payment scalability solution. Drivechains, on the other hand, enable many=
 new use cases apart from scaling, which have a much lower level of complex=
ity (if implemented correctly).</div><div><br></div><div>Since the inceptio=
n of RSK sidechain, I suggested in its white-paper that sidechains=C2=A0sho=
uld be designed to support an hybrid peg-out system, based on both a large =
multisig AND a drivechain, where both groups need to agree for the peg-out =
to occur.=C2=A0 It&#39;s a censorship/security trade-off that most users wo=
uld be willing to accept until a trusted-setup-free SNARK-like based soluti=
on is finally available.<br></div><div><div>Until we have a sidechain-selec=
table SNARK-like succinct=C2=A0verification of any block state transition f=
unction, having a single succint proof to cover the whole sidechain validit=
y, as in Coda (now renamed Mina), drivechains are the low-hanging-fruit.=C2=
=A0</div><div></div></div><div><br></div><div>regards</div></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Dec 31, =
2020 at 7:01 PM Ruben Somsen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div>Hi everyone,</div><div><br></div>This post describes a fully=
 decentralized two-way peg sidechain design. Activating new sidechains requ=
ires a soft fork, hence the name softchains. The key aspect is that all sof=
tchains are validated by everyone via Proof-of-Work Fraud Proofs (PoW FP) -=
- a slow but very efficient consensus mechanism that only requires the vali=
dation of disputed blocks. This does increase the validation burden of main=
chain full nodes, but only by a minimal amount (~100MB per chain per year).=
 It&#39;s similar to drivechains[0], but without the major downside of havi=
ng to rely on miners, since all Bitcoin full node users can efficiently val=
idate each sidechain.<br><br><br>Proof-of-Work Fraud Proofs<br><br>Last yea=
r I posted the idea of PoW FP to the Bitcoin mailing list[1][2]. The idea i=
s 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 t=
his occurs, we download the block in question to verify whether it was vali=
d (and available), and reject it if it was not. We forego the need for main=
taining a UTXO set with UTXO set commitments (such as utreexo[3]), by assum=
ing that the commitment inside the last block to exist in both forks is val=
id. As a result, we only need to download as many blocks (and their corresp=
onding UTXO set proofs) as there are orphans, which lowers the validation c=
osts considerably compared to running a full node.<br><br>In the past 4 mon=
ths, Forkmonitor has registered 11 stale and invalid blocks[4]. Extrapolati=
ng 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:<br>- All PoW headers (~=
4MB per year)<br>- 3 x 11 =3D 33 full blocks (~2MB x 33 =3D 66MB)<br>- UTXO=
 merkle proofs (~1MB x 33 =3D 33MB with utreexo) <br><br>The reason consens=
us is considered slow, is because we need to allow time for a honest PoW mi=
nority to fork away from an invalid chain. If we assume only 1% of all mine=
rs are honest, this means consensus slows down by 100x. If you are normally=
 satisfied waiting for 6 confirmations, you now need to wait 600 confirmati=
ons. The longer you wait, the less honest miners you need.<br><br><br><div>=
Softchains<br><br>In order to have two-way pegged sidechains, you need a su=
ccinct 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).<br><br>The safe=
st 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 use=
rs 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 u=
sing a specific softchain, they should run it as a full node in order to ge=
t fast consensus.<br><br>Peg-ins occur by freezing coins on the mainchain a=
nd assigning them to a softchain. Peg-outs occur by creating a mainchain tr=
ansaction that points to a peg-out transaction on a softchain and waiting f=
or a sufficient number of mainchain confirmations. If the peg-out transacti=
on remains part of the softchain according to PoW FP consensus, the coins b=
ecome spendable.<br><br>The peg-in/peg-out mechanism itself would require a=
 soft fork (the exact design is an open question), and subsequently every s=
oftchain that gets activated will also require a soft fork.<br><br><br></di=
v><div>Potential dangers<br><br>Softchain consensus still requires a form o=
f validation from mainchain users, which means that consensus bugs can have=
 an adverse effect. In particular, if a softchain suffers from a non-determ=
inistic 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 sp=
lit in mainchain consensus. This is why it would be safest to base softchai=
n designs on Bitcoin Core.<br><br>Similarly, it can theoretically be possib=
le 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.<br><br>It is also important that =
each softchain produces a non-trivial amount of PoW, because if the difficu=
lty is too low, the cost of creating forks and increasing the resource usag=
e of PoW FP consensus goes down. It may therefore make sense to have a mini=
mum accepted difficulty for softchain blocks (slowing down the chain when f=
ees are not sufficient). Merged Mining could also help here, since that wou=
ld allow the softchains to potentially receive the same hashrate as Bitcoin=
 (assuming all miners participate), but of course this would also put an ad=
ditional validation burden on miners.<br><br><br></div><div>In closing<br><=
br>It may turn out that the consensus risks outlined above make this prohib=
itively risky, but at the very least it seems worth exploring the possibili=
ties. At a minimum it would provide more opt-in block space, and it could p=
otentially open the door to chains with entirely different consensus rules.=
<br><br>Thank you for taking the time to read and comprehend my work. I wil=
l 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 m=
aximum safety.<br><br>Hopefully this will bring decentralized two-way peg s=
idechains one step closer to becoming a reality.<br><br>Happy new year, eve=
ryone.<br><br><br>-- Ruben Somsen<br></div><div><br></div><div><br></div><d=
iv><br></div><div>This post is mirrored and kept up-to-date here:</div><div=
><a href=3D"https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02=
f13d1" target=3D"_blank">https://gist.github.com/RubenSomsen/7ecf7f13dc2496=
aa7eed8815a02f13d1</a></div><div><br></div><div><br></div><div>[0] Drivecha=
ins</div><div><a href=3D"https://www.drivechain.info/" target=3D"_blank">ht=
tps://www.drivechain.info/</a><br><br>[1] PoW FP</div><div><a href=3D"https=
://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016873.html" =
target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2=
019-April/016873.html</a><br><br>[2] PoW FP without a soft fork</div><div><=
a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Sept=
ember/017287.html" target=3D"_blank">https://lists.linuxfoundation.org/pipe=
rmail/bitcoin-dev/2019-September/017287.html</a><br><br>[3]: utreexo</div><=
div><a href=3D"https://eprint.iacr.org/2019/611.pdf" target=3D"_blank">http=
s://eprint.iacr.org/2019/611.pdf</a><br><br>[4]: Forkmonitor</div><div><a h=
ref=3D"https://forkmonitor.info/notifications" target=3D"_blank">https://fo=
rkmonitor.info/notifications</a><br><br>[5]: Harding on worst-case utreexo<=
/div><div><a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2019-September/017298.html" target=3D"_blank">https://lists.linuxfoundati=
on.org/pipermail/bitcoin-dev/2019-September/017298.html</a><br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--0000000000005315e705b7cb1f6a--