pull down to refresh

1647 sats \ 5 replies \ @nout 20 May 2023 \ on: Ark - better Lightning? bitcoin
So from quick read and chat with Burak, here's what I got so far (but take with grain of salt, I'm not that smart):
  • You first send your onchain coins (UTXO) to one of the pools (Ark Service Providers) and it becomes virtual-txo (comparable to having sats on lightning).
  • The pool coinjoins all vtxos every 5 seconds generating new onchain transaction for every coinjoin (but it's using taproot smartness, so every coinjoin is represented only by a simple 1 input, 1 output transaction taking ~130vB).
  • So this means that each pool will be submitting ~15k vB to mempool every 10 minutes (so there's a limit for number of pools running at the same time - if my math is correct there can be AT MOST 256 pools). But also note here that the numbers are just a suggestion here, the "5 seconds" could change to e.g. 1 minute.
  • When you have your bitcoin in this layer, then you can freely transact with other folks, the transactions happen in 5 seconds and with solid privacy - as far as I can tell the cryptography should prevent the pool from actually being able to link your transactions.
  • Any time you want you can pull your coins out of the pool and send to onchain address.
  • This solves the "I don't have inbound liquidity" problem that lightning has.
It seems that it could be much easier to run Ark node compared to LN node, since you just need to fund it with BTC and the daemon can do its job from there, but also your funding only seems to be going in one direction, so your coins are locked for at least 2 weeks and you may need to be adding more gradually (?). If it works the way I understand it can be quite profitable to run Ark Service Provider node.
write
preview
100 sats \ 0 replies \ @jk_14 21 May 2023
"each pool will be submitting ~15k vB to mempool every 10 minutes (so there's a limit for number of pools running at the same time - if my math is correct there can be AT MOST 256 pools). But also note here that the numbers are just a suggestion here, the "5 seconds" could change to e.g. 1 minute."
256 pools will utilize all the bitcoin tx throughput... and fixing it only a bit by waiting 1 minute for transaction to happen instead of 5 sec - is like going back from L2 to L1 "slow motion" - unacceptable user experience, then
that's mad idea at first look, imo
reply
300 sats \ 1 reply \ @_b_o_n_e_s_ 21 May 2023
thanks for write up
who pays for constant stream of onchain tx?
it sounds like its good solution for privacy. swap into layer to transact, not store funds indefinitely
reply
50 sats \ 0 replies \ @nout 21 May 2023
The Ark Service Provider (ASP) has to pay the fees for those transactions and so that will be passed onto the users. But the trick is that the more users use it, the cheaper it becomes. i.e. users can make 1000 ark transactions and they split only a single onchain fee for 1in-1out tx.
reply
0 sats \ 0 replies \ @fiksn 22 May 2023
You wouldn't need to run an "ark node". Idea is that this improves UX that much that it is feasibe to have just a mobile Ark wallet.
reply
0 sats \ 0 replies \ @phaedrus OP 21 May 2023
Great write up!
I think limits for number of pools that get into a block is huge improvement over LN.
What would be the limit on number of transactions within single coin join (which happens say each 5seconds)?
reply