📅 Original date posted:2019-08-07 📝 Original message:Good morning Bryan, > - ...

ZmnSCPxj [ARCHIVE] /

npub1g5z…ms3l

2023-06-07 18:20:07

in reply to nevent1q…sszu

📅 Original date posted:2019-08-07
📝 Original message:Good morning Bryan,

> - 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?

Regards,
ZmnSCPxj

Author Public Key

npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l

Show more details

Published at

2023-06-07 18:20:07

Kind type

1 Short Text Note

Event JSON

{ "id": "c2280390348dfc1809c3447645d87db37ca914c13feaa3a0e0aadb51aa1c1435", "pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861", "created_at": 1686162007, "kind": 1, "tags": [ [ "e", "b5bf86cbe856764608f643541819ee58498f1f856faf0b3188f430c12259a46d", "", "root" ], [ "e", "e82393526f0691cc76da0d81acdd0eb73dde483fc2a3bd0c3cd44f380e3a30ce", "", "reply" ], [ "p", "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861" ] ], "content": "📅 Original date posted:2019-08-07\n📝 Original message:Good morning Bryan,\n\n\u003e - Re-vaulting transaction. This is where the magic happens. The re-vaulting\n\u003e transaction is signed during transaction tree setup, before constructing the\n\u003e delayed-spend transaction for the parent vault. The re-vaulting transaction is\n\u003e broadcasted when someone wants to prevent a coin withdrawal during the public\n\u003e observation delay period. The re-vaulting transaction spends the delayed-spend\n\u003e transaction outputs. It has a single output with a script created by running\n\u003e the entire vault setup function again. Hence, when the re-vaulting transaction\n\u003e is confirmed, all of the coins go back into a new identically-configured vault\n\u003e instead of being relinquished through the delayed-spend transaction timeout for\n\u003e hot wallet key signing.\n\nAs 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.\nBasically, the number of times we run the vault setup function is the limit on number of re-vaultings possible.\n\nIs my understanding correct?\n\nRegards,\nZmnSCPxj", "sig": "5c277c352f51c7cfe404d5ddbac50f562eb94bc78976306f27c20445ceff40adcf40c2d0078dc048e8890091dfa0b5f43ba272e3e88a274fe1c5606735fa9c8c" }