path: root/0d/43229f75fcd9860afd9ad2b4a064f8fa3c20a4

Return-Path: <ali@notatether.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0A643C002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 May 2023 12:13:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id D9BB5403BE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 May 2023 12:13:05 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org D9BB5403BE
Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=notatether.com header.i=@notatether.com
 header.a=rsa-sha256 header.s=protonmail2 header.b=MXq758M+
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 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, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id pDZjIRC-f4ht
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 May 2023 12:13:04 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org ADA00400EA
Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17])
 by smtp2.osuosl.org (Postfix) with ESMTPS id ADA00400EA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 25 May 2023 12:13:02 +0000 (UTC)
Date: Thu, 25 May 2023 12:12:43 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=notatether.com;
 s=protonmail2; t=1685016779; x=1685275979;
 bh=s2jqSGQW2YGaWszwmacxsmXmqQx4wnqTqH+gkw6depQ=;
 h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
 Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector;
 b=MXq758M+dC9Hr4AOrqIBVVV3nsvvvdCrCCFb8MpZ16iuy2/+yIi8uMz/ZavRpxFhZ
 rVC0OfAPk7ugQC05+4ibfL6zJqAvHssk3YVrrR4gc25nAwNH/AdpQSbCC/ecYo8FfT
 GoRyMdgbeq3jOcZA+lAFV4Q2vP2slJzrfvsLE8RxmqRrZlb/a46vERxW+0+MBriAzE
 hqLQjrxRV7aanZPUi63JhH2Hktw0KIohGZ3sfG8SY9E7elHKPjuzT0C7WL3/NZdtku
 A/0BnVLZvbe27g6CUhovtHvVZE0Onq1px54NtZboRnZ0ko/42f0dY5gF5IT6zA2/s2
 vT7I8ee/uHJxw==
To: bitcoin-dev@lists.linuxfoundation.org, "dave@dtrt.org" <dave@dtrt.org>
From: Ali Sherief <ali@notatether.com>
Message-ID: <11jyozmsQwMq3eZnXuk_yHlUkxmsTolMdfK-CKRe1cPGCbWsp7JGow2xPKGawJGMIz53BpVdUsYiW612NAdSxf9LV4U4K8YR6v296Woad8g=@notatether.com>
Feedback-ID: 34210769:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 25 May 2023 15:06:03 +0000
Cc: "burak@buraks.blog" <burak@buraks.blog>
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: Thu, 25 May 2023 12:13:06 -0000

Regarding this:

> 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.

I'm of the opinion that any L2 protocol having a similar concept of block m=
ining but for L2 transactions is a pretty good idea, but the reorgs trapdoo=
r you mentioned could theoretically be mitigated ARK nodes considering thei=
r settling transactions on L1 as final after say, 3 blocks, or maybe even 6=
 blocks.

I'm leaning towards the standard 6 blocks, as this delay is invisible to us=
ers anyway, and only node operators will really notice it.

It is kind of the same way how miners can't spend coinbase transactions for=
 100 blocks.

It's a pretty good idea from Burak though, and I can't wait to see nodes in=
 action with this.

- Ali

> Hi Burak,
>=20
> 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.
>=20
> 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]:
>=20
> 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?
>=20
> 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?
>=20
> -Dave
>=20
> Rough initial summary of Ark protocol:
>=20
> Alice runs an Ark service provider. Every 5 seconds, she broadcasts a
> new unconfirmed onchain transaction that pays three outputs (the
> three Cs):
>=20
> 1. Change Output: money not used for the other two Cs that gets sent
> back to the the transaction creator.
>=20
> 2. Connector Output: an output that will be used in a future
> transaction created by Alice as protection against double spends.
>=20
> 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).
>=20
> 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.
>=20
> From here, there are several things that Bob can do:
>=20
> - 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]:
>=20
> pk(B) && (older(1 day) || pk(A))
>=20
> - 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:
>=20
> - 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.
>=20
> Also included in Alice's unsigned PSBT is another connector
> output plus the output that pays Bob his 1 BTC.
>=20
> - 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.
>=20
> - Bob signs his PSBT and gives it to Alice. After verifying it,
> Alice signs her PSBT and broadcasts it.
>=20
> - 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:
>=20
> - 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.
>=20
> - 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.
>=20
> - Bob signs; Alice signs and broadcasts.
>=20
> - 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).
>=20
> - Make a conditional payment: imagine that Carol knows a secret (e.g.
> a preimage) that Bob is willing to pay for.
>=20
> - 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.
>=20
> - 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.
>=20
> - Bob signs; Alice signs and broadcasts.
>=20
> - 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.
>=20
> - 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).
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> [1] https://twitter.com/roasbeef/status/1661266771784126464
>=20
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021710.h=
tml
>=20
> [3]
> https://min.sc/#c=3Dpk(B) %26%26 (older(1 day) || pk(A))