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

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

[Burak Keceli]

[-- Attachment #1: Type: text/plain, Size: 9248 bytes --]

Hi list,
I'm excited to publicly publish a new second-layer protocol design I've been working on over the past few months called Ark.
 
Ark is an alternative second-layer scaling approach that allows the protocol users to send and receive funds without introducing liquidity constraints. This means a recipient can get paid without an onboarding setup, such as acquiring inbound liquidity. The protocol also consumes orders of magnitude less on-chain footprint than Lightning, as there is no concept of opening and closing channels.
 
Ark has a UTXO set that lives off the chain. These UTXOs are referred to as virtual UTXOs or vTXOs in short. Virtual UTXOs are like short-lived notes that expire after four weeks. Users must spend their vTXOs upon receiving them within this four-week timeframe or return them to themselves to reset the four-week timer. Virtual UTXOs live under a shared UTXO and can be revealed on-chain.
 
When a payment is made on the protocol, existing vTXOs are redeemed, and new vTXOs are created, similar to how on-chain funds flow. To improve the anonymity set of the coin ownership, vTXOs values are restricted to a set of sats values ranging from one sat to a million sats.
 
Users can acquire vTXOs from someone who already owns them or use a process called lifting, an atomic two-way peg mechanism that doesn't require trust. Lifting lets users lift their on-chain UTXOs off the chain for a 1:1 virtual UTXO. Users can unilaterally redeem a virtual UTXO for an on-chain UTXO without asking for cooperation. 
 
When sending funds, users coin-select & destroy their virtual UTXOs and create new ones for the recipient (plus change) in an off-chain mixing round. Keys for each new virtual UTXO are tweaked with a shared secret that reveals proof of payment when spent. The payment destination is a dedicated well-known public key similar to silent payments; however, the payment trace is obfuscated through plain tweaking and blinded mixing.
 
Ark enables anonymous, off-chain payments through an untrusted intermediary called the Ark Service Provider (ASP). ASPs are always-on servers that provide liquidity to the network and charge liquidity fees, similar to how Lightning service providers work. ASPs on Ark are both (1) liquidity providers, (2) blinded coinjoin coordinators, and (3) Lightning service providers. ASPs main job is to create rapid, blinded coinjoin sessions every five seconds, also known as pools. A user joins a pool session to make a payment, initially coin-selecting and registering their vTXOs to spend, registering vTXOs for intended recipients, and finally co-signing from their vTXOs to redeem them.
 
Ark can be built on Bitcoin today, but we have to compromise on non-interactivity to do so. Recipients must be online to sign from n-of-n multisig to constrain the outputs of a shared UTXO, outputs as in vTXOs. With this approach, users won’t be able to receive offline payments; they need to self-host an Ark client (like Lightning). To make Ark work without running a server, we need a covenant primitive such as BIP-118 or BIP-119. 
 
BIP-118 ANYPREVOUTANYSCRIPT can constrain outputs of a spending transaction by hardcoding a 65-byte signature and a 33-byte unknown public key type in a script. Alternatively, BIP-119 CTV can directly constrain transaction outputs to a template hash. Other alternatives would be (1) TXHASH, (2) CAT + CSFS + TAGGEDHASH, or (3) XOR + CSFS + TAGGEDHASH combinations. 
 
Ark uses a new locktype primitive called txlock to ensure the absolute atomicity of a transfer schedule. Txlock is a condition in which only the existence of a mutually agreed transaction identifier can unlock the condition. A txlock condition could be satisfied by a hypothetical opcode called OP_CHECKPREVTXIDFROMTHEUTXOSETVERIFY. However, Ark uses an alternative approach to achieving the same outcome using connectors. Connectors are a special output type on the protocol. The primitive is that if we want the Bitcoin script to check if a particular transaction id exists, we simply attach an output from that transaction into our spending transaction and check a pre-signed signature against prevouts of our spending transaction. The connector outpoint in the sighash preimage commits to the transaction id for which we want to satisfy the txlock condition. In the Ark context, this is the pool transaction containing vTXOs of intended recipients. Txlocks are used in Anchor Time Locked Contracts (ATLCs) to provide an atomic single-hub payment schedule.
 
Anchor Time Locked Contracts (ATLCs) are conditional payments used on the Ark protocol. When a vTXO was created in the first place, an ATLC was attached to it, similar to how an eltoo:trigger is attached to a funding output during Eltoo channel formation. When a vTXO is spent, the pre-attached ATLC connects to a connector to form a txlock. 
 
This txlock formation ensures that, for the attached ATLC to be claimed by the service provider, the outpoint context of its connector must remain unchanged. In other words, Ark service providers should not double-spend pool transactions they create. This provides an atomic payout construction for senders, as payout vTXOs nest under the same transaction of connectors. The link between connectors and newly created vTXOs is obfuscated through blinded mixing between those.
 
‍Pool transactions are created by Ark service providers perpetually every five seconds, which are effectively blinded, footprint-minimal, rapid coinjoin rounds. ASP funds the pool with their own on-chain funds in exchange for vTXOs redemptions. Therefore, the pool transaction that hits on-chain has only one or a few inputs the ASP provides. The pool transaction has three outputs: vTXOs output, connectors output, and ASP change. Service providers place vTXOs for the intended recipients to claim (under the vTXOs output) and connectors for senders to connect (under the connectors output) in their pool transactions.
 
The first output of the pool transaction, vTXOs output, contains newly created vTXOs of the coinjoin round. vTXOs are bundled and nested under this shared output and can be revealed on-chain. vTXOs output expires four weeks after its creation, and once it expires, the ASP who funded this output in the first place can solely sweep it. Nested vTXOs under the vTXOs output are expected to be redeemed by their owners in this window period. Nested vTXOs may be revealed in this four-week timeframe if the factory operator happens to be non-collaborative or non-responsive for a long period. Upon revealing a vTXO, a unilateral exit window can be triggered by attaching the pre-signed ATLC, similar to Eltoo. In the optimistic big picture, however, the final result is almost always a pool transaction with few inputs and three outputs where pool content is rarely revealed on-chain. Therefore, vTXOs & connectors remain almost always off the chain.

Ark can interoperate with Lightning by attaching HTLCs and PTLCs to a pool transaction, just like ATLCs and connectors. The attached HTLCs live under another shared UTXO called the HTLCs outputs, which also expire after four weeks. Ark service providers forward HTLCs to the broader Lightning Network the moment after they them to their pool transaction. This means Ark service providers are also Lightning service providers. Ark users can also get paid from Lightning using HTLC-nested vTXOs.
 
Ark is an open network where anyone can run their own ASP infrastructure. This means a user can have a vTXO set associated with different ASPs. The Ark protocol design allows users to pay lightning invoices from different vTXO sources using multi-part payments (MPP). Upon attaching HTLCs (or PTLCs) to multiple pools operated by various ASPs, HTLCs can be forwarded to the end destination via MPP.
 
A pool transaction can be double-spent by the Ark service provider while it remains in the mempool. However, in the meantime, the recipient can pay a lightning invoice with their incoming zero-conf vTXOs, so it’s a footgun for the service operator to double-spend in this case. 
 
A transfer schedule from a sender to a receiver is atomic in nature. ASPs cannot redeem senders' vTXOs if they double-spend recipients' vTXOs under the mutually agreed pool transaction id. A future extension of Ark can utilize a hypothetical data manipulation opcode (OP_XOR or OP_CAT) to constrain the ASP's nonce in their signatures to disincentivize double-spending. Users can forge ASP's signature to claim their previously redeemed vTXOs if a double-spend occurs in a pool transaction. This is effectively an inbound liquidity-like tradeoff without compromising on the protocol design.
 
On Ark, payments are credited every five seconds but settled every ten minutes. Payments are credited immediately because users don’t have to wait for on-chain confirmations to spend their zero-conf vTXOs further. They can hand over zero-conf vTXOs to others or pay lightning invoices with them. This is because the ASP who can double-spend users' incoming vTXOs is the same ASP who routes Lightning payments. 
 
You can find more info at https://arkpill.me/deep-dive https://www.arkpill.me/deep-dive.
 
- Burak

[-- Attachment #2: Type: text/html, Size: 11681 bytes --]

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

[ZmnSCPxj]

Good morning Burak,

I have not gone through the deep dive fully yet, but I find myself confused about this particular claim:

> A pool transaction can be double-spent by the Ark service provider while it remains in the mempool. However, in the meantime, the recipient can pay a lightning invoice with their incoming zero-conf vTXOs, so it’s a footgun for the service operator to double-spend in this case. 

Given that you make this claim:

> ASPs on Ark are both (1) liquidity providers, (2) blinded coinjoin coordinators, and (3) Lightning service providers. ASPs main job is to create rapid, blinded coinjoin sessions every five seconds, also known as pools.

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.

Even if the Lightning access is somehow different from the ASP you are receiving funds on, one ASP cannot prove that another ASP is not its sockpuppet except via some expensive process (i.e. locking funds or doing proof-of-work).

Regards,
ZmnSCPxj

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

[Burak Keceli]

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

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

[G. Andrew Stone]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

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 <
bitcoin-dev@lists.linuxfoundation.org> 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
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2032 bytes --]

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

[ZmnSCPxj]

Good morning Burak,

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

This is why competent coders test their code for footguns before deploying in production.

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

You can also do the same in Lightning, with the same risk profile: the LSP opens a 0-conf channel to you, you receive over Lightning, send out over Lightning again, without waiting for onchain confirmations.
Again the LSP can also steal the funds by double-spending the 0-conf channel open, like in the Ark case.

The difference here is that once confirmed, the LSP can no longer attack you.
As I understand Ark, there is always an unconfirmed transaction that can be double-spent by the ASP, so that the ASP can attack at any time.

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

If by "swap-in" you mean "onchain-to-offchain swap" then it is the user who can double-spend their onchain 0-conf HTLC, not the swap service provider.
As the context is receiving money and then sending it out, I think that is what you mean, but I think you also misunderstand the concept.

Regards,
ZmnSPCxj

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

[ZmnSCPxj]

Here is an old write-up that should be read by everyone trying to design a NON-custodial L2: https://zmnscpxj.github.io/offchain/safety.html




Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, May 24th, 2023 at 12:40 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> Good morning Burak,
> 
> > > 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.
> 
> 
> This is why competent coders test their code for footguns before deploying in production.
> 
> > 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.
> 
> 
> You can also do the same in Lightning, with the same risk profile: the LSP opens a 0-conf channel to you, you receive over Lightning, send out over Lightning again, without waiting for onchain confirmations.
> Again the LSP can also steal the funds by double-spending the 0-conf channel open, like in the Ark case.
> 
> The difference here is that once confirmed, the LSP can no longer attack you.
> As I understand Ark, there is always an unconfirmed transaction that can be double-spent by the ASP, so that the ASP can attack at any time.
> 
> > 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.
> 
> 
> If by "swap-in" you mean "onchain-to-offchain swap" then it is the user who can double-spend their onchain 0-conf HTLC, not the swap service provider.
> As the context is receiving money and then sending it out, I think that is what you mean, but I think you also misunderstand the concept.
> 
> Regards,
> ZmnSPCxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Burak Keceli]

> You can also do the same in Lightning, with the same risk profile: the LSP opens a 0-conf channel to you, you receive over Lightning, send out over Lightning again, without waiting for onchain confirmations.

This is not correct. If an LSP opens a zero-conf channel to me, I cannot receive over lightning immediately because I have to wait for that channel to confirm before revealing my preimage for the payment. If I don’t, LSP takes the sender’s money yet double-spends my channel.

This is not the case with Ark. Ark ensures "absolute atomicity" by using ATLCs instead of HTLCs. Users can receive payments and forward them further without waiting for on-chain confirmations. A double-spend attempt breaks the entire atomicity. An ASP cannot redeem senders’ vTXO(s) if they double-spend recipients' vTXO(s).

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

[Burak Keceli]

> 0-conf transactions are unsafe since it is possible to double-spend the inputs they consume, invalidating the 0-conf transaction.

A future extension of Ark can potentially utilize a hypothetical data manipulation opcode (OP_XOR or OP_CAT) to constrain the ASP's nonce in their signatures to disincentivize double-spending. If a double-spend occurs in a pool transaction, users can forge ASP's signature to claim their previously redeemed vTXOs. This is effectively an inbound liquidity-like tradeoff without compromising on the protocol design.

For the time being, you have to wait for on-chain confirmations to consider a payment 'final'. However, this doesn't prevent you from paying lightning invoices with your zero-conf coins. Ark has immediate availability with delayed finality.

Best,
Burak

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

[adiabat]

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, thanks!

-Tadge

[1] https://uploads-ssl.webflow.com/645ae2e299ba34372614141d/6467d1f1bf91e0bf2c2eddef_Screen%20Shot%202023-05-19%20at%2015.44.21-p-1080.png

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

[David A. Harding]

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

[3] 
https://min.sc/#c=pk%28B%29%20%26%26%20%28older%281%20day%29%20%7C%7C%20pk%28A%29%29

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

[Burak Keceli]

Hi David, 

Ark can be used for three purposes:

1. Mixing coins.
Ark is a scalable, footprint-minimal off-chain mixer. People can use Ark to mix their coins with others. This doesn’t require waiting for on-chain confirmations since you’re mixing your own coins with others.

2. Paying lightning invoices
Ark is interoperable with Lightning, and you can use your Ark funds to pay Lightning invoices in a conjoin. This also doesn’t require waiting for on-chain confirmations since you consider your payment “done” when you obtain the vendor's preimage.

3. Making internal transfers
You can use your Ark funds to make internal money transfers without introducing inbound liquidity assumptions. The recipient-end has to wait for several on-chain confirmations to consider their payment “final”, however, their payment has immediate availability to them. Recipients can spend their zero-conf funds to pay Lightning invoices in coordination with their service provider. If we want to enable Lightning-style instant settlement assurances for the internal transfers, we need OP_XOR or OP_CAT on the base layer [1].


I think you get the gist of it, but I lost you after ”Bob wants to deposit 1 BTC with Alice.” sorry.

The initial onboarding phase is non-interactive, and there is no PSBT involved. Onboarding (or lifting) is as simple as funding a Bitcoin address. 

Here I have refactored it for you:
Bob wants to deposit 1 BTC with Alice. Bob asks his friend Charlie to send 1 BTC to an on-chain Bitcoin address whose script is:
pk(B) && (older(4 weeks) || pk(A))

 From here, there are several things that Bob can do:
- *Unilaterally withdraw:*
If Alice happens to be non-collaborative or non-responsive, Bob can simply take his 1 BTC back after four weeks. 

- *Collaboratively withdraw:*
Bob and Alice can sign from the 2-of-2 to collaboratively withdraw 1 BTC anytime.

- *Collaboratively trade commitments:*
Alice crafts a transaction containing three outputs; (a) a commitment output, (b) a connector output, and (c) a change output. We call this transaction “pool”.
(a) commitment output
Commitment output (either using CTV or n-of-n multisig) constrains its descendant transaction to a set of transaction outputs. To simplify things, let’s say there are no other participants in this transaction besides Bob, and the descendant transaction has only one output. We call this output Bob’s vTXO. Bob’s vTXO also constrains (using CTV or 2-of-2 multisig) its descendant transaction to a single transaction output called Bob’s ATLC. Bob’s ATLC contains the following script:
pk(B) && (older(4 weeks) || pk(A))
As you realize “ATLC” script is identical to the “Funding address” script. 

(b) connectors output
Connectors output is simply a single-sig output spendable by Alice herself:
pk(A)

Alice locally crafts a descending transaction from this output, spending “connectors output” to fund a new output. We call this output a ”connector,” which always carries a dust value  and is spendable by Alice herself:
pk(A)

In short, Alice crafts a Bitcoin transaction that spends an input that she controls and funds an output that she controls. Alice does not broadcast this transaction and keeps it secret.

(c) change output
money not used for the other two outputs gets sent back to Alice.

1. Alice places one (or more) input(s) to her “pool” transaction to supply funds to commitment output, connectors output, change output, and transaction fees.

2. Bob creates an unsigned PSBT, placing the input that Charlie was previously funded.

3. Bob passes his PSBT to Alice. 

4. Alice places one input to PSBT, the ”connector output,”  which is a descendant of the (b) connectors output she is crafting.

5. Alice places one output to PSBT, a single-sig output that sweeps all money to herself (pk(A)).

6. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this transaction private. This transaction is not valid yet, since the connector’s outpoint context does not exist.

7. Alice signs her one-in, three-out and broadcasts it. 

8. Alice can now claim 1 BTC Charlie has previously funded by revealing the descendant transaction of (b) connectors output. She should claim this before four weeks.
 
9. Bob now has a 1 BTC worth UTXO representation as a descendant of the (a) commitment output (a virtual UTXO). He can unilaterally claim this 1 BTC by revealing the child (Bob’s vTXO) and grandchild (Bob’s ATLC) of the (a) commitments output, then waiting a 24-hour window period.

So far, Charlie polluted on-chain by funding an address, and Alice by claiming funds from that address. Further steps from here will be footprint minimal. 

1. Say, Bob wants to send 1 BTC to Dave. 

2. Alice crafts a transaction containing three outputs; (a) a commitment output, (b) a connector output, and (c) a change output. This time descendant of (a) commitment output is Daves’s vTXO instead of Bob’s. Similarly descendant of Daves’s vTXO is Dave’s ATLC. Dave’s ATLC is:
pk(D) && (older(4 weeks) || pk(A))

3. Alice places one connector output as a descendant of (b) connectors output, just like before. 

4. Alice places one input to her one-in, three-out transaction to supply funds to commitment output, connectors output, change output, and transaction fees.

5. Bob creates an unsigned PSBT, placing his 1-BTC-worth virtual UTXO from the (a) commitment output descendants that Alice previously 

6. Bob passes his PSBT to Alice. 

7. Alice places one input to PSBT, the ”connector output,”  which is a descendant of the (b) connectors output she is crafting. 

8. Alice places one output to PSBT, a single-sig output that sweeps all money to herself (pk(A)).

9. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this transaction private. 

10. Alice signs her one-in, three-out transaction and broadcasts it. 

11. Bob lets Dave know about this transaction (Alice’s transaction id, Dave’s vTXO output index) out-of-band. 

12. When Dave comes back online, he sees from the out-of-band message that Bob sent him 1-BTC. He then verifies whether Alice’s transaction id exists, whether his vTXO output index is correct, and a set of other validations.

13. If Dave had been online all this time, he would have had to wait for enough confirmations to consider his payment “final.”

[1] https://eprint.iacr.org/2017/394.pdf

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

[David A. Harding]

Hi Burak,

Thanks for your response!  I found it very helpful.  I'm going to reply
to your email a bit out of order.

> 4. Alice places one input to her one-in, three-out transaction to
>    supply funds to commitment output, connectors output, change
>    output, and transaction fees.

You don't mention it in your reply, but was I correct in my earlier
email in assuming that Alice can claim any funds paid to a commitment
output after four weeks if its commitments haven't been published
onchain?  E.g., that in the best case this allows a ~50 vbyte commitment
output that pays an arbitrary number of users to be spent as a ~100
vbyte input (P2TR scriptpath for pk(A) && older(4 weeks))?

> 1. Mixing coins.
> 2. Paying lightning invoices
> 3. Making internal transfers

If commitment outputs can't normally be spent by Alice for four weeks,
then Alice needs to keep enough capital on hand to pay out all amounts
involved in the activities listed above.  I've seen many people make
this point, but I wanted to run some rough numbers to estimate the
extent of that capital load.

Let's say Alice has a million customers who each receive all of their
income and pay all of their expenses with her.  In my country, the
median income is a bit less than $36,000 USD, or about $3,000 a month.
I imagine spending is not evenly distributed over time, so let's say
Alice needs to hold 3x the average to be prepared for a busy period.
That implies Alice's capital requirements are about $9 billion USD (3 *
3000 * 1e6).

At a hypothetical risk-free interest rate of 1.5% annual, that's about
$135 that will need to be recovered from each user per year (9e9 * 0.015
/ 1e6).

Additionally, if we assume the cost of an onchain transaction is $100
and the service creates one transaction per five seconds, that's $630 in
fee costs that will need to be recovered from each user per year ((60 /
5) * 60 * 24 * 365 * 100 / 1e6).

I'll come back to this financial analysis later.

> If we want to enable Lightning-style instant settlement assurances for
> the internal transfers, we need OP_XOR or OP_CAT on the base layer
> [...] https://eprint.iacr.org/2017/394.pdf

What do you mean by "instant"?  Do you mean "settlement as soon as the
next onchain pool transaction is published"?  For example, within 5
seconds if the coinjoining completes on time?  That's significantly
slower than LN today, at least in the typical case for a well-connected
node.[1]

I think 5 seconds is fine for a lot of purposes (at both point-of-sale
terminals and on websites, I very often need to wait >5 seconds for a
credit card transaction to process), but I think it's worth noting the
speed difference in a technical discussion.

Additionally, I think the idea described significantly predates that
paper's publication, e.g.:

"Well while you can't prevent it you could render it insecure enabling
miners to take funds.  That could work via a one-show signature
[...]"[2]

A problem with the idea of using one-show signatures as double-spend
protection is that miner-claimable fidelity bonds don't work as well
against adversaries that are not just counterparties but also miners
themselves.  This same problem has been described for other ideas[3],
but to summarize:

Bob has something valuable.  Alice offers him the output of an
unconfirmed transaction in exchange for that thing.  She also provides a
bond that will pay its amount to any miner who can prove that Alice
double spent her input to the unconfirmed transaction.

If Alice is miner, she can privately create candidate blocks that double
spend the payment to Bob and which also claim the bond.  If she fails to
find a PoW solution for those candidate blocks, she lets Bob have his
money.  If she does find a PoW solution, she publishes the block, taking
Bob's money, securing her bond, and also receiving all the regular block
rewards (sans the fees from whatever space she used for her
transaction).

I haven't exactly[4] seen this mentioned before, but I think it's
possible to weaken Alice's position by putting a timelock on the
spending of the bond, preventing it from being spent in the same block
as the double-spend.  For example, a one-block timelock (AKA: 1 CSV)
would mean that she would need to mine both the block containing her
unconfirmed transactions (to double spend them) and the next block (to
pay the fidelity bonds back to herself).

Ignoring fee-sniping (bond-sniping in this case), selfish mining, and
51% attacks, her chance of success at claiming the fidelity bond is
equal to her portion of the network hashrate, e.g. if she has 33%, she's
33% likely to succeed at double spending without paying a penalty.  The
value of the fidelity bond can be scaled to compensate for that, e.g. if
you're worried about Alice controlling up to 50% of hashrate, you make
the fidelity bond at least 2x the base amount (1 / 50%).  Let's again
assume that Alice has a million users making $3,000 USD of payments per
month (28 days), or about on average $75,000 per minute (1e6 * 3000 / 28
/ 24 / 60).  If Alice bonds 2x the payment value and her bonds don't
expire for 6 blocks (which might take 3 hours), she needs an additional
$27 million worth of BTC on hand (75000 * 2 * (3 * 60)), which I admit
is trivial compared to the other capital requirements mentioned above.

* * *

Taken all together, it seems to me that Alice might need to keep several
billion dollars worth of BTC in a hot wallet in order to serve a million
users.  The per-user cost in fees and capital service would be around
$1,000 per year.  If we assume onchain transaction costs are about $100,
that would be equal to 10 channels that could be opened or closed by
each user for the same amount (i.e. an average of 5 channel rotations
per year).

Did I miss something in my analysis that would indicate the capital
costs would be significantly lower or that there wouldn't be other
tradeoffs (slower settlement than LN and a need to use a timelocked
fidelity bond)?

Thanks!,

-Dave

[1] https://twitter.com/Leishman/status/1661138737009442818

[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007038.html

[3] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018010.html

[4] Years ago, I think I saw a reply by Peter Todd to some idea about
     paying money to miners in a fair way and he noted that it was
     critical to pay miners far enough in the future that the current set
     of miners wouldn't be incentivized to manipulate who got the money
     by choosing which block to include the transaction in now.  I wasn't
     able to quickly find that post, but it definitely influenced my
     thinking here.

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

[Burak Keceli]

> A problem with the idea of using one-show signatures as double-spend
> protection is that miner-claimable fidelity bonds don't work as well
> against adversaries that are not just counterparties but also miners
> themselves. 

Hey David,

The fidelity bonds in the Ark context are nothing but the vTXOs themselves, which in simple terms, have two possible closures: (1) a key-path collaborative closure with higher precedence and (2) a script-path closure with lower precedence.

The key-path closure is a 2-of-2 between the rightful owner of the vTXO and the service provider. The script path closure, on the other hand, lets the service provider sweep funds after a relative lock time. The key-path closure has higher precedence over the script-path closure since it can be triggered immediately with a satisfying signature.

If the service provider double-spends a transaction that enforces a one-time signature where Bob is the vendor, Bob can forge the service provider’s signature from the 2-of-2 and can immediately claim his previously-spent vTXO(s). If Alice (or the service provider) is a miner she won’t be able steal funds regardless, since she won’t be able co-sign from the Bob’s key.

Best,
Burak

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

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 9925 bytes --]

Hi Burak,

Thanks for the interesting Ark proposal.

From my understanding the protocol is played between 3 entities: the
sender, the receiver and the ASP and you have 3 types of transactions:
- the pool_tx
- the ATLC-connection_tx
- the ATLC-refund_tx

The pool_tx spends an on-chain funding input and 3 outputs:
- the commitment output, committing to a set of N vTXOs outputs (e.g a tree
of promised outputs)
- the connector output, spendable by the ASP signature
- the change output, from the value overflow of the on-chain funding input

A "receiver" vTXO scriptpubkey on pool_tx N includes the following
pseudo-script: multisig(receiver, ASP) or ((pk(receiver)+24h) or
(pk(ASP)+4weeks)). From the PoV of the next pool_tx state, the receiver
becomes the sender.

A ATLC-connection_tx is associated with a pool_tx N is spending one or more
vTXOs outputs from the "sender" (i.e receiver at pool_tx N-1) and one or
more connector outputs from pool_tx N. The initial
uplifting ATLC- connection_tx spends an on-chain input from the initial
sender.

I think there is a loss of funds weakness during the vTXLO transfer phase,
i.e by leveraging an ATLC-refund transaction using the unilateral exit path.

Let's say you have Alice (the sender), Bob (the receiver) and the ASP at
state N. Alice owns a vTXO on pool_tx N:
- after 24, her vTXO N can be spend unilaterally with only her own signature
- she engages with the ASP to construct a new pool_tx N+1 paying a vTXO to
Bob (this vTXO has same relative locktime 24h)
- she reveals her signature to the ASP for the ATLC-connection_tx N+1
spending her vTXO at state N and the connector output at state N+1
- the ASP broadcasts the pool_tx N+1 and the transaction is pending in
network mempools
- Alice broadcasts her ATLC refund tx using the mature unilateral exit path
- this ATLC refund tx replaces any ATLC-connection tx pending in network
mempools
- both the ATLC refund tx for vTXO at state N and the pool_tx at state N+1
confirms
- Bob the receiver can wait 24h and then he can spend the vTXO at state N+1
unilaterally

Alice and Bob successfully colluded to "double-spend" the ASP, without this
service provider earning compensation for the pool_tx state N+1 funding
input.

If I'm correct, I don't know if this weakness can be fixed by adding
another round of interactivity between the sender and the ASP, e.g
disclosing a revocation secret for the ATLC-refund transaction, without
opening the door for the ASP to steal user by stalling the next pool_tx N+1
broadcast and waiting 4 weeks time lock expiration.

All mistakes, confusion or misunderstanding are my own. More details about
transactions, scripts and protocol phases would be appreciated.

Cheers,
Antoine

Le ven. 26 mai 2023 à 16:27, Burak Keceli via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Hi David,
>
> Ark can be used for three purposes:
>
> 1. Mixing coins.
> Ark is a scalable, footprint-minimal off-chain mixer. People can use Ark
> to mix their coins with others. This doesn’t require waiting for on-chain
> confirmations since you’re mixing your own coins with others.
>
> 2. Paying lightning invoices
> Ark is interoperable with Lightning, and you can use your Ark funds to pay
> Lightning invoices in a conjoin. This also doesn’t require waiting for
> on-chain confirmations since you consider your payment “done” when you
> obtain the vendor's preimage.
>
> 3. Making internal transfers
> You can use your Ark funds to make internal money transfers without
> introducing inbound liquidity assumptions. The recipient-end has to wait
> for several on-chain confirmations to consider their payment “final”,
> however, their payment has immediate availability to them. Recipients can
> spend their zero-conf funds to pay Lightning invoices in coordination with
> their service provider. If we want to enable Lightning-style instant
> settlement assurances for the internal transfers, we need OP_XOR or OP_CAT
> on the base layer [1].
>
>
> I think you get the gist of it, but I lost you after ”Bob wants to deposit
> 1 BTC with Alice.” sorry.
>
> The initial onboarding phase is non-interactive, and there is no PSBT
> involved. Onboarding (or lifting) is as simple as funding a Bitcoin
> address.
>
> Here I have refactored it for you:
> Bob wants to deposit 1 BTC with Alice. Bob asks his friend Charlie to send
> 1 BTC to an on-chain Bitcoin address whose script is:
> pk(B) && (older(4 weeks) || pk(A))
>
>  From here, there are several things that Bob can do:
> - *Unilaterally withdraw:*
> If Alice happens to be non-collaborative or non-responsive, Bob can simply
> take his 1 BTC back after four weeks.
>
> - *Collaboratively withdraw:*
> Bob and Alice can sign from the 2-of-2 to collaboratively withdraw 1 BTC
> anytime.
>
> - *Collaboratively trade commitments:*
> Alice crafts a transaction containing three outputs; (a) a commitment
> output, (b) a connector output, and (c) a change output. We call this
> transaction “pool”.
> (a) commitment output
> Commitment output (either using CTV or n-of-n multisig) constrains its
> descendant transaction to a set of transaction outputs. To simplify things,
> let’s say there are no other participants in this transaction besides Bob,
> and the descendant transaction has only one output. We call this output
> Bob’s vTXO. Bob’s vTXO also constrains (using CTV or 2-of-2 multisig) its
> descendant transaction to a single transaction output called Bob’s ATLC.
> Bob’s ATLC contains the following script:
> pk(B) && (older(4 weeks) || pk(A))
> As you realize “ATLC” script is identical to the “Funding address” script.
>
> (b) connectors output
> Connectors output is simply a single-sig output spendable by Alice herself:
> pk(A)
>
> Alice locally crafts a descending transaction from this output, spending
> “connectors output” to fund a new output. We call this output a
> ”connector,” which always carries a dust value  and is spendable by Alice
> herself:
> pk(A)
>
> In short, Alice crafts a Bitcoin transaction that spends an input that she
> controls and funds an output that she controls. Alice does not broadcast
> this transaction and keeps it secret.
>
> (c) change output
> money not used for the other two outputs gets sent back to Alice.
>
> 1. Alice places one (or more) input(s) to her “pool” transaction to supply
> funds to commitment output, connectors output, change output, and
> transaction fees.
>
> 2. Bob creates an unsigned PSBT, placing the input that Charlie was
> previously funded.
>
> 3. Bob passes his PSBT to Alice.
>
> 4. Alice places one input to PSBT, the ”connector output,”  which is a
> descendant of the (b) connectors output she is crafting.
>
> 5. Alice places one output to PSBT, a single-sig output that sweeps all
> money to herself (pk(A)).
>
> 6. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this
> transaction private. This transaction is not valid yet, since the
> connector’s outpoint context does not exist.
>
> 7. Alice signs her one-in, three-out and broadcasts it.
>
> 8. Alice can now claim 1 BTC Charlie has previously funded by revealing
> the descendant transaction of (b) connectors output. She should claim this
> before four weeks.
>
> 9. Bob now has a 1 BTC worth UTXO representation as a descendant of the
> (a) commitment output (a virtual UTXO). He can unilaterally claim this 1
> BTC by revealing the child (Bob’s vTXO) and grandchild (Bob’s ATLC) of the
> (a) commitments output, then waiting a 24-hour window period.
>
> So far, Charlie polluted on-chain by funding an address, and Alice by
> claiming funds from that address. Further steps from here will be footprint
> minimal.
>
> 1. Say, Bob wants to send 1 BTC to Dave.
>
> 2. Alice crafts a transaction containing three outputs; (a) a commitment
> output, (b) a connector output, and (c) a change output. This time
> descendant of (a) commitment output is Daves’s vTXO instead of Bob’s.
> Similarly descendant of Daves’s vTXO is Dave’s ATLC. Dave’s ATLC is:
> pk(D) && (older(4 weeks) || pk(A))
>
> 3. Alice places one connector output as a descendant of (b) connectors
> output, just like before.
>
> 4. Alice places one input to her one-in, three-out transaction to supply
> funds to commitment output, connectors output, change output, and
> transaction fees.
>
> 5. Bob creates an unsigned PSBT, placing his 1-BTC-worth virtual UTXO from
> the (a) commitment output descendants that Alice previously
>
> 6. Bob passes his PSBT to Alice.
>
> 7. Alice places one input to PSBT, the ”connector output,”  which is a
> descendant of the (b) connectors output she is crafting.
>
> 8. Alice places one output to PSBT, a single-sig output that sweeps all
> money to herself (pk(A)).
>
> 9. Alice passes PSBT to Bob. Alice and Bob sign the PSBT and keeps this
> transaction private.
>
> 10. Alice signs her one-in, three-out transaction and broadcasts it.
>
> 11. Bob lets Dave know about this transaction (Alice’s transaction id,
> Dave’s vTXO output index) out-of-band.
>
> 12. When Dave comes back online, he sees from the out-of-band message that
> Bob sent him 1-BTC. He then verifies whether Alice’s transaction id exists,
> whether his vTXO output index is correct, and a set of other validations.
>
> 13. If Dave had been online all this time, he would have had to wait for
> enough confirmations to consider his payment “final.”
>
> [1] https://eprint.iacr.org/2017/394.pdf
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 11034 bytes --]

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

[moonsettler]

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

Hi All,

I have a question about the often touted statement that "APO can emulate CTV". From what I have found in the specs and the inquisition codebase:

> BIP-118 ANYPREVOUTANYSCRIPT can constrain outputs of a spending transaction by hardcoding a 65-byte signature and a 33-byte unknown public key type in a script. Alternatively, BIP-119 CTV can directly constrain transaction outputs to a template hash.

APO/AS SIGHASH does not commit to the number of inputs (nor obviously the other input outpoints themselves). This has some interesting consequences for Ark, which relies on TXID non-malleability for it's ATLCs.

Either one of these cases seem to be true depending on how the contracts are constructed:

- APO only: Users can double spend the ASP (USER CAN STEAL)
- APO + ASP single sig: ASP can stop users from unilateral exit and sweep funds after 4 weeks (ASP CAN STEAL)
- n-of-n musig on the vTXO tree: trustless, APO however is not needed, full interactivity, analogous to key deletion covenant (NOBODY CAN STEAL)

APO/AS can also not be used for the ATLC itself, as it has to commit to the TX outpoint of the connector transaction.

OP_CTV however commits to the number of inputs explicitly, thus committing to a single input prevents TXID malleability and ensures the ATLC is going to be enforceable.

I would like to ask what the devs who are deeper into covenant research think about this, and if I'm missing something?
- moonsettler

[-- Attachment #2: Type: text/html, Size: 1995 bytes --]

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

[David A. Harding]

On 2023-06-07 03:30, Burak Keceli wrote:
> If the service provider double-spends a transaction that enforces a
> one-time signature where Bob is the vendor, Bob can forge the service
> provider’s signature from the 2-of-2 and can immediately claim his
> previously-spent vTXO(s).

Hi Burak,

I'm confused.  Bob owns some bitcoins that are timelocked against
immediate withdrawal, but where he can spend immediately with the
cooperation of service provider Sally.  Bob transfers some bitcoins to
Sally contingent on her spending an equal amount of bitcoins (minus a
fee) to Carol.  You already have a mechanism to enforce this contingency
(tx outpoints), so if Carol doesn't receive the bitcoins from Sally,
then Sally also doesn't receive the bitcoins from Bob.  In other words,
you already have atomicity for a single transfer.

Are you describing the effect over multiple transfers?  For example, Bob
previously transferred bitcoins to Sally and she paid users X, Y, and Z
in transactions that are now confirmed onchain, although she hasn't yet
swept Bob's funds.  Now when Sally double spends the payment to Carol,
Bob can not only reclaim the funds he gave Sally to pay to Carol (which
was guaranteed by the atomicity), he can also reclaim the unswept funds
he gave Sally to pay X, Y, and Z.

If so, I don't think that works.  In a private protocol, Carol can't be
sure that Bob and Sally are separate individuals.  If they're the same
entity, then any forfeit that Sally needs to pay Bob is just an internal
transfer, not a penalty.

I'd appreciate any clarification you can offer.  Thanks!,

-Dave

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

[Ali Sherief]

[-- Attachment #1: Type: text/plain, Size: 3263 bytes --]

Burak, I don't remember if this has been mentioned previously in the conversation about Ark, but a disadvantage in the protocol as it is currently is that "Ark require users to come online and "refresh" their coins every few weeks, otherwise the ASP can sweep the funds." (putting that in quotes because although I copied this from a forum, it may have originally been said on this list.)

However, yesterday I have come up with a scheme to mitigate this disadvantage, in a way that works similar to LN watchtowers.

This watchtower program for Ark would be made that runs on an internet-connected server and inputs your wallet password and the date in the future to perform the refreshing. A child process can then be spawned that acts similar to a cronjob, and stores the wallet password with AES encryption in memory.

The key to this cipher is the time stored in ISO 8601 format as a byte string. It is promptly discarded from memory.

Every second, the watchtower child process will attempt to decrypt the cipher using the current ISO 8601 time looking like "YYYY-mm-ddTHH:MM:SSZ" as the key.

Naturally this will only succeed at the requisite time at which the wallet is to be unlocked by the watchtower child process - following which the coins inside the ASP are refreshed, and the watchtower child process is terminated and the encrypted wallet password destroyed.

Of course, memory scrubbing should be applied to the region that has the decrypted wallet password.
If at any point the user comes online by themselves, they can simply cancel the watchtower refreshing task, which will terminate the watchtower child process without opening your wallet and refreshing coins.

The key feature is that nobody will be able to decrypt the wallet password unless they know the exact time it is to be unlocked as an ISO 8601 string. It cannot be unlocked at any time in the future, just at that particular instant, as long as the key is discarded and the software randomly guesses the decryption by attempting each second the new time as the encryption key. Even if the watchtower is hacked after the task has been made, the hacker still won't be able to decrypt the wallet password unless they brute-force the encryption key by exhaustively trying all timestamps in the future.

Alternatively, instead of encrypting the wallet password, it can encrypt a signed transaction which is used by Ark to refresh the coins. In this case, the wallet password would still need to be collected, but only for the purpose of signing the transaction, after which the password is promptly erased from memory.

How this can be extended to repeatedly arming the watchtower program with refreshes remains to be seen, but using the wallet password as the encryption directly is one option albeit not a secure one A better and more secure option would be to take note of the UTXOs created by the coin refreshing transaction, use those as inputs to a second refreshing transaction that is created immediately after the first one, sign it, and similarly create a third, fourth, etc. as many as are desirable for the user. Then every 4 weeks, one of these transactions can be broadcasted, in the order that they were created obviously.

Looking forward to your feedback on this.
-Ali

[-- Attachment #2: Type: text/html, Size: 4819 bytes --]

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

[jk_14]

[-- Attachment #1: Type: text/html, Size: 8961 bytes --]

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

[Ali Sherief]

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 mining but for L2 transactions is a pretty good idea, but the reorgs trapdoor you mentioned could theoretically be mitigated ARK nodes considering their 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 users 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,
> 
> 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.html
> 
> [3]
> https://min.sc/#c=pk(B) %26%26 (older(1 day) || pk(A))