Date: Mon, 16 Aug 2021 11:48:43 +0000
To: Zac Greenwood <zachgrw@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <wdlRrp4fZxH79mzVpTQWp99V9uI8jLvRU40mwdJ8lZ5A2mGMsxUK1TmZEZTV7O4_eUnNyq3feEGv5BUN-ecPSlbL-EYR6ZyLxk9ErsFiPlE=@protonmail.com>
In-Reply-To: <CAJ4-pECSE=by2ag4QmqrXbX_R0sk6HOL1KH0z2h=+915jaEE6Q@mail.gmail.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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
Precedence: list

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 witho=
ut making any changes to consensus.
>
> Your counterproposal is understandably more technical in nature because i=
t explores an implementation on top of Bitcoin as-is. However I feel that f=
or a fair comparison of the functionality of both proposals a purely functi=
onal description of your proposal is essential.
>
> If I understand your proposal correctly, then I believe there are some ma=
jor gaps between yours and mine:
>
> Keys for unrestricted spending: in my proposal, they never have to come o=
nline unless spending more than the limit is desired. In your proposal, the=
se 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 implemen=
table 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 su=
ch presigning requirement be detrimental for the usability of your proposal=
? Does it mean that for instance the amount and window in which the transac=
tion can be spent is determined at the time of signing? In my proposal, the=
re 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 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.
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.

>
> Number of windows: limited in your proposal, unlimited in mine.

Correct, though you can always have a fairly large number of windows ("640k=
B ought to be enough for anybody").

>
> There are probably additional gaps that I am currently not technically ab=
le to recognize.

It requires a fair amount of storage for the signatures at minimum, though =
that may be as small as 64 bytes per window.
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.

> I feel that the above gaps are significant enough to state that your prop=
osal 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 feasibilit=
y of implementing your counterproposal.
>
> I feel that your counterproposal has little chance of being implemented b=
ecause of the still considerable effort required and the poor result in fun=
ctional terms. I also wonder if your proposal is feasible considering walle=
t operability.

See above, particularly the gap that does not, in fact, exist.

>
> Considering all the above, I believe that implementing consensus changes =
in order to support the proposed functionality would preferable =C2=A0over =
your counterproposal.
>
> I acknowledge that a consensus change takes years and is difficult to ach=
ieve, 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 without requir=
ing presigning.

Since the basic "just use `nSequence`" scheme already implements what you n=
eed, what the covenant opcodes buy you is that you do not need the offline =
keyset to be onlined and there is no need to keep signatures, removing the =
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 wit=
h 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 motivat=
ing examples for covenants in the first place.

Regards,
ZmnSCPxj