path: root/b8/bcdc906a4179c43989a30f9bbc5a8b914afe96

Return-Path: <jk_14@op.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9D154C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 26 May 2023 07:38:58 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 668AA616D9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 26 May 2023 07:38:58 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 668AA616D9
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256
 header.s=2011 header.b=IpdRx5vX
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level: 
X-Spam-Status: No, score=-1.622 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, HTML_MESSAGE=0.001,
 HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id t1F9h1T5AWky
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 26 May 2023 07:38:57 +0000 (UTC)
X-Greylist: delayed 00:05:04 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E1D0A60C22
Received: from smtpo79.poczta.onet.pl (smtpo79.poczta.onet.pl [141.105.16.29])
 by smtp3.osuosl.org (Postfix) with ESMTPS id E1D0A60C22
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 26 May 2023 07:38:56 +0000 (UTC)
Received: from mta1.m5r2.onet (mta1.m5r2.onet [10.174.35.135])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4QSGr61H3dz2K25F9;
 Fri, 26 May 2023 09:33:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011;
 t=1685086422; bh=5tMRKML32tsJRl7Zre/F4wTsexPCFzXvbvuv+W0qi8A=;
 h=From:To:Subject:Date:From;
 b=IpdRx5vXJxphHRClq8o705n2HKfhC79Hgu/yMxgFdveAcKyEUQeAMHiNDvMErF9Hy
 2lxAWzufzUsVuzPS5Q8/ShgWOxMEE22nZfSlJKKPXAtxyjFLfmUaYYHQRcLykI9EK6
 UILZVui1AdssVem8n9aHysN5uVoVxYJpiQzcbI+k=
Content-Type: text/html; charset=utf-8
X-Mailer: onet.poczta
X-Priority: 3
X-Onet-Pmq: <jk_14@op.pl>;89.64.64.233;PL;1
Received: from [89.64.64.233] by mta2.m5r2.onet with HTTP id
 5ecde0d7a5c4fe73; Fri, 26 May 2023 09:33:41 +0200
From: jk_14@op.pl
To: "David A. Harding" <dave@dtrt.org>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>, Burak Keceli <burak@buraks.blog>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <993e075b-f989-ec2d-ad89-ccd0fe0b34e8@op.pl>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 26 May 2023 07:33:42 +0000
MIME-Version: 1.0
X-ONET_PL-MDA-SEGREGATION: 0
X-Mailman-Approved-At: Fri, 26 May 2023 15:27:10 +0000
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second
 Layer Solution
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: Fri, 26 May 2023 07:38:58 -0000

<div><br />"Alice runs an Ark service provider. Every 5 seconds, she =
broadcasts a new unconfirmed onchain transaction"<br /><br />Is that means =
each such instance adding ~15k vB to single block, i.e. every 10 minutes?=
<br />In such case only 200 of such nodes - would utilize the whole tx =
throughput of Bitcoin?<br /><br />Regards<br />Jaroslaw<br /><br /><br =
/></div>
<div>W dniu 2023-05-25 01:03:02 u=C5=BCytkownik David A. Harding =
via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt; =
napisa=C5=82:</div>
<blockquote style=3D"margin-right: 0; margin-left: 7px;=
 border-left: 2px solid orange; padding-left: 8px;">
<pre>Hi Burak,

Thanks for this really interesting protocol!  I tend to analyze
complicated ideas like this by writing about them in my own words, so
I've pasted my summary of your idea to the end of this email in case
it's useful, either to other people or to you in helping understand my
one concern.

My concern is the same one I think Olaoluwa Osuntokun =
mentioned on
Twitter[1] and (less clear to me) might be related to =
ZmnSCPxj's
concern[2]:

It seems to me that receiving a payment on the =
protocol, including
conditional payments using HTLC, PTLC, or Anchor-TLC, =
requires waiting
for the transaction containing that payment to confirm to =
a sufficient
depth (e.g., I'd wait 6 blocks for small payments and longer =
for huge
payments).  Am I missing something?

My summary of how I think =
that part of the protocol works is in the
sections labeled "Make an =
unconditioned payment" and "Make a conditional
payment" below.  In short, =
it's clear to me how the service provider and
the customer can make instant=
 atomic swaps with each other---they can
either spend instantly =
cooperatively, or they have to wait for a
timeout.  But how can a receiver =
of funds be assured that they will
actually get those funds unless there's =
already a timelock and
cooperative spend path placed on those funds?

-Dave

Rough initial summary of Ark protocol:

Alice runs an Ark service provider=
.  Every 5 seconds, she broadcasts a
new unconfirmed onchain transaction =
that pays three outputs (the
three Cs):

1. *Change Output:* money not used=
 for the other two Cs that gets sent
    back to the the transaction =
creator.

2. *Connector Output:* an output that will be used in a future
    transaction created by Alice as protection against double spends.

3. *Commitment Output:* a CTV-style commitment to a set of outputs that
    can be published later in a descendant transaction (alternatively,
    the commitment output may be spent unilaterally by Alice after 4
    weeks).

Bob wants to deposit 1 BTC with Alice.  He sends her an =
unsigned PSBT
with an input of his and a change output.  She updates the =
PSBT with a
commitment output that refunds Bob the 1 BTC and a connector =
output with
some minimum value.  They both sign the PBST and it is =
broadcast.  We'll
ignore fees in our examples, both onchain transaction =
fees and fees paid
to Alice.

 From here, there are several things that Bob=
 can do:

- *Unilaterally withdraw:* Bob can spend from the commitment =
output to
   put his refund onchain.  The refund can only be spent after a =
24-hour
   time delay, allowing Bob to optionally come to an agreement with=
 Alice
   about how to spend the funds before Bob can spend them =
unilaterally
   (as we'll see in a moment).  For example, the script might =
be[3]:

     pk(B) &amp;&amp; (older(1 day) || pk(A))

- *Collaboratively withdraw:* as seen above, Bob has the ability to come
   to a trustless agreement with Alice about how to spend his funds.
   They can use that ability to allow Bob to trade his (unpublished) UTXO
   for a UTXO that Alice funds and broadcasts.  For example:

     - Alice creates an unsigned PSBT that uses as one of its inputs the
       connector from Bob's deposit transaction.  This will ensure that
       any attempt by Bob to double-spend his deposit transaction will
       invalidate this withdrawal transaction, preventing Bob from being
       able to steal any of Alice's funds.

         Also included in =
Alice's unsigned PSBT is another connector
         output plus the output =
that pays Bob his 1 BTC.

     - Bob receives Alice's unsigned PSBT and =
creates a separate PSBT
       that includes his unpublished UTXO as an =
input, giving its value
       to Alice in an output.  The PSBT also =
includes as an input the
       connector output from Alice's PSBT.  This =
will ensure that any
       attempt by Alice to double spend her =
transaction paying him will
       invalidate his transaction paying her.

     - Bob signs his PSBT and gives it to Alice.  After verifying it,
       Alice signs her PSBT and broadcasts it.

- *Collaboratively trade =
commitments:* as mentioned, the commitment
   output that pays Bob may be =
claimed instead by Alice after 4 weeks, so
   Bob will need to either =
withdraw or obtain a new commitment within=20
that
   time.  To trade his =
existing commitment for a new commitment looks
   similar to the =
collaborative withdrawal procedure but without the
   creation of an =
immediately-spendable onchain output:

     - Alice creates an unsigned =
PSBT that uses as one of its inputs the
       connector from Bob's deposit=
 transaction, again preventing double
       spending by Bob.  Alice also =
includes a new connector and a new
       commitment that again allows Bob =
to later claim 1 BTC.

     - Bob receives Alice's PSBT and creates a PSBT =
transferring his
       existing commitment to her, with the new connector =
again being
       included as an input to ensure atomicity.

     - Bob signs; Alice signs and broadcasts.

- *Make an unconditioned =
payment:* using the mechanisms described above,
   it's possible to make =
either an onchain payment or an offchain
   payment---just have Carol =
receive the new output or commitment rather
   than Bob.  That payment =
would have no conditions (except its
   atomicity).

- *Make a conditional payment:* imagine that Carol knows a secret (e.g.
   a preimage) that Bob is willing to pay for.

      - Alice creates an =
unsigned PSBT depending on the connector from
        Bob's deposit =
transaction and creating a new connector.  The PSBT
        includes an output paying Carol (either onchain or via a
        commitment) with an HTLC, allowing Carol to claim the funds if=20
she
        reveals the secret or allowing Bob to claim the funds after a
        timeout.

      - Bob receives Alice's PSBT and creates a PSBT =
transferring his
        existing commitment to her with the HTLC condition=
 attached and,
        again, with connectors being used to ensure =
atomicity.

      - Bob signs; Alice signs and broadcasts.

      - Carol can settle her HTLC by either revealing the secret onchain
        or by trading her commitment containing the HTLC clause for a
        commitment from Alice that doesn't contain the clause (which
        Alice will only accept by learning the secret, since Alice has
        to settle with Bob).  Alice can then either settle onchain or
        trade commitments with Bob after giving him the secret.

- *Do nothing for 4 weeks:* if Bob does nothing for four weeks, Alice
   can claim the funds from the commitment output (i.e., takes his
   money).

     If Bob did actually do something, and if every other user =
who also
     had an unpublished output in the commitment transaction did
     something, then they all exchanged their portion of the funds in
     this output to Alice, so Alice can now claim all of those funds
     onchain in a highly efficient manner.

Regarding the connector outputs=
, although all of the examples above show
Alice directly spending from the =
connector output in Bob's deposit
transaction, atomicity is also ensured if=
 Alice spends from any output
descended from Bob's connector output.  =
Connector outputs from different
deposits can be used as inputs into the =
same transaction, merging their
histories.  This allows all operations made=
 by Alice to be fully atomic,
ensuring that she doesn't lose any money =
during a reorg of any length.

Users are not so well protected during =
reorgs, e.g. if Bob double-spends
a transaction whose funds were later used=
 in a payment to Carol, then
Carol loses the money.  For this reason, Alice=
 will probably want to
prove to users that no funds they receive in a =
payment derive from any
deposit less than safe_confirmation_depth blocks.

[1] https://twitter.com/roasbeef/status/1661266771784126464

[2]=20
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021710.=
html

[3]=20
https://min.sc/#c=3Dpk%28B%29%20%26%26%20%28older%281%20day%29=
%20%7C%7C%20pk%28A%29%29
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
</pre>
</blockquote>