7c04cce18a8ff7b44d89d5e7bb9f7bca8842f8
1 Return-Path: <fresheneesz@gmail.com> 2 Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) 3 by lists.linuxfoundation.org (Postfix) with ESMTP id 7CC30C000E 4 for <bitcoin-dev@lists.linuxfoundation.org>; 5 Wed, 28 Jul 2021 17:57:32 +0000 (UTC) 6 Received: from localhost (localhost [127.0.0.1]) 7 by smtp3.osuosl.org (Postfix) with ESMTP id 621196088A 8 for <bitcoin-dev@lists.linuxfoundation.org>; 9 Wed, 28 Jul 2021 17:57:32 +0000 (UTC) 10 X-Virus-Scanned: amavisd-new at osuosl.org 11 X-Spam-Flag: NO 12 X-Spam-Score: -2.098 13 X-Spam-Level: 14 X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 15 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 16 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 17 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 18 SPF_PASS=-0.001] autolearn=ham autolearn_force=no 19 Authentication-Results: smtp3.osuosl.org (amavisd-new); 20 dkim=pass (2048-bit key) header.d=gmail.com 21 Received: from smtp3.osuosl.org ([127.0.0.1]) 22 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) 23 with ESMTP id O-5FafGGpTNG 24 for <bitcoin-dev@lists.linuxfoundation.org>; 25 Wed, 28 Jul 2021 17:57:30 +0000 (UTC) 26 X-Greylist: whitelisted by SQLgrey-1.8.0 27 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com 28 [IPv6:2a00:1450:4864:20::530]) 29 by smtp3.osuosl.org (Postfix) with ESMTPS id DAA3A606E2 30 for <bitcoin-dev@lists.linuxfoundation.org>; 31 Wed, 28 Jul 2021 17:57:29 +0000 (UTC) 32 Received: by mail-ed1-x530.google.com with SMTP id f13so4351845edq.13 33 for <bitcoin-dev@lists.linuxfoundation.org>; 34 Wed, 28 Jul 2021 10:57:29 -0700 (PDT) 35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 36 h=mime-version:references:in-reply-to:from:date:message-id:subject:to 37 :cc; bh=SKMdD1G3Q9aOhaG0SZCGVxXd59tgIr5opwLwVGHyAyw=; 38 b=oqoa8knuXaW9q485kMZo7ZfAjTmO5ejGB0zdx/8MMlHGLBrfCjreBznEjgmOd91wU1 39 92wffd8MRMwOoNN1knkMFcRkdMKP7v/wyrTbRA7KKxLnI3jYWkQr8LT4KSTbvdGdUQJP 40 X0y6ZzV3bDANQXNACYxdpX9fWTyzcJMSGaa/rnM7VJQQhj/QH6aTd3ueHV+RzQgGkfz7 41 Z1UXAHBGfG4M0juSCs8YL1xttn/kc81FnjBSr2uBzCdHUcdC5vmDHcMpoz54/FmeeJu7 42 47/vheex8UF8yeU1QedG3UD0Z2n7XkO+pgUuIlhybPnfzBBxo5ijstehFhLNyRi4DUOB 43 cSvw== 44 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 45 d=1e100.net; s=20161025; 46 h=x-gm-message-state:mime-version:references:in-reply-to:from:date 47 :message-id:subject:to:cc; 48 bh=SKMdD1G3Q9aOhaG0SZCGVxXd59tgIr5opwLwVGHyAyw=; 49 b=KI8lOLWCCnWHzd6rDFnRXISCVtgxZ/ADvt3MT533pvjCmugeKmRdZLlx0MZe27bVoJ 50 DNM82VcuR0/vYdRWIpzjKjdf+91Cbphw32qeu2MnmgZtKqgkGGg10+xOXEtOMGHP43bT 51 rrE7qqTJg7xS68J/q7BL6JRXXHovRuf526yDjmLHae8GFLiFHn3JXjWKBQLmdlaBjIbP 52 GD7219F61NCWrSl4nrGFnodJenaPGli73i6ABMfW9CWZM9E/p0wrJdFmh4a8USzeXfdP 53 IhiR9NNUlM3XZKoZ00dYR1Ducl54wEnV86XdsS6ypqLtJc7Wf0qfQYkUn69p3AI+FQ3u 54 mZpw== 55 X-Gm-Message-State: AOAM533j6ES6Y7ASap3QJDdJj5oqNpr4MrZBzP0lKKei8jip7XTKzazB 56 vjGFFwbCZOz+NWmNiuHV7TAgZd8YybLTKfabiQA= 57 X-Google-Smtp-Source: ABdhPJxVBXnYITdV8jRUO0NSPgXMRtwqXfghIcsyPMYoYKmKDQSVyRoQnh4FUzQterExny7yOtvyds12hUfitt9hEIg= 58 X-Received: by 2002:a05:6402:19a:: with SMTP id 59 r26mr1245119edv.230.1627495047936; 60 Wed, 28 Jul 2021 10:57:27 -0700 (PDT) 61 MIME-Version: 1.0 62 References: <CAGpPWDZ0aos5qHw2=popCpjuH7OXC0geEj8i3dwDTfP0j=or4w@mail.gmail.com> 63 <20210725053803.fnmd6etv3f7x3u3p@ganymede> 64 <CAGpPWDZ8EWd7kGV5pFZadQM1kqETrTK2zybsGF1hW9fx2oZb7w@mail.gmail.com> 65 <CAH+Axy7cPufMUCMQbCz2MUgRqQbgenAozPBFD8kPYrSjwcRG8w@mail.gmail.com> 66 <CAGpPWDb8yzGO-VtCO-x09e-phKHT7ezOms+DzeWc9vS3rN1AAw@mail.gmail.com> 67 <CAJ4-pEDWuNfdE4NXkZBsOnuSQ4YOv28YVwGavyiU+FPvpC6y1w@mail.gmail.com> 68 <CAGpPWDZL6BpzoNa0Qgf-Ux60fyWPjZH=NESkgbhEQO_My=XiAg@mail.gmail.com> 69 <CAJ4-pEBwdUJ3kg=yb-kWZLoaX5f_2t353K7Tr+dJy+JpAoKTmQ@mail.gmail.com> 70 In-Reply-To: <CAJ4-pEBwdUJ3kg=yb-kWZLoaX5f_2t353K7Tr+dJy+JpAoKTmQ@mail.gmail.com> 71 From: Billy Tetrud <billy.tetrud@gmail.com> 72 Date: Wed, 28 Jul 2021 10:57:09 -0700 73 Message-ID: <CAGpPWDYMZ+w3VSaLhR68f4WVq7NCUp3SedwW2e8QnRHOgLQqQg@mail.gmail.com> 74 To: Zac Greenwood <zachgrw@gmail.com> 75 Content-Type: multipart/alternative; boundary="00000000000034becf05c832b8e8" 76 X-Mailman-Approved-At: Wed, 28 Jul 2021 18:17:05 +0000 77 Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 78 Subject: Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION 79 (an alternative to OP_CTV) 80 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 81 X-Mailman-Version: 2.1.15 82 Precedence: list 83 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 84 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 85 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 86 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 87 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 88 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 89 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 90 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 91 X-List-Received-Date: Wed, 28 Jul 2021 17:57:32 -0000 92 93 --00000000000034becf05c832b8e8 94 Content-Type: text/plain; charset="UTF-8" 95 Content-Transfer-Encoding: quoted-printable 96 97 Hi Zac, 98 99 > a smart wallet should be able to set up and maintain multiple 100 rate-limited addresses in such a way that their aggregate behaviour meets 101 any rate-limiting parameters as desired by the user 102 103 I think that would be possible if there was a way to say "within the last B 104 blocks, this output can only spend to addresses other than X,Y,Z an amount 105 less than C coins minus however much coins have been spent by those 106 addresses in the last B blocks". This would require that full nodes keep 107 around information about which addresses have been spent from recently, so 108 that information is accessible during script execution. This could be made 109 a bit less heavy by requiring countable transactions to run some particular 110 opcode (so only opted-in transactions would need to be stored). 111 112 > This ought to alleviate your privacy concerns because it means that the 113 wallet will be able to mix outputs. 114 115 The ability to mix outputs isn't a privacy issue. The ability to keep 116 outputs separate is the privacy issue. For rate-limiting to work, the 117 outputs must be associated with eachother so that rate limiting can take 118 them all into account. It seems to me that its fundamentally impossible to 119 do this while keeping outputs uncorrelated. 120 121 > such user-enabled rate-limiting is superior to one that requires a third 122 party. 123 124 Removing a 3rd party certainly has upsides. However, using a 3rd party 125 would be able to solve the privacy issue by keeping outputs uncorrelated 126 (in different addresses) to the outside world. Trade offs. 127 128 In any case, if you want to continue talking about rate-limiting 129 transactions, it might be a good idea to start a new thread for that, since 130 its a bit off topic for this one. 131 132 > how a vault solution would be able to prevent an attacker who is in 133 possession of the vaults=E2=80=99 private key from sabotaging the user by r= 134 eplacing 135 the user transaction with one having a higher fee every time the user 136 attempts to transact 137 138 A wallet vault has multiple keys. If one key is stolen, the user can use 139 two keys to override the attacker's transaction. If two keys are stolen, 140 the user can use three keys. Etc. The attacker must have as many keys as 141 the user can use in order to successfully steal funds. This can happen in 142 one of these kinds of ways: 143 144 A. The attacker steals all keys. 145 B. The attacker steals half the keys and ensures that the victim doesn't 146 have access to those keys (eg the attacker steals the only copy of half the 147 keys). 148 C. The attacker steals any key and incapacitates the victim for the entire 149 cooldown period, so they can't use any of their keys. 150 151 In case C, it would be useful to have rate limiting actually. 152 153 On Tue, Jul 27, 2021 at 9:57 PM Zac Greenwood <zachgrw@gmail.com> wrote: 154 155 > Hi Billy, 156 > 157 > Thank you for your comprehensive reply. My purpose was to find out whethe= 158 r 159 > a proposal to somehow limit the amount being sent from an address exists 160 > and to further illustrate my thoughts by giving a concrete example of how 161 > this might work functionally without getting to deep into the 162 > technicalities. 163 > 164 > As for your assumption: for an amount limit to have the desired effect, I 165 > realize now that there must also exist some limit on the number of 166 > transactions that will be allowed from the encumbered address. 167 > 168 > Taking a step back, a typical use case would be a speculating user 169 > intending to hodl bitcoin but who still wishes to be able to occasionally 170 > transact minor amounts. 171 > 172 > Ideally, such user should optionally still be able to bypass the rate 173 > limit and spend the entire amount in a single transaction by signing with 174 > an additional private key (multisig). 175 > 176 > During the setup phase, a user sends all their to-be-rate-limited coin to 177 > a single address. When spending from this rate limited address, any chang= 178 e 179 > sent to the change address must be rate limited as well using identical 180 > parameters. I believe that=E2=80=99s also what you=E2=80=99re suggesting. 181 > 182 > I believe that a smart wallet should be able to set up and maintain 183 > multiple rate-limited addresses in such a way that their aggregate 184 > behaviour meets any rate-limiting parameters as desired by the user. This 185 > ought to alleviate your privacy concerns because it means that the wallet 186 > will be able to mix outputs. 187 > 188 > The options for the to-be implemented rate-limiting parameters vary from 189 > completely arbitrary to more restrictive. 190 > 191 > Completely arbitrary parameters would allow users to set up a rate limit 192 > that basically destroys their funds, for instance rate-limiting an addres= 193 s 194 > to an amount of 1 satoshi per 100 blocks. 195 > 196 > More restrictive rate limits would remove such footgun and may require 197 > that only a combination of parameters are allowed such that all funds wil= 198 l 199 > be spendable within a set number of blocks (for instance 210,000). 200 > 201 > As for the rate-limiting parameters, in addition to a per-transaction 202 > maximum of (minimum amount in satoshi or a percentage of the total amount 203 > stored at the address), also the transaction frequency must be limited. I 204 > would propose this to be expressed as a number of blocks before a next 205 > transaction can be sent from the encumbered address(es). 206 > 207 > I believe such user-enabled rate-limiting is superior to one that require= 208 s 209 > a third party. 210 > 211 > As an aside, I am not sure how a vault solution would be able to prevent 212 > an attacker who is in possession of the vaults=E2=80=99 private key from = 213 sabotaging 214 > the user by replacing the user transaction with one having a higher fee 215 > every time the user attempts to transact. I am probably missing something 216 > here though. 217 > 218 > Zac 219 > 220 > 221 > On Tue, 27 Jul 2021 at 19:21, Billy Tetrud <billy.tetrud@gmail.com> wrote= 222 : 223 > 224 >> Hi Zac, 225 >> 226 >> I haven't heard of any proposal for limiting the amount that can be sent 227 >> from an address. I assume you mean limiting the amount that can be sent = 228 in 229 >> a period of time - eg something that would encode that for address A, on= 230 ly 231 >> X bitcoin can be sent from the address in a given day/week/etc, is that 232 >> right? That would actually be a somewhat difficult thing to do in the 233 >> output-based system Bitcoin uses, and would be easier in an account base= 234 d 235 >> system like Ethereum. The problem is that each output is separate, and 236 >> there's no concept in bitcoin of encumbering outputs together. 237 >> 238 >> What you could do is design a system where coins would be combined in a 239 >> single output, and then encumber that output with a script that allows a 240 >> limited amount of coin be sent to a destination address and requires all 241 >> other bitcoins be returned to sender in a new change output that is also 242 >> timelocked. That way, the new change output can't be used again until th= 243 e 244 >> timelock expires (eg a week). However, to ensure this wallet works 245 >> properly, any deposit into the wallet would have to also spend the walle= 246 t's 247 >> single output, so as to create a new single output at that address. So 3= 248 rd 249 >> parties wouldn't be able to arbitrarily send money in (or rather, they 250 >> could, but each output would have its own separate spending limit). 251 >> 252 >> > such kind of restriction would be extremely effective in thwarting the 253 >> most damaging type of theft being the one where all funds are swept in a 254 >> single transaction 255 >> 256 >> It would. However a normal wallet vault basically already has this 257 >> property - a thief can't simply sweep funds instantly, but instead the 258 >> victim will see an initiated transaction and will be able to reverse it 259 >> within a delay time-window. I don't think adding a spending limit would = 260 add 261 >> meaningful security to a delayed-send wallet vault like that. But it cou= 262 ld 263 >> be used to increase the security of a wallet vault that can be instantly 264 >> spent from - ie if the attacker successfully steals funds, then the vict= 265 im 266 >> has time to go gather their additional keys and move the remaining 267 >> (unstolen) funds into a new wallet. 268 >> 269 >> OP_CD could potentially be augmented to allow specifying limit amounts 270 >> for each destination, which would allow you to create a wallet like this= 271 . 272 >> It would be a bit of an awkward wallet to use tho, since you couldn't 273 >> receive directly into it from a 3rd party and you also couldn't keep 274 >> separate outputs (which is bad for privacy). 275 >> 276 >> An alternate way of doing this that you don't need any new opcodes for 277 >> would be to have a 3rd party service that signs multisig transactions fr= 278 om 279 >> a wallet only up to a limit. The end-user could have additional keys suc= 280 h 281 >> that the 3rd party can't prevent them from accessing that (if they turn 282 >> uncooperative), and the 3rd party would only have a single key so they 283 >> can't steal funds, but the user would sign a transaction with one key, a= 284 nd 285 >> the 3rd party with another as long as the spending limit hasn't been 286 >> reached. This wouldn't have much counterparty risk, but would be a less 287 >> awkward wallet than what I described above - meaning anyone could send 288 >> funds into the wallet without defeating the spending limit, and privacy 289 >> could be kept intact (minus the fact that the 3rd party would know what 290 >> your outputs are). 291 >> 292 >> BT 293 >> 294 >> On Tue, Jul 27, 2021 at 4:18 AM Zac Greenwood <zachgrw@gmail.com> wrote: 295 >> 296 >>> Hi Billy, 297 >>> 298 >>> On the topic of wallet vaults, are there any plans to implement a way t= 299 o 300 >>> limit the maximum amount to be sent from an address? 301 >>> 302 >>> An example of such limit might be: the maximum amount allowed to send i= 303 s 304 >>> max(s, p) where s is a number of satoshi and p a percentage of the tota= 305 l 306 >>> available (sendable) amount. 307 >>> 308 >>> A minimum value may be imposed on the percentage to ensure that the 309 >>> address can be emptied within a reasonable number of transactions. The 310 >>> second parameter s allows a minimum permitted amount. (This is necessar= 311 y 312 >>> because with only the percentage parameter the minimum permitted amount 313 >>> converges to zero, making it impossible to empty the address). 314 >>> 315 >>> There may be other ways too. In my view, such kind of restriction would 316 >>> be extremely effective in thwarting the most damaging type of theft bei= 317 ng 318 >>> the one where all funds are swept in a single transaction. 319 >>> 320 >>> Zac 321 >>> 322 >>> 323 >>> On Tue, 27 Jul 2021 at 03:26, Billy Tetrud via bitcoin-dev < 324 >>> bitcoin-dev@lists.linuxfoundation.org> wrote: 325 >>> 326 >>>> Hey James, 327 >>>> 328 >>>> In the examples you mentioned, what I was exploring was a mechanism of 329 >>>> attack by which the attacker could steal user A's key and use that key= 330 to 331 >>>> send a transaction with the maximum possible fee. User B would still 332 >>>> receive some funds (probably), but if the fee could be large, the atta= 333 cker 334 >>>> would either do a lot of damage to user B (griefing) or could make an 335 >>>> agreement with a miner to give back some of the large fee (theft). 336 >>>> 337 >>>> But as for use cases, the proposal mentions a number of use cases 338 >>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main= 339 /cd/bip-constraindestination.md#motivation> and 340 >>>> most overlap with the use cases of op_ctv <https://utxos.org/uses/> (J= 341 eremy 342 >>>> Rubin's website for op_ctv has a lot of good details, most of which ar= 343 e 344 >>>> also relevant to op_cd). The use case I'm most interested in is wallet 345 >>>> vaults. This opcode can be used to create a wallet vault where the use= 346 r 347 >>>> only needs to use, for example, 1 key to spend funds, but the attacker= 348 must 349 >>>> steal 2 or more keys to spend funds. The benefits of a 2 key wallet va= 350 ult 351 >>>> like this vs a normal 2-of-2 multisig wallet are that not only does an 352 >>>> attacker have to steal both keys (same level of security), but also th= 353 e 354 >>>> user can lose one key and still recover their funds (better redundancy= 355 ) and 356 >>>> also that generally the user doesn't need to access their second key -= 357 so 358 >>>> that can remain in a much more secure location (which would also proba= 359 bly 360 >>>> make that key harder to steal). The only time the second key only come= 361 s 362 >>>> into play if one key is stolen and the attacker attempts to send a 363 >>>> transaction. At that point, the user would go find and use his second = 364 key 365 >>>> (along with the first) to send a revoke transaction to prevent the att= 366 acker 367 >>>> from stealing their funds. This is somewhat akin to a lightning watcht= 368 ower 369 >>>> scenario, where your wallet would watch the chain and alert you about = 370 an 371 >>>> unexpected transaction, at which point you'd manually do a revoke (vs = 372 a 373 >>>> watchtower's automated response). You might be interested in taking a = 374 look 375 >>>> at this wallet vault design 376 >>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main= 377 /cd/op_cdWalletVault1.md> 378 >>>> that uses OP_CD or even my full vision 379 >>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults> of the 380 >>>> wallet vault I want to be able to create. 381 >>>> 382 >>>> With a covenant opcode like this, its possible to create very usable 383 >>>> and accessible but highly secure wallets that can allow normal people = 384 to 385 >>>> hold self custody of their keys without fear of loss or theft and with= 386 out 387 >>>> the hassle of a lot of safe deposit boxes (or other secure seed storag= 388 e 389 >>>> locations). 390 >>>> 391 >>>> Cheers, 392 >>>> BT 393 >>>> 394 >>>> 395 >>>> 396 >>>> 397 >>>> 398 >>>> On Mon, Jul 26, 2021 at 2:08 PM James MacWhyte <macwhyte@gmail.com> 399 >>>> wrote: 400 >>>> 401 >>>>> Hi Billy! 402 >>>>> 403 >>>>> See above, but to break down that situation a bit further, these are 404 >>>>>> the two situations I can think of: 405 >>>>>> 406 >>>>>> 1. The opcode limits user/group A to send the output to 407 >>>>>> user/group B 408 >>>>>> 2. The opcode limits user A to send from one address they own to 409 >>>>>> another address they own. 410 >>>>>> 411 >>>>>> I'm trying to think of a good use case for this type of opcode. In 412 >>>>> these examples, an attacker who compromises the key for user A can't = 413 steal 414 >>>>> the money because it can only be sent to user B. So if the attacker w= 415 ants 416 >>>>> to steal the funds, they would need to compromise the keys of both us= 417 er A 418 >>>>> and user B. 419 >>>>> 420 >>>>> But how is that any better than a 2-of-2 multisig? Isn't the end 421 >>>>> result exactly the same? 422 >>>>> 423 >>>>> James 424 >>>>> 425 >>>> _______________________________________________ 426 >>>> bitcoin-dev mailing list 427 >>>> bitcoin-dev@lists.linuxfoundation.org 428 >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 429 >>>> 430 >>> 431 432 --00000000000034becf05c832b8e8 433 Content-Type: text/html; charset="UTF-8" 434 Content-Transfer-Encoding: quoted-printable 435 436 <div dir=3D"ltr">Hi Zac,<div><br></div><div>>=C2=A0<span style=3D"color:= 437 rgb(49,49,49);font-size:16px;word-spacing:1px">a smart wallet should be abl= 438 e to set up and maintain multiple rate-limited addresses in such a way that= 439 their aggregate behaviour meets any rate-limiting parameters as desired by= 440 the user</span></div><div><span style=3D"color:rgb(49,49,49);font-size:16p= 441 x;word-spacing:1px"><br></span></div><div><span style=3D"color:rgb(49,49,49= 442 );font-size:16px;word-spacing:1px">I think that would be possible if there = 443 was a way to say "within the last B blocks, this output can only spend= 444 to addresses other than X,Y,Z an amount less than C coins minus however mu= 445 ch coins have been spent by those addresses in the last B blocks". Thi= 446 s would require that full nodes keep around information about which address= 447 es have been spent from recently, so that information=C2=A0is accessible du= 448 ring script execution. This could be made a bit less heavy by requiring cou= 449 ntable transactions to run some particular opcode (so only opted-in transac= 450 tions would need to be stored).=C2=A0</span></div><div><span style=3D"color= 451 :rgb(49,49,49);font-size:16px;word-spacing:1px"><br></span></div><div><span= 452 style=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">>=C2=A0</= 453 span><span style=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">Th= 454 is ought to alleviate your privacy concerns because it means that the walle= 455 t will be able to mix outputs.</span></div><div><span style=3D"color:rgb(49= 456 ,49,49);font-size:16px;word-spacing:1px"><br>The ability to mix outputs isn= 457 't a privacy issue. The ability to keep outputs separate is the privacy= 458 issue. For rate-limiting to work, the outputs must be associated with each= 459 other so that rate limiting can take them all into account. It seems to me = 460 that its fundamentally impossible to do this while keeping outputs uncorrel= 461 ated.</span></div><div><span style=3D"color:rgb(49,49,49);font-size:16px;wo= 462 rd-spacing:1px"><br></span></div><div><span style=3D"color:rgb(49,49,49);fo= 463 nt-size:16px;word-spacing:1px">>=C2=A0</span><span style=3D"color:rgb(49= 464 ,49,49);font-size:16px;word-spacing:1px">such user-enabled rate-limiting is= 465 superior to one that requires a third party.</span></div><div><span style= 466 =3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px"><br></span></div><= 467 div><span style=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">Rem= 468 oving a 3rd party certainly has upsides. However, using a 3rd party would b= 469 e able to solve the privacy issue by keeping outputs uncorrelated (in diffe= 470 rent addresses) to the outside world. Trade offs.</span></div><div><span st= 471 yle=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px"><br></span></di= 472 v><div><span style=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">= 473 In any case, if you want to continue talking about rate-limiting transactio= 474 ns, it might be a good idea to start a new thread for that, since its a bit= 475 off topic for this one.=C2=A0</span></div><div><span style=3D"color:rgb(49= 476 ,49,49);font-size:16px;word-spacing:1px"><br></span></div><div><span style= 477 =3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">>=C2=A0</span><= 478 span style=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">how a va= 479 ult solution would be able to prevent an attacker who is in possession of t= 480 he vaults=E2=80=99 private key from sabotaging the user by replacing the us= 481 er transaction with one having a higher fee every time the user attempts to= 482 transact</span></div><div><span style=3D"color:rgb(49,49,49);font-size:16p= 483 x;word-spacing:1px"><br></span></div><div><span style=3D"color:rgb(49,49,49= 484 );font-size:16px;word-spacing:1px">A wallet vault has multiple keys. If one= 485 key is stolen, the user can use two keys to override the attacker's tr= 486 ansaction. If two keys are stolen, the user can use three keys. Etc. The at= 487 tacker must have as many keys as the user can use in order to successfully = 488 steal funds. This can happen in one of these kinds of ways:<br><br>A. The a= 489 ttacker steals all keys.</span></div><div><span style=3D"color:rgb(49,49,49= 490 );font-size:16px;word-spacing:1px">B. The attacker steals half the keys and= 491 ensures that the victim doesn't have access to those keys (eg the atta= 492 cker steals the only copy of half the keys).</span></div><div><span style= 493 =3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">C. The attacker st= 494 eals any key and incapacitates the victim for the entire cooldown period, s= 495 o they can't use any of their keys.</span></div><div><span style=3D"col= 496 or:rgb(49,49,49);font-size:16px;word-spacing:1px"><br></span></div><div><sp= 497 an style=3D"color:rgb(49,49,49);font-size:16px;word-spacing:1px">In case C,= 498 it would be useful to have rate limiting actually.</span></div></div><br><= 499 div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul= 500 27, 2021 at 9:57 PM Zac Greenwood <<a href=3D"mailto:zachgrw@gmail.com"= 501 >zachgrw@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote= 502 " style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);= 503 padding-left:1ex"><div><div dir=3D"auto" style=3D"font-size:1rem;word-spaci= 504 ng:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">Hi Billy,</div><div = 505 dir=3D"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(49,4= 506 9,49);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-size:1= 507 rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">Thank = 508 you for your comprehensive reply. My purpose was to find out whether a prop= 509 osal to somehow limit the amount being sent from an address exists and to f= 510 urther illustrate my thoughts by giving a concrete example of how this migh= 511 t work functionally without getting to deep into the technicalities.</div><= 512 div dir=3D"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(= 513 49,49,49);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-si= 514 ze:1rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">As= 515 for your assumption: for an amount limit to have the desired effect, I rea= 516 lize now that there must also exist some limit on the number of transaction= 517 s that will be allowed from the encumbered address.</div><div dir=3D"auto" = 518 style=3D"font-size:16px;word-spacing:1px;border-color:rgb(49,49,49);color:r= 519 gb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-size:1rem;word-spac= 520 ing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">Taking a step back,= 521 a typical use case would be a speculating user intending to hodl bitcoin b= 522 ut who still wishes to be able to occasionally transact minor amounts.</div= 523 ><div dir=3D"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rg= 524 b(49,49,49);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-= 525 size:1rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">= 526 Ideally, such user should optionally still be able to bypass the rate limit= 527 and spend the entire amount in a single transaction by signing with an add= 528 itional private key (multisig).</div><div dir=3D"auto" style=3D"font-size:1= 529 6px;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><br></= 530 div><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1px;border-color= 531 :rgb(49,49,49);color:rgb(49,49,49)">During the setup phase, a user sends al= 532 l their to-be-rate-limited coin to a single address. When spending from thi= 533 s rate limited address, any change sent to the change address must be rate = 534 limited as well using identical parameters. I believe that=E2=80=99s also w= 535 hat you=E2=80=99re suggesting.</div><div dir=3D"auto" style=3D"font-size:16= 536 px;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><br></d= 537 iv><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1px;border-color:= 538 rgb(49,49,49);color:rgb(49,49,49)">I believe that a smart wallet should be = 539 able to set up and maintain multiple rate-limited addresses in such a way t= 540 hat their aggregate behaviour meets any rate-limiting parameters as desired= 541 by the user. This ought to alleviate your privacy concerns because it mean= 542 s that the wallet will be able to mix outputs.</div><div dir=3D"auto" style= 543 =3D"font-size:16px;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49= 544 ,49,49)"><br></div><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1= 545 px;border-color:rgb(49,49,49);color:rgb(49,49,49)">The options for the to-b= 546 e implemented rate-limiting parameters vary from completely arbitrary to mo= 547 re restrictive.</div><div dir=3D"auto" style=3D"font-size:16px;word-spacing= 548 :1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><br></div><div dir=3D"= 549 auto" style=3D"font-size:1rem;word-spacing:1px;border-color:rgb(49,49,49);c= 550 olor:rgb(49,49,49)">Completely arbitrary parameters would allow users to se= 551 t up a rate limit that basically destroys their funds, for instance rate-li= 552 miting an address to an amount of 1 satoshi per 100 blocks.</div><div dir= 553 =3D"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(49,49,4= 554 9);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-size:1rem= 555 ;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">More rest= 556 rictive rate limits would remove such footgun and may require that only a c= 557 ombination of parameters are allowed such that all funds will be spendable = 558 within a set number of blocks (for instance 210,000).=C2=A0</div><div dir= 559 =3D"auto" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(49,49,4= 560 9);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-size:1rem= 561 ;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">As for th= 562 e rate-limiting parameters, in addition to a per-transaction maximum of (mi= 563 nimum amount in satoshi or a percentage of the total amount stored at the a= 564 ddress), also the transaction frequency must be limited. I would propose th= 565 is to be expressed as a number of blocks before a next transaction can be s= 566 ent from the encumbered address(es).</div><div dir=3D"auto" style=3D"font-s= 567 ize:16px;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><= 568 br></div><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1px;border-= 569 color:rgb(49,49,49);color:rgb(49,49,49)">I believe such user-enabled rate-l= 570 imiting is superior to one that requires a third party.</div><div dir=3D"au= 571 to" style=3D"font-size:16px;word-spacing:1px;border-color:rgb(49,49,49);col= 572 or:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"font-size:1rem;word-= 573 spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">As an aside, I = 574 am not sure how a vault solution would be able to prevent an attacker who i= 575 s in possession of the vaults=E2=80=99 private key from sabotaging the user= 576 by replacing the user transaction with one having a higher fee every time = 577 the user attempts to transact. I am probably missing something here though.= 578 </div><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1px;border-col= 579 or:rgb(49,49,49);color:rgb(49,49,49)"><br></div><div dir=3D"auto" style=3D"= 580 font-size:1rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,= 581 49)">Zac</div><div dir=3D"auto" style=3D"font-size:1rem;word-spacing:1px;bo= 582 rder-color:rgb(49,49,49);color:rgb(49,49,49)"><br></div></div><div><br><div= 583 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 27 Jul= 584 2021 at 19:21, Billy Tetrud <<a href=3D"mailto:billy.tetrud@gmail.com" = 585 target=3D"_blank">billy.tetrud@gmail.com</a>> wrote:<br></div><blockquot= 586 e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= 587 olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Zac,<div><br></= 588 div><div>I haven't heard of any proposal for limiting the amount that c= 589 an be sent from an address. I assume you mean limiting the amount that can = 590 be sent in a period of time - eg something that would encode that for addre= 591 ss A, only X bitcoin can be sent from the address in a given day/week/etc, = 592 is that right? That would actually be a somewhat difficult thing to do in t= 593 he output-based system Bitcoin uses, and would be easier in an account base= 594 d system like Ethereum. The problem is that each output is separate, and th= 595 ere's no concept in bitcoin of encumbering outputs together.=C2=A0</div= 596 ><div><br></div><div>What you could do is design a system where coins would= 597 be combined in a single output, and then encumber that output with a scrip= 598 t that allows a limited amount of coin be sent to a destination address and= 599 requires all other bitcoins be returned to sender in a new change output t= 600 hat is also timelocked. That way, the new change output can't be used a= 601 gain until the timelock expires (eg a week). However, to ensure this wallet= 602 works properly, any deposit into the wallet would have to also spend the w= 603 allet's single output, so as to create a new single output at that addr= 604 ess. So 3rd parties wouldn't be able to arbitrarily send money in (or r= 605 ather, they could, but each output would have its own separate spending lim= 606 it).=C2=A0</div><div><br></div><div>> such kind of restriction would be = 607 extremely effective in thwarting the most damaging type of theft being the = 608 one where all funds are swept in a single transaction</div><div><br></div><= 609 div>It would. However a normal wallet vault basically=C2=A0already has this= 610 property - a thief can't simply sweep funds instantly, but instead the= 611 victim will see an initiated transaction and will be able to reverse it wi= 612 thin a delay time-window. I don't think adding a spending limit would a= 613 dd meaningful security to a delayed-send wallet vault like that. But it cou= 614 ld be used to increase the security of a wallet vault that can be instantly= 615 spent from - ie if the attacker successfully steals funds, then the victim= 616 has time to go gather their additional keys and move the remaining (unstol= 617 en) funds into a new wallet.=C2=A0</div><div><br></div><div>OP_CD could pot= 618 entially be augmented to allow specifying limit amounts for each destinatio= 619 n, which would allow you to create a wallet like this. It would be a bit of= 620 an awkward wallet to use tho, since you couldn't receive directly into= 621 it from a 3rd party and you also couldn't keep separate outputs (which= 622 is bad for privacy).=C2=A0</div><div><br></div><div>An alternate way of do= 623 ing this that you don't need any new opcodes for would be to have a 3rd= 624 party service that signs multisig transactions from a wallet only up to a = 625 limit. The end-user could have additional keys such that the 3rd party can&= 626 #39;t prevent them from accessing that (if they turn uncooperative), and th= 627 e 3rd party would only have a single key so they can't steal funds, but= 628 the user would sign a transaction with one key, and the 3rd party with ano= 629 ther as long as the spending limit hasn't been reached. This wouldn'= 630 ;t have much counterparty risk, but would be a less awkward wallet than wha= 631 t I described above - meaning anyone could send funds into the wallet witho= 632 ut defeating the spending limit, and privacy could be kept intact (minus th= 633 e fact that the 3rd party would know what your outputs are).=C2=A0</div></d= 634 iv><div dir=3D"ltr"><div><br></div><div>BT</div></div><br><div class=3D"gma= 635 il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 27, 2021 at 4:1= 636 8 AM Zac Greenwood <<a href=3D"mailto:zachgrw@gmail.com" target=3D"_blan= 637 k">zachgrw@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quo= 638 te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= 639 );padding-left:1ex"><div dir=3D"auto">Hi Billy,</div><div dir=3D"auto"><br>= 640 </div><div dir=3D"auto">On the topic of wallet vaults, are there any plans = 641 to implement a way to limit the maximum amount to be sent from an address?<= 642 /div><div dir=3D"auto"><br></div><div dir=3D"auto">An example of such limit= 643 might be: the maximum amount allowed to send is max(s, p) where s is a num= 644 ber of satoshi and p a percentage of the total available (sendable) amount.= 645 </div><div dir=3D"auto"><br></div><div dir=3D"auto">A minimum value may be = 646 imposed on the percentage to ensure that the address can be emptied within = 647 a reasonable number of transactions. The second parameter s allows a minimu= 648 m permitted amount. (This is necessary because with only the percentage par= 649 ameter the minimum permitted amount converges to zero, making it impossible= 650 to empty the address).=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"= 651 auto">There may be other ways too. In my view, such kind of restriction wou= 652 ld be extremely effective in thwarting the most damaging type of theft bein= 653 g the one where all funds are swept in a single transaction.</div><div dir= 654 =3D"auto"><br></div><div dir=3D"auto">Zac</div><div dir=3D"auto"><br></div>= 655 <div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O= 656 n Tue, 27 Jul 2021 at 03:26, Billy Tetrud via bitcoin-dev <<a href=3D"ma= 657 ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l= 658 ists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail= 659 _quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204= 660 ,204);padding-left:1ex"><div dir=3D"ltr">Hey James,<div><br></div><div>In t= 661 he examples you mentioned, what I was exploring was a mechanism of attack b= 662 y which the attacker could steal user A's key and use that key to send = 663 a transaction with the maximum possible fee. User B would still receive som= 664 e funds (probably), but if the fee could be large, the attacker would eithe= 665 r do a lot of damage to user B (griefing) or could make an agreement with a= 666 miner to give back some of the large fee (theft).=C2=A0</div><div><br></di= 667 v><div>But as for use cases, the proposal mentions <a href=3D"https://githu= 668 b.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constrainde= 669 stination.md#motivation" target=3D"_blank">a number of use cases</a>=C2=A0a= 670 nd most overlap with the <a href=3D"https://utxos.org/uses/" target=3D"_bla= 671 nk">use cases of op_ctv</a>=C2=A0(Jeremy Rubin's website for op_ctv has= 672 a lot of good details, most of which are also relevant to op_cd). The use = 673 case I'm most interested=C2=A0in is wallet vaults. This opcode can be u= 674 sed to create a wallet vault where the user only needs to use, for example,= 675 1 key to spend funds, but the attacker must steal 2 or more keys to spend = 676 funds. The benefits of a 2 key wallet vault like this vs a normal 2-of-2 mu= 677 ltisig wallet are that not only does an attacker have to steal both keys (s= 678 ame level of security), but also the user can lose one key and still recove= 679 r their funds (better redundancy) and also that generally the user doesn= 680 9;t need to access their second key - so that can remain in a much more sec= 681 ure location (which would also probably make that key harder to steal). The= 682 only time the second key only comes into play if one key is stolen and the= 683 attacker attempts to send a transaction. At that point, the user would go = 684 find and use his second key (along with the first) to send a revoke transac= 685 tion to prevent the attacker from stealing their funds. This is somewhat ak= 686 in to a lightning watchtower scenario, where your wallet would watch the ch= 687 ain and alert you about an unexpected transaction, at which point you'd= 688 manually do a revoke (vs a watchtower's automated response). You might= 689 be interested in taking a look at <a href=3D"https://github.com/freshenees= 690 z/bip-efficient-bitcoin-vaults/blob/main/cd/op_cdWalletVault1.md" target=3D= 691 "_blank">this wallet vault design</a> that uses OP_CD or even <a href=3D"ht= 692 tps://github.com/fresheneesz/bip-efficient-bitcoin-vaults" target=3D"_blank= 693 ">my full vision</a> of the wallet vault I want to be able to create.</div>= 694 <div><br></div><div>With a covenant opcode like this, its possible to creat= 695 e very usable and accessible but highly secure wallets that can allow norma= 696 l people to hold self custody of their keys without fear of loss or theft a= 697 nd without the hassle of a lot of safe deposit boxes (or other secure seed = 698 storage locations).=C2=A0</div><div><br></div><div>Cheers,</div><div>BT</di= 699 v><div><br></div><div><br></div><div><br></div><div><br></div></div><br><di= 700 v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 2= 701 6, 2021 at 2:08 PM James MacWhyte <<a href=3D"mailto:macwhyte@gmail.com"= 702 target=3D"_blank">macwhyte@gmail.com</a>> wrote:<br></div><blockquote c= 703 lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli= 704 d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Hi B= 705 illy!</div><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><blockquot= 706 e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= 707 olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><span>See abo= 708 ve, but to break down that situation a bit further, these are the two situa= 709 tions I can think of:</span><br></div><div><div><ol><li style=3D"padding-bo= 710 ttom:0.6001em">The opcode limits user/group A to send the output to user/gr= 711 oup B</li><li style=3D"padding-bottom:0.6001em">The opcode limits user A to= 712 send from one address they own to another address they own.=C2=A0</li></ol= 713 ></div></div></div></blockquote><div><span>I'm trying to think of a goo= 714 d use case for this type of opcode. In these examples, an attacker who comp= 715 romises the key for user A can't steal the money because it can only be= 716 sent to user B. So if the attacker wants to steal the funds, they would ne= 717 ed to compromise the keys of both user A and user B.</span></div><div><span= 718 ><br></span></div><div><span>But how is that any better than a 2-of-2 multi= 719 sig? Isn't the end result exactly=C2=A0the same?</span><br></div><div><= 720 span><br></span></div><div><span>James</span></div></div></div> 721 </blockquote></div> 722 _______________________________________________<br> 723 bitcoin-dev mailing list<br> 724 <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= 725 bitcoin-dev@lists.linuxfoundation.org</a><br> 726 <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = 727 rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= 728 man/listinfo/bitcoin-dev</a><br> 729 </blockquote></div></div> 730 </blockquote></div> 731 </blockquote></div></div> 732 </blockquote></div> 733 734 --00000000000034becf05c832b8e8-- 735 736