From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Zac Greenwood <zachgrw@gmail•com>
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
Date: Sat, 14 Aug 2021 01:50:45 +0000 [thread overview]
Message-ID: <1qkQ1p1rAZApZhMKVFwQV6gfLyZxMYIUPrhcjtXNU4z0DBRwslPSbi76GnNnllpvPPfqt1bH3EyzJNhfK0Uxum7zJ_dh3H0DXqUpf2nmHyk=@protonmail.com> (raw)
In-Reply-To: <CAJ4-pED7sAe+yNqxv_1HSaku=kuTQYTU3nm2o6vUVCEnhkxxFA@mail.gmail.com>
Good morning Zac,
> Hi ZmnSCPxj,
>
> Thank you for your insightful response.
>
> Perhaps I should take a step back and take a strictly functional angle. Perhaps the list could help me to establish whether the proposed functionality 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 private 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 transaction) while spending is unrestricted for the other private key (no limits apply). 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 key 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 unrestricted spending, the online key is limited in how much it is allowed to spend over time.
>
> Furthermore, the spending limit must be intuitive. Best candidate I believe 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* implement a window, sort of.
More specifically, it implements a timeout on spending --- if you spend using a presigned transaction (which creates an unencumbered specific-valued TXO that can be arbitrarily spent with your online keyset) then you cannot get another "batch" of funds until the `nSequence` relative locktime passes.
However, this *does* implement a window that limits a maximum value spendable per any window of the relative timelock you select.
The disadvantage is that `nSequence` use is a lot more obvious and discernible 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, (say 50-50) `nSequence`-in-relative-locktime-mode as an alternate anti-fee-sniping 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 online to generate a new set of transactions.
It has the massive massive advantage that you can implement it today without any consensus change, and I think you can expect that consensus change will take a LONG time (xref SegWit, Taproot).
Certainly the functionality is desirable.
But it seems it can be implemented with Bitcoin today.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-08-14 1:51 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-21 5:56 [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) Billy Tetrud
2021-07-25 5:38 ` David A. Harding
2021-07-25 19:49 ` Billy Tetrud
2021-07-26 0:05 ` David A. Harding
[not found] ` <SN7PR18MB3981DC1CD23B90367045995FD2E89@SN7PR18MB3981.namprd18.prod.outlook.com>
2021-07-26 20:18 ` Billy Tetrud
2021-07-26 21:08 ` James MacWhyte
2021-07-27 0:41 ` Billy Tetrud
2021-07-27 11:18 ` Zac Greenwood
2021-07-27 17:21 ` Billy Tetrud
2021-07-28 4:57 ` Zac Greenwood
2021-07-28 17:57 ` Billy Tetrud
2021-07-28 22:30 ` Jeremy
2021-07-30 18:42 ` Billy Tetrud
2021-11-01 1:19 ` Billy Tetrud
2021-07-31 20:01 ` [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value Zac Greenwood
2021-08-02 4:40 ` Billy Tetrud
2021-08-10 2:17 ` ZmnSCPxj
2021-08-13 11:02 ` Zac Greenwood
2021-08-14 1:50 ` ZmnSCPxj [this message]
2021-08-16 11:17 ` Zac Greenwood
2021-08-16 11:48 ` ZmnSCPxj
2021-08-30 14:43 ` Zac Greenwood
2021-08-31 9:00 ` ZmnSCPxj
2021-08-31 14:09 ` Zac Greenwood
2021-08-31 14:22 ` ZmnSCPxj
2021-09-01 15:15 ` Zac Greenwood
2021-08-01 8:09 Zac Greenwood
2021-08-02 9:32 ` Zac Greenwood
2021-08-03 18:12 ` Billy Tetrud
2021-08-04 10:48 ` Zac Greenwood
2021-08-05 6:39 ` Billy Tetrud
2021-08-05 14:22 ` Zac Greenwood
2021-08-10 0:41 ` Billy Tetrud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='1qkQ1p1rAZApZhMKVFwQV6gfLyZxMYIUPrhcjtXNU4z0DBRwslPSbi76GnNnllpvPPfqt1bH3EyzJNhfK0Uxum7zJ_dh3H0DXqUpf2nmHyk=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=zachgrw@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox