10:04:29 <parazyd> Hi. In the stratum mining protocol for xmrig, there is a "target" parameter. Is this calculated from the difficulty and then encoded to hex?
10:04:31 <parazyd> https://github.com/xmrig/xmrig-proxy/blob/master/doc/STRATUM.md#job
10:05:33 <parazyd> The difficulty is retrieved from getblocktemplate. So target should be 0xFF...FF (32 bytes) divided by difficulty?
10:06:19 <parazyd> i.e. for difficulty=1 target=ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ?
10:26:48 <sech1> yes, but it uses 32-bit or 64-bit division to calculate the target
10:34:22 <parazyd> I'm doing it in Rust and I'm using BigUint from the num-bigint crate so I can do that kind of division
10:34:50 <parazyd> However when sending target=ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff to xmrig, I still get 'login error code: 5', which leads me to think something is wrong
10:37:02 <parazyd> I see in xmrig::Job::setTarget() there is size==4 else size==8, but I can't understand what the hex target input there should be
10:42:22 <sech1> 32 or 64 bit hex value
10:44:48 <moneromooo> If you convert to hex yourself, be careful to not mess up endianness.
10:44:52 <moneromooo> (or from hex)
10:45:41 <parazyd> I understand that, but what is unclear is where (and how) this 32/64-bit value comes from. 
10:46:15 <parazyd> It doesn't seem to be the hex-encoded difficulty
10:46:19 <moneromooo> IIRC it's the least significant bits of the value a hash must be below (or equal maybe) to be a valid pow.
10:46:38 <moneromooo> The other bits are deemed to be 1. It's an optimization.
10:51:39 <parazyd> oh that seems to work
10:53:58 <parazyd> moneromooo: So what about endianness, is it known to be big or little?
11:03:48 <moneromooo> Big endian. 256 will be 00..0100 in hex.
11:04:46 <parazyd> Thanks
22:11:29 <m-relay> <k​eepemup:matrix.org> Quick questions about wallet RPC...
22:11:29 <m-relay> <k​eepemup:matrix.org> 1) is it possible to check individual sub address balance ?  Another step further is checking individual outputs and their balances too
22:11:29 <m-relay> <k​eepemup:matrix.org> 2)how to check which stealth address  the xmr was sent to? This can be done by eliminating your change stealth but that only works for a 2 output txn..
22:11:30 <m-relay> <k​eepemup:matrix.org> 3) confused about sweep_single.
22:11:30 <m-relay> <k​eepemup:matrix.org> Why are multiple subaddress indices allowed if you're sweeping a single output.  Same goes for below_amount...
22:12:34 <m-relay> <k​eepemup:matrix.org> Quick questions about wallet RPC...
22:12:34 <m-relay> <k​eepemup:matrix.org> 1) is it possible to check individual sub address balance ?  Another step further is checking individual outputs and their balances too
22:12:35 <m-relay> <k​eepemup:matrix.org> 2)how to check which stealth address  the xmr was sent to during a transfer? This can be done by eliminating your change stealth but that only works for a 2 output txn..
22:12:35 <m-relay> <k​eepemup:matrix.org> 3) confused about sweep_single.
22:12:36 <m-relay> <k​eepemup:matrix.org> Why are multiple subaddress indices allowed if you're sweeping a single output.  Same goes for below_amount...
22:13:35 <m-relay> <k​eepemup:matrix.org> Quick questions about wallet RPC...
22:13:36 <m-relay> <k​eepemup:matrix.org> 1) is it possible to check individual sub address balance ?  Another step further is checking individual outputs and their balances too
22:13:36 <m-relay> <k​eepemup:matrix.org> 2)how to check which stealth address  the xmr was sent to during a transfer (per output)? This can be done by eliminating your change stealth but that only works for a 2 output txn..
22:13:37 <m-relay> <k​eepemup:matrix.org> 3) confused about sweep_single.
22:13:37 <m-relay> <k​eepemup:matrix.org> Why are multiple subaddress indices allowed if you're sweeping a single output.  Same goes for below_amount...
22:14:34 <moneromooo> 1: Yes, see wallet2::balance_per_subaddress in src/wallet/wallet2.cpp
22:15:15 <moneromooo> 2: from the chain data, you can't. From your wallet cache, it's saved in m_dests in confirmed_transfer_details (wallet2.h)
22:15:38 <moneromooo> 3: you can have a tx with one input and several outputs
22:16:07 <moneromooo> And please do not edit large text for trivial changes, the bridge just reposts the entire thing.
22:16:40 <moneromooo> For 2: obviously, if you nuke your cache and later rescan the chain, that info will have gone
22:18:00 <moneromooo> Ah, it wasn't trivial changes only. Dunno about 3 then. Maybe just because it uses the same worker function under the hood.
22:18:40 <m-relay> <k​eepemup:matrix.org> So the wallet RPC doesn't natively support #1 and #2??
22:19:09 <moneromooo> I dunno without having to look.
22:19:55 <moneromooo> I looked. Looks like it does support it (get_balance).
22:20:03 <moneromooo> (well, for 1)
22:20:22 <moneromooo> Pretty sure you'd get 2 as well.
22:21:39 <m-relay> <k​eepemup:matrix.org> Looks like getmonero  and monerodocs differ
22:21:40 <moneromooo> I looked too, I'm not seeing destinations, so maybe it's not there.
22:23:00 <moneromooo> Feel free to add destinations to get_transfers btw if it's useful to you.
22:23:48 <m-relay> <k​eepemup:matrix.org> If only I knew "how to code"
22:24:40 <moneromooo> Well, you're posting in -dev.
22:25:11 <m-relay> <k​eepemup:matrix.org> This where all the answers are
22:27:54 <m-relay> <k​eepemup:matrix.org> Anyway it looks like getmonero docs is more up to date, the other site was entirely confusing