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