hyc: paste.debian.net/hidden/69df42a8 this times out on exit

it prints `connect: Operation timed out` and then `sendto: No route to host`

introduced in monero-project/monero #2376

seems there is MINIUPNPC_SET_SOCKET_TIMEOUT which sets the timeout to 3 seconds, this could solve it

we already use MINIUPNPC_SET_SOCKET_TIMEOUT, so that's not it. will have to use --no-igd

interesting. since it's trying to delete a mapping, does that mean it successfully created a mapping at startup?

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

e.g. start monerod, close my laptop, open it later again, exit monerod

ah

I wonder if we can get a signal on entering/exiting standby

so far no one else has reported this issue so maybe it is something related to my local network setup

does your router actually have upnp enabled?

it does not, there is no setting for it

What's the official TX extra rules?

As in, what is the official wallet2 behavior for TX extra encoding?

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.

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.

... 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.

And yes, I do understand all the cryptography here :p Just not familiar with the exact wallet2 formatting/R handling rules.

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 :/

More than one R only if subaddresses are involved.

wallet sorts extra now. Lemme find the code...

sort_tx_extra, called from construct_tx...

About multiple R: bool need_additional_txkeys = num_subaddresses > 0 && (num_stdaddresses > 0 || num_subaddresses > 1);

Nothing in this is consensus.

When additional Rs are present, they're in output order.

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.

... doesn't that dox if you're sending to a subaddress?

It does.

I thought Monero was impervious to that sort of stuff.

...

The idea is that soon, every tx will go to a subaddress.

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.

And most txes are 2 out, which reuses the single R scheme.

So for a few specific questions:

1) Will Monero ever use a subaddress as a change address?

Yes.

2) When Monero scans TXs with a list of Rs, does it scan with all Rs?

Since 1, how does 2 outs use a single R if the out and the change are sub?

Usually, but you can create txes where it won't I think.

I don't know.

:D

this is fun :p

Could be I'm wrong about using a single R for 1 subaddress out...

Thanks for trying. It sounds like I'll need to read through this entire code myself lol

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

I guess you can make a tx and see what gets generated :)

Yet I know of single R usage in some TXs and... already knew it'd be messier :/

... wait are you suggesting I do actual work?

:( and to think I wanted to continue living in my own bubble for a bit longer :(

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

Thanks again mooo :)

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);

Does change count as a subaddress?

*in that num_subaddresses

If not from account 0, yes. IIRC change goes to minor 0 of the sending account.

Right. Was more asking it was counted in that section. Not if it technically is ;)

From the sections of wallet2 I've read, it seems largely incompetent at correlating data.

What do you mean by correlating here ?

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.

I will immediately point to addresses.

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

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`

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

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...

Well, genRctSimple is like that.

Right

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

Just came back to point out genRctSimple lol

... and while this complaint didn't hold against the wallet, I do have plenty of other complaints there lol

The closest example with the wallet code was vector<secret>, vector<public>

Where it optimized the scalarmul yet didn't move to a new struct.

Not how I'd do it, but yep, I understand it (which is how a lot of projects with large communities go ;) )

moneromooo why do we let v0.18 wallets to connect to v0.17 nodes after the fork? reddit.com/r/Monero/comments/wtoxm8…e=reddit&utm_medium=web2x&context=3

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

the fact that v14 chain is still somewhat alive, makes things even worse

it's currently at height 2,688,934

Dunno really. It seemed to make sense to only reject when the RPC major gets bumped.

But "can't sync to that" is also a valid reason.

sech1: Perhaps worthwhile to create a PR for it so it can be included in the .1.1

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

* cli one (thats the 200+ one)

Hey, everyone

I run my own monerod node on private server to perform transactions routine for project N

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

Is there any known issues on this case after hardfork? Find one monero-project/monero #3539 but very outdated and related to Android app

params i've sending txs with... (full message at libera.ems.host/_matrix/media/r0/do…a691e448a1de0028030c0abeb3b20b6ea84)

ring_size was updated after monerod update

there's some warning after restart as well

Sounds like you tried ti make a tx on the wrong chain before updating.

Or maybe not. But in any case, try deleting ~/.ringdb while monero-wallet-cli isn't running.

<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

will throw an error.

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

it's accompanied with this output in monero-wallet-rpc, but this is probably expected:

`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`

hello good day

i am trying to explain/understand bulletproofs, range proofs.

How can i do a pedersen commitment without elliptic curves?

i need a very small Field F_p and 3 generators H G and Q.

is this possible?

if V = aH + bG; what is the difference between G and b for example?

in that case both b and G would be points on F_p right?

p has to be less than 100 or so

question: in F_p, you would generally write it in multiplicative notation, e.g. v = h^a * g^b

a field F_p is a commutative ring , closed under + and *

the notation remains additive

you don't need a ring but a group with one group operation, which is multiplication in this case

V = ag + bh mod p

with elliptic curves, the group operation is point addition

a group with one group operation?

why not 2?

or i only need 1

?

and i can only use 1?

i ran that and now im ranting about it

because that checks out and p is 22 or something

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

again its a field!

also you might want to try #monero-research-lounge

this is a dev channel

the group is also multiplicative

thanks

@computerfreak94 CI build with connection patch reverted: github.com/selsta/monero/suites/7904407827/artifacts/336290979

sech1: not exactly the solution you suggested but this should help in the next release with users using simple mode monero-project/monero #8519

and our latest checkpoint in 0.18.1.0 is ...?

it was released before the fork

yes, but v0.18.1.1 has a new checkpoint

ok, nice

i know this won't work on fork boundaries but it seemed simple enough to add for now

we must something for the next fork anyway because of address format change

*must have

I think RPC major version will be bumped

<moneromooo> "Or maybe not. But in any case..." <- Thanks a lot. Deleting `rm -rf ~/.shared-ringdb` worked for me!

this needs another review monero-project/monero #8486