diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2022-05-15 20:01:29 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-05-16 00:01:42 +0000 |
| commit | 2b7a8ea4d0c0ab51c23a403f39e20da1b6bb2a8c (patch) | |
| tree | a16a4daf33a46682d60e8417edfbc1a154bc62e0 | |
| parent | b7a18c6f63f8fd1c6c0f9198f457603e28ddd247 (diff) | |
| download | pi-bitcoindev-2b7a8ea4d0c0ab51c23a403f39e20da1b6bb2a8c.tar.gz pi-bitcoindev-2b7a8ea4d0c0ab51c23a403f39e20da1b6bb2a8c.zip | |
[bitcoin-dev] A small tweak to TLUV to enable off-chain cancellation of payment pool transactions
| -rw-r--r-- | db/9e9027f456c05c01d9a6c7259e3fa4be31d844 | 219 |
1 files changed, 219 insertions, 0 deletions
diff --git a/db/9e9027f456c05c01d9a6c7259e3fa4be31d844 b/db/9e9027f456c05c01d9a6c7259e3fa4be31d844 new file mode 100644 index 000000000..49a934f83 --- /dev/null +++ b/db/9e9027f456c05c01d9a6c7259e3fa4be31d844 @@ -0,0 +1,219 @@ +Return-Path: <antoine.riard@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 749C8C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 16 May 2022 00:01:42 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 5F78A8130B + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 16 May 2022 00:01:42 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp1.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id TtyLB5eOtRlE + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 16 May 2022 00:01:41 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com + [IPv6:2607:f8b0:4864:20::b2b]) + by smtp1.osuosl.org (Postfix) with ESMTPS id 6AD5681301 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 16 May 2022 00:01:41 +0000 (UTC) +Received: by mail-yb1-xb2b.google.com with SMTP id p139so3470239ybc.11 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 15 May 2022 17:01:41 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=mime-version:from:date:message-id:subject:to; + bh=e3se0F5ZepOd9cH6yMIeuA3vi6tZYRU540abl/lerC8=; + b=oPJ9pbBA3gtLmajYCp0c0Z9KF1ev5C7Rji1xHrU3etCiM40lzpFisI++0bmWWZwPOE + i9uzNHfKCAH85caUfPsK325qkimopPwxaUzY3miNVv61e8meH6phCYT0LPA+t6PExdSU + JQhbK2H0+SUFIbCxBEu9tr5Juu4bkcTcvprpiDQwXH/X/wcWEJLbyDSvQ/2bHGi56i3Y + jKo1s2T6bQZkbaG4B8i+JkBn5UMU7938ncrIbW5d5hx0yY5arYz8r4I4yLXMCNvmfN06 + QgC3zMMAEN5YqBR21sUC1ZN3YvY+0YtviNeJ3otl2WHBq4AMVWZITsbbu2GxO1Z3N64w + hi8g== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:from:date:message-id:subject:to; + bh=e3se0F5ZepOd9cH6yMIeuA3vi6tZYRU540abl/lerC8=; + b=6DPVtni+bphAVKk86/QOVhfU8Yi9f+Zd8F/8Jv+omggHqP9E7ho+P4lnzpOivJy8ra + dU3eXf9yDj85esB6H2igmhtrNA3/1wcga9R//R5qAvdpOL7JxGBSn1fQPLaxOAoY1JSZ + 3+2RwztcGN/p9vbLYIaKapiDSBcAIP6slgDMB3QVzTO/R2v/MUEor7/Z1AfRYgNjLroR + V2p2MVD1X+wA4tNdEB+9IfqofhiJ75hdC8NEAGiMRVTNURqpaPMuMcz7L9K9OO9AKFy5 + Bqx3TVZZJds+tNnMVnisry0bS9JUiMBu/9GuRdnbEWe+cXhZtZOcjGqyMVOQq5pNvWXx + dQKw== +X-Gm-Message-State: AOAM530BASHHfFgYTj9AZBT90ZMPdlUBk+sYVH5Pua8fVB0g6y5Zq1mX + fIagnBcmdDpghDGxpV4ePVkW47taoq8IRqS3VD93iGgRiAs= +X-Google-Smtp-Source: ABdhPJwrdNElDxKejLRZnKISIRPYCa7dpvwt2NQr48rMxl79AOQwuj12pJrixrd7/GJLvqZniLuF11fVTQfQ9U21IkY= +X-Received: by 2002:a5b:783:0:b0:64a:2087:b252 with SMTP id + b3-20020a5b0783000000b0064a2087b252mr15081490ybq.467.1652659300193; Sun, 15 + May 2022 17:01:40 -0700 (PDT) +MIME-Version: 1.0 +From: Antoine Riard <antoine.riard@gmail.com> +Date: Sun, 15 May 2022 20:01:29 -0400 +Message-ID: <CALZpt+F+Hmwm_1F1j0-58cFjsHTqqxAMxwdLqu0vqtk0--ArFA@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000085d91205df15bad0" +X-Mailman-Approved-At: Mon, 16 May 2022 07:56:40 +0000 +Subject: [bitcoin-dev] A small tweak to TLUV to enable off-chain + cancellation of payment pool transactions +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Mon, 16 May 2022 00:01:42 -0000 + +--00000000000085d91205df15bad0 +Content-Type: text/plain; charset="UTF-8" + +Hi, + +Proposing a small tweak to TLUV to enable cancellation of an off-chain +transaction among a set of pool participants. Namely, to give the index of +the constrained output as an opcode item. + +Using CoinPool terminology, the Withdraw phase happens by a participant +publishing an Update transaction and her own Withdraw transaction, freeing +her balance from the pool control. From then, any participant can +recursively and unilaterally publish a Withdraw transaction. Or the +consensus of the remaining participants can agree to stay in the pool by +cancelling the non-published Withdraw transactions with a Snapshot one +spending the pool output. This transaction implies a rotation of the +tapscripts, effectively cancelling the Withdraws. + +The presence of this latest transaction is a bit artificial and could be +removed by cancelling the non-published Withdraw transactions. This +cancellation would be manifested by producing a group signature spending +any non-published Withdraw transaction `pool_output` and `balance_output`. + +If the SIGHASH_ANYPREVOUTANYSCRIPT semantic is used, this re-lifting Update +transaction could be attached on any Withdraw transaction, even if the user +balances are not equal, as the amounts are not committed. To enable +rebinding on multiple cancelled Withdraw +transactions, I think SIGHASH_ANYONECANPAY could be used. + +However, the group producing the signature to spend any cancelled output +should reflect the new set of pool participants after the withdrawals have +been played out. Any withdrawing user should have been removed, as there is +no interest anymore to +contribute to the signature. We would like to avoid a former participant +with nothing at stake in the pool to block the pool operations. + +E,g let's say you have Alice, Bob, Caroll and Dave as pool participants. +Each of them owns a Withdraw transaction to exit their individual balances +at any time. Alice publishes her Withdraw transaction. Bob, Caroll and Dave +would like to cancel their non-published ones to pursue the pool +operations. To cancel the non-published transactions, only Bob, Caroll and +Dave should be part of the group of signers encumbering the non-published +Withdraw transactions outputs. + +That said, the composition of this group of signers is a function of the +Withdraw transactions order, and as thus is unknown at pool state +generation. Therefore, it should be constrained leveraging some covenant +mechanism. + +I believe this is achievable using TLUV semantics, at the condition to add +an output index to target the second output. Currently, a Withdraw +transaction `balance_output` is only the owner pubkey. The update internal +pubkey should also be inherited there to make the output cancellable. The +owner withdrawing capability could be moved as a timelock + a key inside a +tapscript. + +A tapscript from a CoinPool Withdraw transaction currently looks like this +"0 A MERKLESUB P CHECKSIGVERIFY" [0] + +The new tapscript would duplicate TLUV with an output index to constrain +the spending transactions both outputs, and therefore make them cancellable: + +"<output_index=0> <control_integer> <path_step> <pubkey_tweak> TLUV +<output_index=1 <control_integer> <path_step> <pubkey_tweak> TLUV +<pubkey> CHECKSIGVERIFY" + +I think it is a really slight modification of TLUV and it might serve other +use-cases, beyond the payment pool one ? + +Thoughts ? + +[0] While it could be argue to split TLUV in two smaller opcodes like +OP_MERKLESUB or a hypothesis OP_MERKLEADD to save few bytes when only the +subtraction or the addition feature is used, I'm not sure it's worthy the +complexity increased. In the context of payment pools, the usage of a TLUV +opcode should only happen in case of "pessimistic" non-cooperative +publication... + +--00000000000085d91205df15bad0 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi,<br><br>Proposing a small tweak to TLUV to enable cance= +llation of an off-chain transaction among a set of pool participants. Namel= +y, to give the index of the constrained output as an opcode item.<br><br>Us= +ing CoinPool terminology, the Withdraw phase happens by a participant publi= +shing an Update transaction and her own Withdraw transaction, freeing her b= +alance from the pool control. From then, any participant can recursively an= +d unilaterally publish a Withdraw transaction. Or the consensus of the rema= +ining participants can agree to stay in the pool by cancelling the non-publ= +ished Withdraw transactions with a Snapshot one spending the pool output. T= +his transaction implies a rotation of the tapscripts, effectively cancellin= +g the Withdraws.<br><br>The presence of this latest transaction is a bit ar= +tificial and could be removed by cancelling the non-published Withdraw tran= +sactions. This cancellation would be manifested by producing a group signat= +ure spending any non-published Withdraw transaction `pool_output` and `bala= +nce_output`.<br><br>If the SIGHASH_ANYPREVOUTANYSCRIPT semantic is used, th= +is re-lifting Update transaction could be attached on any Withdraw transact= +ion, even if the user balances are not equal, as the amounts are not commit= +ted. To enable rebinding on multiple cancelled Withdraw<br>transactions, I = +think SIGHASH_ANYONECANPAY could be used.<br><br>However, the group produci= +ng the signature to spend any cancelled output should reflect the new set o= +f pool participants after the withdrawals have been played out. Any withdra= +wing user should have been removed, as there is no interest anymore to<br>c= +ontribute to the signature. We would like to avoid a former participant wit= +h nothing at stake in the pool to block the pool operations.<br><br>E,g let= +'s say you have Alice, Bob, Caroll and Dave as pool participants. Each = +of them owns a Withdraw transaction to exit their individual balances at an= +y time. Alice publishes her Withdraw transaction. Bob, Caroll and Dave woul= +d like to cancel their non-published ones to pursue the pool operations. To= + cancel the non-published transactions, only Bob, Caroll and Dave should be= + part of the group of signers encumbering the non-published Withdraw transa= +ctions outputs.<br><br>That said, the composition of this group of signers = +is a function of the Withdraw transactions order, and as thus is unknown at= + pool state generation. Therefore, it should be constrained leveraging some= + covenant mechanism.<br><br>I believe this is achievable using TLUV semanti= +cs, at the condition to add an output index to target the second output. Cu= +rrently, a Withdraw transaction `balance_output` is only the owner pubkey. = +The update internal pubkey should also be inherited there to make the outpu= +t cancellable. The owner withdrawing capability could be moved as a timeloc= +k + a key inside a tapscript.<br><br>A tapscript from a CoinPool Withdraw t= +ransaction currently looks like this <br>"0 A MERKLESUB P CHECKSIGVERI= +FY" [0]<br><br>The new tapscript would duplicate TLUV with an output i= +ndex to constrain the spending transactions both outputs, and therefore mak= +e them cancellable:<br><br>"<output_index=3D0> <control_integ= +er> <path_step> <pubkey_tweak> TLUV<br> <output_index=3D1= + <control_integer> <path_step> <pubkey_tweak> TLUV<br> &l= +t;pubkey> CHECKSIGVERIFY"<br><br>I think it is a really slight modi= +fication of TLUV and it might serve other use-cases, beyond the payment poo= +l one ?<br><br>Thoughts ?<br><br>[0] While it could be argue to split TLUV = +in two smaller opcodes like OP_MERKLESUB or a hypothesis OP_MERKLEADD to sa= +ve few bytes when only the subtraction or the addition feature is used, I&#= +39;m not sure it's worthy the complexity increased. In the context of p= +ayment pools, the usage of a TLUV opcode should only happen in case of &quo= +t;pessimistic" non-cooperative publication...<br></div> + +--00000000000085d91205df15bad0-- + |