From: Zac Greenwood <zachgrw@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•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: Fri, 13 Aug 2021 13:02:14 +0200 [thread overview]
Message-ID: <CAJ4-pED7sAe+yNqxv_1HSaku=kuTQYTU3nm2o6vUVCEnhkxxFA@mail.gmail.com> (raw)
In-Reply-To: <T9dyi_J_ZLwT8hXaxOBlCEhdoB9hsBcvFZX3r1JrtxunUTnFe7wefV6hi3Itw8z84drqAn64ZCJhfSfz7Aw0cqx4Aa8DtN1irvE-d4JPoeE=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3944 bytes --]
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.
I look forward to any feedback you may have.
Zac
On Tue, 10 Aug 2021 at 04:17, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> fromGood morning Zac,
>
>
> With some work, what you want can be implemented, to some extent, today,
> without changes to consensus.
>
> The point you want, I believe, is to have two sets of keys:
>
> * A long-term-storage keyset, in "cold" storage.
> * A short-term-spending keyset, in "warm" storage, controlling only a
> small amount of funds.
>
> What you can do would be:
>
> * Put all your funds in a single UTXO, with an k-of-n of your cold keys
> (ideally P2TR, or some P2WSH k-of-n).
> * Put your cold keys online, and sign a transaction spending the above
> UTXO, and spending most of it to a new address that is a tweaked k-of-n of
> your cold keys, and a smaller output (up to the limit you want) controlled
> by the k-of-n of your warm keys.
> * Keep this transaction offchain, in your warm storage.
> * Put your cold keys back offline.
> * When you need to spend using your warm keys, bring the above transaction
> onchain, then spend from the budget as needed.
>
>
> If you need to have some estimated amount of usable funds for every future
> unit of time, just create a chain of transactions with future `nLockTime`.
>
> nLocktime +1day nLockTime +2day
> +------------+ +------------+ +------------+
> cold UTXO -->| cold TXO|-->| cold TXO|-->| cold TXO|--> etc.
> | | | | | |
> | warm TXO| | warm TXO| | warm TXO|
> +------------+ +------------+ +------------+
>
> Pre-sign the above transactions, store the pre-signed transactions in warm
> storage together with your warm keys.
> Then put the cold keys back offline.
>
> Then from today to tomorrow, you can spend only the first warm TXO.
> From tomorrow to the day after, you can spend only the first two warm TXOs.
> And so on.
>
> If tomorrow your warm keys are stolen, you can bring the cold keys online
> to claim the second cold TXO and limit your fund loss to only just the
> first two warm TXOs.
>
> The above is bulky, but it has the advantage of not using any special
> opcodes or features (improving privacy, especially with P2TR which would in
> theory allow k-of-n/n-of-n to be indistinguishable from 1-of-1), and using
> just `nLockTime`, which is much easier to hide since most modern wallets
> will set `nLockTime` to recent block heights.
>
> Regards,
> ZmnSCPxj
>
>
[-- Attachment #2: Type: text/html, Size: 7630 bytes --]
next prev parent reply other threads:[~2021-08-13 11:02 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 [this message]
2021-08-14 1:50 ` ZmnSCPxj
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='CAJ4-pED7sAe+yNqxv_1HSaku=kuTQYTU3nm2o6vUVCEnhkxxFA@mail.gmail.com' \
--to=zachgrw@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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