From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3E9F9C000E for ; Tue, 27 Jul 2021 17:21:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2CFC68387D for ; Tue, 27 Jul 2021 17:21:34 +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: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erJdpXegdaBr for ; Tue, 27 Jul 2021 17:21:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6D0A08386F for ; Tue, 27 Jul 2021 17:21:31 +0000 (UTC) Received: by mail-ej1-x629.google.com with SMTP id e19so23215581ejs.9 for ; Tue, 27 Jul 2021 10:21:31 -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=JrrHwLt5oYY0Aqx4eGPTdrf5mb8ec14GfTffw3ffm60=; b=eb1zz4l3UVBEdpKqyciaPafWmWzAzhX8/Ntkh+Tp0JJVlV2t9pSYZ/GFZKDw1vXP1a c+bdjSee385WVE4FDmlhKP0bfSnV+ugHvelaFFQ7m2b0OP1VN1hQ8JooQRm6Z/Lellys /SteBKSGiJ58nm7eN0zMiLOXOTg4GIj/BEr/v8PaR6HADRtx1E4Q+7f8UCwU1S5MYPa/ uCIwRWLQlsDABmR6PQgDKV1a/EbZEkvenCSwllihHPd1yyHH/Ej8b/a+9UHka8/9F9f7 +dGhnDImbA/kTJTvSwR8XDrTcwIBioWceYon/zRuw54LPUIi4g4PfdQW8oQhLe9K5DOt 6C2Q== 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=JrrHwLt5oYY0Aqx4eGPTdrf5mb8ec14GfTffw3ffm60=; b=ZPMbNoB8W7IsvaR4Ar+lyuPVt3mFe57UmxDzQDtaDDIc6qd+JbPHTTSQOEGJEK5MV5 /L0A7ljKdcn9+we9P2zmC+iukqBYRpF2EBA0gIcDHD+DIDLq+/zkxu624qdN9Iarr5Aq WpREclhCPD8F0O/7GtN3O1irveIVDH77Or1AB1V4LuGyvkttvltya9m0fEHwhycDViID Cu+a9pylIsnzi8T3P6KlfeYJAZMpTtUzTeCqvlcVmMueOux+VkM5pqpLpuKN02xaBSFT c5jAyMC/Pnaei86tUAn2TDagVA4xdlyqeZKv9IucyjVWh2pOnnDdW/u6efcFiM2XTYoT NCAg== X-Gm-Message-State: AOAM532s3Sxll23yOK6XfMdiXI70Ztk8GDqjrP1RO8z+Aw7Qu8+nmwwg Qj12BbcSdv/gtReiW3YhilgLvQAooFqmI3XX4us= X-Google-Smtp-Source: ABdhPJzjbvucbzfnvqKP0ibHQ+2QJ3ZCLq01bffN/Cb/+Mb+SbrxhWX7VWX1flyZ+1/rUZkMk2v4wxDg7N2Zf+F3rQU= X-Received: by 2002:a17:906:2b58:: with SMTP id b24mr21933340ejg.141.1627406489409; Tue, 27 Jul 2021 10:21:29 -0700 (PDT) MIME-Version: 1.0 References: <20210725053803.fnmd6etv3f7x3u3p@ganymede> In-Reply-To: From: Billy Tetrud Date: Tue, 27 Jul 2021 10:21:11 -0700 Message-ID: To: Zac Greenwood Content-Type: multipart/alternative; boundary="000000000000b4de1405c81e1950" X-Mailman-Approved-At: Tue, 27 Jul 2021 18:22:16 +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: Tue, 27 Jul 2021 17:21:34 -0000 --000000000000b4de1405c81e1950 Content-Type: text/plain; charset="UTF-8" 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, 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 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 3rd 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 could 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 (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 from 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, and 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 being 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 attacker >> 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 (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 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 vault >> 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 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 transaction to prevent the attacker >> from stealing their funds. This is somewhat akin to a lightning watchtower >> 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 >> >> 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 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 without the >> 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 steal >>> the money because it can only be sent to user B. So if the attacker wants >>> to steal the funds, 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 the same? >>> >>> James >>> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --000000000000b4de1405c81e1950 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Zac,

I haven't heard of any prop= osal 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 somethi= ng that would encode that for address A, only X bitcoin can be sent from th= e 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 t= hat each output is separate, and there's no concept in bitcoin of encum= bering outputs together.=C2=A0

What you could do i= s design a system where coins would be combined in a single output, and the= n encumber that output with a script that allows a limited amount of coin b= e 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 ne= w change output can't be used again until the timelock expires (eg a we= ek). However, to ensure this wallet works properly, any deposit into the wa= llet would have to also spend the wallet's single output, so as to crea= te a new single output at that address. 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 limit).=C2=A0

>= such kind of restriction would be extremely effective in thwarting the mos= t damaging type of theft being the one where all funds are swept in a singl= e transaction

It would. However a normal wallet va= ult basically=C2=A0already has this property - a thief can't simply swe= ep funds instantly, but instead the victim will see an initiated transactio= n and will be able to reverse it within a delay time-window. I don't th= ink adding a spending limit would add meaningful security to a delayed-send= wallet vault like that. But it could be used to increase the security of a= wallet vault that can be instantly spent from - ie if the attacker success= fully steals funds, then the victim has time to go gather their additional = keys and move the remaining (unstolen) funds into a new wallet.=C2=A0
=

OP_CD could potentially be augmented to allow specifyin= g limit amounts for each destination, which would allow you to create a wal= let 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).=C2=A0
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 trans= actions from a wallet only up to a limit. The end-user could have additiona= l 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, and the 3rd party with another as long as the spending limit hasn&= #39;t been reached. This wouldn't have much counterparty risk, but woul= d be a less awkward wallet than what I described above - meaning anyone cou= ld send funds into the wallet without defeating the spending limit, and pri= vacy could be kept intact (minus the fact that the 3rd party would know wha= t your outputs are).=C2=A0

BT

On Tue, Jul 27,= 2021 at 4:18 AM Zac Greenwood <zac= hgrw@gmail.com> wrote:
Hi Billy,

=
On the topic of wallet vaults, are there any plans to imp= lement a way to limit the maximum amount to be sent from an address?
<= 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 number of= satoshi and p a percentage of the total available (sendable) amount.
=

A minimum value may be impose= d on the percentage to ensure that the address can be emptied within a reas= onable number of transactions. The second parameter s allows a minimum perm= itted amount. (This is necessary because with only the percentage parameter= the minimum permitted amount converges to zero, making it impossible to em= pty the address).=C2=A0

= 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 being 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.li= nuxfoundation.org> wrote:
Hey James,

In the exam= ples 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 trans= action with the maximum possible fee. User B would still receive some funds= (probably), but if the fee could be large, the attacker 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).=C2=A0

= But as for use cases, the proposal mentions a number of use cases=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&= #39;m most interested=C2=A0in 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 vault like this vs a normal 2-of-2 multisig = wallet are that not only does an attacker have to steal both keys (same lev= el 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 nee= d to access their second key - so that can remain in a much more secure loc= ation (which would also probably make that key harder to steal). The only t= ime the second key only comes into play if one key is stolen and the attack= er attempts to send a transaction. At that point, the user would go find an= d use his second key (along with the first) to send a revoke transaction to= prevent the attacker from stealing their funds. This is somewhat akin to a= lightning watchtower scenario, where your wallet would watch the chain and= alert you about an unexpected transaction, at which point you'd manual= ly do a revoke (vs a watchtower's automated response). You might be int= erested in taking a look at this wallet vault design that uses OP_CD or even my fu= ll vision 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 peopl= e 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 storage= locations).=C2=A0

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 f= rom one address they own to another address they own.=C2=A0
=
I'm trying to think of a good use c= ase 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 t= o user B. So if the attacker wants to steal the funds, they would need to c= ompromise the keys of both user A and user B.

But how is that any better than a 2-of-2 multisig? Is= n'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
--000000000000b4de1405c81e1950--