path: root/24/471ba6eaefd30a6f18bf61ba4a9286c2f9ed68

Return-Path: <el33th4x0r@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8BC2ED4B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 12 Dec 2015 21:01:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com
	[209.85.192.53])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4664689
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 12 Dec 2015 21:01:57 +0000 (UTC)
Received: by qgfb51 with SMTP id b51so19357318qgf.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 12 Dec 2015 13:01:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc:content-type;
	bh=eZlDLspXH0M8mzSTHGmnqB/kOoSH8FwQO4kO6cew07s=;
	b=yX9BMsKr+vAaqug205+pfHOtKj1Dh3LeWkzaxTR6n0A5Y+ZthvD4r0IG0XbrufzQhL
	hYaLV6WbWzBlK2tt/mbhMgi/7j51aqXUoXW28hO+QcdDiJl5O1NvWhRe4cx+l/ljVi7Z
	nqF+Um3eay4k4aEbTU86mzyNatNAStzoFd7rWNVtpuz7Xtx/Fce/9AWB7NVB/iubWhzY
	Q8hnl+Hn1wN52KKXzQaD+GVyISYUuluJt7rrlCVsXQpT3IKNKfqKcP9tfcqGEKTlNy79
	qogJ1sIn44WXFActCTyDXVhlnnJ7+C/NZzXIK/a5Hlfhj8GM0k1G+HsB92iKP8O0EmO8
	Y/bg==
X-Received: by 10.140.42.108 with SMTP id b99mr32050529qga.67.1449954116546;
	Sat, 12 Dec 2015 13:01:56 -0800 (PST)
MIME-Version: 1.0
References: <CAEj3M+wYicoACcpG5YUU6vF8vg98XCcJWmgBiyrJj-xHHxrhig@mail.gmail.com>
	<CABm2gDq3K2uUWx_itZQJH53EFOJKAWOLiy3NdHWGPvUOCm33wA@mail.gmail.com>
	<CAEj3M+ze9HU1KWoWT2nugw9hYY97jk_xsL8WUWqThq_wrXSAVg@mail.gmail.com>
	<CABm2gDr5rKNMerPebJ6b3ayJznEAAvu_zM76syooH-3MepSzXg@mail.gmail.com>
	<CAEj3M+yFPRA8iGzv-D+bQqchxwhqNEdLLwF_KNHGKqVBHNtTXQ@mail.gmail.com>
	<CABm2gDp--7Hkecop2h7yZNnJ5D0HnGF6t+uWK_G6-tHkC9q4Fg@mail.gmail.com>
In-Reply-To: <CABm2gDp--7Hkecop2h7yZNnJ5D0HnGF6t+uWK_G6-tHkC9q4Fg@mail.gmail.com>
From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@gmail.com>
Date: Sat, 12 Dec 2015 21:01:45 +0000
Message-ID: <CAPkFh0vk7M_oGR7hQKrgbs3WLdDnqVDagd7kNbVOXzxWkqZXeQ@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>, 
	Luke Durback <luke.durback@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c118d80eb9530526b9c050
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW, URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sat, 12 Dec 2015 21:01:58 -0000

--001a11c118d80eb9530526b9c050
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

.,
,
/.
, /,

,.
   / ,
..
,,,  . // .,      .

_. ...  ..   ._.

,    _


,



,
,
  , , ...     _  _.

,.

.  ,.,    _.
.,    ,  ..
,

,,

._

.  .

_
.
,
,     ,    ,   /..,,

/ ,

.     .

_
.,. _.. ,
,

.. _
   ..

,.,, _
, _
,
///
. ,

   / . ,.
  ,
,.,
. ,
, .,   ,. ._ ,  ,,,//

,        ,
.

,

,
  . . ,

, //  .
,  ,
/

      _,.

, . ,, .

..
  /,/ .
.


  .   .,,_//
,,
.,  .

.  /_. ,
/
.
  /
.._
.
,, / .
   . _ ,
,  ,
/     ,    _ .,
, ,,, ..  ,
  ,

  /.,.
  /. /
. ,/  ,

. .   /,
/,
._
   ,/.
_
.,
,//
, .,,, , ,    , ,
,

,.   ,.,.  .

,  .    ,.  .,   ,
/   _
.
/
  ,.,. ,
,._


,,

, _ _ ,

,
. ,,   ,  _


_..,

  ,
// ,
__ /
!;"$'''. b
    __

On Sat, Dec 12, 2015, 3:01 PM Jorge Tim=C3=B3n <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback <luke.durback@gmail.com>
> wrote:
> >>If it's voting for something consensus, you will need something special=
.
> If
> >> it's not consensus (ie external) thw voting doesn't have to hit the
> chain at
> >> all.
> >
> > I had in mind voting for something that can't be trusted if done
> externally:
> > Perhaps BIPs for instance.  People would somehow "mark" their BTC as
> being
> > "For Proposition X" (as opposed to all other propositions) and the vote
> > would be canceled as soon as the BTC is spent again.
> >
> > Unfortunately, I've spent the past 2 days trying to find a design that
> would
> > allow this (I don't think my original suggestion made sense in the
> context
> > of how transactions work), and I haven't gotten much yet.
>
> Well, as said, if it's for consensus, you will need to adapt the
> system in a special way anyway, but I still don't see why turing
> completeness is required.
> This type of idea is not new. Since miners can censor votes (and
> that's undetectable for consensus), several solutions have been
> proposed, time lock the votes, for example.
>
> >>But each scriptSig is only executed once with its corresponding
> >> scriptPubKey. Are you proposing we change that?
> >
> > Sorry, I didn't understand Bitcoin's transaction model well enough when=
 I
> > first made the proposal.  If Turing Pseudo-Completeness is possible wit=
h
> > Bitcoin, then I understand now that it could not require you to execute=
 a
> > script more than once.  My current thought is that recursion can be
> > accomplished via checking if the next output's scriptPubKey is identica=
l
> in
> > every way to the current scriptPubKey.  Unfortunately, a lot more is
> needed
> > than just recursion in order to do on-chain BTC voting the way I have i=
n
> > mind.  I'll keep working on this.
>
> What you call "recursion" seems similar to what we usually call
> "covenants", see
>
> https://bitcointalk.org/index.php?topic=3D278122.0
>
> Although the thread says "an amusingly bad idea", I think it's
> actually a great idea and there's some use cases that are very hard to
> support without covenants.
> Again, no Turing completeness required for this.
>
> > On Fri, Dec 11, 2015 at 10:36 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> w=
rote:
> >>
> >>
> >> On Dec 10, 2015 7:36 AM, "Luke Durback" <luke.durback@gmail.com> wrote=
:
> >> >
> >> > Tomorrow, I'll work on writing a way to do voting on proposals with
> BTC
> >> > used as voting shares (This will be difficult as I do not know
> FORTH).  That
> >> > seems like a fairly simple, useful example that will require loops a=
nd
> >> > reused functions.  I'll add a fee that goes to the creator.
> >>
> >> If it's voting for something consensus, you will need something specia=
l.
> >> If it's not consensus (ie external) thw voting doesn't have to hit the
> chain
> >> at all.
> >> I don't see how "loops and reused functions" are needed in the scripti=
ng
> >> language for this use case, but I'm probably missing some details.
> Please,
> >> the more concrete you make your example, the easiest it will be for me
> to
> >> understand.
> >>
> >> > IMO, if you write a complicated system of scripts that's used
> >> > frequently, it makes sense to charge a fee for its usage.
> >>
> >> But each scriptSig is only executed once with its corresponding
> >> scriptPubKey. Are you proposing we change that?
> >>
> >> >  A decentralized exchange between colored coins, for instance might
> take
> >> > a small fee on each trade.
> >>
> >> I've been researching the topic of decentralized exchange from before
> the
> >> term "colored coins" was first used (now there's multiple designs and
> >> implementations); contributed to and reviewed many designs: none of th=
em
> >> (colored coins or not) required turing completeness.
> >> I'm sorry, but what you are saying here is too vague for me to
> concretely
> >> be able to refute the low level "needs" you claim your use cases to
> have.
> >>
> >> > On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev"
> >> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> > > This, combined with the ability to make new transactions arbitrari=
ly
> >> > > would allow a function to pay its creator.
> >> >
> >> > I don't understand what you mean by "a function" in this context, I
> >> > assume you mean a scriptSig, but then "paying its creator" doesn't
> make much
> >> > sense to me .
> >> >
> >> > Could you provide some high level examples of the use cases you woul=
d
> >> > like to support with this?
> >
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a11c118d80eb9530526b9c050
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
., <br>
 ,<br>
/. <br>
 , /,</p>
<p dir=3D"ltr"> ,.<br>
=C2=A0=C2=A0 / ,<br>
.. <br>
,,,=C2=A0 . // .,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 . </p>
<p dir=3D"ltr"> _. ...=C2=A0 ..=C2=A0=C2=A0 ._. </p>
<p dir=3D"ltr"> ,=C2=A0=C2=A0=C2=A0 _<br>
 <br></p>
<p dir=3D"ltr"> <br>
 , </p>
<p dir=3D"ltr"> <br>
=C2=A0 <br>
, <br>
, <br>
=C2=A0 , , ...=C2=A0=C2=A0=C2=A0=C2=A0 _=C2=A0 _.</p>
<p dir=3D"ltr">,.</p>
<p dir=3D"ltr">.=C2=A0 ,.,=C2=A0=C2=A0=C2=A0 _. <br>
.,=C2=A0=C2=A0=C2=A0 ,=C2=A0 ..=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>
, <br>
=C2=A0=C2=A0 <br>
 ,, <br>
=C2=A0 <br>
._</p>
<p dir=3D"ltr"> .=C2=A0 . </p>
<p dir=3D"ltr">_<br>
. <br>
 ,<br>
,=C2=A0=C2=A0=C2=A0=C2=A0 ,=C2=A0=C2=A0=C2=A0 ,=C2=A0=C2=A0 /..,,=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 </p>
<p dir=3D"ltr"> / ,=C2=A0 </p>
<p dir=3D"ltr">.=C2=A0=C2=A0=C2=A0=C2=A0 .=C2=A0 <br>
 <br>
 _<br>
.,. _.. ,<br>
,<br></p>
<p dir=3D"ltr"> .. _=C2=A0=C2=A0=C2=A0=C2=A0 <br>
=C2=A0=C2=A0 ..=C2=A0 <br>
=C2=A0 <br>
,.,, _<br>
 , _ <br>
,=C2=A0=C2=A0=C2=A0=C2=A0 <br>
/// <br>
. ,<br>
=C2=A0 <br>
=C2=A0=C2=A0 / . ,.<br>
=C2=A0 ,<br>
,.,<br>
 . ,=C2=A0 <br>
 , .,=C2=A0=C2=A0 ,. ._ ,=C2=A0 ,,,//=C2=A0 <br>
=C2=A0=C2=A0=C2=A0 <br>
,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 , <br>
.</p>
<p dir=3D"ltr">, <br>
 <br>
, <br>
=C2=A0 . . ,=C2=A0=C2=A0=C2=A0=C2=A0 </p>
<p dir=3D"ltr">, //=C2=A0 .=C2=A0 <br>
,=C2=A0 ,<br>
 /=C2=A0 </p>
<p dir=3D"ltr">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _,. </p>
<p dir=3D"ltr">, . ,, .<br>
 </p>
<p dir=3D"ltr">..=C2=A0=C2=A0=C2=A0=C2=A0 <br>
=C2=A0 /,/ .<br>
.<br>
=C2=A0=C2=A0=C2=A0=C2=A0 </p>
<p dir=3D"ltr">=C2=A0 .=C2=A0=C2=A0 .,,_//<br>
,, <br>
 .,=C2=A0 .<br><br></p>
<p dir=3D"ltr">.=C2=A0 /_. ,<br>
 / <br>
.=C2=A0 <br>
=C2=A0 / <br>
.._<br>
.<br>
,, / .<br>
=C2=A0=C2=A0 . _ ,<br>
,=C2=A0 ,=C2=A0 <br>
 /=C2=A0=C2=A0=C2=A0=C2=A0 ,=C2=A0=C2=A0=C2=A0 _ ., <br>
, ,,, ..=C2=A0 ,<br>
=C2=A0 ,<br>
=C2=A0=C2=A0=C2=A0 <br>
=C2=A0 /.,.<br>
=C2=A0 /. / <br>
. ,/=C2=A0 ,<br>
 <br>
. .=C2=A0=C2=A0 /,<br>
 /,<br>
._<br>
=C2=A0=C2=A0 ,/.=C2=A0 <br>
_<br>
., <br>
,// <br>
, .,,, , ,=C2=A0=C2=A0=C2=A0 , , <br>
,<br></p>
<p dir=3D"ltr"> ,.=C2=A0=C2=A0 ,.,.=C2=A0 . </p>
<p dir=3D"ltr">,=C2=A0 .=C2=A0=C2=A0=C2=A0 ,.=C2=A0 .,=C2=A0=C2=A0 ,<br>
 /=C2=A0=C2=A0 _<br>
.<br>
/<br>
=C2=A0 ,.,. ,=C2=A0 <br>
,._<br>
 <br>
=C2=A0 <br>
 ,,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>
=C2=A0 <br>
 , _ _ ,=C2=A0=C2=A0 <br>
=C2=A0=C2=A0 <br>
,<br>
. ,,=C2=A0=C2=A0 ,=C2=A0 _</p>
<p dir=3D"ltr">=C2=A0 <br>
 _..,<br><br></p>
<p dir=3D"ltr">=C2=A0 , <br>
 // , <br>
__ /<br>
!;&quot;$&#39;&#39;&#39;. b<br>
=C2=A0=C2=A0=C2=A0 __ </p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Dec 12, 2015, 3:01 =
PM=C2=A0Jorge Tim=C3=B3n &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback=
 &lt;<a href=3D"mailto:luke.durback@gmail.com" target=3D"_blank">luke.durba=
ck@gmail.com</a>&gt; wrote:<br>
&gt;&gt;If it&#39;s voting for something consensus, you will need something=
 special. If<br>
&gt;&gt; it&#39;s not consensus (ie external) thw voting doesn&#39;t have t=
o hit the chain at<br>
&gt;&gt; all.<br>
&gt;<br>
&gt; I had in mind voting for something that can&#39;t be trusted if done e=
xternally:<br>
&gt; Perhaps BIPs for instance.=C2=A0 People would somehow &quot;mark&quot;=
 their BTC as being<br>
&gt; &quot;For Proposition X&quot; (as opposed to all other propositions) a=
nd the vote<br>
&gt; would be canceled as soon as the BTC is spent again.<br>
&gt;<br>
&gt; Unfortunately, I&#39;ve spent the past 2 days trying to find a design =
that would<br>
&gt; allow this (I don&#39;t think my original suggestion made sense in the=
 context<br>
&gt; of how transactions work), and I haven&#39;t gotten much yet.<br>
<br>
Well, as said, if it&#39;s for consensus, you will need to adapt the<br>
system in a special way anyway, but I still don&#39;t see why turing<br>
completeness is required.<br>
This type of idea is not new. Since miners can censor votes (and<br>
that&#39;s undetectable for consensus), several solutions have been<br>
proposed, time lock the votes, for example.<br>
<br>
&gt;&gt;But each scriptSig is only executed once with its corresponding<br>
&gt;&gt; scriptPubKey. Are you proposing we change that?<br>
&gt;<br>
&gt; Sorry, I didn&#39;t understand Bitcoin&#39;s transaction model well en=
ough when I<br>
&gt; first made the proposal.=C2=A0 If Turing Pseudo-Completeness is possib=
le with<br>
&gt; Bitcoin, then I understand now that it could not require you to execut=
e a<br>
&gt; script more than once.=C2=A0 My current thought is that recursion can =
be<br>
&gt; accomplished via checking if the next output&#39;s scriptPubKey is ide=
ntical in<br>
&gt; every way to the current scriptPubKey.=C2=A0 Unfortunately, a lot more=
 is needed<br>
&gt; than just recursion in order to do on-chain BTC voting the way I have =
in<br>
&gt; mind.=C2=A0 I&#39;ll keep working on this.<br>
<br>
What you call &quot;recursion&quot; seems similar to what we usually call &=
quot;covenants&quot;, see<br>
<br>
<a href=3D"https://bitcointalk.org/index.php?topic=3D278122.0" rel=3D"noref=
errer" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D278122.0=
</a><br>
<br>
Although the thread says &quot;an amusingly bad idea&quot;, I think it&#39;=
s<br>
actually a great idea and there&#39;s some use cases that are very hard to<=
br>
support without covenants.<br>
Again, no Turing completeness required for this.<br>
<br>
&gt; On Fri, Dec 11, 2015 at 10:36 AM, Jorge Tim=C3=B3n &lt;jtimon@jtimon.c=
c&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Dec 10, 2015 7:36 AM, &quot;Luke Durback&quot; &lt;<a href=3D"m=
ailto:luke.durback@gmail.com" target=3D"_blank">luke.durback@gmail.com</a>&=
gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Tomorrow, I&#39;ll work on writing a way to do voting on prop=
osals with BTC<br>
&gt;&gt; &gt; used as voting shares (This will be difficult as I do not kno=
w FORTH).=C2=A0 That<br>
&gt;&gt; &gt; seems like a fairly simple, useful example that will require =
loops and<br>
&gt;&gt; &gt; reused functions.=C2=A0 I&#39;ll add a fee that goes to the c=
reator.<br>
&gt;&gt;<br>
&gt;&gt; If it&#39;s voting for something consensus, you will need somethin=
g special.<br>
&gt;&gt; If it&#39;s not consensus (ie external) thw voting doesn&#39;t hav=
e to hit the chain<br>
&gt;&gt; at all.<br>
&gt;&gt; I don&#39;t see how &quot;loops and reused functions&quot; are nee=
ded in the scripting<br>
&gt;&gt; language for this use case, but I&#39;m probably missing some deta=
ils. Please,<br>
&gt;&gt; the more concrete you make your example, the easiest it will be fo=
r me to<br>
&gt;&gt; understand.<br>
&gt;&gt;<br>
&gt;&gt; &gt; IMO, if you write a complicated system of scripts that&#39;s =
used<br>
&gt;&gt; &gt; frequently, it makes sense to charge a fee for its usage.<br>
&gt;&gt;<br>
&gt;&gt; But each scriptSig is only executed once with its corresponding<br=
>
&gt;&gt; scriptPubKey. Are you proposing we change that?<br>
&gt;&gt;<br>
&gt;&gt; &gt;=C2=A0 A decentralized exchange between colored coins, for ins=
tance might take<br>
&gt;&gt; &gt; a small fee on each trade.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;ve been researching the topic of decentralized exchange from=
 before the<br>
&gt;&gt; term &quot;colored coins&quot; was first used (now there&#39;s mul=
tiple designs and<br>
&gt;&gt; implementations); contributed to and reviewed many designs: none o=
f them<br>
&gt;&gt; (colored coins or not) required turing completeness.<br>
&gt;&gt; I&#39;m sorry, but what you are saying here is too vague for me to=
 concretely<br>
&gt;&gt; be able to refute the low level &quot;needs&quot; you claim your u=
se cases to have.<br>
&gt;&gt;<br>
&gt;&gt; &gt; On Dec 10, 2015 10:10 AM, &quot;Luke Durback via bitcoin-dev&=
quot;<br>
&gt;&gt; &gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; &gt; &gt; This, combined with the ability to make new transactions=
 arbitrarily<br>
&gt;&gt; &gt; &gt; would allow a function to pay its creator.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I don&#39;t understand what you mean by &quot;a function&quot=
; in this context, I<br>
&gt;&gt; &gt; assume you mean a scriptSig, but then &quot;paying its creato=
r&quot; doesn&#39;t make much<br>
&gt;&gt; &gt; sense to me .<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Could you provide some high level examples of the use cases y=
ou would<br>
&gt;&gt; &gt; like to support with this?<br>
&gt;<br>
&gt;<br>
_______________________________________________<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>

--001a11c118d80eb9530526b9c050--