03:43:40 Would this be the right place to find someone to discuss my proposal with me? 03:43:41 I posted to https://monero.town/post/6526877 and https://github.com/monero-project/research-lab/issues/136#issuecomment-3191634811 03:43:43 It was responded to in both places, but after having considered the criticisms, including fully reading the github discussion, I do not understand how they apply. 03:43:45 Combined with something related to the miners sign the blocks idea, as far as I can see, this idea would provide the following benefits: 03:43:47 1. Increase cost of flash attacks by an arbitrary amount without punishing long term committed miners. 03:43:49 2. provides the solution to make miners signing blocks sybil attack proof (or at least does not allow a sybil attack to by pass the above penalty. 03:43:51 3. allows for potentially limiting the percentage of total hash rate any one identity can contribute, which could be a pressure to break up large pools without preventing the use of p2pool. (it doesn't force this however, merely forces a more complicated command and control infrastructure.) 03:43:53 I know that the devs are all very busy, but this is not leaving my brain even after much thought on my part as to why it was dismissed, so I would love to have a two way discussion to help me understand why this wouldn't work. It'll help me sleep better if nothing else. 03:43:55 Thanks for considering. 10:45:34 I put my proposal up as well. I hope it's constructive and bs as my previous one! 10:45:35 https://github.com/monero-project/research-lab/issues/141 10:45:56 *not bs as my previous one 11:27:41

for fluffys proposal on defending against selfish mining, cant that be spoofed? 11:46:30 removed? 11:48:49 orange_horizon: , from a quick glance, the idea has the identity tracking problem. There are ways around that i think 11:55:10 gingeropolous: Thanks for the response, I believe this identity tracking problem is what was discussed by Fluffy in relation to another kind of similar idea that Tevador mentioned in their response to me on github. 11:55:11 However, I think that if the hashrate can be tracked per identity as my idea puts forward, then because the penalty is paid upfront, making new/bogus identities is no longer economically positive for the attacker. 11:55:13 Do you know if there is anywhere i can read up on the identity tracking problem? All of what I read in the git hub discussion on 'Miner signing blocks' seemed to point to the ease with which new identities can be assumed. is that the problem or is there more to it? 11:58:00 naw, the miner signing blocks is different. It just means that pooled mining is impossible, doesn't really have to do with identity. just modifies the block creation process in a way .. its what wownero did afaik. 11:59:49 no? 12:00:01 the link works for me 12:00:20 I couldnt see it either. 12:00:26 404 12:00:40 u sure your github account not flag or anything? 12:01:04 how do I check that? 12:03:06 my account doesn't show if i'm logged out / in private browser.. strange 12:03:08 https://webapps.stackexchange.com/a/172303 12:04:48 Would you be so kind as to describe the identity tracking problem for me? 12:04:49 Perhaps that is what I am missing in my understanding of why my concept doesn't work. 12:14:07 from what im reading, a miner needs to submit something to the network to have their hashrate essentially tracked. So i'm a miner, and i submit some PoW share to the network, how is this being managed by the protocol? Then, when i find a block, how does the protocol dig up which miner verification shares were yours? 12:14:56 honestly I think it could be addressed with hash commitments, kinda similar to the idea i slapped together that would give weight to long-term miners during fork choices. 12:15:26 but your gonna end up with a boatload of these miner verification data blobs on the blockchain 12:15:33 with your approach methinks 12:17:06 (how does the protocol dig up which miner verification shares were mine) is how that one line should read 12:17:08 I was thinking that long term these verifications do not matter, so if they were stored in a way that can be pruned, then it would be safe to prune them once the averaging window has passed., tbh my main worry was that the bandwidth required would be too high. 12:17:51 each verification would be signed by the identities private key. which ties that share to that identity. 12:18:21 but yeah imo its driving towards the notion that I tihnk has merit - in general, novel fast-spike hashrate is likely nefarious 12:18:51 but how do you weave a permissionless protocol around that 12:19:46 because novel high hashrate could be benign. someone could have just decided to build a datacenter to mine monero because they support the protocol, and is there anything "wrong" with that? 12:20:49 however, any approach that uses this notion of .... building trust by creating higher bars of effort, still allows an attacker to put in the work to eventually gain a foothold 12:21:06 yeah i understand that, it is one of the 'drawbacks' that I thought of. in fact any new hash rate has to pay the penalty, large or small. 12:21:15 its just more work than hur dur let me pay some mercenaries for a day 12:22:10 The idea is that if the attacker has enough resources to overcome the penalty, then it is likely that we wouldn't have been able to stop them anyway. 12:22:33 yeah. 12:23:24 at any point if the system is permissionless, then you by definition cannot deny access. to anyone. however if the incentive is to act in best interests then it improves the security. 12:24:17 which is why I think these investigations into how to prevent selfish mining may be more beneficial 12:25:29 the penalty could be anything but i was thinking maybe 4 to 10 times the standard difficulty over about a three to six month period. for an average miner adding a rig, it just means writing off half your earnings for the period, which isn't much compared to the cost of gear. 12:25:44 thanks. am indeed shadow-banned. posted here instead. (and opened a support ticket at github) 12:25:45 see https://matrix.to/#/!toFcRZtpaiwiyapgVO:matrix.org/$rQuYTxjemVzPvkMQyFCE1VQPds1gjyytVNCrohtS2-A?via=matrix.org&via=monero.social&via=cypherstack.com 12:26:50 i think that my idea is complimentary to this. both would work together. preventing selfish mining doesn't raise the bar of the 51% attack but does improve things below that threshold. 12:26:51 my concept increases the bar, but only for a time. 12:29:32 my concept also, i think provides an advantage to p2pool over classic pools as well. this is because if a pool is setup under an identity and hash rate is added to it, then every miner in the pool suffers the penalty, it is shared over the pool. by contrast because p2pool miners are individual, they would only have to pay for hash rate they increased themselves. 12:30:54 also if the hash rate can be tracked for identities then it is possible to penalise unsigned blocks, as well as penalise all hash rate forever that exceeds a given percentage of the network rate to force large pools to atleast run multiple identities. 12:31:11 qubic has just had a halving of its coin emission, so we'll see how it affects the hashrate 12:35:17 there isn't anything 'wrong' with that, under this system every one has had to pay the penalty for all of their hash rate, so in that sense it is not unfair to new people joining, although it could be perceived as a barrier to entry, it is also a reason to remain committed as well. 12:39:47 Anyways thanks for the chat gingeropolous I have to go. last thing is, should this idea go back to the github repo as its own separate issue? or is it better here until further analysed? 12:39:47 I'm not up with the etiquette but just want to contribute what i can without causing fuss. 13:52:46 ofrnxmr: Would you mind if I publish your raw patch in a gist? I would probably also switch out checkpoints.moneronet.info and checkpoints.moneroconsensus.info for checkpoints.townforger.net checkpoints.townforgepool.net because the latter two domains are less likely to cause DNS availability issues. 13:54:53 Er, my patch has a workaround in it due to a bug 13:55:22 So its ugly... i'd prefer if the bug was fixed :P 13:56:24 Let me see if i can get the patch cleaned up 15:27:29 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/ZQVcgUfMWpQjlOyfGothTeZY 15:29:34 Qubic average 3 hours I watched it was 2ghs- 2.3ghs. The average in the past was around 2.5ghs to 3ghs 15:38:31 I believe whatever value you see up there you can discard it as irrelevant 15:38:33 would be nice to have a tool that calculates the hashrate based on the last X blocks mined 15:39:39 let's call it: blockrate 15:42:20 It’s the best we have right now and the amount of blocks per 1,000 with qubic went 29% to 24%. 15:45:29 So is this a perfect representation of how they’re doing? No it isn’t, but I was just trying to see if the halving they had today had any effect 15:50:56 This can be faulty with selfish mining. You have to manually do it based on context 15:52:20 it's faulty also to trust the data the pool submits regarding their hashrate 15:53:13 read an issue on gh which explained there is a way to gather leaked data from miners and detect when selfish mining is happening 15:54:29 Yes, going through the original paper on that now. The pool distributes work and you can see an unexpected block hash in that request 15:55:42 then we can accurately determine hashrate from blocks, even when selfish mined 15:56:03 you still only know they are selfish mining or attempted to 15:56:17 just helps confirm that the block time in header was indeed correct 15:56:34 you might catch some orphans they generate that way that never get published, too 16:05:03 I watched it for hours and the highest qubic reported I saw was 2.3gh/s sure this still a lot and a interesting tid bit is that it also seemed like supportxmr and nano pool got a bump from their hashrate too. Maybe this is a coincidence, but it’s possible that there is movement from the qubic pool to those pools. 16:36:18 https://github.com/monero-project/monero/pull/10029 I knew `monerod` was lying to me about connections count. I wasn't just imagining it! https://libera.monerologs.net/monero-research-lounge/20250515#c526065 16:36:19 Thanks, vtnerd 19:25:47 could anyone elucidate on this 19:25:47 i get the block height by RPC 19:25:49 ``` 19:25:51 curl -sX POST http://monero.leonardofaoro.com:18081/json_rpc -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":"0","method":"get_info"}' | jq '.result.height' 19:25:53 3482191 19:25:55 ``` 19:25:57 then I take the height reported by monerod 3482191 and get the latest block 19:25:59 ``` 19:26:01 curl -sX POST http://monero.leonardofaoro.com:18081/json_rpc -H 'Content-Type: application/json' -d "{\"jsonrpc\":\"2.0\",\"id\":\"0\",\"method\":\"get_block\",\"params\":{\"height\":3482191}}" | jq 19:26:03 { 19:26:05 "error": { 19:28:09 Yes status reports block height being mined 19:28:49 thank you vt 19:31:11 therefore to get the latest block it's just current_height-1 19:36:21 in the minertx there's a key and a viewtag, can those be used to check the miner wallet? 19:39:38 in the minertx there's a key and a viewtag, can those be used to check the miner wallet? or what's their purpose 19:40:49 A viewtag is not a view key. Every Monero tx now has a view tag. 20:25:52 [@gingeropolous:monero.social](https://matrix.to/#/@gingeropolous:monero.social) 20:26:47 https://matrix.monero.social/_matrix/media/v1/download/xmr.mx/OJBfHXsJuOKJWTXOjkfhqelz 20:38:40 Leonardo: https://localmonero.co/knowledge/view-tags-reduce-monero-sync-time?language=en 20:48:16 hello, I missed the meeting but regarding Mining Rig Rentals Funds, I think the gameplan I am going with tomorrow is to keep an eye on this chat and if there arises an urgent need for hashrate I can deploy. 20:53:49 makes sense to make a new wallet that now supports this feature, transfer all funds and decomission old wallets which txs don't have the tag, this way every time you have to sync your wallet again, it'll be 40% faster 21:01:27 That's not how it works. You don't get the speedup benefit for existing txs without viewtags if you scan them 21:01:53 Better to just churn XMR to yourself and change your refresh height 21:03:05 Also, all wallets support view tags by design . you don't need to create a new wallet for view tags 21:03:26 If you have made a Monero tx in the last 3 years, you've used viewtags 21:13:45 my wallet restore height is 2237000, this means those transactions before viewtags were introduced will be slow to sync 21:13:45 checked the date on that block 21:13:47 ```date --date="@1606147042" 21:13:49 Mon Nov 23 17:57:22 EET 2020``` 21:13:51 how do you churn monero to yourself? you mean the sweep function in monero gui? 21:13:53 once I do that I can use the new height for the restore of the wallet? 21:13:56 my wallet restore height is 2237000, this means those transactions before viewtags were introduced will be slow to sync 21:13:57 checked the date on that block 21:13:59 ````date 21:14:01 Mon Nov 23 17:57:22 EET 2020``` 21:14:03 ```` 21:14:05 my wallet restore height is 2237000, this means those transactions before viewtags were introduced will be slow to sync 21:14:07 checked the date on that block 21:14:09 ````date 21:14:11 Mon Nov 23 17:57:22 EET 2020``` 21:14:13 ```` 21:14:15 how do you churn monero to yourself? you mean the sweep function in monero gui? 21:14:17 once I do that I can use the new height for the restore of the wallet? 21:19:19 All transactions before v15 did not have view tags, all transactions after v15 (ignoring the grace period) have view tags. Your wallets scans against *all* transactions on the blockchain, not just the ones that you own. This is how the wallet figures out which TXOs you own. Transactions with view tags are 40% faster to scan. So it doesn't matter how many of *your* txs have view ta gs , it matters how many *total* txs have view tags over the span of time that you're scanning . 21:20:30 Yeah you can use "sweep_all", or "transfer" if youre aware of which inputs you're using 21:21:11 After that, you can increase the restore height to sometime before the first unspent transaction 21:21:31 Also, please don't edit messages, it spams IRC 21:21:42 once I do sweep_all to my own wallet address, I can start the restore point from the new block height, right? 21:22:01 Yes 21:22:19 awesome, thank you jeffro 21:22:46 Ofc 21:24:31 the extra field in a block, is just a bunch of bytes represented as integers? 21:24:31 I tried to convert those ints to byte and read the extra message, but I end up with gibberish 21:24:33 ``` 21:24:35 [3 33 0 143 172 61 107 217 31 79 64 145 55 197 166 214 98 131 125 162 240 188 230 158 21 216 228 224 19 144 5 45 119 68 112 1 207 139 77 206 145 43 254 101 183 28 46 92 186 108 68 187 174 139 34 179 117 33 242 61 119 1 39 247 14 148 220 2 2 32 0 0 0 0 0 0 0 0 141 0 234 86 29 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0] 21:24:37 ``` 21:24:39 ``` 21:24:41 !=kO@7Ŧb}-wDpϋMΑ+e.\lD"u!=w' V 21:24:43 ``` 21:24:53 ^ this is the last block btw 21:27:49 is there a proper way to read the Extra field? 21:37:52 Blocks do not have an `extra` field, but txs do. You're looking at the extra field for the coinbase tx. The extra field contains transaction pubkeys, encrypted payment IDs, and mining nonces 21:38:02 Most of those are going to be largely uniform random bytes 21:38:58 But you can use the `cryptonote::parse_tx_extra()` function to look at the structure of a transaction extra field: https://github.com/monero-project/monero/blob/389e3ba1df4a6df4c8f9d116aa239d4c00f5bc78/src/cryptonote_basic/cryptonote_format_utils.cpp#L544 21:39:11 alternate golang implementation https://git.gammaspectra.live/P2Pool/consensus/src/branch/master/monero/transaction/extra.go 21:39:35 thank you guys 21:40:04 also if you want to parse only coinbase transactions https://git.gammaspectra.live/P2Pool/consensus/src/branch/master/monero/transaction/coinbase.go 21:42:33 Monero-rs is a rust crate that can do that too, I think that is a tari created block as the `3` tag is at the start and tari uses monero-rs internally. 21:46:01 monero-rs adds 3 in the extra of mined blocks? 21:46:06 monero-rs adds 3 in the extra of mined blocks? why 21:46:51 that's merge mining tag 21:47:26 p2pool has it, qubic has it 21:47:38 or anyone else who does merge mine, 21:47:52 `3` is the identifier of the merge mining field, I think core monero sorts the fields by tag so if core monero created it 3 wouldn't be first AFAIK 21:48:50 p2pool has pubkey first 21:49:14 from tests recently, qubic blocks that merge mine have the merge mine tag first 21:50:05 most recent example https://p2pool.io/explorer/tx/c4676ff1a10283b0287e96f359113c35ca73a4ae7fce53f973a2e72e4665c95b 21:50:17 (last of their blocks) 21:50:33 Yeah they are using the tari merge mine interface directly then, ig p2pool just takes the merge mining hash and creates its own block 21:52:37 pubkey of what? thought p2pool splits the coinbase to all addresses with shares 21:52:56 yep, p2pool has this https://github.com/SChernykh/p2pool/blob/master/src/pool_block_parser.inl#L175-L212 21:53:05 pubkey of the transaction private key 21:53:16 for example https://p2pool.observer/share/8be48c2ce394a62cb57d14bc7113c3d1c79c27879805d225162f0ff93602258b 21:53:22 think p2pool is the only blocks that have multiple vouts at the coinbase level 21:53:26 Coinbase Private Key f81909fd808af9cb4ea9e44683573ecfd7ff32a99f13b4489bb1d7317feb5600 21:53:47 if you go to payout proof of any of the outputs there like https://p2pool.observer/proof/02ecf51e1bb58218b830e258609518d89d665299c5ff55753d943ba2b19169df/0 21:54:04 you see you can use the tx private key to prove it's that address 21:54:21 or use any of the OutProofV2/V1 without sharing the tx private key directly 21:54:40 this can be verified for example, https://localmonero.co/blocks/tx/9a9604003b864200f35b1bea82bcae93a2234d44c0ea88ce1548d05d5d560d61?xmraddress=42QX3D639LUeuoVSe1DGXi6kPZtsCntimdwVu8a8FYpE7ggbrtvrQisErQxBPwWycJBniwR7VfV3PJMwAgnwHv1hPnF12qe&txprvkey=f81909fd808af9cb4ea9e44683573ecfd7ff32a99f13b4489bb1d7317feb5600 21:55:28 yes, ingenious, nice 21:55:35 I'd recommend looking into how monero works outputs wise, as there's many things that are different. you might find multiple public keys in the tx extra for example for any subaddresses the receivers might have 21:55:50 also some encrypted values for vendors (not recommended) etc.