path: root/db/9e9027f456c05c01d9a6c7259e3fa4be31d844

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=
&#39;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>&quot;0 A MERKLESUB P CHECKSIGVERI=
FY&quot; [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>&quot;&lt;output_index=3D0&gt; &lt;control_integ=
er&gt; &lt;path_step&gt; &lt;pubkey_tweak&gt; TLUV<br>	&lt;output_index=3D1=
 &lt;control_integer&gt; &lt;path_step&gt; &lt;pubkey_tweak&gt; TLUV<br>	&l=
t;pubkey&gt; CHECKSIGVERIFY&quot;<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&#39;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&quot; non-cooperative publication...<br></div>

--00000000000085d91205df15bad0--