MIME-Version: 1.0
References: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com>
In-Reply-To: <1300890009.1516890.1684742043892@eu1.myprofessionalmail.com>
From: adiabat <rx@awsomnet.org>
Date: Wed, 24 May 2023 16:20:35 -0400
Message-ID: <CAKEeUhg1qeZOv-Lk8SSTxdkgfSee_E6_4fwNV=hfwsxLgwWkUw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second
	Layer Solution
Precedence: list

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