diff options
| author | Zac Greenwood <zachgrw@gmail.com> | 2021-08-30 16:43:30 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-08-30 14:43:46 +0000 |
| commit | 2ae10d974fdd043662cce7c4fedd04bb01715717 (patch) | |
| tree | 3755e2663cf26f3d5cfb682774a94b6f2e17be93 | |
| parent | 35ce73424863752cc3e73c419769e08645b6c881 (diff) | |
| download | pi-bitcoindev-2ae10d974fdd043662cce7c4fedd04bb01715717.tar.gz pi-bitcoindev-2ae10d974fdd043662cce7c4fedd04bb01715717.zip | |
Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value
| -rw-r--r-- | ce/dcb2ed55a00695a68c6f596ff8116cfe0f4a35 | 440 |
1 files changed, 440 insertions, 0 deletions
diff --git a/ce/dcb2ed55a00695a68c6f596ff8116cfe0f4a35 b/ce/dcb2ed55a00695a68c6f596ff8116cfe0f4a35 new file mode 100644 index 000000000..ba293c047 --- /dev/null +++ b/ce/dcb2ed55a00695a68c6f596ff8116cfe0f4a35 @@ -0,0 +1,440 @@ +Return-Path: <zachgrw@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id B3B06C000E + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 30 Aug 2021 14:43:46 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id A2B0F80EC2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 30 Aug 2021 14:43:46 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.598 +X-Spam-Level: +X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no +Authentication-Results: smtp1.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id azmbZDWyk52x + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 30 Aug 2021 14:43:42 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com + [IPv6:2607:f8b0:4864:20::d2f]) + by smtp1.osuosl.org (Postfix) with ESMTPS id A88A380E9A + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 30 Aug 2021 14:43:42 +0000 (UTC) +Received: by mail-io1-xd2f.google.com with SMTP id e186so20187698iof.12 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 30 Aug 2021 07:43:42 -0700 (PDT) +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=0z72vf+yUgHsDzb09Dh378W+pVHaW57riTcWForrmeg=; + b=J319/M0+wN2ptfDrrM+TdTNYv6RRVp+Hcl0yuklXEd4UfCcxOqTA3Z+4YtzF5nTeij + oue5H9X1DuPUXx+ygj+h+BNsk7Dg7bum+TVfgOTGiV9qhVqkrSb8zUgd7usrI/xIkrEI + SjWqzhYJAnc9kA4DP5V1V/DSEo/iVwVY0OkX65PU1BxYfpVV2wIW9VjhI5/ny0RPZhfH + nv8ehe0rVfgjEY8xvoxggrTDpKwNc0pHpqiqVzrlngmdb7v72kA1URluAZATCk0ZTrc7 + pZXkm9s4Cwuxghp312WOu5I5U8b2WnPCanwiwUsBVccB5w1W65oiqdgYLSdA2e3cP7w4 + HmeA== +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=0z72vf+yUgHsDzb09Dh378W+pVHaW57riTcWForrmeg=; + b=d7FVlem0Re/2XOhyLHuRDgnImMOXRjCmizMzUMjYwk0UqVhBymLSo05YPg+6t2yEPG + Zr1IAcy4tEEaIiKpHOuWM1p3OxpylehQHNu1a7dQ1NVGmxE7qD5NUdSccTi0OtJ1F1dT + gGcbphdzSR978Pcx5apGGDeLxIitfLEW6xsckfDDS0FLSOR+I6f+Idz19CwmFiDRwnap + NMhwULc860rxXL+yBRZZMq0gLTI5XQ4OmFC+aLoqD6Ck2G31vuaj5WYKLt490UgrXlXE + DC7Un3KjQhIMwR0qidVsPQXRaKtHkOs3SIgQ220tJiDNqrErPz29dVjPztzawBDaoLTN + qyrQ== +X-Gm-Message-State: AOAM531nakPxszi4zrDay958Bw5VSBUOZogbr5MWVy7gxrJrWDUfTPd8 + bRVAr84UGhbU+UALF1TGFx4vxm+aNYkV0Rxz/8s= +X-Google-Smtp-Source: ABdhPJw+dZNDG6JkCLSkCIFOPVyNmwVDhB0qYB+dvesYa6vz5+dY5ewzR9xgFajQfCjsKu63LbRhTkSiTXWuWjn44e8= +X-Received: by 2002:a6b:905:: with SMTP id t5mr18153519ioi.209.1630334621815; + Mon, 30 Aug 2021 07:43:41 -0700 (PDT) +MIME-Version: 1.0 +References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com> + <CAGpPWDZL6BpzoNa0Qgf-Ux60fyWPjZH=NESkgbhEQO_My=XiAg@mail.gmail.com> + <CAJ4-pEBwdUJ3kg=yb-kWZLoaX5f_2t353K7Tr+dJy+JpAoKTmQ@mail.gmail.com> + <CAGpPWDYMZ+w3VSaLhR68f4WVq7NCUp3SedwW2e8QnRHOgLQqQg@mail.gmail.com> + <CAJ4-pEAT8Rrf7dN9A+F2SUvaRz0-DqgDw45whtZcWCTPeQ+uxA@mail.gmail.com> + <T9dyi_J_ZLwT8hXaxOBlCEhdoB9hsBcvFZX3r1JrtxunUTnFe7wefV6hi3Itw8z84drqAn64ZCJhfSfz7Aw0cqx4Aa8DtN1irvE-d4JPoeE=@protonmail.com> + <CAJ4-pED7sAe+yNqxv_1HSaku=kuTQYTU3nm2o6vUVCEnhkxxFA@mail.gmail.com> + <1qkQ1p1rAZApZhMKVFwQV6gfLyZxMYIUPrhcjtXNU4z0DBRwslPSbi76GnNnllpvPPfqt1bH3EyzJNhfK0Uxum7zJ_dh3H0DXqUpf2nmHyk=@protonmail.com> + <CAJ4-pECSE=by2ag4QmqrXbX_R0sk6HOL1KH0z2h=+915jaEE6Q@mail.gmail.com> + <wdlRrp4fZxH79mzVpTQWp99V9uI8jLvRU40mwdJ8lZ5A2mGMsxUK1TmZEZTV7O4_eUnNyq3feEGv5BUN-ecPSlbL-EYR6ZyLxk9ErsFiPlE=@protonmail.com> +In-Reply-To: <wdlRrp4fZxH79mzVpTQWp99V9uI8jLvRU40mwdJ8lZ5A2mGMsxUK1TmZEZTV7O4_eUnNyq3feEGv5BUN-ecPSlbL-EYR6ZyLxk9ErsFiPlE=@protonmail.com> +From: Zac Greenwood <zachgrw@gmail.com> +Date: Mon, 30 Aug 2021 16:43:30 +0200 +Message-ID: <CAJ4-pECwGfrrB15oS0t-+vsjn11sC=9Bz6JGsGsicUorCjuYpA@mail.gmail.com> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Content-Type: multipart/alternative; boundary="000000000000ff984205cac7dbe0" +X-Mailman-Approved-At: Mon, 30 Aug 2021 15:24:04 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Exploring: limiting transaction output amount as + a function of total input value +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: Mon, 30 Aug 2021 14:43:46 -0000 + +--000000000000ff984205cac7dbe0 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi ZmnSCPxj, + +> I suggest looking into the covenant opcodes and supporting those instead +of your own proposal, as your application is very close to one of the +motivating examples for covenants in the first place. + +I believe it is not the right approach to take a proposal, chop off key +aspects of its functionality, and rely to some future change in Bitcoin +that may perhaps enable implementing some watered down version of the +intended functionality. In my opinion the right order would be to first +discuss the unmodified proposal on a functional level and gauge community +interest, then move forward to discuss technical challenges for the +*unmodified* proposal instead of first knee-capping the proposal in order +to (presumably) reduce cost of implementation. + +I believe that we both recognize that the proposed functionality would be +beneficial. I believe that your position is that functionality close to +what I have in mind can be implemented using covenants, albeit with some +gaps. For me personally however these gaps would not be acceptable because +they severely hurt the predictability and intuitiveness of the behavior of +the functionality for the end-user. But as noted, I believe at this point +it is premature to have this discussion. + +Perhaps you could help me understand what would be required to implement +the *unmodified* proposal. That way, the community will be able to better +assess the cost (in terms of effort and risk) and weigh it against the +perceived benefits. Perhaps *then* we find that the cost could be +significantly reduced without any significant reduction of the benefits, +for instance by slightly compromising on the functionality such that no +changes to consensus would be required for its implementation. (I am +skeptical that this would be possible though). The cost reduction must be +carefully weighed against the functional gaps it creates. + +I am aware that my proposal must be well-defined functionally before being +able to reason about its benefits and implementational aspects. I believe +that the proposed functionality is pretty straightforward, but I am happy +to come up with a more precise functional spec. However, such effort would +be wasted if there is no community interest for this functionality. So far +only few people have engaged with this thread, and I am not sure that this +is because there is no interest in the proposal or because most people just +lurk here and do not feel like giving their opinion on random proposals. It +would be great however to learn about more people's opinions. + +As a reminder, the proposed functionality is to enable a user to limit the +amount that they able to spent from an address within a certain time-frame +or window (defined in number of blocks) while retaining the ability to +spend arbitrary amounts using a secondary private key (or set of private +keys). The general use case is to prevent theft of large amounts while +still allowing a user to spend small amounts over time. Hodlers as well as +exchanges dealing with cold, warm and hot wallets come to mind as users who +could materially benefit from this functionality. + +Zac + + + +On Mon, Aug 16, 2021 at 1:48 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote: + +> Good morning Zac, +> +> > Thank you for your counterproposal. I fully agree that as a first step +> we must establish whether the proposed functionality can be implemented +> without making any changes to consensus. +> > +> > Your counterproposal is understandably more technical in nature because +> it explores an implementation on top of Bitcoin as-is. However I feel tha= +t +> for a fair comparison of the functionality of both proposals a purely +> functional description of your proposal is essential. +> > +> > If I understand your proposal correctly, then I believe there are some +> major gaps between yours and mine: +> > +> > Keys for unrestricted spending: in my proposal, they never have to come +> online unless spending more than the limit is desired. In your proposal, +> these keys are required to come online in several situations. +> +> Correct, that is indeed a weakness. +> +> It is helpful to see https://zmnscpxj.github.io/bitcoin/unchained.html +> Basically: any quorum of signers can impose any rules that are not +> implementable on the base layer, including the rules you desire. +> That quorum is the "offline keyset" in my proposal. +> +> > +> > Presigning transactions: not required in my proposal. Wouldn=E2=80=99t = +such +> presigning requirement be detrimental for the usability of your proposal? +> Does it mean that for instance the amount and window in which the +> transaction can be spent is determined at the time of signing? In my +> proposal, there is no limit in the number of transactions per window. +> +> No. +> Remember, the output is a simple 1-of-1 or k-of-n of the online keyset. +> The online keyset can spend that wherever and however, including paying i= +t +> out to N parties, or paying part of the limit to 1 party and then paying +> the remainder back to the same onchain keyset so it can access the funds = +in +> the future. +> Both cases are also available in your proposal, and the latter case (pay +> out part of the limit to a single output, then keep the rest back to the +> same onchain keyset) can be used to add an indefinite number of +> transactions per window. +> +> > +> > Number of windows: limited in your proposal, unlimited in mine. +> +> Correct, though you can always have a fairly large number of windows +> ("640kB ought to be enough for anybody"). +> +> > +> > There are probably additional gaps that I am currently not technically +> able to recognize. +> +> It requires a fair amount of storage for the signatures at minimum, thoug= +h +> that may be as small as 64 bytes per window. +> 1Mb of storage for signatures would allow 16,384 windows, assuming you us= +e +> 1-day windows that is about 44.88 years, probably more than enough that a +> one-time onlining of the offline keys (or just print out the signatures o= +n +> paper or display as a QR code, whatever) is acceptable. +> +> > I feel that the above gaps are significant enough to state that your +> proposal does not meet the basic requirements of my proposal. +> > +> > Next to consider is whether the gap is acceptable, weighing the effort +> to implement the required consensus changes against the effort and +> feasibility of implementing your counterproposal. +> > +> > I feel that your counterproposal has little chance of being implemented +> because of the still considerable effort required and the poor result in +> functional terms. I also wonder if your proposal is feasible considering +> wallet operability. +> +> See above, particularly the gap that does not, in fact, exist. +> +> > +> > Considering all the above, I believe that implementing consensus change= +s +> in order to support the proposed functionality would preferable over you= +r +> counterproposal. +> > +> > I acknowledge that a consensus change takes years and is difficult to +> achieve, but that should not be any reason to stop exploring the appetite +> for the proposed functionality and perhaps start looking at possible +> technical solutions. +> +> You can also look into the "covenant" opcodes (`OP_CHECKSIGFROMSTACK`, +> `OP_CHECKTEMPLATEVERIFY`, etc.), I think JeremyRubin has a bunch of them +> listed somewhere, which may be used to implement something similar withou= +t +> requiring presigning. +> +> Since the basic "just use `nSequence`" scheme already implements what you +> need, what the covenant opcodes buy you is that you do not need the offli= +ne +> keyset to be onlined and there is no need to keep signatures, removing th= +e +> remaining gaps you identified. +> With a proper looping covenant opcode, there is also no limit on the +> number of windows. +> +> The issue with the covenant opcodes is that there are several proposals +> with overlapping abilities and different tradeoffs. +> This is the sort of thing that invites bikeshed-painting. +> +> I suggest looking into the covenant opcodes and supporting those instead +> of your own proposal, as your application is very close to one of the +> motivating examples for covenants in the first place. +> +> Regards, +> ZmnSCPxj +> + +--000000000000ff984205cac7dbe0 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi ZmnSCPxj,<div><br></div><div>> I suggest looking int= +o the covenant opcodes and supporting those instead of your own proposal, a= +s your application is very close to one of the motivating examples for cove= +nants in the first place.</div><br><div>I believe it is not the right appro= +ach to take a proposal, chop off key aspects of its functionality, and rely= + to some future change in Bitcoin that may perhaps enable implementing some= + watered down version of the intended functionality. In my opinion the righ= +t order would be to first discuss the unmodified proposal on a functional l= +evel and gauge community interest, then move forward to discuss technical c= +hallenges for the *unmodified* proposal instead of first knee-capping the p= +roposal in order to (presumably) reduce cost of implementation.</div><div><= +br></div><div>I believe that we both recognize that the proposed functional= +ity would be beneficial. I believe that your position is that functionality= + close to what I have in mind can be implemented using covenants, albeit wi= +th some gaps. For me personally however these gaps would not be acceptable = +because they severely hurt the predictability and intuitiveness of the beha= +vior of the functionality for the end-user. But as noted, I believe at this= + point it is premature to have this discussion.</div><div><br></div><div>Pe= +rhaps you could help me understand what would be required to implement the = +*unmodified* proposal. That way, the community will be able to better asses= +s the cost (in terms of effort and risk) and weigh it against the perceived= + benefits. Perhaps *then* we find that the cost could be significantly redu= +ced without any significant reduction of the benefits, for instance by slig= +htly compromising on the functionality such that no changes to consensus wo= +uld be required for its implementation. (I am skeptical that this would be = +possible though). The cost reduction must be carefully weighed against the = +functional gaps it creates.</div><div><br></div><div>I am aware that my pro= +posal must be well-defined functionally before being able to reason about i= +ts benefits and implementational aspects. I believe that the proposed funct= +ionality is pretty straightforward, but I am happy to come up with a more p= +recise functional spec. However, such effort would be wasted if there is no= + community interest for this functionality. So far only few people have eng= +aged with this thread, and I am not sure that this is because there is no i= +nterest in the proposal or because most people just lurk here and do not fe= +el like giving their opinion on random proposals. It would be great however= + to learn about more people's opinions.</div><div><br></div><div>As a r= +eminder, the proposed functionality is to enable a user to limit the amount= + that they able to spent from an address within a certain time-frame or win= +dow (defined in number of blocks) while retaining the ability to spend arbi= +trary amounts using a secondary private key (or set of private keys). The g= +eneral use case is to prevent theft of large amounts while still allowing a= + user to spend small amounts over time. Hodlers as well as exchanges dealin= +g with cold, warm and hot wallets come to mind as users who could materiall= +y benefit from this functionality.</div><div><br></div><div>Zac</div><div><= +br></div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"lt= +r" class=3D"gmail_attr">On Mon, Aug 16, 2021 at 1:48 PM ZmnSCPxj <<a hre= +f=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.= +com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg= +in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e= +x">Good morning Zac,<br> +<br> +> Thank you for your counterproposal. I fully agree that as a first step= + we must establish whether the proposed functionality can be implemented wi= +thout making any changes to consensus.<br> +><br> +> Your counterproposal is understandably more technical in nature becaus= +e it explores an implementation on top of Bitcoin as-is. However I feel tha= +t for a fair comparison of the functionality of both proposals a purely fun= +ctional description of your proposal is essential.<br> +><br> +> If I understand your proposal correctly, then I believe there are some= + major gaps between yours and mine:<br> +><br> +> Keys for unrestricted spending: in my proposal, they never have to com= +e online unless spending more than the limit is desired. In your proposal, = +these keys are required to come online in several situations.<br> +<br> +Correct, that is indeed a weakness.<br> +<br> +It is helpful to see <a href=3D"https://zmnscpxj.github.io/bitcoin/unchaine= +d.html" rel=3D"noreferrer" target=3D"_blank">https://zmnscpxj.github.io/bit= +coin/unchained.html</a><br> +Basically: any quorum of signers can impose any rules that are not implemen= +table on the base layer, including the rules you desire.<br> +That quorum is the "offline keyset" in my proposal.<br> +<br> +><br> +> Presigning transactions: not required in my proposal. Wouldn=E2=80=99t= + such presigning requirement be detrimental for the usability of your propo= +sal? Does it mean that for instance the amount and window in which the tran= +saction can be spent is determined at the time of signing? In my proposal, = +there is no limit in the number of transactions per window.<br> +<br> +No.<br> +Remember, the output is a simple 1-of-1 or k-of-n of the online keyset.<br> +The online keyset can spend that wherever and however, including paying it = +out to N parties, or paying part of the limit to 1 party and then paying th= +e remainder back to the same onchain keyset so it can access the funds in t= +he future.<br> +Both cases are also available in your proposal, and the latter case (pay ou= +t part of the limit to a single output, then keep the rest back to the same= + onchain keyset) can be used to add an indefinite number of transactions pe= +r window.<br> +<br> +><br> +> Number of windows: limited in your proposal, unlimited in mine.<br> +<br> +Correct, though you can always have a fairly large number of windows ("= +;640kB ought to be enough for anybody").<br> +<br> +><br> +> There are probably additional gaps that I am currently not technically= + able to recognize.<br> +<br> +It requires a fair amount of storage for the signatures at minimum, though = +that may be as small as 64 bytes per window.<br> +1Mb of storage for signatures would allow 16,384 windows, assuming you use = +1-day windows that is about 44.88 years, probably more than enough that a o= +ne-time onlining of the offline keys (or just print out the signatures on p= +aper or display as a QR code, whatever) is acceptable.<br> +<br> +> I feel that the above gaps are significant enough to state that your p= +roposal does not meet the basic requirements of my proposal.<br> +><br> +> Next to consider is whether the gap is acceptable, weighing the effort= + to implement the required consensus changes against the effort and feasibi= +lity of implementing your counterproposal.<br> +><br> +> I feel that your counterproposal has little chance of being implemente= +d because of the still considerable effort required and the poor result in = +functional terms. I also wonder if your proposal is feasible considering wa= +llet operability.<br> +<br> +See above, particularly the gap that does not, in fact, exist.<br> +<br> +><br> +> Considering all the above, I believe that implementing consensus chang= +es in order to support the proposed functionality would preferable =C2=A0ov= +er your counterproposal.<br> +><br> +> I acknowledge that a consensus change takes years and is difficult to = +achieve, but that should not be any reason to stop exploring the appetite f= +or the proposed functionality and perhaps start looking at possible technic= +al solutions.<br> +<br> +You can also look into the "covenant" opcodes (`OP_CHECKSIGFROMST= +ACK`, `OP_CHECKTEMPLATEVERIFY`, etc.), I think JeremyRubin has a bunch of t= +hem listed somewhere, which may be used to implement something similar with= +out requiring presigning.<br> +<br> +Since the basic "just use `nSequence`" scheme already implements = +what you need, what the covenant opcodes buy you is that you do not need th= +e offline keyset to be onlined and there is no need to keep signatures, rem= +oving the remaining gaps you identified.<br> +With a proper looping covenant opcode, there is also no limit on the number= + of windows.<br> +<br> +The issue with the covenant opcodes is that there are several proposals wit= +h overlapping abilities and different tradeoffs.<br> +This is the sort of thing that invites bikeshed-painting.<br> +<br> +I suggest looking into the covenant opcodes and supporting those instead of= + your own proposal, as your application is very close to one of the motivat= +ing examples for covenants in the first place.<br> +<br> +Regards,<br> +ZmnSCPxj<br> +</blockquote></div> + +--000000000000ff984205cac7dbe0-- + |