ok so youre talked about a coordinated attack where you delibrately lower or raise the hash rate

talking*

and that essentially feedbacks into the network, and you can then "control" network

Hey everyone :D I was wondering how I can stop my xmrig-proxy from showing debug messages, I must've pressed a key earlier to enable it and don't know what the toggle key is to disable it, any help would be appreciated

Can the payment id from an integrated address be used as a ‘poor man’ version of viewtags?

I was thinking a server can keep track of all payment_ids. Then the user just polls by payment_id. This would work great for PoS or payment plugins. No need to run a node or share a view_key with a server (possibily overloading it if hundreds of payments). The view_key stays local, the server just returns the raw_tx associated with the payment_id

Payment ids are encrypted on chain. You need the view key to decrypt the actual value from the transaction. So the server cannot look up a tx based on a payment id value.

Also I would caution against basing new functionality on payment ids as they will be deprecated in the future.

<tevador> "Also I would caution against..." <- but the seraphis addressing scheme will also include a shared secret between buyer and seller. Maybe it would be good to think about if another tier could be helpful that can only decrypt the shared secret aka paymentid

There is already Tier 1.5 which can do that (it can also see amounts)

With PHP, in order to use the get_height RPC on my local monerod node, I'm doing :

exec('curl 127.0.0.1:18081/get_height', $output, $retval);

It works well, but I'm curious if there is maybe a smarter way to proceed ?

s///

Yes, not running something that looks like it's interpreted by a shell.

Though that one's innocuous enough I guess.

Using /usr/bin/curl would at least prevent an obvious oops.

Thanks Mooo

<tevador> "Payment ids are encrypted on..." <- I understand. Theoretically, given that that decryption requires the tx_public_key and view_secret_key I could still do this locally.

Ask the server for all tx's that have payment_ids in the next N blocks (5 for a 10 minute pay window). Try to decrypt them locally using txs_public_key and view_private_key.

The benefit I see to this scheme is not communicating the viewkey to the server. Offload the processing to the client. Monitor and verify payments locally.

The client just has to find it's payment_id in the set of decrypted_payment_ids

This is stupid lol, sorry. If I have the viewkey locally I can still do this same scheme without payment_ids.

hi

I'm looking for experienced blockchain developers to help me with something

Guest33: On Matrix, you can go to #monero-recruitment:monero.social

hm?

on matrix.org?

hello?

ANYONE

CAN ANYONE HERE ME?

nope

hi

Guest33: hi

what's up?

nm hbu?

i'm tryna get help but none of these guys will help

ok

Here’s a tip: ask a real question if you want an answer.

Is there a way to find what the starting block of a wallet is after it is already created and I forget when I made it?

Using getmonero.org/resources/developer-guides/wallet-rpc.html

AFAIK the timestamp is saved in the .keys file, but I'm not sure if there is an API call that can display the value

rpc_connection.get_height() 👀

^ that returns the current sync height, not the restore height

ah, i think this is just the 'height it is currently at' - ignore

so, get_transfers and find the tx with the earliest blockheight

plowsof: Smart, thanks!