--- Log opened Sat Feb 15 00:00:39 2020 03:09 -!- belcher [~belcher@unaffiliated/belcher] has joined #braidpool 12:40 < bsm117532> hodlwave your first pastebin looks correct to me. 12:41 < bsm117532> Rest of your comments are correct too, I think. 12:41 < bsm117532> Yes, shares must be recomputed every time a cohort changes, which could happen due to high-latency beads. 12:42 < bsm117532> So, shares (rewards) must be computed ex-post-facto, in contrast to Bitcoin's rewards which are computed and claimed by the miner in his coinbase. 12:42 < bsm117532> Since that miner can't possibly be aware of other competing beads produced at roughly the same time, he can't possibly compute his own reward. 12:42 < bsm117532> So the system must compute rewards some time later, after cohorts have sufficiently "settled". 12:43 < bsm117532> In bitcoin this is analagous to the 100-block coinbase spending rule (coinbase coins can't be spent for 100 blocks after they're mined). 12:44 < bsm117532> Using the same number just for simplicity, braidpool would compute rewards 100 bitcoin blocks (= 16.7 hours on avg) later, after which high-latency beads wouldn't be accepted into the DAG. 12:46 < bsm117532> Braidpool miners would just publish an address, and not actually claim tx-fee coins or share-pool coins in a coinbase. 100 bitcoin blocks later, relevant UTXOs would be created, computed from the cohorts seen 100 blocks ago. 12:48 < bsm117532> My preference for share-coin allocation is to have them be directly proportional to difficulty, and NOT computed as a function of cohort structure. So if rewards are done that way, each bead could create its share-coin UTXO for the miner. 12:49 < bsm117532> This choice prevents some latency-based game theory -- the whole orphan problem exists because one miner gets paid and the orphaned miner doesn't, which causes the game. In braidpool, miners would earn the same share-coins regardless of their latency (up to some reasonable limit). 12:49 < bsm117532> Removing incentives to screw around with graph structure and naming parents -- you're going to get paid the same anyway. 12:58 < bsm117532> Tx fees *may* be a different matter however, since two miners on opposite sides of a diamond graph may include the same transaction. But you could just allocate them to only one of the miners based on luck in case of a tie too. 17:56 < hodlwave> Ok so the cohort structure is used to agree on Tx ordering but not on share-coin rewards. Makes sense. 18:00 < hodlwave> So braidpool would help miners that are mining over a high latency connection like Tor right? Because would no longer pay the penalty of missing out on a block due to their slower connection... 18:03 < hodlwave> Isn't this cost borne by the other members of the pool with lower latency connections? Because the pool might still miss out on valid Bitcoin blocks the Tor hashers find while compensating them for shares they find 18:03 < hodlwave> Maybe I'm missing something. Still trying to put a lot of the pieces together 19:28 < bsm117532> At the end of the day, we can't get away from the fact that the bitcoin blockchain is a synchronous sysstem. 19:29 < bsm117532> So, high-latency beads that could never become bitcoin blocks (because they would be orphans) must be punished (unfortunately). 19:29 < bsm117532> A perfect DAG-chain could avoid this, but as braidpool will sync to a synchronous system, there's a time parameter describing that synchronicity. 19:30 < bsm117532> So, if your braidpool bead is delayed by 10+ minutes, we can't afford to give you rewards. 19:31 < bsm117532> Fortunately, braidpool provides a way to *measure* global latency, and use that as a parameter in the rewards algorithm. 19:32 < bsm117532> The measure of the number of beads per cohort is exactly this measurement, and is directly related to bitcoin's orphan rate. 19:33 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 19:34 < bsm117532> Now, high-latency beads must be punished unfortunately, but not that much. The expected bead time will be around 0.5s-1s, as described on my github. But a 1s delayed bead need only be punished by e.g. 1/600 which is the rough probability that it will be a bitcoin orphan. 19:35 < bsm117532> The exact reward formula is left as an exercise for the reader, but the parameters are available (beads/cohort) as part of consensus. 19:38 < hodlwave> Oh gotcha, so a high latency bead is punished only so often as it will generate a Bitcoin orphan right? 19:46 < bsm117532> Yes, high latency beads should be "punished" in *exact* proportion to their probability to be a bitcoin block. Anything else will generate game theory, and we have a high-statistics measurement of that probability since the bead time is much faster than the bitcoin block time. 19:48 < bsm117532> We have some extra tools here in ex-post-facto evaluation of rewards. 19:51 < hodlwave> Cool, makes sense. 19:52 < bsm117532> And evaluation of whether a bead could have been a bitcoin block is basically an exact science. You can falsify DAG structure in one direction only -- increasing latency, which only hurts you. 19:53 < bsm117532> That said, a more careful evaluation of the exact algorithm we land on WRT the 51% attack, selfish mining attacks, etc is required. --- Log closed Sun Feb 16 00:00:41 2020