<o​range_horizon:matrix.org> Would this be the right place to find someone to discuss my proposal with me?

<o​range_horizon:matrix.org> I posted to monero.town/post/6526877 and monero-project/research-lab #136#issuecomment-3191634811

<o​range_horizon:matrix.org> 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.

<o​range_horizon:matrix.org> Combined with something related to the miners sign the blocks idea, as far as I can see, this idea would provide the following benefits:

<o​range_horizon:matrix.org> 1. Increase cost of flash attacks by an arbitrary amount without punishing long term committed miners.

<o​range_horizon:matrix.org> 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.

<o​range_horizon:matrix.org> 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.)

<o​range_horizon:matrix.org> 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.

<o​range_horizon:matrix.org> Thanks for considering.

<v​enture:monero.social> I put my proposal up as well. I hope it's constructive and bs as my previous one!

<v​enture:monero.social> monero-project/research-lab #141

<v​enture:monero.social> *not bs as my previous one

<n​oname-user0:matrix.org> for fluffys proposal on defending against selfish mining, cant that be spoofed?

<b​asses:matrix.org> removed?

<g​ingeropolous:monero.social> orange_horizon: , from a quick glance, the idea has the identity tracking problem. There are ways around that i think

<o​range_horizon:matrix.org> 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.

<o​range_horizon:matrix.org> 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.

<o​range_horizon:matrix.org> 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?

<g​ingeropolous:monero.social> 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.

<v​enture:monero.social> no?

<v​enture:monero.social> the link works for me

<o​range_horizon:matrix.org> I couldnt see it either.

<b​asses:matrix.org> 404

<b​asses:matrix.org> u sure your github account not flag or anything?

<v​enture:monero.social> how do I check that?

<v​enture:monero.social> my account doesn't show if i'm logged out / in private browser.. strange

<b​asses:matrix.org> webapps.stackexchange.com/a/172303

<o​range_horizon:matrix.org> Would you be so kind as to describe the identity tracking problem for me?

<o​range_horizon:matrix.org> Perhaps that is what I am missing in my understanding of why my concept doesn't work.

<g​ingeropolous:monero.social> 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?

<g​ingeropolous:monero.social> 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.

<g​ingeropolous:monero.social> but your gonna end up with a boatload of these miner verification data blobs on the blockchain

<g​ingeropolous:monero.social> with your approach methinks

<g​ingeropolous:monero.social> (how does the protocol dig up which miner verification shares were mine) is how that one line should read

<o​range_horizon:matrix.org> 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.

<o​range_horizon:matrix.org> each verification would be signed by the identities private key. which ties that share to that identity.

<g​ingeropolous:monero.social> but yeah imo its driving towards the notion that I tihnk has merit - in general, novel fast-spike hashrate is likely nefarious

<g​ingeropolous:monero.social> but how do you weave a permissionless protocol around that

<g​ingeropolous:monero.social> 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?

<g​ingeropolous:monero.social> 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

<o​range_horizon:matrix.org> 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.

<g​ingeropolous:monero.social> its just more work than hur dur let me pay some mercenaries for a day

<o​range_horizon:matrix.org> 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.

<g​ingeropolous:monero.social> yeah.

<o​range_horizon:matrix.org> 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.

<g​ingeropolous:monero.social> which is why I think these investigations into how to prevent selfish mining may be more beneficial

<o​range_horizon:matrix.org> 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.

<v​enture:monero.social> thanks. am indeed shadow-banned. posted here instead. (and opened a support ticket at github)

<v​enture:monero.social> see matrix.to/#/!toFcRZtpaiwiyapgVO:mat…a=monero.social&via=cypherstack.com

<o​range_horizon:matrix.org> 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.

<o​range_horizon:matrix.org> my concept increases the bar, but only for a time.

<o​range_horizon:matrix.org> 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.

<o​range_horizon:matrix.org> 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.

qubic has just had a halving of its coin emission, so we'll see how it affects the hashrate

<o​range_horizon:matrix.org> 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.

<o​range_horizon:matrix.org> 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?

<o​range_horizon:matrix.org> I'm not up with the etiquette but just want to contribute what i can without causing fuss.

<r​ucknium:monero.social> 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.

<o​frnxmr:xmr.mx> Er, my patch has a workaround in it due to a bug

<o​frnxmr:xmr.mx> So its ugly... i'd prefer if the bug was fixed :P

<o​frnxmr:xmr.mx> Let me see if i can get the patch cleaned up

<b​arthman132:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/ZQVcgUfMWpQjlOyfGothTeZY

<b​arthman132:matrix.org> Qubic average 3 hours I watched it was 2ghs- 2.3ghs. The average in the past was around 2.5ghs to 3ghs

<l​eonarth_:matrix.org> I believe whatever value you see up there you can discard it as irrelevant

<l​eonarth_:matrix.org> would be nice to have a tool that calculates the hashrate based on the last X blocks mined

<l​eonarth_:matrix.org> let's call it: blockrate

<b​arthman132:matrix.org> It’s the best we have right now and the amount of blocks per 1,000 with qubic went 29% to 24%.

<b​arthman132:matrix.org> 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

<v​tnerd:monero.social> This can be faulty with selfish mining. You have to manually do it based on context

<l​eonarth_:matrix.org> it's faulty also to trust the data the pool submits regarding their hashrate

<l​eonarth_:matrix.org> read an issue on gh which explained there is a way to gather leaked data from miners and detect when selfish mining is happening

<v​tnerd:monero.social> Yes, going through the original paper on that now. The pool distributes work and you can see an unexpected block hash in that request

<l​eonarth_:matrix.org> then we can accurately determine hashrate from blocks, even when selfish mined

you still only know they are selfish mining or attempted to

just helps confirm that the block time in header was indeed correct

you might catch some orphans they generate that way that never get published, too

<b​arthman132:matrix.org> 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.

<r​ucknium:monero.social> monero-project/monero #10029 I knew `monerod` was lying to me about connections count. I wasn't just imagining it! libera.monerologs.net/monero-research-lounge/20250515#c526065

<r​ucknium:monero.social> Thanks, vtnerd

<l​eonarth_:matrix.org> could anyone elucidate on this

<l​eonarth_:matrix.org> i get the block height by RPC

<l​eonarth_:matrix.org> ```

<l​eonarth_:matrix.org> curl -sX POST monero.leonardofaoro.com:18081/json_rpc -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":"0","method":"get_info"}' | jq '.result.height'

<l​eonarth_:matrix.org> 3482191

<l​eonarth_:matrix.org> ```

<l​eonarth_:matrix.org> then I take the height reported by monerod 3482191 and get the latest block

<l​eonarth_:matrix.org> ```

<l​eonarth_:matrix.org> curl -sX POST monero.leonardofaoro.com:18081/json_rpc -H 'Content-Type: application/json' -d "{\"jsonrpc\":\"2.0\",\"id\":\"0\",\"method\":\"get_block\",\"params\":{\"height\":3482191}}" | jq

<l​eonarth_:matrix.org> {

<l​eonarth_:matrix.org> "error": {

<v​tnerd:monero.social> Yes status reports block height being mined

<l​eonarth_:matrix.org> thank you vt

<l​eonarth_:matrix.org> therefore to get the latest block it's just current_height-1

<l​eonarth_:matrix.org> in the minertx there's a key and a viewtag, can those be used to check the miner wallet?

<l​eonarth_:matrix.org> in the minertx there's a key and a viewtag, can those be used to check the miner wallet? or what's their purpose

<r​ucknium:monero.social> A viewtag is not a view key. Every Monero tx now has a view tag.

<o​frnxmr:xmr.mx> [@gingeropolous:monero.social](https://matrix.to/#/@gingeropolous:monero.social)

<o​frnxmr:xmr.mx> matrix.monero.social/_matrix/media/…oad/xmr.mx/OJBfHXsJuOKJWTXOjkfhqelz

<j​effro256:monero.social> Leonardo: localmonero.co/knowledge/view-tags-…reduce-monero-sync-time?language=en

<l​ordx3nu:matrix.org> 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.

<l​eonarth_:matrix.org> 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

<j​effro256:monero.social> That's not how it works. You don't get the speedup benefit for existing txs without viewtags if you scan them

<j​effro256:monero.social> Better to just churn XMR to yourself and change your refresh height

<j​effro256:monero.social> Also, all wallets support view tags by design . you don't need to create a new wallet for view tags

<j​effro256:monero.social> If you have made a Monero tx in the last 3 years, you've used viewtags

<l​eonarth_:matrix.org> my wallet restore height is 2237000, this means those transactions before viewtags were introduced will be slow to sync

<l​eonarth_:matrix.org> checked the date on that block

<l​eonarth_:matrix.org> ```date --date="@1606147042"

<l​eonarth_:matrix.org> Mon Nov 23 17:57:22 EET 2020```

<l​eonarth_:matrix.org> how do you churn monero to yourself? you mean the sweep function in monero gui?

<l​eonarth_:matrix.org> once I do that I can use the new height for the restore of the wallet?

<l​eonarth_:matrix.org> my wallet restore height is 2237000, this means those transactions before viewtags were introduced will be slow to sync

<l​eonarth_:matrix.org> checked the date on that block

<l​eonarth_:matrix.org> ````date

<l​eonarth_:matrix.org> Mon Nov 23 17:57:22 EET 2020```

<l​eonarth_:matrix.org> ````

<l​eonarth_:matrix.org> my wallet restore height is 2237000, this means those transactions before viewtags were introduced will be slow to sync

<l​eonarth_:matrix.org> checked the date on that block

<l​eonarth_:matrix.org> ````date

<l​eonarth_:matrix.org> Mon Nov 23 17:57:22 EET 2020```

<l​eonarth_:matrix.org> ````

<l​eonarth_:matrix.org> how do you churn monero to yourself? you mean the sweep function in monero gui?

<l​eonarth_:matrix.org> once I do that I can use the new height for the restore of the wallet?

<j​effro256:monero.social> 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<clipped mes

<j​effro256:monero.social> gs , it matters how many *total* txs have view tags over the span of time that you're scanning .

<j​effro256:monero.social> Yeah you can use "sweep_all", or "transfer" if youre aware of which inputs you're using

<j​effro256:monero.social> After that, you can increase the restore height to sometime before the first unspent transaction

<j​effro256:monero.social> Also, please don't edit messages, it spams IRC

<l​eonarth_:matrix.org> once I do sweep_all to my own wallet address, I can start the restore point from the new block height, right?

<j​effro256:monero.social> Yes

<l​eonarth_:matrix.org> awesome, thank you jeffro

<j​effro256:monero.social> Ofc

<l​eonarth_:matrix.org> the extra field in a block, is just a bunch of bytes represented as integers?

<l​eonarth_:matrix.org> I tried to convert those ints to byte and read the extra message, but I end up with gibberish

<l​eonarth_:matrix.org> ```

<l​eonarth_:matrix.org> [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]

<l​eonarth_:matrix.org> ```

<l​eonarth_:matrix.org> ```

<l​eonarth_:matrix.org> !=kO@7Ŧb}-wDpϋMΑ+e.\lD"u!=w' V

<l​eonarth_:matrix.org> ```

<l​eonarth_:matrix.org> ^ this is the last block btw

<l​eonarth_:matrix.org> is there a proper way to read the Extra field?

<j​effro256:monero.social> 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

<j​effro256:monero.social> Most of those are going to be largely uniform random bytes

<j​effro256:monero.social> But you can use the `cryptonote::parse_tx_extra()` function to look at the structure of a transaction extra field: github.com/monero-project/monero/bl…ic/cryptonote_format_utils.cpp#L544

alternate golang implementation git.gammaspectra.live/P2Pool/consen…/master/monero/transaction/extra.go

<l​eonarth_:matrix.org> thank you guys

also if you want to parse only coinbase transactions git.gammaspectra.live/P2Pool/consen…ster/monero/transaction/coinbase.go

<b​oog900:monero.social> 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.

<l​eonarth_:matrix.org> monero-rs adds 3 in the extra of mined blocks?

<l​eonarth_:matrix.org> monero-rs adds 3 in the extra of mined blocks? why

that's merge mining tag

p2pool has it, qubic has it

or anyone else who does merge mine,

<b​oog900:monero.social> `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

p2pool has pubkey first

from tests recently, qubic blocks that merge mine have the merge mine tag first

most recent example p2pool.io/explorer/tx/c4676ff1a1028…c35ca73a4ae7fce53f973a2e72e4665c95b

(last of their blocks)

<b​oog900:monero.social> Yeah they are using the tari merge mine interface directly then, ig p2pool just takes the merge mining hash and creates its own block

<l​eonarth_:matrix.org> pubkey of what? thought p2pool splits the coinbase to all addresses with shares

yep, p2pool has this github.com/SChernykh/p2pool/blob/ma…src/pool_block_parser.inl#L175-L212

pubkey of the transaction private key

for example p2pool.observer/share/8be48c2ce394a…3d1c79c27879805d225162f0ff93602258b

<l​eonarth_:matrix.org> think p2pool is the only blocks that have multiple vouts at the coinbase level

Coinbase Private Key f81909fd808af9cb4ea9e44683573ecfd7ff32a99f13b4489bb1d7317feb5600

if you go to payout proof of any of the outputs there like p2pool.observer/proof/02ecf51e1bb58…89d665299c5ff55753d943ba2b19169df/0

you see you can use the tx private key to prove it's that address

or use any of the OutProofV2/V1 without sharing the tx private key directly

this can be verified for example, localmonero.co/blocks/tx/9a9604003b…ecfd7ff32a99f13b4489bb1d7317feb5600

<l​eonarth_:matrix.org> yes, ingenious, nice

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

also some encrypted values for vendors (not recommended) etc.