Date: Thu, 25 May 2023 12:12:43 +0000
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
Cc: "burak@buraks.blog" <burak@buraks.blog>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second
	Layer Solution
Precedence: list

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