path: root/39/abbc36c75568986e400fd48b50540e673c95dc

Return-Path: <ecurrencyhodler@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 39B1AC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 May 2023 16:07:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 14A2283AAD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 May 2023 16:07:14 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 14A2283AAD
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=Oe6XWv+j
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
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 Z2ZCQRBGBlkA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 May 2023 16:07:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8575483A9E
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
 [IPv6:2a00:1450:4864:20::22a])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 8575483A9E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 May 2023 16:07:11 +0000 (UTC)
Received: by mail-lj1-x22a.google.com with SMTP id
 38308e7fff4ca-2afb2874e83so8486121fa.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 May 2023 09:07:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1685030829; x=1687622829;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=Y3dJpoSEf25O8mHSnAO3XgHybLUQCqMYFNyu0gw8AQA=;
 b=Oe6XWv+j1ZOEUdHVR1ggUSbOP5v1bRueE/hEOKbAsbwnf6U94lYqUqtCwDpcMcBTkR
 ndau2rClB62+IzIgErXNmbOOddbjFhiSCJ2IM4PSYQGap2TRID9llJA8DZ7Xw5mbLq0H
 H8LayuwFy+mpPTbqBmTdZyBU0GczCzlLBwgDQWDuXONkPG9gW+wYGYbz40crHSBuMw3o
 kYe9E3Ydo3A1zhI+AtWxC3R9MdYOtUAqPSPZtTSvqGZHZOj6gShCeJ6+q3a1xnnGpsXn
 MAhhtNczaLv8n1BKaLBuImoRuQ+kOkwnF601E7OLmTzqg62SSt1btLDtr8tN3NSR4eTn
 MWag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1685030829; x=1687622829;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=Y3dJpoSEf25O8mHSnAO3XgHybLUQCqMYFNyu0gw8AQA=;
 b=eIergTkacQpxONi0FQSgPldrB2BYtM568Qg6bOxbW1gpQwbySI+GReuoYEtZeG9AHz
 voJGniEN+iN+NIk9qhE3lej6LpSrxYDqmrorjo55Lsn60wXzS/xNQYymR/1O2SXlpsRz
 Hb3VXZPHWVy9Pc0x7shjhs9TRUbHJTHL6k2EBRSlRKgEaX9QgETdm0o+WmdZpjXeg1rk
 aO2sfBUJkDVdFcZlCtup11yOO9mZ09/3tdOj7K6cDWzEA93bJ/aa9sjc8PYKYcGwAoh2
 0OeAD2ZK2dW5K2hHLSWzF0tPBW3mTVTE4zBDOPH7iMl9eYpYZ7TtXCrBgfN21uLw9YbL
 3gvg==
X-Gm-Message-State: AC+VfDyoE1UfuPtmxOj0cH24qwn8cqwcJXoG6xHI+z7WImuYyhQ4vgaf
 /R8oxF8QMuDR3Q3F+d1Tist3o8e+KmjOoQlDU3E9bVOAUFQ=
X-Google-Smtp-Source: ACHHUZ467JO2RsWr6qpqo8lqaK84HGkR1/PFx9cC46FXEPOhw7zb/a+n5x+M+OGMH5AANHurJvg5PEWowC/DtoOZjBo=
X-Received: by 2002:a05:651c:144:b0:2ad:275a:44b6 with SMTP id
 c4-20020a05651c014400b002ad275a44b6mr1075695ljd.52.1685030828334; Thu, 25 May
 2023 09:07:08 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.17.1685016003.20381.bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.17.1685016003.20381.bitcoin-dev@lists.linuxfoundation.org>
From: ecurrencyhodler <ecurrencyhodler@gmail.com>
Date: Thu, 25 May 2023 09:06:31 -0700
Message-ID: <CAKFmrWM7DXEnsSg0FWbwFR8GUhky+xDE+SsOFeF=O7LsqnT0xQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000f5646c05fc86cf30"
X-Mailman-Approved-At: Thu, 25 May 2023 17:06:10 +0000
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 96, Issue 58
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: Thu, 25 May 2023 16:07:14 -0000

--000000000000f5646c05fc86cf30
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Date: Wed, 24 May 2023
From: ecurrencyhodler<ecurrencyhodler@gmail.com>
To: Bitcoin Protocol Discussion
        <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving
        Second  Layer Solution (ecurrencyhodler)

Thanks David for your write up. Clear, concise, and super understandable as
always.

It sounds like to me that ARK is using PSBT's + covenants to secure
unconfirmed txns.

I see how this significantly reduces onchain footprint. But wouldn't this
also have a massive impact at scale to the mempool filling it with
unconfirmed txns? Couple concerns I have are:

   1. It would create an ever growing fee environment within the 10-minute
   block. Therefore it would be possible for the first settlement txn in th=
e
   first 5 seconds to get pushed out of the mempool by later settlement txn=
s
   closer to the 10 minute mark.
   2. Mempools would have to drastically increase their size to capture all
   the 5-second settlement unconfirmed txns and default bitcoin core nodes
   would get flooded.

Thanks again burak for your ARK proposal. There seems to be a good amount
of excitement about what this could unlock in the future which is quite
refreshing to see.

On Thu, May 25, 2023 at 5:01=E2=80=AFAM <
bitcoin-dev-request@lists.linuxfoundation.org> wrote:

> Send bitcoin-dev mailing list submissions to
>         bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
>         bitcoin-dev-request@lists.linuxfoundation.org
>
> You can reach the person managing the list at
>         bitcoin-dev-owner@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Ark: An Alternative Privacy-preserving Second Layer
>       Solution (adiabat)
>    2. Re: Ark: An Alternative Privacy-preserving Second Layer
>       Solution (David A. Harding)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 24 May 2023 16:20:35 -0400
> From: adiabat <rx@awsomnet.org>
> To: Bitcoin Protocol Discussion
>         <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving
>         Second  Layer Solution
> Message-ID:
>         <CAKEeUhg1qeZOv-Lk8SSTxdkgfSee_E6_4fwNV=3D
> hfwsxLgwWkUw@mail.gmail.com>
> Content-Type: text/plain; charset=3D"UTF-8"
>
> Hi - thanks for the Ark write up; I have a bunch of questions but here's =
2:
>
> ---
> Q1:
> "Pool transactions are created by ark service providers perpetually
> every 5 seconds"
>
> What exactly happens every 5 seconds?  From the 15.44.21-p-1080.png
> diagram [1], a pool transaction is a bitcoin transaction, with all the
> inputs coming from the ASP.  My understanding is that every 5 seconds,
> we progress from PoolTx(N) to PoolTx(N+1).  Does the ASP sign a new
> transaction which spends the same ASP funding inputs as the previous
> pool transaction, which is a double spend or fee bump?  Or does it
> spend the outputs from the previous PoolTx?
>
> In other words, does PoolTx(2) replace PoolTx(1) RBF-style, spending
> the same inputs (call this method A), or does PoolTx(2) spend an
> output Of Pooltx(1) such that PoolTx(1) must be confirmed in order for
> PoolTx(2) to become valid (method B)?  Or are they completely separate
> transactions with unconflicting inputs (method C)?
>
> When the ASP creates a pool transaction, what do they do with it?  Do
> they broadcast it to the gossip network?  Or share it with other pool
> participants?
>
> With method A, if the ASP shares pool transactions with other people,
> there Doesn't seem to be any way to ensure which PoolTx gets
> confirmed, invalidating all the other ones.  They're all valid so
> whichever gets into a block first wins.
>
> With method B, there seems to be a large on-chain load, with ~120
> chained transactions trying to get in every block. This wouldn't play
> nicely with mempool standardness and doesn't seem like you could ever
> "catch up".
>
> With method C, ASPs would need a pretty large number of inputs but
> could recycle them as blocks confirm.  It would cost a lot but maybe
> could work.
>
> ---
> Q2:
>
> The other part I'm missing is: what prevents the ASP from taking all
> the money?  Before even getting to vTXOs and connector outputs, from
> the diagram there are only ASP inputs funding the pool transaction.
> If the pool transaction is confirmed, the vTXOs are locked in place,
> since the vTXO output cannot be changed and commits to all
> "constrained outs" via OP_CTV.  If the pool transaction is
> unconfirmed, the ASP can create & sign a transaction spending all ASP
> funding inputs sending the money back to the ASP, or anywhere else.
> In this case, users don't have any assurance that their vTXO can ever
> turn into a real UTXO; the ASP can "rug-pull" at any time, taking all
> the money in the pool.  Adding other inputs not controlled by the ASP
> to the transaction wouldn't seem to fix the problem, because then any
> user removing their inputs would cancel the whole transaction.
>
> More detail about how these transactions work would be appreciated, thank=
s!
>
> -Tadge
>
> [1]
> https://uploads-ssl.webflow.com/645ae2e299ba34372614141d/6467d1f1bf91e0bf=
2c2eddef_Screen%20Shot%202023-05-19%20at%2015.44.21-p-1080.png
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 24 May 2023 13:02:40 -1000
> From: "David A. Harding" <dave@dtrt.org>
> To: Burak Keceli <burak@buraks.blog>, Bitcoin Protocol Discussion
>         <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving
>         Second Layer Solution
> Message-ID: <3c6c3b8b562bb56bbb855dc2b2b71f78@dtrt.org>
> Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed
>
> 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) && (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
> 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
> 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]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021710.h=
tml
>
> [3]
>
> https://min.sc/#c=3Dpk%28B%29%20%26%26%20%28older%281%20day%29%20%7C%7C%2=
0pk%28A%29%29
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 96, Issue 58
> *******************************************
>

--000000000000f5646c05fc86cf30
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Date: Wed, 24 May 2023=C2=A0<br>From: ecurrencyhodler=
&lt;<a href=3D"mailto:ecurrencyhodler@gmail.com">ecurrencyhodler@gmail.com<=
/a>&gt;<br>To: Bitcoin Protocol Discussion<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt;<br>Subject: Re: [bitcoin-dev] Ark: An Altern=
ative Privacy-preserving<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Second =C2=A0Layer =
Solution (ecurrencyhodler)<br></div><div><br></div><div>Thanks David for yo=
ur write up. Clear, concise, and super understandable as always.</div><div>=
<br></div><div>It sounds like to me that ARK is using PSBT&#39;s=C2=A0+ cov=
enants to secure unconfirmed txns.=C2=A0</div><div><br></div><div>I see how=
 this significantly reduces onchain footprint. But wouldn&#39;t this also h=
ave a massive impact at scale to the mempool filling it with unconfirmed tx=
ns? Couple concerns I have are:</div><div><ol><li>It would create an ever g=
rowing fee environment within the 10-minute block. Therefore it would be po=
ssible for the first settlement txn in the first 5 seconds to get pushed ou=
t of the mempool by later settlement txns closer to the 10 minute mark.=C2=
=A0</li><li>Mempools would have to drastically increase their size to captu=
re all the 5-second settlement unconfirmed txns and default bitcoin core no=
des would get flooded.</li></ol><div>Thanks again burak for your ARK propos=
al. There seems to be a good amount of excitement about what this could unl=
ock in the future which is quite refreshing to see.</div></div></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, May =
25, 2023 at 5:01=E2=80=AFAM &lt;<a href=3D"mailto:bitcoin-dev-request@lists=
.linuxfoundation.org">bitcoin-dev-request@lists.linuxfoundation.org</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send bit=
coin-dev mailing list submissions to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-request@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev-request@lists.linuxfoundati=
on.org</a><br>
<br>
You can reach the person managing the list at<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-owner@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev-owner@lists.linuxfoundation.o=
rg</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of bitcoin-dev digest...&quot;<br>
<br>
<br>
Today&#39;s Topics:<br>
<br>
=C2=A0 =C2=A01. Re: Ark: An Alternative Privacy-preserving Second Layer<br>
=C2=A0 =C2=A0 =C2=A0 Solution (adiabat)<br>
=C2=A0 =C2=A02. Re: Ark: An Alternative Privacy-preserving Second Layer<br>
=C2=A0 =C2=A0 =C2=A0 Solution (David A. Harding)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 24 May 2023 16:20:35 -0400<br>
From: adiabat &lt;<a href=3D"mailto:rx@awsomnet.org" target=3D"_blank">rx@a=
wsomnet.org</a>&gt;<br>
To: Bitcoin Protocol Discussion<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;<br>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Second=C2=A0 Layer Solution<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;CAKEeUhg1qeZOv-Lk8SSTxdkgfSee_E6_4fwNV=3D<a=
 href=3D"mailto:hfwsxLgwWkUw@mail.gmail.com" target=3D"_blank">hfwsxLgwWkUw=
@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;UTF-8&quot;<br>
<br>
Hi - thanks for the Ark write up; I have a bunch of questions but here&#39;=
s 2:<br>
<br>
---<br>
Q1:<br>
&quot;Pool transactions are created by ark service providers perpetually<br=
>
every 5 seconds&quot;<br>
<br>
What exactly happens every 5 seconds?=C2=A0 From the 15.44.21-p-1080.png<br=
>
diagram [1], a pool transaction is a bitcoin transaction, with all the<br>
inputs coming from the ASP.=C2=A0 My understanding is that every 5 seconds,=
<br>
we progress from PoolTx(N) to PoolTx(N+1).=C2=A0 Does the ASP sign a new<br=
>
transaction which spends the same ASP funding inputs as the previous<br>
pool transaction, which is a double spend or fee bump?=C2=A0 Or does it<br>
spend the outputs from the previous PoolTx?<br>
<br>
In other words, does PoolTx(2) replace PoolTx(1) RBF-style, spending<br>
the same inputs (call this method A), or does PoolTx(2) spend an<br>
output Of Pooltx(1) such that PoolTx(1) must be confirmed in order for<br>
PoolTx(2) to become valid (method B)?=C2=A0 Or are they completely separate=
<br>
transactions with unconflicting inputs (method C)?<br>
<br>
When the ASP creates a pool transaction, what do they do with it?=C2=A0 Do<=
br>
they broadcast it to the gossip network?=C2=A0 Or share it with other pool<=
br>
participants?<br>
<br>
With method A, if the ASP shares pool transactions with other people,<br>
there Doesn&#39;t seem to be any way to ensure which PoolTx gets<br>
confirmed, invalidating all the other ones.=C2=A0 They&#39;re all valid so<=
br>
whichever gets into a block first wins.<br>
<br>
With method B, there seems to be a large on-chain load, with ~120<br>
chained transactions trying to get in every block. This wouldn&#39;t play<b=
r>
nicely with mempool standardness and doesn&#39;t seem like you could ever<b=
r>
&quot;catch up&quot;.<br>
<br>
With method C, ASPs would need a pretty large number of inputs but<br>
could recycle them as blocks confirm.=C2=A0 It would cost a lot but maybe<b=
r>
could work.<br>
<br>
---<br>
Q2:<br>
<br>
The other part I&#39;m missing is: what prevents the ASP from taking all<br=
>
the money?=C2=A0 Before even getting to vTXOs and connector outputs, from<b=
r>
the diagram there are only ASP inputs funding the pool transaction.<br>
If the pool transaction is confirmed, the vTXOs are locked in place,<br>
since the vTXO output cannot be changed and commits to all<br>
&quot;constrained outs&quot; via OP_CTV.=C2=A0 If the pool transaction is<b=
r>
unconfirmed, the ASP can create &amp; sign a transaction spending all ASP<b=
r>
funding inputs sending the money back to the ASP, or anywhere else.<br>
In this case, users don&#39;t have any assurance that their vTXO can ever<b=
r>
turn into a real UTXO; the ASP can &quot;rug-pull&quot; at any time, taking=
 all<br>
the money in the pool.=C2=A0 Adding other inputs not controlled by the ASP<=
br>
to the transaction wouldn&#39;t seem to fix the problem, because then any<b=
r>
user removing their inputs would cancel the whole transaction.<br>
<br>
More detail about how these transactions work would be appreciated, thanks!=
<br>
<br>
-Tadge<br>
<br>
[1] <a href=3D"https://uploads-ssl.webflow.com/645ae2e299ba34372614141d/646=
7d1f1bf91e0bf2c2eddef_Screen%20Shot%202023-05-19%20at%2015.44.21-p-1080.png=
" rel=3D"noreferrer" target=3D"_blank">https://uploads-ssl.webflow.com/645a=
e2e299ba34372614141d/6467d1f1bf91e0bf2c2eddef_Screen%20Shot%202023-05-19%20=
at%2015.44.21-p-1080.png</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 24 May 2023 13:02:40 -1000<br>
From: &quot;David A. Harding&quot; &lt;<a href=3D"mailto:dave@dtrt.org" tar=
get=3D"_blank">dave@dtrt.org</a>&gt;<br>
To: Burak Keceli &lt;burak@buraks.blog&gt;, Bitcoin Protocol Discussion<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;<br>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Second Layer Solution<br>
Message-ID: &lt;<a href=3D"mailto:3c6c3b8b562bb56bbb855dc2b2b71f78@dtrt.org=
" target=3D"_blank">3c6c3b8b562bb56bbb855dc2b2b71f78@dtrt.org</a>&gt;<br>
Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed<br>
<br>
Hi Burak,<br>
<br>
Thanks for this really interesting protocol!=C2=A0 I tend to analyze<br>
complicated ideas like this by writing about them in my own words, so<br>
I&#39;ve pasted my summary of your idea to the end of this email in case<br=
>
it&#39;s useful, either to other people or to you in helping understand my<=
br>
one concern.<br>
<br>
My concern is the same one I think Olaoluwa Osuntokun mentioned on<br>
Twitter[1] and (less clear to me) might be related to ZmnSCPxj&#39;s<br>
concern[2]:<br>
<br>
It seems to me that receiving a payment on the protocol, including<br>
conditional payments using HTLC, PTLC, or Anchor-TLC, requires waiting<br>
for the transaction containing that payment to confirm to a sufficient<br>
depth (e.g., I&#39;d wait 6 blocks for small payments and longer for huge<b=
r>
payments).=C2=A0 Am I missing something?<br>
<br>
My summary of how I think that part of the protocol works is in the<br>
sections labeled &quot;Make an unconditioned payment&quot; and &quot;Make a=
 conditional<br>
payment&quot; below.=C2=A0 In short, it&#39;s clear to me how the service p=
rovider and<br>
the customer can make instant atomic swaps with each other---they can<br>
either spend instantly cooperatively, or they have to wait for a<br>
timeout.=C2=A0 But how can a receiver of funds be assured that they will<br=
>
actually get those funds unless there&#39;s already a timelock and<br>
cooperative spend path placed on those funds?<br>
<br>
-Dave<br>
<br>
Rough initial summary of Ark protocol:<br>
<br>
Alice runs an Ark service provider.=C2=A0 Every 5 seconds, she broadcasts a=
<br>
new unconfirmed onchain transaction that pays three outputs (the<br>
three Cs):<br>
<br>
1. *Change Output:* money not used for the other two Cs that gets sent<br>
=C2=A0 =C2=A0 back to the the transaction creator.<br>
<br>
2. *Connector Output:* an output that will be used in a future<br>
=C2=A0 =C2=A0 transaction created by Alice as protection against double spe=
nds.<br>
<br>
3. *Commitment Output:* a CTV-style commitment to a set of outputs that<br>
=C2=A0 =C2=A0 can be published later in a descendant transaction (alternati=
vely,<br>
=C2=A0 =C2=A0 the commitment output may be spent unilaterally by Alice afte=
r 4<br>
=C2=A0 =C2=A0 weeks).<br>
<br>
Bob wants to deposit 1 BTC with Alice.=C2=A0 He sends her an unsigned PSBT<=
br>
with an input of his and a change output.=C2=A0 She updates the PSBT with a=
<br>
commitment output that refunds Bob the 1 BTC and a connector output with<br=
>
some minimum value.=C2=A0 They both sign the PBST and it is broadcast.=C2=
=A0 We&#39;ll<br>
ignore fees in our examples, both onchain transaction fees and fees paid<br=
>
to Alice.<br>
<br>
=C2=A0From here, there are several things that Bob can do:<br>
<br>
- *Unilaterally withdraw:* Bob can spend from the commitment output to<br>
=C2=A0 =C2=A0put his refund onchain.=C2=A0 The refund can only be spent aft=
er a 24-hour<br>
=C2=A0 =C2=A0time delay, allowing Bob to optionally come to an agreement wi=
th Alice<br>
=C2=A0 =C2=A0about how to spend the funds before Bob can spend them unilate=
rally<br>
=C2=A0 =C2=A0(as we&#39;ll see in a moment).=C2=A0 For example, the script =
might be[3]:<br>
<br>
=C2=A0 =C2=A0 =C2=A0pk(B) &amp;&amp; (older(1 day) || pk(A))<br>
<br>
- *Collaboratively withdraw:* as seen above, Bob has the ability to come<br=
>
=C2=A0 =C2=A0to a trustless agreement with Alice about how to spend his fun=
ds.<br>
=C2=A0 =C2=A0They can use that ability to allow Bob to trade his (unpublish=
ed) UTXO<br>
=C2=A0 =C2=A0for a UTXO that Alice funds and broadcasts.=C2=A0 For example:=
<br>
<br>
=C2=A0 =C2=A0 =C2=A0- Alice creates an unsigned PSBT that uses as one of it=
s inputs the<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0connector from Bob&#39;s deposit transaction.=C2=
=A0 This will ensure that<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0any attempt by Bob to double-spend his deposit t=
ransaction will<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0invalidate this withdrawal transaction, preventi=
ng Bob from being<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0able to steal any of Alice&#39;s funds.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Also included in Alice&#39;s unsigned PSB=
T is another connector<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0output plus the output that pays Bob his =
1 BTC.<br>
<br>
=C2=A0 =C2=A0 =C2=A0- Bob receives Alice&#39;s unsigned PSBT and creates a =
separate PSBT<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0that includes his unpublished UTXO as an input, =
giving its value<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0to Alice in an output.=C2=A0 The PSBT also inclu=
des as an input the<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0connector output from Alice&#39;s PSBT.=C2=A0 Th=
is will ensure that any<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0attempt by Alice to double spend her transaction=
 paying him will<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0invalidate his transaction paying her.<br>
<br>
=C2=A0 =C2=A0 =C2=A0- Bob signs his PSBT and gives it to Alice.=C2=A0 After=
 verifying it,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0Alice signs her PSBT and broadcasts it.<br>
<br>
- *Collaboratively trade commitments:* as mentioned, the commitment<br>
=C2=A0 =C2=A0output that pays Bob may be claimed instead by Alice after 4 w=
eeks, so<br>
=C2=A0 =C2=A0Bob will need to either withdraw or obtain a new commitment wi=
thin <br>
that<br>
=C2=A0 =C2=A0time.=C2=A0 To trade his existing commitment for a new commitm=
ent looks<br>
=C2=A0 =C2=A0similar to the collaborative withdrawal procedure but without =
the<br>
=C2=A0 =C2=A0creation of an immediately-spendable onchain output:<br>
<br>
=C2=A0 =C2=A0 =C2=A0- Alice creates an unsigned PSBT that uses as one of it=
s inputs the<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0connector from Bob&#39;s deposit transaction, ag=
ain preventing double<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0spending by Bob.=C2=A0 Alice also includes a new=
 connector and a new<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0commitment that again allows Bob to later claim =
1 BTC.<br>
<br>
=C2=A0 =C2=A0 =C2=A0- Bob receives Alice&#39;s PSBT and creates a PSBT tran=
sferring his<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0existing commitment to her, with the new connect=
or again being<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0included as an input to ensure atomicity.<br>
<br>
=C2=A0 =C2=A0 =C2=A0- Bob signs; Alice signs and broadcasts.<br>
<br>
- *Make an unconditioned payment:* using the mechanisms described above,<br=
>
=C2=A0 =C2=A0it&#39;s possible to make either an onchain payment or an offc=
hain<br>
=C2=A0 =C2=A0payment---just have Carol receive the new output or commitment=
 rather<br>
=C2=A0 =C2=A0than Bob.=C2=A0 That payment would have no conditions (except =
its<br>
=C2=A0 =C2=A0atomicity).<br>
<br>
- *Make a conditional payment:* imagine that Carol knows a secret (e.g.<br>
=C2=A0 =C2=A0a preimage) that Bob is willing to pay for.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 - Alice creates an unsigned PSBT depending on the conn=
ector from<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bob&#39;s deposit transaction and creating a ne=
w connector.=C2=A0 The PSBT<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 includes an output paying Carol (either onchain=
 or via a<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 commitment) with an HTLC, allowing Carol to cla=
im the funds if <br>
she<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reveals the secret or allowing Bob to claim the=
 funds after a<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 timeout.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 - Bob receives Alice&#39;s PSBT and creates a PSBT tra=
nsferring his<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 existing commitment to her with the HTLC condit=
ion attached and,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 again, with connectors being used to ensure ato=
micity.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 - Bob signs; Alice signs and broadcasts.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 - Carol can settle her HTLC by either revealing the se=
cret onchain<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 or by trading her commitment containing the HTL=
C clause for a<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 commitment from Alice that doesn&#39;t contain =
the clause (which<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alice will only accept by learning the secret, =
since Alice has<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to settle with Bob).=C2=A0 Alice can then eithe=
r settle onchain or<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 trade commitments with Bob after giving him the=
 secret.<br>
<br>
- *Do nothing for 4 weeks:* if Bob does nothing for four weeks, Alice<br>
=C2=A0 =C2=A0can claim the funds from the commitment output (i.e., takes hi=
s<br>
=C2=A0 =C2=A0money).<br>
<br>
=C2=A0 =C2=A0 =C2=A0If Bob did actually do something, and if every other us=
er who also<br>
=C2=A0 =C2=A0 =C2=A0had an unpublished output in the commitment transaction=
 did<br>
=C2=A0 =C2=A0 =C2=A0something, then they all exchanged their portion of the=
 funds in<br>
=C2=A0 =C2=A0 =C2=A0this output to Alice, so Alice can now claim all of tho=
se funds<br>
=C2=A0 =C2=A0 =C2=A0onchain in a highly efficient manner.<br>
<br>
Regarding the connector outputs, although all of the examples above show<br=
>
Alice directly spending from the connector output in Bob&#39;s deposit<br>
transaction, atomicity is also ensured if Alice spends from any output<br>
descended from Bob&#39;s connector output.=C2=A0 Connector outputs from dif=
ferent<br>
deposits can be used as inputs into the same transaction, merging their<br>
histories.=C2=A0 This allows all operations made by Alice to be fully atomi=
c,<br>
ensuring that she doesn&#39;t lose any money during a reorg of any length.<=
br>
<br>
Users are not so well protected during reorgs, e.g. if Bob double-spends<br=
>
a transaction whose funds were later used in a payment to Carol, then<br>
Carol loses the money.=C2=A0 For this reason, Alice will probably want to<b=
r>
prove to users that no funds they receive in a payment derive from any<br>
deposit less than safe_confirmation_depth blocks.<br>
<br>
[1] <a href=3D"https://twitter.com/roasbeef/status/1661266771784126464" rel=
=3D"noreferrer" target=3D"_blank">https://twitter.com/roasbeef/status/16612=
66771784126464</a><br>
<br>
[2] <br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May=
/021710.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfound=
ation.org/pipermail/bitcoin-dev/2023-May/021710.html</a><br>
<br>
[3] <br>
<a href=3D"https://min.sc/#c=3Dpk%28B%29%20%26%26%20%28older%281%20day%29%2=
0%7C%7C%20pk%28A%29%29" rel=3D"noreferrer" target=3D"_blank">https://min.sc=
/#c=3Dpk%28B%29%20%26%26%20%28older%281%20day%29%20%7C%7C%20pk%28A%29%29</a=
><br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of bitcoin-dev Digest, Vol 96, Issue 58<br>
*******************************************<br>
</blockquote></div>

--000000000000f5646c05fc86cf30--