05:45:41 i'm trying to validate a monero address by reading what java I can from https://github.com/monero-ecosystem/monero-java/blob/master/src/main/java/monero/utils/MoneroUtils.java, so far no success .. do these look reasonable ? 05:45:43 {:checksum-check "efbfbd75" 05:45:45 :checksum-hash "e2182fb9" 05:45:47 :decoded-address "02efbfbd365f510befbfbdefbfbd63efbfbd4a1defbfbd6d1e542fefbfbdefbfbdefbfbd3a5449efbfbd2e491cefbfbdefbfbd1c7063efbfbdefbfbd0defbfbdefbfbdefbfbd7d664aefbfbd28efbfbd3e2aefbfbdefbfbdefbfbd7fefbfbd6fefbfbdefbfbdefbfbd117256efbfbd20efbfbd28d5b925efbfbdefbfbdefbfbd75" 05:45:49 :encoded-str "e2182fb9dfb0cefe9c07fba05f670417ceac8421532df0a3a6c1214e9e09d85a" 05:45:51 :validated false} 05:46:19 the variable names i'm using are modeled after the isValidAddressHash function in the java code 05:47:24 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 05:50:00 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? 05:53:34 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 :) 06:13:41 --- 06:13:42 get_payments 06:13:42 Get a list of incoming payments using a given payment id. 06:13:49 is that the one that will be deprecated? 07:30:40 kayront: are you familiar with this website? https://xmr.llcoins.net/addresstests.html 07:30:56 I am now 07:30:58 :D 07:34:09 so basically all the values are wrong 07:34:10 good times 07:35:11 your decoded address seems to have a lot of e, b, f, and d 07:37:35 i suppose that's an artifact of the wrong way it's being calculated, all of them exhibit such patterns when I tried 08:08:33 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? 08:10:43 you mean a hex string corresponds with some integer? 08:13:55 no, just that it's a hex string and always 64 in size, and used in the context of transactions 08:14:06 i named the function monero-txid? but it's not just for txids 08:14:14 txhash maybe? 08:16:24 string_converts_to_32byte_hex() 08:17:48 string_is_64_hex_digits() 09:06:02 for get_spend_proof, is the txid the tx_hash from incoming_transfers ? 09:09:23 seems likely 09:10:05 {:error {:code -1 :message "This tx wasn't generated by this wallet!"} 09:10:24 (get-spend-proof (:tx_hash (first (:transfers (:result (incoming-transfers :all)))))) 09:15:15 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 09:15:34 (therefore ensuring the tx actually exists in the wallet, after all it was just grabbed from there) 09:50:36 in check_tx_proof, it says in https://www.getmonero.org/resources/developer-guides/wallet-rpc.html that the message parameter is optional 09:50:51 but without including it, I'm always getting a signature header check error 09:51:25 turns out by passing "" (empty string) it works with: :result {:confirmations XXX :good true :in_pool false :received XXXXXX}} 09:51:43 but it also "works" by passing it any other message, except confirmations comes back as zero -- shouldn't it error out in this case? 09:51:53 oh, :good is false then 09:52:01 nevermind. but about the first point? bug? 12:30:47 what a merge fest Snipa ! 12:35:33 kinky 14:04:51 Does anyone here know how the serialiser actually works 14:04:53 for example 14:04:55 void get_transaction_prefix_hash(const transaction_prefix& tx, crypto::hash& h) { std::ostringstream s; binary_archive a(s); ::serialization::serialize(a, const_cast(tx)); 14:05:27 ", \"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\": 14:05:28 {\"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\": 14:05:28 \"1cd1b738ada5a316e38d5232a522a20cde1926667ce4d5b349695c8efdb22669\"}}, {\"key\": {\"amount\": 60000, \"key_offsets\": [ 458521], \"k_image\": \"bc2bb7d91af6a3bef45c8ec424e60433bf758fd6f6b33db126bfb95c80a5a7d2\"}}, {\"key\": {\"amount\": 10000, \"key_offsets\": [ 5234650], \"k_image\": 14:05:29 \"8519023131dc29406146223683c3d58ac9bb07e94acc576c33c971ecf92aef10\"}}], \"vout\": [ {\"amount\": 4, \"target\": {\"key\": \"200a613f2fcc9045ab4a4c55ced5612965e351bbbea308ffb27787d2c053c4ea\"}}, {\"amount\": 7000, \"target\": {\"key\": \"a743a0cacd556c3e3680cfe8a2f3a1fba2d15ff29187df06feaa8e614dc112ce\"}}, {\"amount\": 70000, \"target\": {\"key\": 14:05:29 \"51d295bb01550e70c53307a6369416e08878d731032d1888c7734e773d60e5f4\"}}, {\"amount\": 600, \"target\": {\"key\": \"1f6d93b2ae521d96c58c8a75ca151db3eec3beabc1ba494bc2d8f87f853e6f0e\"}}, {\"amount\": 50, \"target\": {\"key\": \"22e097fef7045ff5ac7a4fb163c1cc82307d17171e116ff2c54a839cfce367f2\"}}], \"extra\": [ 2, 33, 0, 20, 163, 204, 17, 164, 173, 14:05:30 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]" 14:05:50 Debugging it appears that the key image hex is serialised as-is 14:06:01 "010007026401c6faec01e6aa00d0677dd32bc4378aa54ec08bbe72ee53c902082aa6eec3ec300241941d02f40301d4d59801356b1c02e6540d5ba4d2866c87c6832df1fa1f62011e9fedec874128ebe239c3020401fa9685019531008dedb1c38c300eeb03b488b728e5081f472233d01ba4d0fc0bb1a4954a023c01fee86f23db2686edfe7c3aa0f28889bae0f82ca0ddf4424880b1fb36e7ba603f7ffbde02d83601dfa63e1cd1b738ada5a316e 14:06:02 38d5232a522a20cde1926667ce4d5b349695c8efdb2266902e0d4030199fe1bbc2bb7d91af6a3bef45c8ec424e60433bf758fd6f6b33db126bfb95c80a5a7d202904e01dabfbf028519023131dc29406146223683c3d58ac9bb07e94acc576c33c971ecf92aef10050402200a613f2fcc9045ab4a4c55ced5612965e351bbbea308ffb27787d2c053c4ead83602a743a0cacd556c3e3680cfe8a2f3a1fba2d15ff29187df06feaa8e614dc112cef0a 14:06:02 2040251d295bb01550e70c53307a6369416e08878d731032d1888c7734e773d60e5f4d804021f6d93b2ae521d96c58c8a75ca151db3eec3beabc1ba494bc2d8f87f853e6f0e320222e097fef7045ff5ac7a4fb163c1cc82307d17171e116ff2c54a839cfce367f24402210014a3cc11a4add626b202c35ac5e81eb2b67cebf3a62c333a1234567890abf4fa01dc7fe9f04f61869f048b66a30919fce4040977c33e2e5a4fbc31c5b054adf1a0" 14:06:13 That's the hex equivalent of the binary string 14:06:25 in between these values though, it just seems like garbage 14:08:02 I'm wondering how regular numbers are being serialised (the amounts) 14:09:09 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. 14:09:54 Ok sorry dude. Thaks 14:09:56 thanks 16:07:41 `cc1plus.exe: out of memory allocating 600896 bytes` 16:07:47 would changing -j3 to -j2 help here? 16:09:43 Might do 16:09:49 Possibly. Depends how much it wants overall. 16:10:42 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. 21:47:56 Hi guys, what do you all think about enforcing sorted TLV format in the extra field for a future hard fork? https://github.com/monero-project/research-lab/issues/61 21:49:24 I think it's mostly pointless. People who want to put different stuff in can still do, and it constrains with no good reason. 21:50:21 Now, changing the suggested format to TLV might be a good idea though. 21:50:47 Though I'm not sure about the work/benefit ratio being large enough. 21:58:27 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. 22:25:18 Most pools put random shite in this ? 22:26:27 If so, the problem isn't a framing format, but that pools are being arses, and they'll be able to be later too. 22:29:02 If a user puts fingerprintable things in it, they can still do it after the change. 22:29:48 I saw a reference that some smartarse puts their pool name in the coinbase. 22:29:53 That can still be done. 22:30:25 And there's no way to prevent this if you keep extra as a "user's choice". 22:30:59 So they'll just get fingerprinted on some different bits. Not much progress.