Date: Sat, 14 Aug 2021 01:50:45 +0000
To: Zac Greenwood <zachgrw@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <1qkQ1p1rAZApZhMKVFwQV6gfLyZxMYIUPrhcjtXNU4z0DBRwslPSbi76GnNnllpvPPfqt1bH3EyzJNhfK0Uxum7zJ_dh3H0DXqUpf2nmHyk=@protonmail.com>
In-Reply-To: <CAJ4-pED7sAe+yNqxv_1HSaku=kuTQYTU3nm2o6vUVCEnhkxxFA@mail.gmail.com>
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
 <CAGpPWDb8yzGO-VtCO-x09e-phKHT7ezOms+DzeWc9vS3rN1AAw@mail.gmail.com>
 <CAJ4-pEDWuNfdE4NXkZBsOnuSQ4YOv28YVwGavyiU+FPvpC6y1w@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>
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,


> Hi=C2=A0ZmnSCPxj,
>
> Thank you for your insightful response.
>
> Perhaps I should take a step back and take a strictly functional angle. P=
erhaps the list could help me to establish whether=C2=A0the proposed functi=
onality is:
>
> Desirable;
> Not already possible;
> Feasible to implement.
>
> The proposed functionality is as follows:
>
> The ability to control some coin with two private keys (or two sets of pr=
ivate keys) such that spending is limited over time for one private key (i.=
e., it is for instance not possible to spend all coin in a single transacti=
on) while spending is unrestricted for the other private key (no limits app=
ly). No limits must apply to coin transacted to a third party.
>
> Also, it must be possible never having to bring the unrestricted private =
key online unless more than the limit imposed on the restrictive private ke=
y is desired to be spent.
>
> Less generally, taking the perspective of a hodler: the user must be able=
 to keep one key offline and one key online. The offline key allows unrestr=
icted spending, the online key is limited in how much it is allowed to spen=
d over time.
>
> Furthermore, the spending limit must be intuitive. Best candidate I belie=
ve would be a maximum spend per some fixed number of blocks. For instance, =
the restrictive key may allow a maximum of 100k sats per any window of 144 =
blocks. Ofcourse the user must be able to set these parameters freely.

My proposal does not *quite* implement a window.
However, that is because it uses `nLockTime`.

With the use of `nSequence` in relative-locktime mode, however, it *does* i=
mplement a window, sort of.
More specifically, it implements a timeout on spending --- if you spend usi=
ng a presigned transaction (which creates an unencumbered specific-valued T=
XO that can be arbitrarily spent with your online keyset) then you cannot g=
et another "batch" of funds until the `nSequence` relative locktime passes.
However, this *does* implement a window that limits a maximum value spendab=
le per any window of the relative timelock you select.

The disadvantage is that `nSequence` use is a lot more obvious and discerni=
ble than `nLockTime` use.
Many wallets today use non-zero `nLockTime` for anti-fee-sniping, and that =
is a good cover for `nLockTime` transactions.
I believe Dave Harding proposed that wallets should also use, at random, (s=
ay 50-50) `nSequence`-in-relative-locktime-mode as an alternate anti-fee-sn=
iping mechanism.
This alternate anti-fee-sniping would help cover `nSequence` use.

Note that my proposal does impose a maximum limit on the number of windows.
With `nSequence`-in-relative-locktime-mode the limit is the number of times=
 that the online keyset can spend.
After spending that many windows, the offline keyset has to be put back onl=
ine to generate a new set of transactions.

It has the massive massive advantage that you can implement it today withou=
t any consensus change, and I think you can expect that consensus change wi=
ll take a LONG time (xref SegWit, Taproot).

Certainly the functionality is desirable.
But it seems it can be implemented with Bitcoin today.

Regards,
ZmnSCPxj