--- Log opened Fri Mar 13 00:00:25 2020 10:50 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 272 seconds] 10:51 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##ctv-bip-review 11:28 < bsm117532> jeremyrubin: this is only long-term valuable if it reduces the on-chain load. N miners with a lookback of M blocks will create N*M individual UTXOs. When a miner cashes out, it reduces the tx's they could take in fees. 11:28 < bsm117532> This is one problem that p2pool had -- they just put all that in the coinbase. 11:29 < bsm117532> Centralized pools can also aggregate payments, creating fewer UTXOs. 11:29 < bsm117532> I'm not sure how to do that here... 11:30 < bsm117532> To have less than N*M UTXOs you'd have to aggregate across different coinbases somehow... 11:31 < bsm117532> FWIW I've long wanted to have the coinbases be channel openings, that can pay small hashers without all that on-chain load. But now you have a coordination problem that I (nor anyone else) has provided a reasonable solution for... 11:36 < bsm117532> Maybe this is an interesting direction more generally: given 2 CTV-locked outputs, I want to rearrange the commitments in them to create fewer UTXOs, paying the same people the same amounts, while still satisfying the sum-value constraint. 11:37 < bsm117532> "Congestion control" would be WAY more interesting if you could show that in some circumstance it resulted in fewer UTXOs being created, to compensate for its overhead. 16:59 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 17:10 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##ctv-bip-review 17:32 -!- pigeons_ [~pigeons@androzani.sysevolve.com] has joined ##ctv-bip-review 17:34 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 17:34 -!- pigeons [~pigeons@androzani.sysevolve.com] has quit [Ping timeout: 240 seconds] 17:37 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined ##ctv-bip-review 17:53 < jeremyrubin> bsm117532: Have you reviewed the use cases on https://utxos.org 17:53 < jeremyrubin> You can non-interactively trustlessly create auditable channels between participants 17:53 < jeremyrubin> Which can be used in the mining pool example 17:54 < jeremyrubin> So you can do cut through on the channels because you can have common groupings and eliminate 17:54 < jeremyrubin> [01:34] Miners can also be paid out in non-interactive setup channels, allowing them to eliminate payouts and collapse the state down to a single utxo per miner when withdrawing from the pool, or do a trustless withdraw if the other miner(s) are offline. 17:55 < jeremyrubin> next point 17:55 < jeremyrubin> [11:36] "Congestion control" would be WAY more interesting if you could show that in some circumstance it resulted in fewer UTXOs being created, to compensate for its overhead. 17:55 < jeremyrubin> https://github.com/JeremyRubin/CTVSims/tree/master/batch-splitting 17:55 < jeremyrubin> This is more or less what I demonstrate here 17:55 < jeremyrubin> CTV uses less chain space 17:57 < bsm117532> Oooooh neat! Will look tomorrow :-D 18:02 < jeremyrubin> :) 18:03 < jeremyrubin> Yeah It creates less or similar UTXOs because you eliminate the need for change 18:03 < jeremyrubin> ANd overall chain space use is smaller --- Log closed Sat Mar 14 00:00:22 2020