Paid 10 sat/vb where 1 was enough:
Also, what are the first two outputs?
Yes this is correct. We currently don’t have any fee estimation logic in place and we use a simple hard-coded fee. It is on our todo-list to use the fee estimator service, either from your bitcoin node or from an esplora or mempool.space instance, to provide more accurate fee estimations.
To follow progress, you can follow this issue on our repo.
When doing an off-board, you leave the Ark through a round transaction. So the 2 first transaction outputs you can see are the round outputs themselves: the round tx tree root and the connector one.
Ah yeah, it was late yesterday. This transaction is not built by bark at all, but by the server. The round feerate is set by the server and communicated to the users. The users then only pay a fee for the bytes that their output consumes in the transaction.
2 Likes
Thanks. This looks more complicated than I thought. Does the offboarding byte size depend on how many times a vtxo changed hands or was refreshed?
Assuming you’re talking about the output size, no, it is only affected by the script you use as your offboard destination.
When doing an offboard, you are just doing an atomic swap of your old VTXO against an onchain UTXO locked by the script you provide.
Ok, so I created two wallets and sent some sats back and forth offchain (not paying bolt11) a few times. I noticed each payment costed about 1000 sats, which is a lot for L2. Why so much?
Then, I simulated the Ark server going under by editing my hosts file, and tried a unilateral exit. I got this response:
% bark exit --all --wait
[16:20:32.315 INFO] Connecting to ASP using TLS...
[16:20:32.757 WARN] Ark server handshake failed: couldn't connect to Ark server
[16:20:32.759 WARN] Failed to sync incoming Ark payments, still doing exit: You should be connected to ASP to perform this action
An error occurred: error starting exit process for existing vtxos
Caused by:
total exit fee estimate is 0.00216770 BTC, wallet only has 0 BTC
216k sats to exit an L2 is REALLY A LOT, given that signet has 1 s/vb cost. Is it trying to put the whole history of payments on chain, and needs confirmed chain funds to do CPFP? Compared to Lightning, this L2 does not save on chain fees, but merely postpones paying them. And the last guy holding the bag will be screwed. Until that moment, the sats are custodial. Am I missing something?
Yeah, we currently don’t have any fee estimation logic, so they might not be adapted to the network state.
The way arkoors are implemented as of today indeed make the tx chain longer everytime you do a transaction. While a simple mitigation is to simply refresh vtxos - you’ll get back to a small tx branch after that - we also plan to build implementations that do not imply increasing chains for out-of-round payment, like virtual channels.
We took that message on the safe side. We are basically grossly overestimating the total bytes you have to broadcast and then multiplying with a very high feerate. That will definitely improve a lot.
The main reason we decided to have this check for now, is because our exit process is not yet robust enough to reliably recover from a failure halfway through, so if you would end up with not enough funds halfway through, it was likely that the entire exit would fail. That’s why we currently put in an extremely conservative fee estimate to be on the safe side.
Also, just a notice, exit cost is not related to the amount of sats in your vtxo, but the size in bytes of the txs on chain. If you have been sending dozens of txs back and forth, you might still only have a 1000 sats in your vtxo, but now the exist cost is quite high. If you’re doing high volumes like this, it might make sense to refresh more frequently.
But again, we’re working to get all this hickups straightened asap. Thanks for the feedback for sure.
Ok, will keep an eye on the development. Thanks for the incentive to learn all this. Do you envisage many Arc servers running this eventually on mainnet, or mostly one? Do I understand correctly, this idea competes with cashus, but has an advantage of fallback if a server rugs?
1 Like
Yeah your understanding is correct 
Running an Ark server is quite involved and requires a non-trivial amount of liquidity, so we expect there not to be too many of them. We are mostly focused right now on developing the server for our own needs and make the client as flexible as possible for people to integrate using it.
But we nonetheless stay committed to keeping the server-side code open-source, of course!
1 Like
Does it actually cost anything for the server to move off-chain funds from one wallet to another? I saw 983 sats fee charged for a payment with 1 vtxo input and 1270 with 2. Any reason for this?
Why is this fee policy not mentioned in ark-info?
We haven’t implemented a fee policy yet.
Currently, all fees are hard-coded and they are set very conservative to ensure transactions can make it on chain if they need to. The result is that fee costs you will see in the demo are much higher as needed.
The bark send command uses a construct that we call out-of-round. Here, we creates a new off-chain bitcoin transaction which spends a few old-vtxo’s and creates a couple of new vtxo’s. To ensure we can bring the transaction on-chain at any time we have to add a fee-anchor.
Today, we have to put a non-zero amount in the fee-anchor. As a client you lose all money in this fee-anchor. The money goes to the server when it sweeps the round. We can’t reduce this fee (yet).
However, bitcoin 29.0 will ship ephemeral anchors which will allow us to set the fee-anchor to 0. This feature would make off-chain transactions much cheaper.
1 Like