i'm trying to validate a monero address by reading what java I can from github.com/monero-ecosystem/monero-…/java/monero/utils/MoneroUtils.java, so far no success .. do these look reasonable ?

{:checksum-check "efbfbd75"

:checksum-hash "e2182fb9"

:decoded-address "02efbfbd365f510befbfbdefbfbd63efbfbd4a1defbfbd6d1e542fefbfbdefbfbdefbfbd3a5449efbfbd2e491cefbfbdefbfbd1c7063efbfbdefbfbd0defbfbdefbfbdefbfbd7d664aefbfbd28efbfbd3e2aefbfbdefbfbdefbfbd7fefbfbd6fefbfbdefbfbdefbfbd117256efbfbd20efbfbd28d5b925efbfbdefbfbdefbfbd75"

:encoded-str "e2182fb9dfb0cefe9c07fba05f670417ceac8421532df0a3a6c1214e9e09d85a"

:validated false}

the variable names i'm using are modeled after the isValidAddressHash function in the java code

basically if anyone could confirm that the regularity in the decoded-address is to be expected and the checksum-check/checksum-hash look reasonable (even though they don't match) plus the size of the encoded-str, that would be helpful

and also, in the java code that function takes one argument, a decodedAddrStr, the function call appears to be on line 116 and the parameter passed to it is defined a few lines above as the result of a call to decodeAddressToHex, that function I could not really follow .. in my code i'm decoding the address to base58, then turn that into bytes/bin, and finally from bytes/bin to hex .. is that the gist of it?

i've checked that base58 encode/decode work as expected by checking against online base58 encoders, same for hex, although I found some info that the base58 that monero uses is not quite the standard but the posts were from years ago.. obviously if that's still the case, it could explain the inability to validate .. any pointers appreciated :)

---

get_payments

Get a list of incoming payments using a given payment id.

is that the one that will be deprecated?

kayront: are you familiar with this website? xmr.llcoins.net/addresstests.html

I am now

:D

so basically all the values are wrong

good times

your decoded address seems to have a lot of e, b, f, and d

i suppose that's an artifact of the wrong way it's being calculated, all of them exhibit such patterns when I tried

there seem to be a few places where stuff related to transactions is in hex format and 64 in size. sometimes it's tx ids, others tx hashes, and yet in other contexts a tx key; what would be a helpful name to describe a function that validates that the data is in hex and the right size?

you mean a hex string corresponds with some integer?

no, just that it's a hex string and always 64 in size, and used in the context of transactions

i named the function monero-txid? but it's not just for txids

txhash maybe?

string_converts_to_32byte_hex()

string_is_64_hex_digits()

for get_spend_proof, is the txid the tx_hash from incoming_transfers ?

seems likely

{:error {:code -1 :message "This tx wasn't generated by this wallet!"}

(get-spend-proof (:tx_hash (first (:transfers (:result (incoming-transfers :all))))))

that basically means it's grabbing the tx-hash from the first transfer obtained from incoming_transfers and feeding it as an argument to get_spend_proof, if it wasn't clear

(therefore ensuring the tx actually exists in the wallet, after all it was just grabbed from there)

in check_tx_proof, it says in getmonero.org/resources/developer-guides/wallet-rpc.html that the message parameter is optional

but without including it, I'm always getting a signature header check error

turns out by passing "" (empty string) it works with: :result {:confirmations XXX :good true :in_pool false :received XXXXXX}}

but it also "works" by passing it any other message, except confirmations comes back as zero -- shouldn't it error out in this case?

oh, :good is false then

nevermind. but about the first point? bug?

what a merge fest Snipa !

kinky

Does anyone here know how the serialiser actually works

for example

void get_transaction_prefix_hash(const transaction_prefix& tx, crypto::hash& h) { std::ostringstream s; binary_archive<true> a(s); ::serialization::serialize(a, const_cast<transaction_prefix&>(tx));

", \"version\": 1, \"unlock_time\": 0, \"vin\": [ {\"key\": {\"amount\": 100, \"key_offsets\": [ 3882310], \"k_image\": \"e6aa00d0677dd32bc4378aa54ec08bbe72ee53c902082aa6eec3ec300241941d\"}}, {\"key\": {\"amount\": 500, \"key_offsets\": [ 2501332], \"k_image\": \"356b1c02e6540d5ba4d2866c87c6832df1fa1f62011e9fedec874128ebe239c3\"}}, {\"key\":

{\"amount\": 4, \"key_offsets\": [ 2182010], \"k_image\": \"9531008dedb1c38c300eeb03b488b728e5081f472233d01ba4d0fc0bb1a4954a\"}}, {\"key\": {\"amount\": 60, \"key_offsets\": [ 1832062], \"k_image\": \"23db2686edfe7c3aa0f28889bae0f82ca0ddf4424880b1fb36e7ba603f7ffbde\"}}, {\"key\": {\"amount\": 7000, \"key_offsets\": [ 1020767], \"k_image\":

\"1cd1b738ada5a316e38d5232a522a20cde1926667ce4d5b349695c8efdb22669\"}}, {\"key\": {\"amount\": 60000, \"key_offsets\": [ 458521], \"k_image\": \"bc2bb7d91af6a3bef45c8ec424e60433bf758fd6f6b33db126bfb95c80a5a7d2\"}}, {\"key\": {\"amount\": 10000, \"key_offsets\": [ 5234650], \"k_image\":

\"8519023131dc29406146223683c3d58ac9bb07e94acc576c33c971ecf92aef10\"}}], \"vout\": [ {\"amount\": 4, \"target\": {\"key\": \"200a613f2fcc9045ab4a4c55ced5612965e351bbbea308ffb27787d2c053c4ea\"}}, {\"amount\": 7000, \"target\": {\"key\": \"a743a0cacd556c3e3680cfe8a2f3a1fba2d15ff29187df06feaa8e614dc112ce\"}}, {\"amount\": 70000, \"target\": {\"key\":

\"51d295bb01550e70c53307a6369416e08878d731032d1888c7734e773d60e5f4\"}}, {\"amount\": 600, \"target\": {\"key\": \"1f6d93b2ae521d96c58c8a75ca151db3eec3beabc1ba494bc2d8f87f853e6f0e\"}}, {\"amount\": 50, \"target\": {\"key\": \"22e097fef7045ff5ac7a4fb163c1cc82307d17171e116ff2c54a839cfce367f2\"}}], \"extra\": [ 2, 33, 0, 20, 163, 204, 17, 164, 173,

214, 38, 178, 2, 195, 90, 197, 232, 30, 178, 182, 124, 235, 243, 166, 44, 51, 58, 18, 52, 86, 120, 144, 171, 244, 250, 1, 220, 127, 233, 240, 79, 97, 134, 159, 4, 139, 102, 163, 9, 25, 252, 228, 4, 9, 119, 195, 62, 46, 90, 79, 188, 49, 197, 176, 84, 173, 241, 160]"

Debugging it appears that the key image hex is serialised as-is

"010007026401c6faec01e6aa00d0677dd32bc4378aa54ec08bbe72ee53c902082aa6eec3ec300241941d02f40301d4d59801356b1c02e6540d5ba4d2866c87c6832df1fa1f62011e9fedec874128ebe239c3020401fa9685019531008dedb1c38c300eeb03b488b728e5081f472233d01ba4d0fc0bb1a4954a023c01fee86f23db2686edfe7c3aa0f28889bae0f82ca0ddf4424880b1fb36e7ba603f7ffbde02d83601dfa63e1cd1b738ada5a316e

38d5232a522a20cde1926667ce4d5b349695c8efdb2266902e0d4030199fe1bbc2bb7d91af6a3bef45c8ec424e60433bf758fd6f6b33db126bfb95c80a5a7d202904e01dabfbf028519023131dc29406146223683c3d58ac9bb07e94acc576c33c971ecf92aef10050402200a613f2fcc9045ab4a4c55ced5612965e351bbbea308ffb27787d2c053c4ead83602a743a0cacd556c3e3680cfe8a2f3a1fba2d15ff29187df06feaa8e614dc112cef0a

2040251d295bb01550e70c53307a6369416e08878d731032d1888c7734e773d60e5f4d804021f6d93b2ae521d96c58c8a75ca151db3eec3beabc1ba494bc2d8f87f853e6f0e320222e097fef7045ff5ac7a4fb163c1cc82307d17171e116ff2c54a839cfce367f24402210014a3cc11a4add626b202c35ac5e81eb2b67cebf3a62c333a1234567890abf4fa01dc7fe9f04f61869f048b66a30919fce4040977c33e2e5a4fbc31c5b054adf1a0"

That's the hex equivalent of the binary string

in between these values though, it just seems like garbage

I'm wondering how regular numbers are being serialised (the amounts)

Don't spam please. Use a pastebin if you want to paste a large amount of stuff. Many numbers are varints. See varint.h for details.

Ok sorry dude. Thaks

thanks

`cc1plus.exe: out of memory allocating 600896 bytes`

would changing -j3 to -j2 help here?

Might do

Possibly. Depends how much it wants overall.

If someone knows cmake, it might also possible to tell it to build wallet2.cpp and chaingen_main.cpp non parallel. And maube core_rpc_server.cpp.

Hi guys, what do you all think about enforcing sorted TLV format in the extra field for a future hard fork? monero-project/research-lab #61

I think it's mostly pointless. People who want to put different stuff in can still do, and it constrains with no good reason.

Now, changing the suggested format to TLV might be a good idea though.

Though I'm not sure about the work/benefit ratio being large enough.

I agree that people can still put whatever they want in it. However, there are at least two 'bare bones' implementations in the wild since the field has no structure (namely sorted and unsorted). From my pov, bare bones implementations should be fundamentally the same, and only extensions beyond that deviate from the norm. Most pools have different implementations, since there is no basic structure to build off of.

Most pools put random shite in this ?

If so, the problem isn't a framing format, but that pools are being arses, and they'll be able to be later too.

If a user puts fingerprintable things in it, they can still do it after the change.

I saw a reference that some smartarse puts their pool name in the coinbase.

That can still be done.

And there's no way to prevent this if you keep extra as a "user's choice".

So they'll just get fingerprinted on some different bits. Not much progress.