--- Log opened Sat Mar 14 00:00:22 2020
11:22 < bsm117532> jeremyrubin: if the less-or-similar UTXOs come entirely from eliminating change, doesn't this mean that standard batching techniques would achieve the same benefit, without the CTV overhead?
12:08 < jeremyrubin> nope
12:09 < jeremyrubin> did you read the link I sent at 17:54?
12:22 < bsm117532> Yes, I was responding to your comment above
12:23 < jeremyrubin> Heterogeneous batches without ctv have 1 change output per batch
12:23 < jeremyrubin> CTV is one change output for all batches
12:24 < jeremyrubin> This not only pays for the additional layer of indirection, but increases change liquidity as it's not dependent on getting  a batch confirmed
12:26 < bsm117532> ah ok
12:26 < bsm117532> as in, not dependent on getting all leaves of the batch confirmed, right? There's one change in the CTV commitment tx.
12:28 < jeremyrubin> yep correct
12:29 < jeremyrubin> tree structure can look something like this:
12:29 < jeremyrubin> root txn -> expander utxo -> expander txn -> {change, batch1, batch2...batch n}
12:30 < jeremyrubin> So that the "spot demand" fees for the root txn are O(1)
12:31 < jeremyrubin> and then each batch has only 1 input (compared to however many needed without CTV -- guessing average 2-3) and no change output.
12:31 < jeremyrubin> So you save on signatures for change, signatures for general inputs, total inputs needed.
12:32 < jeremyrubin> you can also do without the expander utxo, but then you're mixing fee priorities more to be overpaid based on # of batches
12:32 < jeremyrubin> root txn -> {change, expander utxo -> expander txn -> {batch1, batch2...batch n}}
12:33 < jeremyrubin> that's also a fine structure if you want your change liquidity faster
12:34 < jeremyrubin> but it costs you (highest batch feerate-desired change feerate)*1 output  more
16:38 -!- pigeons_ is now known as pigeons
--- Log closed Sun Mar 15 00:00:22 2020