00:21:41 <selsta> hyc: https://paste.debian.net/hidden/69df42a8/ this times out on exit
00:23:24 <selsta> it prints `connect: Operation timed out` and then `sendto: No route to host`
00:25:21 <selsta> introduced in https://github.com/monero-project/monero/pull/2376
00:29:52 <selsta> seems there is MINIUPNPC_SET_SOCKET_TIMEOUT which sets the timeout to 3 seconds, this could solve it
00:36:30 <selsta> we already use MINIUPNPC_SET_SOCKET_TIMEOUT, so that's not it. will have to use --no-igd
01:27:11 <hyc> interesting. since it's trying to delete a mapping, does that mean it successfully created a mapping at startup?
01:36:58 <selsta> there are no warnings on startup, but i would have to double check if it creates a mapping. the issue mostly shows up when i lose internet / wifi connection after monerod got started
01:37:42 <selsta> e.g. start monerod, close my laptop, open it later again, exit monerod
01:39:49 <hyc> ah
01:40:14 <hyc> I wonder if we can get a signal on entering/exiting standby
01:41:06 <selsta> so far no one else has reported this issue so maybe it is something related to my local network setup
01:43:35 <hyc> does your router actually have upnp enabled?
01:48:34 <selsta> it does not, there is no setting for it
07:05:30 <kayabaNerve> What's the official TX extra rules?
07:05:45 <kayabaNerve> As in, what is the official wallet2 behavior for TX extra encoding?
07:06:36 <kayabaNerve> I know it's the TX Rs with 1 8-byte payment ID, which is random if not actually used. I just want to confirm the behavior regarding quantity of Rs and location of the payment ID.
07:07:57 <kayabaNerve> I believe it's: TX_PUBLIC_KEY (or whatever the constant is) for the first R, which is the only R if there's only two outputs. Then, if there's more than 2 outputs, TX_ADDITIONAL_PUBKEYS is used for the rest, with each output adding +1. Then after that, the payment ID is added.
07:08:46 <kayabaNerve> ... except if there's only 1 R for two outputs, you can't send to two subaddresses in a transaction with just two outputs, unless there's a custom rule there.
07:09:31 <kayabaNerve> And yes, I do understand all the cryptography here :p Just not familiar with the exact wallet2 formatting/R handling rules.
07:10:25 <kayabaNerve> Also, when scanning a transaction, should all Rs be scanned or can you determine per-output a single R according to wallet2? I'd assume wallet2 has a standardized ordering when creating, of course, yet if wallet2 scans all Rs for all outputs... gotta match :/
07:28:26 <moneromooo> More than one R only if subaddresses are involved.
07:29:09 <moneromooo> wallet sorts extra now. Lemme find the code...
07:30:03 <moneromooo> sort_tx_extra, called from construct_tx...
07:30:38 <moneromooo> About multiple R: bool need_additional_txkeys = num_subaddresses > 0 && (num_stdaddresses > 0 || num_subaddresses > 1);
07:30:59 <moneromooo> Nothing in this is consensus.
07:31:20 <moneromooo> When additional Rs are present, they're in output order.
07:34:27 <moneromooo> If you need to scan old txes, there was a bug when cold signing where two Rs would be added, and the second was used.
07:34:53 <kayabaNerve> ... doesn't that dox if you're sending to a subaddress?
07:35:02 <moneromooo> It does.
07:35:07 <kayabaNerve> I thought Monero was impervious to that sort of stuff.
07:35:13 <kayabaNerve> ...
07:35:25 <moneromooo> The idea is that soon, every tx will go to a subaddress.
07:35:56 <kayabaNerve> I was going to match wallet2 to the letter. Now, I assume I should be indistinguishable from something it *would* create, yet not match it.
07:36:01 <moneromooo> And most txes are 2 out, which reuses the single R scheme.
07:36:18 <kayabaNerve> So for a few specific questions:
07:36:31 <kayabaNerve> 1) Will Monero ever use a subaddress as a change address?
07:36:38 <moneromooo> Yes.
07:36:41 <kayabaNerve> 2) When Monero scans TXs with a list of Rs, does it scan with all Rs?
07:37:00 <kayabaNerve> Since 1, how does 2 outs use a single R if the out and the change are sub?
07:37:04 <moneromooo> Usually, but you can create txes where it won't I think.
07:37:20 <moneromooo> I don't know.
07:37:24 <kayabaNerve> :D
07:37:34 <kayabaNerve> this is fun :p
07:38:02 <moneromooo> Could be I'm wrong about using a single R for 1 subaddress out...
07:38:08 <kayabaNerve> Thanks for trying. It sounds like I'll need to read through this entire code myself lol
07:38:39 <kayabaNerve> I was hoping to hear: 1) PUB_KEY, ADDITIONAL, PAYMENT_ID 2) 1 R per output 3) wallet2 will only scan R[o] for output o
07:38:45 <moneromooo> I guess you can make a tx and see what gets generated :)
07:38:57 <kayabaNerve> Yet I know of single R usage in some TXs and... already knew it'd be messier :/
07:39:08 <kayabaNerve> ... wait are you suggesting I do actual work?
07:39:21 <kayabaNerve> :( and to think I wanted to continue living in my own bubble for a bit longer :(
07:39:48 <kayabaNerve> But yeah lol, seems like reading the actual code and trying a few different TX params is the way to go. I'll also try to create a set of rules on this behavior that can be referred to
07:40:42 <kayabaNerve> Thanks again mooo :)
07:40:43 <moneromooo> This answers the "how does 2 outs use a single R if the out and the change are sub" question: bool need_additional_txkeys = num_subaddresses > 0 && (num_stdaddresses > 0 || num_subaddresses > 1);
07:41:04 <kayabaNerve> Does change count as a subaddress?
07:41:10 <kayabaNerve> *in that num_subaddresses
07:41:24 <moneromooo> If not from account 0, yes. IIRC change goes to minor 0 of the sending account.
07:41:43 <kayabaNerve> Right. Was more asking it was counted in that section. Not if it technically is ;)
07:42:06 <kayabaNerve> From the sections of wallet2 I've read, it seems largely incompetent at correlating data.
07:42:27 <moneromooo> What do you mean by correlating here ?
07:42:30 <kayabaNerve> Not that it isn't functional. That it constantly splits up values that have a relation and assumes the caller/callee still has whatever understanding it needs, and that it matches whatever else is in the stack.
07:42:44 <kayabaNerve> I will immediately point to addresses.
07:43:02 <kayabaNerve> wallet2 doesn't pass around a variadic address struct when creating a TX at every level. It splits into a list of the individual components IIRC
07:44:55 <kayabaNerve> Not to say it should never decompose/reduce. To say I don't want a function signature of `rct::key* spend_keys, rct::key* view_keys` compared to `KeyPair* addresses`
07:45:30 <kayabaNerve> And yes, I understand that's not an actual function signature and I'm sure we have some key_pair type somewhere. It's more a comment on usage of multiple vectors/pointers/lists instead of one list where element is a tuple/struct as needed
07:51:18 <kayabaNerve> Eh. My specific comment here may be unfounded. Most multiple variables are so the values don't have to be copied into new types and I'm not immediately finding something like I posited...
07:51:45 <moneromooo> Well, genRctSimple is like that.
07:54:37 <kayabaNerve> Right
07:54:53 <kayabaNerve> I guess it's not the wallet as a whole that's like that, and just the crypto libs, and I work with the crypto libs :p
07:54:58 <kayabaNerve> Just came back to point out genRctSimple lol
07:55:17 <kayabaNerve> ... and while this complaint didn't hold against the wallet, I do have plenty of other complaints there lol
07:55:35 <kayabaNerve> The closest example with the wallet code was vector<secret>, vector<public>
07:55:44 <kayabaNerve> Where it optimized the scalarmul yet didn't move to a new struct.
07:56:06 <kayabaNerve> Not how I'd do it, but yep, I understand it (which is how a lot of projects with large communities go ;) )
08:48:27 <sech1> moneromooo why do we let v0.18 wallets to connect to v0.17 nodes after the fork? https://www.reddit.com/r/Monero/comments/wtoxm8/comment/il6767q/?utm_source=reddit&utm_medium=web2x&context=3
08:49:17 <sech1> I mean, wallet can see node's height and can see that it's still on v14 after block 2,688,888 so it can deduce it's not updated and show the user an error
08:50:47 <sech1> the fact that v14 chain is still somewhat alive, makes things even worse
08:51:05 <sech1> it's currently at height 2,688,934
09:21:11 <moneromooo> Dunno really. It seemed to make sense to only reject when the RPC major gets bumped.
09:21:30 <moneromooo> But "can't sync to that" is also a valid reason.
09:33:13 <dEBRUYNE> sech1: Perhaps worthwhile to create a PR for it so it can be included in the .1.1
10:17:49 <federico[m]12> Hello, I tried wallet2 method estimate_rtc_tx_size to estimate monero transaction fees but there's a 200~bytes difference between my weight estimate and monero's cli one
10:18:23 <federico[m]12> * cli one (thats the 200+ one)
11:53:34 <MikhailSytchev[m> Hey, everyone
11:53:35 <MikhailSytchev[m> I run my own monerod node on private server to perform transactions routine for project N
11:53:35 <MikhailSytchev[m> After latest hardfork transfer method in JSON API became broken. I've updated my monerod to `'Fluorine Fermi' (v0.18.0.0-release)` but still receiving `Known ring does not include the spent output: 59563164` error 
11:54:56 <MikhailSytchev[m> Is there any known issues on this case after hardfork? Find one https://github.com/monero-project/monero/issues/3539 but very outdated and related to Android app
11:58:34 <MikhailSytchev[m> params i've sending txs with... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/fecfca691e448a1de0028030c0abeb3b20b6ea84)
11:59:14 <MikhailSytchev[m> ring_size was updated after monerod update
12:04:12 <MikhailSytchev[m> there's some warning after restart as well
12:04:13 * MikhailSytchev[m uploaded an image: (639KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/bSvtwrxXFNWHnkpdnmCwhzsG/image.png >
12:22:23 <moneromooo> Sounds like you tried ti make a tx on the wrong chain before updating.
12:23:04 <moneromooo> Or maybe not. But in any case, try deleting ~/.ringdb while monero-wallet-cli isn't running.
12:34:40 <willshu[m]> <selsta> "will.shu: did you set the..." <- Yes. First I set up the view wallet without specifying `--subaddress-lookahead`. Second I set up the view wallet specifying `--subaddress-lookahead 1:1000000`. In the second way, the view wallet correctly scans the deposit at the subaddress with index 1:181,162, thus exports an output hex much longer than the the first way would. It seems the `monero-javascript` cannot process the second way and
12:34:40 <willshu[m]> will throw an error.
12:34:40 <willshu[m]> https://github.com/monero-ecosystem/monero-javascript/issues/99
13:36:13 <woodser[m]> after calling `scan_tx` with ids already scanned by the wallet, `get_transfers` starts returning a transfer with fee=0 for the scanned txs. not sure if it's an erroneous transfer or the fee was deleted by the scan command, but it's causing an error reconciling transfers from the wallet
13:37:45 <woodser[m]> it's accompanied with this output in monero-wallet-rpc, but this is probably expected:
13:37:45 <woodser[m]> `2022-08-21 13:21:40.823	E Public key fdfa07f837a16a90d733fceb55581c0c0f8c6ba3574ef928738512083c65622a from received 35.173300860152 output already exists with spent 35.173300860152 in tx <ea6c9edae116224a5494e78bbeafc5508cc11734bc8e6e36a9784c6b7dcf160f>, received output ignored`
14:13:55 <question> hello good day
14:13:55 <question>  i am trying to explain/understand bulletproofs, range proofs.
14:13:55 <question> How can i do a pedersen commitment without elliptic curves?
14:13:55 <question>  i need a very small Field F_p and 3 generators H G and Q.
14:13:55 <question>  is this possible?
14:13:55 <question>  if V = aH + bG; what is the difference between G and b for example?
14:13:57 <question> in that case both b and G would be points on F_p right?
14:14:01 <question>  p has to be less than 100 or so
14:27:09 <tevador> question: in F_p, you would generally write it in multiplicative notation, e.g. v = h^a * g^b
14:28:21 <question> a field F_p is a commutative ring , closed under + and *
14:29:02 <question> the notation remains additive
14:29:12 <tevador> you don't need a ring but a group with one group operation, which is multiplication in this case
14:29:33 <question> V = ag + bh mod p
14:29:36 <tevador> with elliptic curves, the group operation is point addition
14:31:01 <question> a group with one group operation?
14:31:45 <question> why not 2?
14:32:20 <question> or i only need 1
14:32:22 <question> ?
14:32:31 <question> and i can only use 1?
14:33:07 <question> https://doc-internal.dalek.rs/bulletproofs/notes/range_proof/index.html
14:33:23 <question> https://pastebin.com/Ha5NSdyj
14:34:17 <question> i ran that and now im ranting about it
14:34:41 <question> because that checks out and p is 22 or something 
14:34:52 <tevador> a group is defined with a single binary operator; I guess an additive group mod p might work as a toy example, but fails in practice because this operation is easily invertible with modular division, so you can trivially calculate the private key of any public key
14:35:57 <question> again its a field!
14:36:03 <tevador> also you might want to try #monero-research-lounge
14:36:15 <tevador> this is a dev channel
14:36:38 <question> the group is also multiplicative
14:39:03 <question> thanks
16:58:57 <vtnerd> @computerfreak94 CI build with connection patch reverted: https://github.com/selsta/monero/suites/7904407827/artifacts/336290979
17:29:25 <selsta> sech1: not exactly the solution you suggested but this should help in the next release with users using simple mode https://github.com/monero-project/monero/pull/8519
17:30:51 <sech1> and our latest checkpoint in 0.18.1.0 is ...?
17:31:00 <sech1> it was released before the fork
17:31:09 <selsta> yes, but v0.18.1.1 has a new checkpoint
17:31:35 <sech1> ok, nice
17:31:43 <selsta> i know this won't work on fork boundaries but it seemed simple enough to add for now
17:35:16 <sech1> we must something for the next fork anyway because of address format change
17:35:19 <sech1> *must have
17:35:27 <sech1> I think RPC major version will be bumped
18:38:09 <MikhailSytchev[m> <moneromooo> "Or maybe not. But in any case..." <- Thanks a lot. Deleting `rm -rf ~/.shared-ringdb` worked for me!
22:59:14 <selsta> this needs another review https://github.com/monero-project/monero/pull/8486