From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B072BD8B for ; Thu, 8 Aug 2019 01:18:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4902082D for ; Thu, 8 Aug 2019 01:18:34 +0000 (UTC) Received: by mail-vs1-f53.google.com with SMTP id a186so4973565vsd.7 for ; Wed, 07 Aug 2019 18:18:34 -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=0Ykk0A2wzzLAgxPVmppym1OV5aYyA5qU48W9JTJn2iw=; b=blerPziY3Vr24b1RHZRgTIP1Hd2zhL6+PJYVavgR6PMf04mH8ZhxtpbN2G/KnMPI/g 8drBiIOLaiVqDkD2N6nR9R0midRq6vZZ4oP0GEEWBu5in5zz0eo1r/bE4D/L1/kNIPAb lJZqTMZLx0d4+ufiLs8//l3hCXst+6h1Ltev7f1HrygaB8W5MsA4NRwu/roz3VvzNa/e R7zD69KsXMHcPn0l/3vIOn45vFDuedRv6XBtNvDCvdiHulsemyd4NxZU/pf5uheSTMhH l8yTEfllJJvL8N/g1r4dADlLcomMooU8LLIkWkOR76aHhsDWXdfV0lRKL2FgMjENzUG+ EOcA== 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=0Ykk0A2wzzLAgxPVmppym1OV5aYyA5qU48W9JTJn2iw=; b=l1ruLUekH0gIpIv8iVtMuSCNNFKQJ2c4tD87FB3tiINGZlSCS4re/c6epnO6QSDfmd EW/fZPzzVN1VVBqc+PF3QnvQrAEMsB/3f+ueWC/2GaYxuy0QbQ8BWn+TZG+5/xDKZ0n0 oLMDgxchHs23B0pLJ0/ACiw8aKuHk3btWYmzs+LJ6KzEk/28WygwMzfaKWjyOwkEDqBv SDUDFdeOcV+xOu60n9Ehp1Em6pBGIOJwmDLtRBKPRRBojikfGCU3L+p5Rwpn8LTZ09ph ysMV8FOjRW2dLRUiO1KYZ1HWdq3l1RiLPPixjw0NDUCKtuK+XRswBkOsCP2Q+MVGHaoZ 2xIA== X-Gm-Message-State: APjAAAXuecaTN8rLlXq2pMboboQuNbULmsqbL6NPkIQr+Lf3ywZnouXp DixmwIrCo3h/1e589895oCwBWv4j8oEpozBFX/w= X-Google-Smtp-Source: APXvYqygacCYDGyxw0ZNY/CmU7OYiip9M7Va957ZOGauzfKWOcQz3+jc9SjiCUfjN4spLl54fNMrMfMlQWuwZOYQsls= X-Received: by 2002:a05:6102:3c5:: with SMTP id n5mr8060829vsq.56.1565227113363; Wed, 07 Aug 2019 18:18:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bryan Bishop Date: Wed, 7 Aug 2019 20:16:42 -0500 Message-ID: To: ZmnSCPxj , Dustin Dettmer , Bryan Bishop Content-Type: multipart/alternative; boundary="00000000000015bfc5058f90d61d" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 01:18:35 -0000 --00000000000015bfc5058f90d61d Content-Type: text/plain; charset="UTF-8" Replying to two emails below. On Wed, Aug 7, 2019 at 7:27 PM ZmnSCPxj wrote: > > - Re-vaulting transaction. This is where the magic happens. The > re-vaulting > > transaction is signed during transaction tree setup, before > constructing the > > delayed-spend transaction for the parent vault. The re-vaulting > transaction is > > broadcasted when someone wants to prevent a coin withdrawal during > the public > > observation delay period. The re-vaulting transaction spends the > delayed-spend > > transaction outputs. It has a single output with a script created by > running > > the entire vault setup function again. Hence, when the re-vaulting > transaction > > is confirmed, all of the coins go back into a new > identically-configured vault > > instead of being relinquished through the delayed-spend transaction > timeout for > > hot wallet key signing. > > As transactions need to be signed in reverse order, it seems to me that > there is a practical limit in the number of times a vault can be used. > Basically, the number of times we run the vault setup function is the > limit on number of re-vaultings possible. > > Is my understanding correct? > Yes, that is correct. When setting up the vault, plan it "all the way to the end" like next 100+ years. With exponential backoff on the relative timelock values, the total number of pre-signed transactions isn't really that high. With a few thousand pre-signed transactions (more than enough), you can have high resolution timelocks well into the future. On Wed, Aug 7, 2019 at 4:19 PM Dustin Dettmer wrote: > Does revaulting vault up with the same keys, or new ones? > Are they new derivation paths on the same key? > Honestly, no idea. The answer to that might depend on each individual vault user. If the user doesn't want to deal with the expense of managing a bunch of unique keys and other data, then it might make more sense to use the same values and have a small blob that has to be stored for a long time, rather than many different blobs stored in different places to deal with. - Bryan http://heybryan.org/ --00000000000015bfc5058f90d61d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Replying to two emails below.

On Wed, Aug 7, 2019 at 7= :27 PM ZmnSCPxj <ZmnSCPxj@pro= tonmail.com> wrote:
> -=C2=A0 =C2=A0Re-vaulting transaction. This is where the magic happens= . The re-vaulting
>=C2=A0 =C2=A0 =C2=A0transaction is signed during transaction tree setup= , before constructing the
>=C2=A0 =C2=A0 =C2=A0delayed-spend transaction for the parent vault. The= re-vaulting transaction is
>=C2=A0 =C2=A0 =C2=A0broadcasted when someone wants to prevent a coin wi= thdrawal during the public
>=C2=A0 =C2=A0 =C2=A0observation delay period. The re-vaulting transacti= on spends the delayed-spend
>=C2=A0 =C2=A0 =C2=A0transaction outputs. It has a single output with a = script created by running
>=C2=A0 =C2=A0 =C2=A0the entire vault setup function again. Hence, when = the re-vaulting transaction
>=C2=A0 =C2=A0 =C2=A0is confirmed, all of the coins go back into a new i= dentically-configured vault
>=C2=A0 =C2=A0 =C2=A0instead of being relinquished through the delayed-s= pend transaction timeout for
>=C2=A0 =C2=A0 =C2=A0hot wallet key signing.

As transactions need to be signed in reverse order, it seems to me that the= re is a practical limit in the number of times a vault can be used.
Basically, the number of times we run the vault setup function is the limit= on number of re-vaultings possible.

Is my understanding correct?

Yes, that is correct.= When setting up the vault, plan it "all the way to the end" like= next 100+ years. With exponential backoff on the relative timelock values,= the total number of pre-signed transactions isn't really that high. Wi= th a few thousand pre-signed transactions (more than enough), you can have = high resolution timelocks well into the future.

On Wed, Aug 7, 2019 at 4:19 PM Dustin Dettmer <dustinpaystaxes@gmail.com> wro= te:
Does revaulting vault up with the same keys, or new ones?
<= /div>
Are they new derivation paths on the same key?
=

Honestly, no idea. The answer to that might depend on each= individual vault user. If the user doesn't want to deal with the expen= se of managing a bunch of unique keys and other data, then it might make mo= re sense to use the same values and have a small blob that has to be stored= for a long time, rather than many different blobs stored in different plac= es to deal with.

- Bryan
http://he= ybryan.org/
--00000000000015bfc5058f90d61d--