Date: Thu, 08 Aug 2019 00:27:32 +0000
To: Bryan Bishop <kanzure@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <japBRkZAIadJ9g0xOFbixrzJv4hk67ONKrjO6QuWARaeMtdIhNb7rDT_8NroxDCIVKFTjcAqukSt4sApPsJ0U9ori3bkCKmEW_jJMcXWMqc=@protonmail.com>
In-Reply-To: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
References: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback
	mechanisms
Precedence: list

Good morning Bryan,

> -   Re-vaulting transaction. This is where the magic happens. The re-vaul=
ting
>     transaction is signed during transaction tree setup, before construct=
ing the
>     delayed-spend transaction for the parent vault. The re-vaulting trans=
action is
>     broadcasted when someone wants to prevent a coin withdrawal during th=
e public
>     observation delay period. The re-vaulting transaction spends the dela=
yed-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 tr=
ansaction
>     is confirmed, all of the coins go back into a new identically-configu=
red vault
>     instead of being relinquished through the delayed-spend transaction t=
imeout for
>     hot 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?

Regards,
ZmnSCPxj