01:03:52 <br-m> <fr33_yourself> I currently believe that tevador's proposals to mitigate selfish mining are the most promising. That being said, would it be possible for an attacker to spam the network with invalid workshares (that require verification) creating a DOS issue?
10:26:41 <br-m> <venture> is my assumption correct that the current MAX_TX_EXTRA_SIZE=1060 limits work-shares to be included to 13 ?
12:35:09 <br-m> <gp1688:matrix.org> I did not read https://github.com/monero-project/research-lab/issues/146#issuecomment-3344168035 thoroughly, but wonders whether a persistent network lag >6s will cost no one to produce the block?
15:12:45 <br-m> <venture> No. Exceeding d (network propagation delay), is not relevant for new blocks that extend the tip
15:15:35 <br-m> <venture> @venture: "is my assumption correct that the current MAX_TX_EXTRA_SIZE=1060 limits work-shares to be included to 13 ?"
15:15:35 <br-m> <venture> As per the last comment on GH, the number is rather 24-25 workshares since not all fields need to serialized and can be inferred from the block it is contained in (eg, prev_id)
15:16:50 <br-m> <venture> > <@fr33_yourself> I currently believe that tevador's proposals to mitigate selfish mining are the most promising. That being said, would it be possible for an attacker to spam the network with invalid workshares (that require verification) creating a DOS issue?
15:16:50 <br-m> <venture> "I currently believe that tevador's proposals to mitigate selfish mining are the most promising. That being said, would it be possible for an attacker to spam the network with invalid workshares (that require verification) creating a DOS issue?"
15:16:50 <br-m> <venture> I don't think this is an issue. It's one hash with the nonce provided and check the target against diff(x)/w
15:54:13 <br-m> <rucknium> @venture:monero.social: No, AFAIK. Max tx_extra size is for user txs relayed through the network. It isn't even a consensus rule for user txs. Coinbase txs aren't subject to it, AFAIK. > <@venture> is my assumption correct that the current MAX_TX_EXTRA_SIZE=1060 limits work-shares to be included to 13 ?
15:58:23 <sech1> 1060 bytes limit is for mempool
15:58:34 <sech1> coinbase transactions are a different thing, they don't have this limit
15:59:53 <DataHoarder> > Coinbase txs aren't subject to it, AFAIK.
15:59:53 <DataHoarder> They have no effective limit which makes decoding them from the wild quite fun buffer wise :D
16:00:03 <DataHoarder> besides max p2p size
16:16:34 <DataHoarder> some of the fields in tx extra have a commonly agreed encoding... but really it could be anything 
16:18:44 <DataHoarder> also, workshares could be effectively committed into the merge-mine tag (or other) and not have the full data within, and this be transferred via alternative means that allows not retaining it in the future
16:19:14 <DataHoarder> that'd make it compatible with most pool backed systems out there that have merge mining support for Tari or others
16:38:08 <br-m> <venture> DataHoarder: I'm not familiar with the merge-mine tag, but would this change things regarding space requirements?
16:38:32 <DataHoarder> basically that tag is a merkle root of a merkle tree with various chains
16:38:40 <DataHoarder> the size is constant for however much data you have
16:39:02 <DataHoarder> however, this data + merkle proof (a couple of single hashes, not pow related) need to be presented on a side channel
16:39:13 <DataHoarder> the merkle proof allows verifying that block included this data
16:39:14 <br-m> <venture> and the data of the merkle root is stored where?
16:39:22 <DataHoarder> by looking at the merkle root on coinbase transaction
16:39:52 <DataHoarder> that's a side channel. you can have this be monero p2p, stored, sent via pigeon carrier, "attached" to blocks for nodes that support it
16:40:13 <DataHoarder> but the block is valid "as is" for nodes that don't know about workshares
16:40:19 <DataHoarder> (or merge mined chains as example)
16:40:44 <DataHoarder> storage requirements don't change much, but with this you can make them not permanent
16:41:04 <DataHoarder> you can opt to keep all data, or not keep old workshare data, or once they are not needed forget it
16:41:14 <br-m> <venture> ah okay this makes sense
16:41:16 <DataHoarder> the only data that is kept on-chain is in the coinbase transaction hash tag
16:41:28 <DataHoarder> this is also mentioned on the tracking GH issue
16:41:43 <DataHoarder> (As a bonus adapting a system that already merge mines to this is somewhat easier)
16:43:17 <br-m> <venture> I was somewhat hoping that the merge-mine tag would allow for paying shares, what i proposed on the GH issue 😅 
16:45:40 <DataHoarder> merge mine tag is used for example to prove that you are mining on monero, then p2pool and tari as sidechains
16:46:02 <DataHoarder> example this block mined Tari and P2Pool share as well as the Monero block https://blocks.p2pool.observer/block/8aa3ad2789710f2485bb1381806e26466709f9868db82f9346c7ee207ca14473
16:46:26 <DataHoarder> tari data is a "hash" of their own blob that gets published to make their block elsewhere
16:46:53 <DataHoarder> actually, heh, you could probably design this workshare system as basically a p2pool-like sidechain
16:47:09 <DataHoarder> for sharing of workshares and other assorted data
16:48:20 <br-m> <venture> DataHoarder: yes, the concept seems pretty similar to pool mining
16:48:43 <DataHoarder> yeah, but that's how you could fling the data across, either separate or across monero p2p :)
16:49:01 <DataHoarder> and if using mm tags ... the sidechain would be the Monero block + workshares
16:49:41 <DataHoarder> merkle root commits the workshares you are mining along (plus any other merge mined sidechains)
16:53:23 <br-m> <venture> with w=16 it might actually replace the big p2pool > <DataHoarder> actually, heh, you could probably design this workshare system as basically a p2pool-like sidechain
16:54:12 <DataHoarder> if the idea is to have majority pools have it, it's not so much replacing p2pool, just that you end up with a larger sidechain
16:54:30 <DataHoarder> after all, point of p2pool is to share payouts in smaller slices, not produce workshares (side effect)
16:55:06 <DataHoarder> it uses the weighted shares based on difficulty when it was found to then aggregate payouts :)
16:55:57 <br-m> <venture> ah shit.. i keep forgetting that they are not paid. never mind :)
16:56:00 <DataHoarder> not far off, but critically workshares can only be used within similar heights with less leeway, and anything past a few heights is not relevant
16:57:05 <br-m> <venture> yes, 267MHs current p2pool to 312MHs (5GHs/16)
16:57:25 <DataHoarder> effectively the "hashrate" would be the same wouldn't it?
16:57:42 <DataHoarder> as pools would basically be merge mining and publishing workshares
16:57:58 <DataHoarder> hashrate of p2pool sidechain ~= hashrate of p2pool in main chain
16:58:47 <br-m> <venture> yes, it wouldn't change. it's not even merge-mining and more like normal mining with 2 thresholds (it will be the same hashing blob), first threshold for being a share, second threshold for being a block
16:59:02 <DataHoarder> yes, that's merge mining
16:59:11 <DataHoarder> same hashing blob, different thresholds
16:59:21 <DataHoarder> you send out hashing blob + aux data (in this case workshares)
17:00:12 <br-m> <venture> ah okay :)
17:00:31 <DataHoarder> it's not directly comparable (as you want to closely tie workshares to the specific Monero block id/prev id / height) but here's a nice overview + api P2Pool follows for example for Tari and others https://github.com/SChernykh/p2pool/blob/master/docs/MERGE_MINING.MD
17:01:06 <DataHoarder> merge_mining_get_aux_block sets difficulty, merge_mining_submit_solution sends the blob / proof / template
17:02:44 <DataHoarder> note I am not saying that it has to follow or is this but you can have a tight adapted method along same lines that more or less works with common merge mine methods
17:04:35 <br-m> <venture> thanks. yes, it has some differences, but definitely closely related
17:11:11 <br-m> <venture> was there ever a re-org or selfish-mining happening on p2pool btw? it already has uncles, but rewards the miner that includes the uncle similar to ethereum I think (which was sub-optimal wrt to preventing selfish mining)
17:15:01 <DataHoarder> there have been reorgs, but its allowed uncle depth of 3 allows this to reorg more often
17:15:16 <DataHoarder> some p2pool sidechains have different % 
17:15:41 <DataHoarder> otherwise, there was one big miner with basically borked networking that kept mining behind
17:15:51 <DataHoarder> and releasing these at various intervals
17:16:14 <DataHoarder> and some big miner that bumped mini difficulty past main (more hashrate) though sech1 has more details there
17:17:28 <DataHoarder> at each miner entity you can see a uncle shares counter https://p2pool.observer/miners
17:18:13 <DataHoarder> some bad miners have even orphaned shares (they were mining behind or out of sync)
17:18:54 <DataHoarder> I can't remember but one big miner recently had one of their shares orphaned out, but that share also found a Monero block :)
17:19:28 <DataHoarder> aha, here https://p2pool.observer/share/de4509fef792d13cacc07188771976850134480d9b793a6fa91b676ec1ba685c
17:20:12 <DataHoarder> this is different from a share that mined a monero block but was orphaned from monero itself
17:22:44 <br-m> <venture> DataHoarder: wow that's wild :D
17:23:08 <DataHoarder> bad miners, sometimes with offset clocks +-15m
17:23:15 <br-m> <venture> but that orphaning didn't affect the immediate payout right?
17:23:29 <DataHoarder> or some with worse, but that gets blocked at share verification time
17:23:31 <br-m> <venture> from mining the monero block itself
17:23:35 <DataHoarder> no, that's just p2pool itself
17:23:42 <DataHoarder> it just doesn't count for the miner weight
17:24:06 <DataHoarder> (reward share% = miner weight / total weight
17:24:58 <br-m> <venture> yes I see. still funny.
17:25:01 <DataHoarder> it's funny as this miner had shares before, and one after within uncle distance
17:25:12 <DataHoarder> so they COULD have included it as one of their own uncles
17:25:41 <DataHoarder> but they did not ^ (I actually wonder why, sech1, maybe they had different p2pool instances and share didn't propagate well?)
17:26:36 <sech1> The same instance would have included that share
17:26:47 <DataHoarder> yeah, as they have it locally
17:26:58 <sech1> So they probably run multiple instance
17:27:06 <DataHoarder> their clock was out of wack, lol
17:27:28 <DataHoarder> they mined it 5m late
17:27:39 <DataHoarder> so probably some system stuck behind
17:27:50 <DataHoarder> if we assume clock is right, it was mined late
17:27:52 <br-m> <venture> well, if it's all due to offset clock, it's not intentional at all.. 
17:27:52 <br-m> <venture> Is the SoP proposal somewhat less affected by clock sync? I thought it only needs local time and not be in sync with everyone else's clock?
17:27:59 <DataHoarder> if it was mined in time it'd have been uncled
17:28:21 <DataHoarder> afaik SoP only cares about block heights and ids
17:28:38 <DataHoarder> and a monotonic local clock to handle the time decay
17:30:10 <br-m> <venture> DataHoarder: that's my understanding as well