path: root/60/6d48c45bbd2478169546fea3b85e47221817f9

Return-Path: <zachgrw@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7690AC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 13 Aug 2021 11:02:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 5B7C340765
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 13 Aug 2021 11:02:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.603
X-Spam-Level: 
X-Spam-Status: No, score=0.603 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Oe-7fgCgJECN
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 13 Aug 2021 11:02:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com
 [IPv6:2607:f8b0:4864:20::131])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 5463A407B6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 13 Aug 2021 11:02:26 +0000 (UTC)
Received: by mail-il1-x131.google.com with SMTP id x7so10377056ilh.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 13 Aug 2021 04:02:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=EUepUAAWMbR0J8MNZpptnHOoFgBP1oI6QT7GOLZsr3w=;
 b=EZUcl+UCQtbB1jCOZIUbddv0FoQ4/MSW3EnQGfEiroU1I4xUpxw/lKmTZKihX9dhjy
 OdlxxglvsmMXoVe6PmzAXNbEUFschpGtVtQS4KXdemGMzXBc8x1Nzl4oW2s4gLRxTqsf
 RhNlazhZeK2eTCqxBxn60CZlPFLYvy5uSpHy5bb3fRJd3p/LNPrMkf0FAoDTnKyZlMdS
 BPP087Mrtgcv6h9kLsOsrFj6ICNQYa3XbL7wjT6oNAx7zhPtCJMkFkVd7DkqfFaQ3kZ1
 5hSJZM39OzZxrlkHjV3RicZEmE5pNn54kt5aJESH2BxZHtmo0YuQJBWU9VMBljqgGpGu
 TEVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=EUepUAAWMbR0J8MNZpptnHOoFgBP1oI6QT7GOLZsr3w=;
 b=r4aSkeaSNhsD01T0bPMiWZuJ+RnGZB7qhjl7+v6U8oTC1F4IabaPoEsnKYl/7Z48Ea
 RYjkzIVEeYinKwmmA4Am4VfP+oNPEKQE9mpfUMfSZ9zuqDyrqxMScRWA2KpKwK3+Ct1Y
 8MzjooMvE6IRL3TdJNrU5wal5a/yIgSGyp/Gxge7te0etnEBq2JEpHPFIQMu8ZpRvquQ
 mGiWngfzxXgO8TRXbXIXdYDVOF+JOrEtQESN1KC95jvGbihJjHV1kJzmUKgMqqf27uls
 11IzbAvlIYS/zJ1lCGUinw+44bqXhnCMq+4aN9vdE/c076O8MDSFGqvLp4qQZVeRTj2J
 DmoA==
X-Gm-Message-State: AOAM532jKELZ5sFvzhmx2kwTokhB/pXyCc/P+HwfzBPzBRotyjfrFwbu
 /fUjcDx6/hufmo6KYoc2ieKT9P0UkXjKpi+u7NE=
X-Google-Smtp-Source: ABdhPJyGqCLLFPaLYS2Q9SR02izGpRT7tyhvUu38/5I52mAmmppuL+hsNdDIGW/siyl7Q5PZcutEnyZEull4SfPhZAE=
X-Received: by 2002:a92:d586:: with SMTP id a6mr1345594iln.283.1628852545393; 
 Fri, 13 Aug 2021 04:02:25 -0700 (PDT)
MIME-Version: 1.0
References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com>
 <20210725053803.fnmd6etv3f7x3u3p@ganymede>
 <CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com>
 <CAH+Axy7cPufMUCMQbCz2MUgRqQbgenAozPBFD8kPYrSjwcRG8w@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>
In-Reply-To: <T9dyi_J_ZLwT8hXaxOBlCEhdoB9hsBcvFZX3r1JrtxunUTnFe7wefV6hi3Itw8z84drqAn64ZCJhfSfz7Aw0cqx4Aa8DtN1irvE-d4JPoeE=@protonmail.com>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Fri, 13 Aug 2021 13:02:14 +0200
Message-ID: <CAJ4-pED7sAe+yNqxv_1HSaku=kuTQYTU3nm2o6vUVCEnhkxxFA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000005c17eb05c96ec93e"
X-Mailman-Approved-At: Fri, 13 Aug 2021 11:39:44 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Aug 2021 11:02:27 -0000

--0000000000005c17eb05c96ec93e
Content-Type: text/plain; charset="UTF-8"

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
>
>

--0000000000005c17eb05c96ec93e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hi=C2=A0<span style=3D"color:rgb(0,0,0)">ZmnSCPxj,</span>=
</div><div dir=3D"auto"><span style=3D"color:rgb(0,0,0)"><br></span></div><=
div dir=3D"auto"><span style=3D"color:rgb(0,0,0)">Thank you for your insigh=
tful response.</span></div><div dir=3D"auto"><span style=3D"color:rgb(0,0,0=
)"><br></span></div><div style=3D"background-color:rgba(0,0,0,0)!important;=
border-color:rgb(255,255,255)!important;color:rgb(255,255,255)!important" d=
ir=3D"auto"><font style=3D"color:rgb(0,0,0)">Perhaps I should take a step b=
ack and take a strictly functional angle. Perhaps the list could help me to=
 establish whether=C2=A0</font><span style=3D"color:rgb(0,0,0)">the propose=
d functionality is:</span></div><div style=3D"background-color:rgba(0,0,0,0=
);border-color:rgb(255,255,255)" dir=3D"auto"><span style=3D"color:rgb(0,0,=
0)"><br></span></div><div style=3D"background-color:rgba(0,0,0,0);border-co=
lor:rgb(255,255,255)" dir=3D"auto"><span style=3D"color:rgb(0,0,0)">Desirab=
le;</span></div><div style=3D"background-color:rgba(0,0,0,0)!important;bord=
er-color:rgb(32,33,36)!important;color:rgb(255,255,255)!important" dir=3D"a=
uto"><font style=3D"color:rgb(0,0,0)">Not already possible;</font></div><di=
v style=3D"background-color:rgba(0,0,0,0);border-color:rgb(32,33,36)" dir=
=3D"auto"><font style=3D"color:rgb(0,0,0)">Feasible to implement.</font></d=
iv><div style=3D"background-color:rgba(0,0,0,0);border-color:rgb(32,33,36)"=
 dir=3D"auto"><font style=3D"color:rgb(0,0,0)"><br></font></div><div style=
=3D"background-color:rgba(0,0,0,0)!important;border-color:rgb(222,223,227)!=
important;color:rgb(255,255,255)!important" dir=3D"auto"><font style=3D"col=
or:rgb(0,0,0)">The proposed functionality is as follows:</font></div><div s=
tyle=3D"background-color:rgba(0,0,0,0);border-color:rgb(222,223,227)" dir=
=3D"auto"><font style=3D"color:rgb(0,0,0)"><br></font></div><div style=3D"b=
ackground-color:rgba(0,0,0,0)!important;border-color:rgb(53,54,57)!importan=
t;color:rgb(255,255,255)!important" dir=3D"auto"><font style=3D"color:rgb(0=
,0,0)">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 ke=
y (i.e., it is for instance not possible to spend all coin in a single tran=
saction) while spending is unrestricted for the other private key (no limit=
s apply). No limits must apply to coin transacted to a third party.</font><=
/div><div style=3D"background-color:rgba(0,0,0,0);border-color:rgb(53,54,57=
)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)"><br></font></div><div styl=
e=3D"background-color:rgba(0,0,0,0);border-color:rgb(53,54,57)" dir=3D"auto=
"><font style=3D"color:rgb(0,0,0)">Also, it must be possible never having t=
o bring the unrestricted private key online unless more than the limit impo=
sed on the restrictive private key is desired to be spent.</font></div><div=
 style=3D"background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir=
=3D"auto"><span style=3D"color:rgb(0,0,0)"><br></span></div><div style=3D"b=
ackground-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir=3D"auto"><=
font style=3D"color:rgb(0,0,0)">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.</font></div><div style=3D"backgr=
ound-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir=3D"auto"><font =
style=3D"color:rgb(0,0,0)"><br></font></div><div style=3D"background-color:=
rgba(0,0,0,0)!important;border-color:rgb(32,33,36)!important;color:rgb(255,=
255,255)!important" dir=3D"auto"><font style=3D"color:rgb(0,0,0)">Furthermo=
re, the spending limit must be intuitive. Best candidate I believe would be=
 a maximum spend per some fixed number of blocks. For instance, the restric=
tive key may allow a maximum of 100k sats per any window of 144 blocks. Ofc=
ourse the user must be able to set these parameters freely.</font></div><di=
v style=3D"background-color:rgba(0,0,0,0);border-color:rgb(32,33,36)" dir=
=3D"auto"><font style=3D"color:rgb(0,0,0)"><br></font></div><div style=3D"b=
ackground-color:rgba(0,0,0,0);border-color:rgb(32,33,36)" dir=3D"auto"><fon=
t style=3D"color:rgb(0,0,0)">I look forward to any feedback you may have.</=
font></div><div style=3D"background-color:rgba(0,0,0,0);border-color:rgb(32=
,33,36)" dir=3D"auto"><font style=3D"color:rgb(0,0,0)"><br></font></div><di=
v style=3D"background-color:rgba(0,0,0,0)!important;border-color:rgb(222,22=
3,227)!important;color:rgb(255,255,255)!important" dir=3D"auto"><font style=
=3D"color:rgb(0,0,0)">Zac</font></div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><span style=3D"color:rgb(0,0,0)"><br></span></div><div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 10 Aug 2=
021 at 04:17, ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSC=
Pxj@protonmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style=
:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">=C2=A0fromGood =
morning Zac,<br>
<br>
<br>
With some work, what you want can be implemented, to some extent, today, wi=
thout changes to consensus.<br>
<br>
The point you want, I believe, is to have two sets of keys:<br>
<br>
* A long-term-storage keyset, in &quot;cold&quot; storage.<br>
* A short-term-spending keyset, in &quot;warm&quot; storage, controlling on=
ly a small amount of funds.<br>
<br>
What you can do would be:<br>
<br>
* Put all your funds in a single UTXO, with an k-of-n of your cold keys (id=
eally P2TR, or some P2WSH k-of-n).<br>
* 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 t=
he k-of-n of your warm keys.<br>
=C2=A0 * Keep this transaction offchain, in your warm storage.<br>
* Put your cold keys back offline.<br>
* When you need to spend using your warm keys, bring the above transaction =
onchain, then spend from the budget as needed.<br>
<br>
<br>
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`.<=
br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 nLocktime +1day=C2=A0 nLockTi=
me +2day<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------=
-+=C2=A0 =C2=A0+------------+=C2=A0 =C2=A0+------------+<br>
=C2=A0 =C2=A0 =C2=A0cold UTXO --&gt;|=C2=A0 =C2=A0 cold TXO|--&gt;|=C2=A0 =
=C2=A0 cold TXO|--&gt;|=C2=A0 =C2=A0 cold TXO|--&gt; etc.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 |=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br=
>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=
=A0 warm TXO|=C2=A0 =C2=A0|=C2=A0 =C2=A0 warm TXO|=C2=A0 =C2=A0|=C2=A0 =C2=
=A0 warm TXO|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------=
-+=C2=A0 =C2=A0+------------+=C2=A0 =C2=A0+------------+<br>
<br>
Pre-sign the above transactions, store the pre-signed transactions in warm =
storage together with your warm keys.<br>
Then put the cold keys back offline.<br>
<br>
Then from today to tomorrow, you can spend only the first warm TXO.<br>
From tomorrow to the day after, you can spend only the first two warm TXOs.=
<br>
And so on.<br>
<br>
If tomorrow your warm keys are stolen, you can bring the cold keys online t=
o claim the second cold TXO and limit your fund loss to only just the first=
 two warm TXOs.<br>
<br>
The above is bulky, but it has the advantage of not using any special opcod=
es or features (improving privacy, especially with P2TR which would in theo=
ry 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 s=
et `nLockTime` to recent block heights.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
</blockquote></div></div>

--0000000000005c17eb05c96ec93e--