path: root/06/7c04cce18a8ff7b44d89d5e7bb9f7bca8842f8

Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7CC30C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 28 Jul 2021 17:57:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 621196088A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 28 Jul 2021 17:57:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id O-5FafGGpTNG
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 28 Jul 2021 17:57:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com
 [IPv6:2a00:1450:4864:20::530])
 by smtp3.osuosl.org (Postfix) with ESMTPS id DAA3A606E2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 28 Jul 2021 17:57:29 +0000 (UTC)
Received: by mail-ed1-x530.google.com with SMTP id f13so4351845edq.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 28 Jul 2021 10:57:29 -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=SKMdD1G3Q9aOhaG0SZCGVxXd59tgIr5opwLwVGHyAyw=;
 b=oqoa8knuXaW9q485kMZo7ZfAjTmO5ejGB0zdx/8MMlHGLBrfCjreBznEjgmOd91wU1
 92wffd8MRMwOoNN1knkMFcRkdMKP7v/wyrTbRA7KKxLnI3jYWkQr8LT4KSTbvdGdUQJP
 X0y6ZzV3bDANQXNACYxdpX9fWTyzcJMSGaa/rnM7VJQQhj/QH6aTd3ueHV+RzQgGkfz7
 Z1UXAHBGfG4M0juSCs8YL1xttn/kc81FnjBSr2uBzCdHUcdC5vmDHcMpoz54/FmeeJu7
 47/vheex8UF8yeU1QedG3UD0Z2n7XkO+pgUuIlhybPnfzBBxo5ijstehFhLNyRi4DUOB
 cSvw==
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=SKMdD1G3Q9aOhaG0SZCGVxXd59tgIr5opwLwVGHyAyw=;
 b=KI8lOLWCCnWHzd6rDFnRXISCVtgxZ/ADvt3MT533pvjCmugeKmRdZLlx0MZe27bVoJ
 DNM82VcuR0/vYdRWIpzjKjdf+91Cbphw32qeu2MnmgZtKqgkGGg10+xOXEtOMGHP43bT
 rrE7qqTJg7xS68J/q7BL6JRXXHovRuf526yDjmLHae8GFLiFHn3JXjWKBQLmdlaBjIbP
 GD7219F61NCWrSl4nrGFnodJenaPGli73i6ABMfW9CWZM9E/p0wrJdFmh4a8USzeXfdP
 IhiR9NNUlM3XZKoZ00dYR1Ducl54wEnV86XdsS6ypqLtJc7Wf0qfQYkUn69p3AI+FQ3u
 mZpw==
X-Gm-Message-State: AOAM533j6ES6Y7ASap3QJDdJj5oqNpr4MrZBzP0lKKei8jip7XTKzazB
 vjGFFwbCZOz+NWmNiuHV7TAgZd8YybLTKfabiQA=
X-Google-Smtp-Source: ABdhPJxVBXnYITdV8jRUO0NSPgXMRtwqXfghIcsyPMYoYKmKDQSVyRoQnh4FUzQterExny7yOtvyds12hUfitt9hEIg=
X-Received: by 2002:a05:6402:19a:: with SMTP id
 r26mr1245119edv.230.1627495047936; 
 Wed, 28 Jul 2021 10:57:27 -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>
In-Reply-To: <CAJ4-pEBwdUJ3kg=yb-kWZLoaX5f_2t353K7Tr+dJy+JpAoKTmQ@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 28 Jul 2021 10:57:09 -0700
Message-ID: <CAGpPWDYMZ+w3VSaLhR68f4WVq7NCUp3SedwW2e8QnRHOgLQqQg@mail.gmail.com>
To: Zac Greenwood <zachgrw@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000034becf05c832b8e8"
X-Mailman-Approved-At: Wed, 28 Jul 2021 18:17:05 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION
 (an alternative to OP_CTV)
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: Wed, 28 Jul 2021 17:57:32 -0000

--00000000000034becf05c832b8e8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Zac,

> a smart wallet should be able to set up and maintain multiple
rate-limited addresses in such a way that their aggregate behaviour meets
any rate-limiting parameters as desired by the user

I think that would be possible if there was a way to say "within the last B
blocks, this output can only spend to addresses other than X,Y,Z an amount
less than C coins minus however much coins have been spent by those
addresses in the last B blocks". This would require that full nodes keep
around information about which addresses have been spent from recently, so
that information is accessible during script execution. This could be made
a bit less heavy by requiring countable transactions to run some particular
opcode (so only opted-in transactions would need to be stored).

> This ought to alleviate your privacy concerns because it means that the
wallet will be able to mix outputs.

The ability to mix outputs isn't a privacy issue. The ability to keep
outputs separate is the privacy issue. For rate-limiting to work, the
outputs must be associated with eachother so that rate limiting can take
them all into account. It seems to me that its fundamentally impossible to
do this while keeping outputs uncorrelated.

> such user-enabled rate-limiting is superior to one that requires a third
party.

Removing a 3rd party certainly has upsides. However, using a 3rd party
would be able to solve the privacy issue by keeping outputs uncorrelated
(in different addresses) to the outside world. Trade offs.

In any case, if you want to continue talking about rate-limiting
transactions, it might be a good idea to start a new thread for that, since
its a bit off topic for this one.

> how a vault solution would be able to prevent an attacker who is in
possession of the vaults=E2=80=99 private key from sabotaging the user by r=
eplacing
the user transaction with one having a higher fee every time the user
attempts to transact

A wallet vault has multiple keys. If one key is stolen, the user can use
two keys to override the attacker's transaction. If two keys are stolen,
the user can use three keys. Etc. The attacker must have as many keys as
the user can use in order to successfully steal funds. This can happen in
one of these kinds of ways:

A. The attacker steals all keys.
B. The attacker steals half the keys and ensures that the victim doesn't
have access to those keys (eg the attacker steals the only copy of half the
keys).
C. The attacker steals any key and incapacitates the victim for the entire
cooldown period, so they can't use any of their keys.

In case C, it would be useful to have rate limiting actually.

On Tue, Jul 27, 2021 at 9:57 PM Zac Greenwood <zachgrw@gmail.com> wrote:

> Hi Billy,
>
> Thank you for your comprehensive reply. My purpose was to find out whethe=
r
> a proposal to somehow limit the amount being sent from an address exists
> and to further illustrate my thoughts by giving a concrete example of how
> this might work functionally without getting to deep into the
> technicalities.
>
> As for your assumption: for an amount limit to have the desired effect, I
> realize now that there must also exist some limit on the number of
> transactions that will be allowed from the encumbered address.
>
> Taking a step back, a typical use case would be a speculating user
> intending to hodl bitcoin but who still wishes to be able to occasionally
> transact minor amounts.
>
> Ideally, such user should optionally still be able to bypass the rate
> limit and spend the entire amount in a single transaction by signing with
> an additional private key (multisig).
>
> During the setup phase, a user sends all their to-be-rate-limited coin to
> a single address. When spending from this rate limited address, any chang=
e
> sent to the change address must be rate limited as well using identical
> parameters. I believe that=E2=80=99s also what you=E2=80=99re suggesting.
>
> I believe that a smart wallet should be able to set up and maintain
> multiple rate-limited addresses in such a way that their aggregate
> behaviour meets any rate-limiting parameters as desired by the user. This
> ought to alleviate your privacy concerns because it means that the wallet
> will be able to mix outputs.
>
> The options for the to-be implemented rate-limiting parameters vary from
> completely arbitrary to more restrictive.
>
> Completely arbitrary parameters would allow users to set up a rate limit
> that basically destroys their funds, for instance rate-limiting an addres=
s
> to an amount of 1 satoshi per 100 blocks.
>
> More restrictive rate limits would remove such footgun and may require
> that only a combination of parameters are allowed such that all funds wil=
l
> be spendable within a set number of blocks (for instance 210,000).
>
> As for the rate-limiting parameters, in addition to a per-transaction
> maximum of (minimum amount in satoshi or a percentage of the total amount
> stored at the address), also the transaction frequency must be limited. I
> would propose this to be expressed as a number of blocks before a next
> transaction can be sent from the encumbered address(es).
>
> I believe such user-enabled rate-limiting is superior to one that require=
s
> a third party.
>
> As an aside, I am not sure how a vault solution would be able to prevent
> an attacker who is in possession of the vaults=E2=80=99 private key from =
sabotaging
> the user by replacing the user transaction with one having a higher fee
> every time the user attempts to transact. I am probably missing something
> here though.
>
> Zac
>
>
> On Tue, 27 Jul 2021 at 19:21, Billy Tetrud <billy.tetrud@gmail.com> wrote=
:
>
>> Hi Zac,
>>
>> I haven't heard of any proposal for limiting the amount that can be sent
>> from an address. I assume you mean limiting the amount that can be sent =
in
>> a period of time - eg something that would encode that for address A, on=
ly
>> X bitcoin can be sent from the address in a given day/week/etc, is that
>> right? That would actually be a somewhat difficult thing to do in the
>> output-based system Bitcoin uses, and would be easier in an account base=
d
>> system like Ethereum. The problem is that each output is separate, and
>> there's no concept in bitcoin of encumbering outputs together.
>>
>> What you could do is design a system where coins would be combined in a
>> single output, and then encumber that output with a script that allows a
>> limited amount of coin be sent to a destination address and requires all
>> other bitcoins be returned to sender in a new change output that is also
>> timelocked. That way, the new change output can't be used again until th=
e
>> timelock expires (eg a week). However, to ensure this wallet works
>> properly, any deposit into the wallet would have to also spend the walle=
t's
>> single output, so as to create a new single output at that address. So 3=
rd
>> parties wouldn't be able to arbitrarily send money in (or rather, they
>> could, but each output would have its own separate spending limit).
>>
>> > such kind of restriction would be extremely effective in thwarting the
>> most damaging type of theft being the one where all funds are swept in a
>> single transaction
>>
>> It would. However a normal wallet vault basically already has this
>> property - a thief can't simply sweep funds instantly, but instead the
>> victim will see an initiated transaction and will be able to reverse it
>> within a delay time-window. I don't think adding a spending limit would =
add
>> meaningful security to a delayed-send wallet vault like that. But it cou=
ld
>> be used to increase the security of a wallet vault that can be instantly
>> spent from - ie if the attacker successfully steals funds, then the vict=
im
>> has time to go gather their additional keys and move the remaining
>> (unstolen) funds into a new wallet.
>>
>> OP_CD could potentially be augmented to allow specifying limit amounts
>> for each destination, which would allow you to create a wallet like this=
.
>> It would be a bit of an awkward wallet to use tho, since you couldn't
>> receive directly into it from a 3rd party and you also couldn't keep
>> separate outputs (which is bad for privacy).
>>
>> An alternate way of doing this that you don't need any new opcodes for
>> would be to have a 3rd party service that signs multisig transactions fr=
om
>> a wallet only up to a limit. The end-user could have additional keys suc=
h
>> that the 3rd party can't prevent them from accessing that (if they turn
>> uncooperative), and the 3rd party would only have a single key so they
>> can't steal funds, but the user would sign a transaction with one key, a=
nd
>> the 3rd party with another as long as the spending limit hasn't been
>> reached. This wouldn't have much counterparty risk, but would be a less
>> awkward wallet than what I described above - meaning anyone could send
>> funds into the wallet without defeating the spending limit, and privacy
>> could be kept intact (minus the fact that the 3rd party would know what
>> your outputs are).
>>
>> BT
>>
>> On Tue, Jul 27, 2021 at 4:18 AM Zac Greenwood <zachgrw@gmail.com> wrote:
>>
>>> Hi Billy,
>>>
>>> On the topic of wallet vaults, are there any plans to implement a way t=
o
>>> limit the maximum amount to be sent from an address?
>>>
>>> An example of such limit might be: the maximum amount allowed to send i=
s
>>> max(s, p) where s is a number of satoshi and p a percentage of the tota=
l
>>> available (sendable) amount.
>>>
>>> A minimum value may be imposed on the percentage to ensure that the
>>> address can be emptied within a reasonable number of transactions. The
>>> second parameter s allows a minimum permitted amount. (This is necessar=
y
>>> because with only the percentage parameter the minimum permitted amount
>>> converges to zero, making it impossible to empty the address).
>>>
>>> There may be other ways too. In my view, such kind of restriction would
>>> be extremely effective in thwarting the most damaging type of theft bei=
ng
>>> the one where all funds are swept in a single transaction.
>>>
>>> Zac
>>>
>>>
>>> On Tue, 27 Jul 2021 at 03:26, Billy Tetrud via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Hey James,
>>>>
>>>> In the examples you mentioned, what I was exploring was a mechanism of
>>>> attack by which the attacker could steal user A's key and use that key=
 to
>>>> send a transaction with the maximum possible fee. User B would still
>>>> receive some funds (probably), but if the fee could be large, the atta=
cker
>>>> would either do a lot of damage to user B (griefing) or could make an
>>>> agreement with a miner to give back some of the large fee (theft).
>>>>
>>>> But as for use cases, the proposal mentions a number of use cases
>>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main=
/cd/bip-constraindestination.md#motivation> and
>>>> most overlap with the use cases of op_ctv <https://utxos.org/uses/> (J=
eremy
>>>> Rubin's website for op_ctv has a lot of good details, most of which ar=
e
>>>> also relevant to op_cd). The use case I'm most interested in is wallet
>>>> vaults. This opcode can be used to create a wallet vault where the use=
r
>>>> only needs to use, for example, 1 key to spend funds, but the attacker=
 must
>>>> steal 2 or more keys to spend funds. The benefits of a 2 key wallet va=
ult
>>>> like this vs a normal 2-of-2 multisig wallet are that not only does an
>>>> attacker have to steal both keys (same level of security), but also th=
e
>>>> user can lose one key and still recover their funds (better redundancy=
) and
>>>> also that generally the user doesn't need to access their second key -=
 so
>>>> that can remain in a much more secure location (which would also proba=
bly
>>>> make that key harder to steal). The only time the second key only come=
s
>>>> into play if one key is stolen and the attacker attempts to send a
>>>> transaction. At that point, the user would go find and use his second =
key
>>>> (along with the first) to send a revoke transaction to prevent the att=
acker
>>>> from stealing their funds. This is somewhat akin to a lightning watcht=
ower
>>>> scenario, where your wallet would watch the chain and alert you about =
an
>>>> unexpected transaction, at which point you'd manually do a revoke (vs =
a
>>>> watchtower's automated response). You might be interested in taking a =
look
>>>> at this wallet vault design
>>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main=
/cd/op_cdWalletVault1.md>
>>>> that uses OP_CD or even my full vision
>>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults> of the
>>>> wallet vault I want to be able to create.
>>>>
>>>> With a covenant opcode like this, its possible to create very usable
>>>> and accessible but highly secure wallets that can allow normal people =
to
>>>> hold self custody of their keys without fear of loss or theft and with=
out
>>>> the hassle of a lot of safe deposit boxes (or other secure seed storag=
e
>>>> locations).
>>>>
>>>> Cheers,
>>>> BT
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jul 26, 2021 at 2:08 PM James MacWhyte <macwhyte@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Billy!
>>>>>
>>>>> See above, but to break down that situation a bit further, these are
>>>>>> the two situations I can think of:
>>>>>>
>>>>>>    1. The opcode limits user/group A to send the output to
>>>>>>    user/group B
>>>>>>    2. The opcode limits user A to send from one address they own to
>>>>>>    another address they own.
>>>>>>
>>>>>> I'm trying to think of a good use case for this type of opcode. In
>>>>> these examples, an attacker who compromises the key for user A can't =
steal
>>>>> the money because it can only be sent to user B. So if the attacker w=
ants
>>>>> to steal the funds, they would need to compromise the keys of both us=
er A
>>>>> and user B.
>>>>>
>>>>> But how is that any better than a 2-of-2 multisig? Isn't the end
>>>>> result exactly the same?
>>>>>
>>>>> James
>>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>

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

<div dir=3D"ltr">Hi Zac,<div><br></div><div>&gt;=C2=A0<span style=3D"color:=
rgb(49,49,49);font-size:16px;word-spacing:1px">a smart wallet should be abl=
e to set up and maintain multiple rate-limited addresses in such a way that=
 their aggregate behaviour meets any rate-limiting parameters as desired by=
 the user</span></div><div><span style=3D"color:rgb(49,49,49);font-size:16p=
x;word-spacing:1px"><br></span></div><div><span style=3D"color:rgb(49,49,49=
);font-size:16px;word-spacing:1px">I think that would be possible if there =
was a way to say &quot;within the last B blocks, this output can only spend=
 to addresses other than X,Y,Z an amount less than C coins minus however mu=
ch coins have been spent by those addresses in the last B blocks&quot;. Thi=
s would require that full nodes keep around information about which address=
es have been spent from recently, so that information=C2=A0is accessible du=
ring script execution. This could be made a bit less heavy by requiring cou=
ntable transactions to run some particular opcode (so only opted-in transac=
tions would need to be stored).=C2=A0</span></div><div><span style=3D"color=
:rgb(49,49,49);font-size:16px;word-spacing:1px"><br></span></div><div><span=
 style=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">&gt;=C2=A0</=
span><span style=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">Th=
is ought to alleviate your privacy concerns because it means that the walle=
t will be able to mix outputs.</span></div><div><span style=3D"color:rgb(49=
,49,49);font-size:16px;word-spacing:1px"><br>The ability to mix outputs isn=
&#39;t a privacy issue. The ability to keep outputs separate is the privacy=
 issue. For rate-limiting to work, the outputs must be associated with each=
other so that rate limiting can take them all into account. It seems to me =
that its fundamentally impossible to do this while keeping outputs uncorrel=
ated.</span></div><div><span style=3D"color:rgb(49,49,49);font-size:16px;wo=
rd-spacing:1px"><br></span></div><div><span style=3D"color:rgb(49,49,49);fo=
nt-size:16px;word-spacing:1px">&gt;=C2=A0</span><span style=3D"color:rgb(49=
,49,49);font-size:16px;word-spacing:1px">such user-enabled rate-limiting is=
 superior to one that requires a third party.</span></div><div><span style=
=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px"><br></span></div><=
div><span style=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">Rem=
oving a 3rd party certainly has upsides. However, using a 3rd party would b=
e able to solve the privacy issue by keeping outputs uncorrelated (in diffe=
rent addresses) to the outside world. Trade offs.</span></div><div><span st=
yle=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px"><br></span></di=
v><div><span style=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">=
In any case, if you want to continue talking about rate-limiting transactio=
ns, it might be a good idea to start a new thread for that, since its a bit=
 off topic for this one.=C2=A0</span></div><div><span style=3D"color:rgb(49=
,49,49);font-size:16px;word-spacing:1px"><br></span></div><div><span style=
=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">&gt;=C2=A0</span><=
span style=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">how a va=
ult solution would be able to prevent an attacker who is in possession of t=
he vaults=E2=80=99 private key from sabotaging the user by replacing the us=
er transaction with one having a higher fee every time the user attempts to=
 transact</span></div><div><span style=3D"color:rgb(49,49,49);font-size:16p=
x;word-spacing:1px"><br></span></div><div><span style=3D"color:rgb(49,49,49=
);font-size:16px;word-spacing:1px">A wallet vault has multiple keys. If one=
 key is stolen, the user can use two keys to override the attacker&#39;s tr=
ansaction. If two keys are stolen, the user can use three keys. Etc. The at=
tacker must have as many keys as the user can use in order to successfully =
steal funds. This can happen in one of these kinds of ways:<br><br>A. The a=
ttacker steals all keys.</span></div><div><span style=3D"color:rgb(49,49,49=
);font-size:16px;word-spacing:1px">B. The attacker steals half the keys and=
 ensures that the victim doesn&#39;t have access to those keys (eg the atta=
cker steals the only copy of half the keys).</span></div><div><span style=
=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">C. The attacker st=
eals any key and incapacitates the victim for the entire cooldown period, s=
o they can&#39;t use any of their keys.</span></div><div><span style=3D"col=
or:rgb(49,49,49);font-size:16px;word-spacing:1px"><br></span></div><div><sp=
an style=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">In case C,=
 it would be useful to have rate limiting actually.</span></div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul=
 27, 2021 at 9:57 PM Zac Greenwood &lt;<a href=3D"mailto:zachgrw@gmail.com"=
>zachgrw@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div><div dir=3D"auto" style=3D"font-size:1rem;word-spaci=
ng:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">Hi Billy,</div><div =
dir=3D"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(49,4=
9,49);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-size:1=
rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">Thank =
you for your comprehensive reply. My purpose was to find out whether a prop=
osal to somehow limit the amount being sent from an address exists and to f=
urther illustrate my thoughts by giving a concrete example of how this migh=
t work functionally without getting to deep into the technicalities.</div><=
div dir=3D"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(=
49,49,49);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-si=
ze:1rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">As=
 for your assumption: for an amount limit to have the desired effect, I rea=
lize now that there must also exist some limit on the number of transaction=
s that will be allowed from the encumbered address.</div><div dir=3D"auto" =
style=3D"font-size:16px;word-spacing:1px;border-color:rgb(49,49,49);color:r=
gb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-size:1rem;word-spac=
ing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">Taking a step back,=
 a typical use case would be a speculating user intending to hodl bitcoin b=
ut who still wishes to be able to occasionally transact minor amounts.</div=
><div dir=3D"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rg=
b(49,49,49);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-=
size:1rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">=
Ideally, such user should optionally still be able to bypass the rate limit=
 and spend the entire amount in a single transaction by signing with an add=
itional private key (multisig).</div><div dir=3D"auto" style=3D"font-size:1=
6px;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><br></=
div><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1px;border-color=
:rgb(49,49,49);color:rgb(49,49,49)">During the setup phase, a user sends al=
l their to-be-rate-limited coin to a single address. When spending from thi=
s rate limited address, any change sent to the change address must be rate =
limited as well using identical parameters. I believe that=E2=80=99s also w=
hat you=E2=80=99re suggesting.</div><div dir=3D"auto" style=3D"font-size:16=
px;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><br></d=
iv><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1px;border-color:=
rgb(49,49,49);color:rgb(49,49,49)">I believe that a smart wallet should be =
able to set up and maintain multiple rate-limited addresses in such a way t=
hat their aggregate behaviour meets any rate-limiting parameters as desired=
 by the user. This ought to alleviate your privacy concerns because it mean=
s that the wallet will be able to mix outputs.</div><div dir=3D"auto" style=
=3D"font-size:16px;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49=
,49,49)"><br></div><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1=
px;border-color:rgb(49,49,49);color:rgb(49,49,49)">The options for the to-b=
e implemented rate-limiting parameters vary from completely arbitrary to mo=
re restrictive.</div><div dir=3D"auto" style=3D"font-size:16px;word-spacing=
:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><br></div><div dir=3D"=
auto" style=3D"font-size:1rem;word-spacing:1px;border-color:rgb(49,49,49);c=
olor:rgb(49,49,49)">Completely arbitrary parameters would allow users to se=
t up a rate limit that basically destroys their funds, for instance rate-li=
miting an address to an amount of 1 satoshi per 100 blocks.</div><div dir=
=3D"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(49,49,4=
9);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-size:1rem=
;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">More rest=
rictive rate limits would remove such footgun and may require that only a c=
ombination of parameters are allowed such that all funds will be spendable =
within a set number of blocks (for instance 210,000).=C2=A0</div><div dir=
=3D"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(49,49,4=
9);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-size:1rem=
;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">As for th=
e rate-limiting parameters, in addition to a per-transaction maximum of (mi=
nimum amount in satoshi or a percentage of the total amount stored at the a=
ddress), also the transaction frequency must be limited. I would propose th=
is to be expressed as a number of blocks before a next transaction can be s=
ent from the encumbered address(es).</div><div dir=3D"auto" style=3D"font-s=
ize:16px;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><=
br></div><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1px;border-=
color:rgb(49,49,49);color:rgb(49,49,49)">I believe such user-enabled rate-l=
imiting is superior to one that requires a third party.</div><div dir=3D"au=
to" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(49,49,49);col=
or:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-size:1rem;word-=
spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">As an aside, I =
am not sure how a vault solution would be able to prevent an attacker who i=
s in possession of the vaults=E2=80=99 private key from sabotaging the user=
 by replacing the user transaction with one having a higher fee every time =
the user attempts to transact. I am probably missing something here though.=
</div><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1px;border-col=
or:rgb(49,49,49);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"=
font-size:1rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,=
49)">Zac</div><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1px;bo=
rder-color:rgb(49,49,49);color:rgb(49,49,49)"><br></div></div><div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 27 Jul=
 2021 at 19:21, Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com" =
target=3D"_blank">billy.tetrud@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Zac,<div><br></=
div><div>I haven&#39;t heard of any proposal for limiting the amount that c=
an be sent from an address. I assume you mean limiting the amount that can =
be sent in a period of time - eg something that would encode that for addre=
ss A, only X bitcoin can be sent from the address in a given day/week/etc, =
is that right? That would actually be a somewhat difficult thing to do in t=
he output-based system Bitcoin uses, and would be easier in an account base=
d system like Ethereum. The problem is that each output is separate, and th=
ere&#39;s no concept in bitcoin of encumbering outputs together.=C2=A0</div=
><div><br></div><div>What you could do is design a system where coins would=
 be combined in a single output, and then encumber that output with a scrip=
t that allows a limited amount of coin be sent to a destination address and=
 requires all other bitcoins be returned to sender in a new change output t=
hat is also timelocked. That way, the new change output can&#39;t be used a=
gain until the timelock expires (eg a week). However, to ensure this wallet=
 works properly, any deposit into the wallet would have to also spend the w=
allet&#39;s single output, so as to create a new single output at that addr=
ess. So 3rd parties wouldn&#39;t be able to arbitrarily send money in (or r=
ather, they could, but each output would have its own separate spending lim=
it).=C2=A0</div><div><br></div><div>&gt; such kind of restriction would be =
extremely effective in thwarting the most damaging type of theft being the =
one where all funds are swept in a single transaction</div><div><br></div><=
div>It would. However a normal wallet vault basically=C2=A0already has this=
 property - a thief can&#39;t simply sweep funds instantly, but instead the=
 victim will see an initiated transaction and will be able to reverse it wi=
thin a delay time-window. I don&#39;t think adding a spending limit would a=
dd meaningful security to a delayed-send wallet vault like that. But it cou=
ld be used to increase the security of a wallet vault that can be instantly=
 spent from - ie if the attacker successfully steals funds, then the victim=
 has time to go gather their additional keys and move the remaining (unstol=
en) funds into a new wallet.=C2=A0</div><div><br></div><div>OP_CD could pot=
entially be augmented to allow specifying limit amounts for each destinatio=
n, which would allow you to create a wallet like this. It would be a bit of=
 an awkward wallet to use tho, since you couldn&#39;t receive directly into=
 it from a 3rd party and you also couldn&#39;t keep separate outputs (which=
 is bad for privacy).=C2=A0</div><div><br></div><div>An alternate way of do=
ing this that you don&#39;t need any new opcodes for would be to have a 3rd=
 party service that signs multisig transactions from a wallet only up to a =
limit. The end-user could have additional keys such that the 3rd party can&=
#39;t prevent them from accessing that (if they turn uncooperative), and th=
e 3rd party would only have a single key so they can&#39;t steal funds, but=
 the user would sign a transaction with one key, and the 3rd party with ano=
ther as long as the spending limit hasn&#39;t been reached. This wouldn&#39=
;t have much counterparty risk, but would be a less awkward wallet than wha=
t I described above - meaning anyone could send funds into the wallet witho=
ut defeating the spending limit, and privacy could be kept intact (minus th=
e fact that the 3rd party would know what your outputs are).=C2=A0</div></d=
iv><div dir=3D"ltr"><div><br></div><div>BT</div></div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 27, 2021 at 4:1=
8 AM Zac Greenwood &lt;<a href=3D"mailto:zachgrw@gmail.com" target=3D"_blan=
k">zachgrw@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"auto">Hi Billy,</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">On the topic of wallet vaults, are there any plans =
to implement a way to limit the maximum amount to be sent from an address?<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">An example of such limit=
 might be: the maximum amount allowed to send is max(s, p) where s is a num=
ber of satoshi and p a percentage of the total available (sendable) amount.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">A minimum value may be =
imposed on the percentage to ensure that the address can be emptied within =
a reasonable number of transactions. The second parameter s allows a minimu=
m permitted amount. (This is necessary because with only the percentage par=
ameter the minimum permitted amount converges to zero, making it impossible=
 to empty the address).=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">There may be other ways too. In my view, such kind of restriction wou=
ld be extremely effective in thwarting the most damaging type of theft bein=
g the one where all funds are swept in a single transaction.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Zac</div><div dir=3D"auto"><br></div>=
<div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Tue, 27 Jul 2021 at 03:26, Billy Tetrud via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr">Hey James,<div><br></div><div>In t=
he examples you mentioned, what I was exploring was a mechanism of attack b=
y which the attacker could steal user A&#39;s key and use that key to send =
a transaction with the maximum possible fee. User B would still receive som=
e funds (probably), but if the fee could be large, the attacker would eithe=
r do a lot of damage to user B (griefing) or could make an agreement with a=
 miner to give back some of the large fee (theft).=C2=A0</div><div><br></di=
v><div>But as for use cases, the proposal mentions <a href=3D"https://githu=
b.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constrainde=
stination.md#motivation" target=3D"_blank">a number of use cases</a>=C2=A0a=
nd most overlap with the <a href=3D"https://utxos.org/uses/" target=3D"_bla=
nk">use cases of op_ctv</a>=C2=A0(Jeremy Rubin&#39;s website for op_ctv has=
 a lot of good details, most of which are also relevant to op_cd). The use =
case I&#39;m most interested=C2=A0in is wallet vaults. This opcode can be u=
sed to create a wallet vault where the user only needs to use, for example,=
 1 key to spend funds, but the attacker must steal 2 or more keys to spend =
funds. The benefits of a 2 key wallet vault like this vs a normal 2-of-2 mu=
ltisig wallet are that not only does an attacker have to steal both keys (s=
ame level of security), but also the user can lose one key and still recove=
r their funds (better redundancy) and also that generally the user doesn&#3=
9;t need to access their second key - so that can remain in a much more sec=
ure location (which would also probably make that key harder to steal). The=
 only time the second key only comes into play if one key is stolen and the=
 attacker attempts to send a transaction. At that point, the user would go =
find and use his second key (along with the first) to send a revoke transac=
tion to prevent the attacker from stealing their funds. This is somewhat ak=
in to a lightning watchtower scenario, where your wallet would watch the ch=
ain and alert you about an unexpected transaction, at which point you&#39;d=
 manually do a revoke (vs a watchtower&#39;s automated response). You might=
 be interested in taking a look at <a href=3D"https://github.com/freshenees=
z/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md" target=3D=
"_blank">this wallet vault design</a> that uses OP_CD or even <a href=3D"ht=
tps://github.com/fresheneesz/bip-efficient-bitcoin-vaults" target=3D"_blank=
">my full vision</a> of the wallet vault I want to be able to create.</div>=
<div><br></div><div>With a covenant opcode like this, its possible to creat=
e very usable and accessible but highly secure wallets that can allow norma=
l people to hold self custody of their keys without fear of loss or theft a=
nd without the hassle of a lot of safe deposit boxes (or other secure seed =
storage locations).=C2=A0</div><div><br></div><div>Cheers,</div><div>BT</di=
v><div><br></div><div><br></div><div><br></div><div><br></div></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 2=
6, 2021 at 2:08 PM James MacWhyte &lt;<a href=3D"mailto:macwhyte@gmail.com"=
 target=3D"_blank">macwhyte@gmail.com</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Hi B=
illy!</div><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><span>See abo=
ve, but to break down that situation a bit further, these are the two situa=
tions I can think of:</span><br></div><div><div><ol><li style=3D"padding-bo=
ttom:0.6001em">The opcode limits user/group A to send the output to user/gr=
oup B</li><li style=3D"padding-bottom:0.6001em">The opcode limits user A to=
 send from one address they own to another address they own.=C2=A0</li></ol=
></div></div></div></blockquote><div><span>I&#39;m trying to think of a goo=
d use case for this type of opcode. In these examples, an attacker who comp=
romises the key for user A can&#39;t steal the money because it can only be=
 sent to user B. So if the attacker wants to steal the funds, they would ne=
ed to compromise the keys of both user A and user B.</span></div><div><span=
><br></span></div><div><span>But how is that any better than a 2-of-2 multi=
sig? Isn&#39;t the end result exactly=C2=A0the same?</span><br></div><div><=
span><br></span></div><div><span>James</span></div></div></div>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>

--00000000000034becf05c832b8e8--