Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution

From: "G. Andrew Stone" <[email-masked]>
Date: Tue, 23 May 2023 18:06:02 -0400

Do you have any write up that presents a fully detailed architecture,
including mechanisms like bitcoin scripts, transactions and L2 protocols,
and then derives claims from that base?

On Tue, May 23, 2023, 5:59 AM Burak Keceli via bitcoin-dev <
[email-masked]> wrote:

> > As the access to Lightning is also by the (same?) ASP, it seems to me
> that the ASP will simply fail to forward the payment on the broader
> Lightning network after it has replaced the in-mempool transaction,
> preventing recipients from actually being able to rely on any received
> funds existing until the next pool transaction is confirmed.
>
> Yes, that's correct. Lightning payments are routed through ASPs. ASP may
> not cooperate in forwarding HTLC(s) AFTER double-spending their pool
> transaction. However, it's a footgun if ASP forwards HTLC(s) BEFORE
> double-spending their pool transaction.
>
> What makes Ark magical is, in the collaborative case, users' ability to
> pay lightning invoices with their zero-conf vTXOs, without waiting for
> on-chain confirmations.
>
> This is the opposite of swap-ins, where users SHOULD wait for on-chain
> confirmations before revealing their preimage of the HODL invoice;
> otherwise, the swap service provider can steal users' sats by
> double-spending their zero-conf HTLC.
> _______________________________________________
> bitcoin-dev mailing list
> [email-masked]
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>