From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id F1909C000E for ; Wed, 28 Jul 2021 04:57:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id CC455405B6 for ; Wed, 28 Jul 2021 04:57:46 +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: 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 DINLfGRacICG for ; Wed, 28 Jul 2021 04:57:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) by smtp4.osuosl.org (Postfix) with ESMTPS id 0C243404C1 for ; Wed, 28 Jul 2021 04:57:44 +0000 (UTC) Received: by mail-il1-x12f.google.com with SMTP id u7so1486329ilj.8 for ; Tue, 27 Jul 2021 21:57:44 -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=cxzNtpILMb50fXDKYFB73X1327ArWgi0SDw3vrvbpSo=; b=CYYhNusnfVkXRL1pGkv5cbSgy77nFfVDGQNf6LYlfV0xmzXX4Blngn1bgPrpc0gKiW tCtgqJB2w9y5nSpnMh2fZOWhZYWvxXk4Ud7d2uAPy1fHhleq13gVe6tBQoXtzsCbyjCA iyDA/kZgYrjGuUWBbtHCSAPGNlpgnyvaI/bqnLZ3Bj9sRGt17CdXbxZSTONSgmLvLOOm 5izK6OVoCi0ExyXbBOyO4VJVtVHVDLZCz0RMUARMhJBUJRYunqvGt0cYI+9Ake6k3IGB /ld6u0hoMpuIgvedbtaaOpFgBstKlB1X4CkLjOekTc2DCCOrMNvMt/KQvpcsy4ZhhXEZ bNmQ== 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=cxzNtpILMb50fXDKYFB73X1327ArWgi0SDw3vrvbpSo=; b=FPOqkVwV2p04+5Kb+JVLYQCw+kJH2mNbdFQWUiOsfnHt5GWLXNU58UCNVsH1ocvXZd mc3yjtklUM+zokWWkrK0jvFR6XryEsFSZEwIXet9kfRw+M50UXtupU+9Y0n24FiRQjRL 5ijWZ2HJHoXQAxeq3SMYmNqv0iZFzHVMHpB/lBLHCML4y00QevBIeOEd339JZjPRaNAF OwP22ZHFf1RFLvTpqW8D1Vhb5cqxLORyGPk0KqylomEO8waBT7RQyu3GMkVVfAYXb4F3 H91dP7Qx+3PtW9GF/bp0PzJFSqkT4HwLsXlyM0xByFcmTqiJLRkoefpZlcNwjCN8zQVD +b/w== X-Gm-Message-State: AOAM53071UfItZQnyGNu98I4ENh3Af/YxwojXAbPIUOZvjACnsNAQENm nUy+/xRkh4Uzg6uHkV50X1VtAoAlRyCBf3rR7W8= X-Google-Smtp-Source: ABdhPJzLOz4vr4Yemie/kwyGPgz1ZWMjNT7riVWFWY8Dn3g3WODrJSZjr9nGzLIYCxYsZJsSD7I5ETaZ3vLXaQ+PWiY= X-Received: by 2002:a92:7d08:: with SMTP id y8mr19051997ilc.111.1627448264087; Tue, 27 Jul 2021 21:57:44 -0700 (PDT) MIME-Version: 1.0 References: <20210725053803.fnmd6etv3f7x3u3p@ganymede> In-Reply-To: From: Zac Greenwood Date: Wed, 28 Jul 2021 06:57:33 +0200 Message-ID: To: Billy Tetrud Content-Type: multipart/alternative; boundary="000000000000abdd1105c827d37a" X-Mailman-Approved-At: Wed, 28 Jul 2021 07:40:50 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 04:57:47 -0000 --000000000000abdd1105c827d37a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Billy, Thank you for your comprehensive reply. My purpose was to find out whether 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 change 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 address 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 will 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 requires 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 sabot= aging 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 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 i= n > a period of time - eg something that would encode that for address A, onl= y > 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 based > 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 the > timelock expires (eg a week). However, to ensure this wallet works > properly, any deposit into the wallet would have to also spend the wallet= 's > single output, so as to create a new single output at that address. So 3r= d > 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 a= dd > meaningful security to a delayed-send wallet vault like that. But it coul= d > 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 victi= m > 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 fo= r > 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 receiv= e > 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 fro= m > a wallet only up to a limit. The end-user could have additional keys such > 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, an= d > 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 wrote: > >> Hi Billy, >> >> 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? >> >> An example of such limit might be: the maximum amount allowed to send is >> max(s, p) where s is a number of satoshi and p a percentage of the total >> 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 necessary >> 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 bein= g >> 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 attac= ker >>> 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 >>> and >>> most overlap with the use cases of op_ctv (Je= remy >>> Rubin's website for op_ctv has a lot of good details, most of which are >>> 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 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 vau= lt >>> 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 the >>> 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 probab= ly >>> 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 k= ey >>> (along with the first) to send a revoke transaction to prevent the atta= cker >>> from stealing their funds. This is somewhat akin to a lightning watchto= wer >>> scenario, where your wallet would watch the chain and alert you about a= n >>> unexpected transaction, at which point you'd manually do a revoke (vs a >>> watchtower's automated response). You might be interested in taking a l= ook >>> at this wallet vault design >>> >>> that uses OP_CD or even my full vision >>> of the >>> wallet vault I want to be able to create. >>> >>> With a covenant opcode like this, its possible to create very usable an= d >>> accessible but highly secure wallets that can allow normal people to ho= ld >>> self custody of their keys without fear of loss or theft and without th= e >>> hassle of a lot of safe deposit boxes (or other secure seed storage >>> locations). >>> >>> Cheers, >>> BT >>> >>> >>> >>> >>> >>> On Mon, Jul 26, 2021 at 2:08 PM James MacWhyte >>> 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 s= teal >>>> the money because it can only be sent to user B. So if the attacker wa= nts >>>> to steal the funds, they would need to compromise the keys of both use= r A >>>> and user B. >>>> >>>> But how is that any better than a 2-of-2 multisig? Isn't the end resul= t >>>> exactly the same? >>>> >>>> James >>>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> --000000000000abdd1105c827d37a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Billy,

Thank you for your compr= ehensive reply. My purpose was to find out whether a proposal to somehow li= mit the amount being sent from an address exists and to further illustrate = my thoughts by giving a concrete example of how this might work functionall= y without getting to deep into the technicalities.

As for your assumpti= on: for an amount limit to have the desired effect, I realize now that ther= e must also exist some limit on the number of transactions that will be all= owed from the encumbered address.

=
Taking a step back, a typical use cas= e would be a speculating user intending to hodl bitcoin but who still wishe= s to be able to occasionally transact minor amounts.

Ideally, such user= should optionally still be able to bypass the rate limit and spend the ent= ire amount in a single transaction by signing with an additional private ke= y (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 add= ress, any change sent to the change address must be rate limited as well us= ing 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 aggregat= e 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.


More restrictive rate limits = would remove such footgun and may require that only a combination of parame= ters are allowed such that all funds will be spendable within a set number = of blocks (for instance 210,000).=C2=A0
As for the rate-limiting parame= ters, in addition to a per-transaction maximum of (minimum amount in satosh= i or a percentage of the total amount stored at the address), also the tran= saction 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 encumbere= d address(es).

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

=
As an aside, I am not sure how a vaul= t 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 t= ransact. 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 ca= n be sent in a period of time - eg something that would encode that for add= ress 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= the output-based system Bitcoin uses, and would be easier in an account ba= sed system like Ethereum. The problem is that each output is separate, and = there's no concept in bitcoin of encumbering outputs together.=C2=A0

What you could do is design a system where coins wou= ld be combined in a single output, and then encumber that output with a scr= ipt that allows a limited amount of coin be sent to a destination address a= nd 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 the timelock expires (eg a week). However, to ensure this wall= et works properly, any deposit into the wallet would have to also spend the= wallet's single output, so as to create a new single output at that ad= dress. So 3rd parties wouldn't be able to arbitrarily send money in (or= rather, they could, but each output would have its own separate spending l= imit).=C2=A0

> such kind of restriction would b= e extremely effective in thwarting the most damaging type of theft being th= e one where all funds are swept in a single transaction

It would. However a normal wallet vault basically=C2=A0already has th= is property - a thief can't simply sweep funds instantly, but instead t= he 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 c= ould be used to increase the security of a wallet vault that can be instant= ly 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 (unst= olen) funds into a new wallet.=C2=A0

OP_CD could p= otentially be augmented to allow specifying limit amounts for each destinat= ion, 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 in= to it from a 3rd party and you also couldn't keep separate outputs (whi= ch is bad for privacy).=C2=A0

An alternate way of = doing this that you don't need any new opcodes for would be to have a 3= rd 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 ca= n'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, b= ut the user would sign a transaction with one key, and the 3rd party with a= nother as long as the spending limit hasn't been reached. This wouldn&#= 39;t have much counterparty risk, but would be a less awkward wallet than w= hat I described above - meaning anyone could send funds into the wallet wit= hout defeating the spending limit, and privacy could be kept intact (minus = the fact that the 3rd party would know what your outputs are).=C2=A0
<= /div>

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 to limit the= maximum amount to be sent from an address?

An example of such limit might be: the maximum amount a= llowed to send is max(s, p) where s is a number of satoshi and p a percenta= ge of the total available (sendable) amount.

A minimum value may be imposed on the percentage to en= sure that the address can be emptied within a reasonable number of transact= ions. The second parameter s allows a minimum permitted amount. (This is ne= cessary because with only the percentage parameter the minimum permitted am= ount converges to zero, making it impossible to empty the address).=C2=A0

There may be other ways t= oo. In my view, such kind of restriction would be extremely effective in th= warting the most damaging type of theft being the one where all funds are s= wept in a single transaction.

Zac


On Tue, 27 Jul 2021 at 03:26, Bil= ly Tetrud via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>= wrote:
Hey James,

In the examples you mentioned, what I was exploring was a mechanism o= f attack by which the attacker could steal user A's key and use that ke= y to send a transaction with the maximum possible fee. User B would still r= eceive some funds (probably), but if the fee could be large, the attacker w= ould either do a lot of damage to user B (griefing) or could make an agreem= ent with a miner to give back some of the large fee (theft).=C2=A0

But as for use cases, the proposal mentions a number of use cases<= /a>=C2=A0and most overlap with the use cases of op_ctv=C2=A0(Jeremy Rubin's website for = op_ctv has a lot of good details, most of which are also relevant to op_cd)= . The use case I'm most interested=C2=A0in is wallet vaults. This opcod= e can be used to create a wallet vault where the user only needs to use, fo= r 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 multisig wallet are that not only does an attacker have to steal bo= th keys (same level of security), but also the user can lose one key and st= ill recover their funds (better redundancy) and also that generally the use= r doesn't need to access their second key - so that can remain in a muc= h more secure location (which would also probably make that key harder to s= teal). The only time the second key only comes into play if one key is stol= en 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 revo= ke transaction to prevent the attacker from stealing their funds. This is s= omewhat akin to a lightning watchtower scenario, where your wallet would wa= tch 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 that uses OP_CD or even my full vision of the wallet vault I want to be able to cre= ate.

With a covenant opcode like this, its possibl= e to create very usable and accessible but highly secure wallets that can a= llow normal people to hold self custody of their keys without fear of loss = or theft and without the hassle of a lot of safe deposit boxes (or other se= cure seed storage locations).=C2=A0

Cheers,
<= div>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, thes= e are the two situations I can think of:
  1. The opcode limits user/group A to send th= e output to user/group B
  2. The opco= de limits user A to send from one address they own to another address they = own.=C2=A0
I'm tryin= g to think of a good use case for this type of opcode. In these examples, a= n attacker who compromises the key for user A can't steal the money bec= ause it can only be sent to user B. So if the attacker wants to steal the f= unds, they would need to compromise the keys of both user A and user B.

But how is that any better = than a 2-of-2 multisig? Isn't the end result exactly=C2=A0the same?

James
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000abdd1105c827d37a--