path: root/ce/dcb2ed55a00695a68c6f596ff8116cfe0f4a35

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>&gt; 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&#39;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 &lt;<a hre=
f=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.=
com</a>&gt; 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>
&gt; 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>
&gt;<br>
&gt; 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>
&gt;<br>
&gt; If I understand your proposal correctly, then I believe there are some=
 major gaps between yours and mine:<br>
&gt;<br>
&gt; 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 &quot;offline keyset&quot; in my proposal.<br>
<br>
&gt;<br>
&gt; 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>
&gt;<br>
&gt; Number of windows: limited in your proposal, unlimited in mine.<br>
<br>
Correct, though you can always have a fairly large number of windows (&quot=
;640kB ought to be enough for anybody&quot;).<br>
<br>
&gt;<br>
&gt; 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>
&gt; 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>
&gt;<br>
&gt; 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>
&gt;<br>
&gt; 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>
&gt;<br>
&gt; 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>
&gt;<br>
&gt; 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 &quot;covenant&quot; 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 &quot;just use `nSequence`&quot; 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--