I tested the monero-javascript library and found the offline signing mechanism does not work when a deposit is made to a subaddress with a very large index, say 200,000. Does ledger works correctly when deposits are made to subaddresses with a very large index?

willshu[m]: what lookahead did you set?

So... it looks like for multisig, not only the whole tx creation code was rewritten, but it's actually duplicated. Only for for MS txes. WTF ?

The construct_tx code is called for normal txes, and not at all for MS txes.

This doubles attack surface, doubles the amonut of maintenance and changes needed later.

That can't be right... ?

Oh wait, no. Attack surface is the same, since the verification must have been kept, since the dameon can't tell MS from not MS. So at least that has to be unchanged.

Or is it meant to be temporary, and the construct_tc code will be removed ?

Hello

Does somebody know how to predict tx size in order to calculate fees with daemon rpc (estimate fee)?

the input counting only doesn't work and i didn't found anything that explains how to do that

wallet2 has estimate_tx_fee.

It's not byte exact IIRC, but close enough.

moneromooo: where

src/wallet/wallet2.cpp

Ah, it's estimate_fee.

well so i've to use this right?

Yes, again it's an estimate, but a good one for the kind of txes wallet2 creates.

👌 thank you

what does mixin and bulletproof means?

and extra size

also, does subaddress mean extra size? how they are calculated?

mixin is ring size minus 1. bulletproofs are a type of range proof. extra size is the size of extra, a string of byts that contains, among other things, the tx pubkey.

Subaddresses aren't directly related, but can cause more data to be added to extra.

For current monero txes, we do not use bulletproofs anymore, but BP+.

how can i dinamically get ring size?

The one you ought to be using ? No direct easy way. You have to use what wallet2 does, like: if (use_fork_rules(X)) return Y; etc.

* ring size and calculate extras?

k while instead regarding extras?

If you hve no ideas about htese htings, just make a tx and look at its fee.

(and ask for it not to be relayed)

After exposing wallet2:{en,de}crypt() via json wallet-rpc, does it make sense to expose them to zmq rpc? What is the goal of the zmq rpc compared to the json/http rpc?

It was supposed to replace it, being faster (and allegedly more widespread or something like that, but I never belived that). Never happened, and nobody really maintains it since who wants to have two things that do the same thing.

Now it's really used for pub/sub, which the JSON RPC does not have.

Originally, JSON RPC was supposed to be gutted and made into a thin layer above the 0MQ replacement.

So I'd say expose it there if it's useful to you, but it's probably missing years of changes.

(I mean the 0MQ RPC is probably missing years of changes)

I don't think it is necessary: I think the json rpc is enough so I can hook it up to monero-cpp. woodser do you agree?

Also, what is below json rpc? Raw sockets?

yes json rpc at minimum given zmq hasn't been maintained. that said, I'd really like to support zmq in the libraries for better notification support. much of this is already done

The epee networking code. That relies on boost networking. Which hopefully relies on sockets.

Okay, I don't mind exposing {en/de}crypt to zmq rpc. But "better notification support" sounds like you mean it via zmq pub/sub. I don't see {en,de}crypt making sense via pub/sub, only via req/rep.

ah yes

maybe I'm missing something. is there a way to set up a view-only wallet to only scan a subset of subaddresses?

Erase the addresses you do not want to see from m_subaddresses.

You'll have to add code to do this.

ok, so it's not supported now. wanted to make sure

Also, you'd have to disable the auto lookead system or it'll create more addresses.

friend downloaded the GUI update and got this

both from getmonero.org and GUI update had these dates

r4v3r23[m]: yes, will be fixed with the next release

the package script set the timestamp wrong, it is harmless

jozsef[m]: did you solve your issue with trailing bits?

Yes, I did. I needed to pad the plaintex that I was feeding to wallet2::encrypt().

Also added unit tests and functional tests to exercise it.

jozsef[m]: can you also bump the minor version in src/wallet/wallet_rpc_server_commands_defs.h ?

Done.

ok, let's wait for tests to finish

I'm trying to support multithreading in monero-javascript and running into an error: "A leaf routine is using a thread pool." looking at the code, I'm confused how lines like [this](github.com/monero-project/monero/bl…9d7dee/src/wallet/wallet2.cpp#L2825) don't error, when threadpool.cpp [immediately

errors](github.com/monero-project/monero/bl…d7dee/src/common/threadpool.cpp#L85) on leaf=true, unless it's supposed to be caught and processed in error handling?

ah, it's checking its internal `is_leaf`, not the passed parameter :)

moneromooo jozef[m] : there are two difficulities with merging 0mq and http-json-rpc paths

some of the http-json uses REST, which will work over 0mq, but its a bit more custom (basically a `path_name:{json_object}` ... which isn't really a blocker

the other issue is that some of the endpoint apis would have to be broken, likely in 0mq

the information is often duplicated, but not that exact DOM structure

vtnerd: monero-project/monero #8423#discussion_r946976184

"Dandelion++ is not used over the AN, but the remote service receiving the tx over an AN is expected to use it after a randomized delay" <-- quite sure this gets skipped when disable_noise is enabled

disable_noise does more than just disable noise

transactions sent with disable_noise always show up next to instantly in the mempool, there is no D++ involved

it seems documented here monero-project/monero #6354#pullrequestreview-399554356

hmm. I thought I added code to have a randomized delay when switching between overlay networks

will have to double check that hten

see the last link

ah yeah I see, damn and I even wrote the code

I think the problem was the confusion the delay could cause, but I dunno in hindsight

I only remember this since there were a lot of sybil nodes initially when D++ was introduced and using disable_noise was the only was to get fast transaction times

oh yeah right it makes no sense

in the standard threat model tor is hiding the source. so delaying adds nothing. in the paranoid threat model (a "big" actor monitoring timing analysis) an immediate tx-send after receiving the usual tx is a dead give-away

*usual tx->tx sent in the "noise" window

or no wait, it skips D++ too? ah damn

yeah again, it makes sense because tor is doing the entire leg of work in that less paranoid situation

yep it skips d++ too on the clearnet side

hmm. then I will have to post another comment about that section because its written fairly well then. Also shocking that I dont remember how my own code worked, especially since I still agree with the result

seems to have been a last minute change

going by the comment

correct, it wasn't initially coded that way. I think someone asked about it, and then I realized it was kind of pointless given the standard usage of tor

if you trust the onion overlay network, its just slowing things down (delay AND d++)

So with a zmq layer rpc woukd be faster? Or what is the main rationale?

jozef[m]: yeah in theory it should process faster because the 0mq is faster binary protocol to process than http

but things are probably dominated by json processing time, so Im not sure of the % difference unless msgpack (or similar) is used

the http parser in monerod probably isn't the most optimized either. but even ignoring that...

Is there a high-level doc on the various networking types and protocols used and what their main use by all the tools? E.g. dameon, wallet, req/rep, pub/sub, ...

if `docs/...` doesn't have what you want, then no

vtnerd: last question, "Dandelion++ sending on the hidden service side (immediate flood/fluff)" shouldn't this say on the clearnet side?

guess it wasn't clear, upated comment

from hidden service side to clearnet

ok yes it is more clear now, otherwise some might think we do d++ over tor