--- Log opened Sun Mar 15 00:00:22 2020
06:59 < bsm117532> FWIW, I'm still not sold on congestion control. I see lots of other motivations for CTV, but congestion control adds a lot of complexity (wallet support, in particular) for marginal gain.
07:00 < bsm117532> I like CTV use for vaults, and the mining pool idea is neat but I think possibly impractical. I'll have to think about it more...
07:01 < bsm117532> Is it safe for two different mining pools to participate in this decentralized pool? It would be quite interesting if 100% of pools could use it without risk of 51% attack.
07:02 < bsm117532> Pools tend to stay in the ~20% hashrate range, a factor of 5 reduction in variance for everyone is very interesting.
07:02 < bsm117532> It would also lower the hashrate threshold to be a viable pool.
07:03 < bsm117532> In my MCC talk I calculated that if a miner wants no more than a 1% variance on his annual return, he needs a pool that's at least 19% of the hashrate.
07:06 < bsm117532> However, even with smoothing over blocks like this, you still have a variance in the number of blocks you win, and this doesn't change that.
07:07 < bsm117532> e.g. given blocks per year B = 19% * 144* 365, the Poisson error on the number you win is 1/sqrt(B) = 1%
07:08 < bsm117532> Mmmm...no, I'm wrong...
07:09 < bsm117532> I'd win a payout in every block, assuming I have a block within the "lookback window".
07:10 < bsm117532> Let's assume for simplicity that the lookback window is 1 year (52560 blocks)
07:10 < bsm117532> And 100% of miners are participating.
07:11 < bsm117532> Mmmmm...no I was right. To get < 1% variation on my annual return, I need to have won 19% of the blocks within the lookback window.
07:11 < bsm117532> The fact that it's smoothed doesn't help me (on an annual basis -- though monthly the payouts will come more regularly).
07:13 < bsm117532> So it seems to me, this doesn't practically allow smaller pools. It does smooth payouts on timescales less than the lookback window, but I need a 19% pool.
07:14 < bsm117532> I wonder if miners would be interested in that. That 1% annual variance number corresponds to a 3.5% monthly variance.
07:15 < bsm117532> So with a 1 year lookback window, you're bringing 3.5% variance down to 1%, and I suspect  miners won't care about having payouts faster than that, as monthly is the billing cycle for services (rent, electricity)
07:15 < bsm117532> jeremyrubin: do you agree with that?
07:16 < bsm117532> So I land on: (1) the mining idea does not allow smaller pools. (2) it reduces variance on a monthly basis by 3.5% -> 1% assuming a 19% pool.
07:16 < bsm117532> This seems to me to be a marginal benefit to miners... :-/
07:19 < bsm117532> I used to run a well-known mining operation. I can reach out to some miner friends and ask... I know pool counterparty risk is a huge concern for the more reputable operations, but this doesn't address that at all. :-/
07:21 < bsm117532> Poisson statistics are a bitch. The only solution is faster blocks, which is why I landed on a merge-mined DAG-chain (braidpool) for this. You just can't hack your way around the Poisson statistics of 52560 blocks/year.
07:36 < bsm117532> With a lookback window of 1 year, and 100% of miners participating, this also creates 52560 committed UTXO outputs *per*coinbase*
07:36 < bsm117532> This is FAR larger than the system can handle, as you only have roughly 2000 transactions per block, max.
07:38 < bsm117532> Assuming cashouts of these committed UTXOs saturate all blocks at around 2000 tx/coinbase, your lookback window can be no larger than 2000 blocks.
07:38 < bsm117532> This is a max lookback window of about 14 days.
07:40 < bsm117532> This is a WAY worse problem than the variance discussion above. Without a means to aggregate payouts, this proposal simply creates too many outputs to be useful. :-(
12:36 -!- Netsplit *.net <-> *.split quits: kanzure
12:36 -!- kanzure_ [~kanzure@unaffiliated/kanzure] has joined ##ctv-bip-review
13:30 -!- Netsplit *.net <-> *.split quits: harding, nothingmuch
13:30 -!- harding_ [quassel@2600:3c03::f03c:91ff:fe7b:78d1] has joined ##ctv-bip-review
13:30 -!- Netsplit over, joins: nothingmuch
16:54 < jeremyrubin> I think everything you said is completely off haha
16:55 < jeremyrubin> Are you ignoring non-interactive payment channel tree pools intentionally?
16:55 < jeremyrubin> Are you also ignoring that your math on mining pools viability applies equally to existing mining pools?
16:56 < jeremyrubin> You're also missing the fact that you can reuse keys for mining blocks so that your payout is proportionate to the number of shares you earned in the period not the total number of blocks
16:57 < jeremyrubin> so if I have 100 blocks out 2000, I only have 1 output in the share
16:58 < jeremyrubin> You can also do alternative pooling structures but the game theory is less clear to me; e.g., you pay out only to yourself and to the last person (or N people) in the lookback window. Then people get a single larger payout when their 'share' is 'expiring'
17:00 < jeremyrubin> I think you're also missing that you can window based on time and not blocks btw or a mix. I haven't done out the math completely but my hunch is that different windowing strategies can yield fairer results
17:49 -!- kanzure_ is now known as kanzure
--- Log closed Mon Mar 16 00:00:24 2020