📅 Original date posted:2020-05-08
📝 Original message:The fee bumping construction I described in the previous post is potentially vulnerable
to transaction pinning.
We shared a SINGLE | ANYONECANPAY signature for the first (and only) input of revaulting
transactions to allow any party to append an input and an output in order to bump the
transaction fees.
An user would either append an input signed with ALL, or replace their SINGLE | ANYONECANPAY
signature with one using ALL before broadcasting the transaction.
This allowed one party to decrease the transaction fees down to the minimum relay fees,
and possibly pin the transaction by spending their added single-pubkey output.
We now exchange ALL | ANYONECANPAY signatures for revaulting transactions to restrict the creation
of a new output only spendable by one party.
The fee bumping is now done in two stages (to avoid consuming an entire utxo) :
Unvaulting transaction
--------------------------------
| vault prevout | unvault output |------------------
-------------------------------- \
\ Revaulting transaction
\ ---------------------------------------
| unvault prevout | new vault output |
---------------------------------------
| fee bump prevout |
/ --------------------
Single-party wallet transaction /
----------------------------------------- /
| wallet prevout | fee bump output |----------
-----------------------------------------
| wallet change output |
------------------------
This construction isn't perfect as a malicious party could still pin its fee bumping transaction
and prevent the other stakeholders from **immediatly** replacing this input, because of the second
rule of BIP125 :
> The replacement transaction may only include an unconfirmed input if that input was included
> in one of the original transactions.
However, I think it's preferable as :
- Depending on the unvault CSV, the honest party might pay a high fee to have the fee-bumping
transaction confirm in one of the next two blocks, and then use this now confirmed output as an
additional input of the revaulting transaction.
- If the amount is consequent, the honest party may sacrifice an entire confirmed utxo from its
wallet (effectively skipping the fee bumping transaction).
- It's realistic to expect, for such an application, users' wallets to have a pool of confirmed
utxo that might be sacrificed if the amount is consequent AND the CSV is so small (which is
anyway a bad idea in the first place) that you are not sure to have the fee bumping transaction
to be confirmed before its maturity, ).
Thanks,
Antoine / Darosior
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le vendredi, avril 24, 2020 5:00 PM, darosior <darosior at protonmail.com> a écrit :
> Hi all,
>
> Kevin Loaec and I have been working on a new multiparty vault architecture and I think it reached the point where we’d welcome some feedback.
>
> Intended usage and limitations
>
> ===============================
>
> The aim is to secure the shared storage of coins without relying on a trusted third party and by disincentivizing theft attempts, while not restricting the usage of the funds for day-to-day operations.
>
> Revault uses N-of-N multisigs and thus does not protect against intentional locking of funds (such as refusal to sign, or key erasure). Therefore it assumes its users (likely companies with already on-going agreements between shareholders) to be able to solve intentional blockage outside the Bitcoin network (such as through legal contracts).
>
> The actual architecture
>
> ========================
>
> We called it revault as it relies on pre-signed and revocable (revaultable) transactions.
> The users pre-sign a transaction chain as the only used way to spend from a vault output.
> They would have signed a set of transactions to either cancel a spend attempt or lock the funds for some time beforehand. The funds are always better locked for a long time than stolen.
>
> The transactions
>
> ----------------
>
> The system is composed of mainly 6 transaction types (with N the number of stakeholders) :
>
> - The “vault” transaction which pays to a N-of-N, by which funds are received.
> - The “emergency” transaction, which spends the vault output and pays to a [here goes a
> high value]-days timelocked N-of-N (with N differents but statics keys, assumed to be physically stored in hard(/long) to access locations).
>
> - The “unvault” transaction, which spends the vault output and pays to [either the vault’s N-of-N, or after X blocks to a subset of the stakeholders AND a co-signing server].
> - The “unvault emergency” transaction, which spends the unvault output and pays to the
> same script as the first emergency transaction.
>
> - The “cancel” transaction, which spends the unvault output and pays back to a new vault utxo.
> - The “spend” transaction, which spends the unvault output and pays to an external address (potentially contained in a list of destinations previously agreed-upon by all the stakeholders).
>
> The process
>
>
> The stakeholders would exchange the signatures of all the revaulting transactions after the reception of a new vault utxo, and then exchange the signatures of the unvaulting transaction. Before doing so, the coins are not available to be spent.
>
> In order to spend a vault, the subset of the stakeholders who manages the funds (for example, the traders of an investment fund) would make the cosigning server (which only signs a transaction once) sign the spend transaction.
> They would then present it to the other watchers which would ACK the spend (if paying to an authorized address), and broadcast the "unvault" transaction. Finally, and after X blocks have passed they would be able to broadcast the spend transaction.
> If a stakeholder's watcher detects an unvaulting transaction without knowing about its child “spend” transaction, it triggers an automatic “cancel” transaction (not encumbered by the timelock).
>
> At any point -even in the middle of a spend- any of the stakeholder can trigger an emergency transaction if anything nasty is happening.
> Any network watcher noticing the broadcast of an emergency transaction would also broadcast all other vaults’ emergency transactions.
>
> This network watching and revaulting power can be replicated (watchtowers) to further decrease the reliance on a single machine or internet access.
>
> Pre-signed transactions fun
>
> ---------------------------
>
> In order to avoid our security assumptions to be as weak as betting on the value of the feerate in the future, stakeholders exchange SINGLE | ANYONECANPAY signatures for the revaulting transactions and append their own as SIGHASH_ALL before broadcasting.
> They can add another input (and potentially output) in order to bump the fees before doing so.
>
> We protect ourselves from the bug by leveraging the fact the revaulting (namely the "emergency", "unvault emergency", and "cancel" transactions) only have strictly one input and one output. The change being part of the spend transaction.
>
> In addition, revaulting transactions may signal for RBF to cover a feerate increase after the broadcast. Anyhow, a significant breathing room can be added to the feerate as these transactions are not intended to be used under normal circumstances.
>
> Worth mentioning
>
> ================
>
> The original draft of this architecture was first designed by Kevin Loaec who was hired by NOIA to do so. It was inspired by Bryan Bishop’s single-party vault architecture (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html), who published a demo implementation of it last week (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017755.html, https://github.com/kanzure/python-vaults).
> Kevin and I since detailed and reworked our new architecture together.
>
> A WIP draft / demo / PoC / [enter adjective with “insecure” meaning] implementation is available at https://github.com/re-vault/revault-demo, which uses 4 stakeholders, 2 or 3 traders (doing the day-to-day moves) a CSV of 6 blocks for the unvault script and a CSV of ~1 month for the emergency scripts.
> The transactions used are detailed in the doc/ directory of the same repo, and are coded in the revault/transactions/ module.
>
> The “revault” name was coined by Lea Thiebaut (Lexyon).
>
> Thanks for reading,
> Antoine / Darosior
darosior [ARCHIVE] /
npub1pj…x22xp
2023-06-07 18:24:31
in reply to nevent1q…uhns
Author Public Key
npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xpPublished at
2023-06-07 18:24:31Event JSON
{
"id": "3e74b76b62e156624c6c4fe0e2eebd1ef882d27da06954e18126603b93d100fd",
"pubkey": "0c8af5293ea8c40f3686f22669674e0c116a8e92467163929d736aa891b7ece2",
"created_at": 1686162271,
"kind": 1,
"tags": [
[
"e",
"f9c3ae30cc3a15ce6c1fa226f796675ed4656ee7570661e8fb230bff5a0f4da3",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2020-05-08\n📝 Original message:The fee bumping construction I described in the previous post is potentially vulnerable\nto transaction pinning.\n\n\nWe shared a SINGLE | ANYONECANPAY signature for the first (and only) input of revaulting\ntransactions to allow any party to append an input and an output in order to bump the\ntransaction fees.\nAn user would either append an input signed with ALL, or replace their SINGLE | ANYONECANPAY\nsignature with one using ALL before broadcasting the transaction.\n\nThis allowed one party to decrease the transaction fees down to the minimum relay fees,\nand possibly pin the transaction by spending their added single-pubkey output.\n\n\nWe now exchange ALL | ANYONECANPAY signatures for revaulting transactions to restrict the creation\nof a new output only spendable by one party.\nThe fee bumping is now done in two stages (to avoid consuming an entire utxo) :\n\n\n Unvaulting transaction\n --------------------------------\n | vault prevout | unvault output |------------------\n -------------------------------- \\\n \\ Revaulting transaction\n \\ ---------------------------------------\n | unvault prevout | new vault output |\n ---------------------------------------\n | fee bump prevout |\n / --------------------\n Single-party wallet transaction /\n ----------------------------------------- /\n | wallet prevout | fee bump output |----------\n -----------------------------------------\n | wallet change output |\n ------------------------\n\n\n\nThis construction isn't perfect as a malicious party could still pin its fee bumping transaction\nand prevent the other stakeholders from **immediatly** replacing this input, because of the second\nrule of BIP125 :\n\u003e The replacement transaction may only include an unconfirmed input if that input was included\n\u003e in one of the original transactions.\n\n\nHowever, I think it's preferable as :\n- Depending on the unvault CSV, the honest party might pay a high fee to have the fee-bumping\n transaction confirm in one of the next two blocks, and then use this now confirmed output as an\n additional input of the revaulting transaction.\n- If the amount is consequent, the honest party may sacrifice an entire confirmed utxo from its\n wallet (effectively skipping the fee bumping transaction).\n- It's realistic to expect, for such an application, users' wallets to have a pool of confirmed\n utxo that might be sacrificed if the amount is consequent AND the CSV is so small (which is\n anyway a bad idea in the first place) that you are not sure to have the fee bumping transaction\n to be confirmed before its maturity, ).\n\n\nThanks,\nAntoine / Darosior\n\n\n\n\n‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\nLe vendredi, avril 24, 2020 5:00 PM, darosior \u003cdarosior at protonmail.com\u003e a écrit :\n\n\u003e Hi all,\n\u003e\n\u003e Kevin Loaec and I have been working on a new multiparty vault architecture and I think it reached the point where we’d welcome some feedback.\n\u003e\n\u003e Intended usage and limitations\n\u003e\n\u003e ===============================\n\u003e\n\u003e The aim is to secure the shared storage of coins without relying on a trusted third party and by disincentivizing theft attempts, while not restricting the usage of the funds for day-to-day operations.\n\u003e\n\u003e Revault uses N-of-N multisigs and thus does not protect against intentional locking of funds (such as refusal to sign, or key erasure). Therefore it assumes its users (likely companies with already on-going agreements between shareholders) to be able to solve intentional blockage outside the Bitcoin network (such as through legal contracts).\n\u003e\n\u003e The actual architecture\n\u003e\n\u003e ========================\n\u003e\n\u003e We called it revault as it relies on pre-signed and revocable (revaultable) transactions.\n\u003e The users pre-sign a transaction chain as the only used way to spend from a vault output.\n\u003e They would have signed a set of transactions to either cancel a spend attempt or lock the funds for some time beforehand. The funds are always better locked for a long time than stolen.\n\u003e\n\u003e The transactions\n\u003e\n\u003e ----------------\n\u003e\n\u003e The system is composed of mainly 6 transaction types (with N the number of stakeholders) :\n\u003e\n\u003e - The “vault” transaction which pays to a N-of-N, by which funds are received.\n\u003e - The “emergency” transaction, which spends the vault output and pays to a [here goes a\n\u003e high value]-days timelocked N-of-N (with N differents but statics keys, assumed to be physically stored in hard(/long) to access locations).\n\u003e\n\u003e - The “unvault” transaction, which spends the vault output and pays to [either the vault’s N-of-N, or after X blocks to a subset of the stakeholders AND a co-signing server].\n\u003e - The “unvault emergency” transaction, which spends the unvault output and pays to the\n\u003e same script as the first emergency transaction.\n\u003e\n\u003e - The “cancel” transaction, which spends the unvault output and pays back to a new vault utxo.\n\u003e - The “spend” transaction, which spends the unvault output and pays to an external address (potentially contained in a list of destinations previously agreed-upon by all the stakeholders).\n\u003e\n\u003e The process\n\u003e\n\u003e\n\u003e The stakeholders would exchange the signatures of all the revaulting transactions after the reception of a new vault utxo, and then exchange the signatures of the unvaulting transaction. Before doing so, the coins are not available to be spent.\n\u003e\n\u003e In order to spend a vault, the subset of the stakeholders who manages the funds (for example, the traders of an investment fund) would make the cosigning server (which only signs a transaction once) sign the spend transaction.\n\u003e They would then present it to the other watchers which would ACK the spend (if paying to an authorized address), and broadcast the \"unvault\" transaction. Finally, and after X blocks have passed they would be able to broadcast the spend transaction.\n\u003e If a stakeholder's watcher detects an unvaulting transaction without knowing about its child “spend” transaction, it triggers an automatic “cancel” transaction (not encumbered by the timelock).\n\u003e\n\u003e At any point -even in the middle of a spend- any of the stakeholder can trigger an emergency transaction if anything nasty is happening.\n\u003e Any network watcher noticing the broadcast of an emergency transaction would also broadcast all other vaults’ emergency transactions.\n\u003e\n\u003e This network watching and revaulting power can be replicated (watchtowers) to further decrease the reliance on a single machine or internet access.\n\u003e\n\u003e Pre-signed transactions fun\n\u003e\n\u003e ---------------------------\n\u003e\n\u003e In order to avoid our security assumptions to be as weak as betting on the value of the feerate in the future, stakeholders exchange SINGLE | ANYONECANPAY signatures for the revaulting transactions and append their own as SIGHASH_ALL before broadcasting.\n\u003e They can add another input (and potentially output) in order to bump the fees before doing so.\n\u003e\n\u003e We protect ourselves from the bug by leveraging the fact the revaulting (namely the \"emergency\", \"unvault emergency\", and \"cancel\" transactions) only have strictly one input and one output. The change being part of the spend transaction.\n\u003e\n\u003e In addition, revaulting transactions may signal for RBF to cover a feerate increase after the broadcast. Anyhow, a significant breathing room can be added to the feerate as these transactions are not intended to be used under normal circumstances.\n\u003e\n\u003e Worth mentioning\n\u003e\n\u003e ================\n\u003e\n\u003e The original draft of this architecture was first designed by Kevin Loaec who was hired by NOIA to do so. It was inspired by Bryan Bishop’s single-party vault architecture (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html), who published a demo implementation of it last week (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-April/017755.html, https://github.com/kanzure/python-vaults).\n\u003e Kevin and I since detailed and reworked our new architecture together.\n\u003e\n\u003e A WIP draft / demo / PoC / [enter adjective with “insecure” meaning] implementation is available at https://github.com/re-vault/revault-demo, which uses 4 stakeholders, 2 or 3 traders (doing the day-to-day moves) a CSV of 6 blocks for the unvault script and a CSV of ~1 month for the emergency scripts.\n\u003e The transactions used are detailed in the doc/ directory of the same repo, and are coded in the revault/transactions/ module.\n\u003e\n\u003e The “revault” name was coined by Lea Thiebaut (Lexyon).\n\u003e\n\u003e Thanks for reading,\n\u003e Antoine / Darosior",
"sig": "f36f57e9e45e821851bfa9d46bd619d1ee02c6bb40ea1a1d919ef39a6a91fbf490cdc09ed5ad250ad86da77183b40f060630ed0e0aaa5db1e6334ee6b473e819"
}