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 that 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’t 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 it 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, 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 one-time onlining of the offline keys (or just print out the signatures on 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 changes in order to support the proposed functionality would preferable  over your 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 without 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 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 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