curl -X POST 127.0.0.1:38089/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer","params":{"destinations":[{"amount":123400000000,"address":"78n1uR1CAuaKVW62PVuLpyVYeG6CJNdbTNARj4Y4ors4jCSBzWAKpk4TxgVp9pza5P7z3EjKQLzdDLke8wxGvtbyBCxyira"}],"account_index":0,"subaddr_indices":[0],"ring_size":11,"unlock_time":0}}' -H 'Content-Type: application/json'

Hello, when constructing txns, since the `destinations` is an array, if I pass in several txns, and one txn fails, will all txns fail, or will the ones up to the failed txn succeed and ones after the failed txn fail?

The latter.

.merges

oops I think I messed up 8211

again

thoughts on merging my conflict resolution?

You can PR something to fix whatever is borked and I can approve it I guess. I assume it'll be a small patch.

jberman[m]: monero-project/monero #8178 did you run tests with this patch locally?

functional-tests-rpc seem to have gotten stuck

.merge+ 8061

Added

luigi1112 That merge commit you added seemed to do the trick. Looks good on paper and it builds so no complaints. Seems like mj-xmr agrees

maybe it's just me being picky but if you could properly rebase without luigi's merge commit the git history would look cleaner jeffro256[m]

but if you don't want to change it it's fine too

Yeah I can rebase for sure, I'll squish the merge commit with another

As far as I could see, there was just one conflict in one file (CMakeLists.txt).

selsta Okay I rebased to fix the history, no changes to lines

You can double-check it with the compare button if you want

Shall we merge this time? :)

We need a Senior Manager here to keep y'all anarchists in place.

That would be nice

I feel bad for dragging you around every time we merge

It's not your fault.

I appreciate all the effort you put into tho!

PROVE IT! ... by checking one of my olden PRs :)

I can show you some uncontroversial ones.

You can't go wrong with this one:

jeffro256[m]:

where are the managers

thanks guys

i manage the merge queue does that make me a manager

luigi1112 It was tongue-in-cheek I think because someone suggested that we have a dev manager in my PR :)

selsta: I think you are closest we've got to a manager

luigi1112 thanks for merging. cheers!

Thankfully the recruitment ended quickly.

selsta for manager

"I am the manager now" -selsta

.merges

.manages

wow so much left to merge

SELSTA: Senior Elected Leader of Stewardship To Alterations

perfect

+1

Hi, I tried to run monero-wallet-rpc with a view-only wallet. When I tried using the `transfer` RPC method, the wallet-rpc printed these lines and crashed:... (full message at libera.ems.host/_matrix/media/r0/do…ac3625f4e88ca8039f988f6a4c91bfdcb8b)

The crash looks like a memory corruption (or bug in the red black tree code, which less likely). Very bad. Did you build monero-wallet-rpc youtself ?

yes, within docker

I see that `incoming_transfers` method works in restricted mode, will use it instead.

Then try rebuilding with asan (add -D USE_SANITIZER=ON to the cmake command line) and try to make it crash again.

It should print better information, hopefully from the original bug.

er: -D SANTIZE=ON

Also, one little change in unbound too:

in external/unbound/util/storage/lookup3.c

add this line at the very top:

#define VALGRIND

alright I'll add those and get back to you some time later. It's kinda late now hopefully you don't mind.

Sure.

You might have to install asan libs, if you do not have them too.

excellent backronym jeffro256[m]

.merge+ 8245 8246

Added

<Siren[m]> "alright I'll add those and get..." <- Heya again, I ended up compiling it again but this time out of docker

It did not crash this time and even returned a response but there gotta be something wrong since this is a view only wallet

@siren monerodocs.org/cold-storage/offline…ning/#offline-transaction-signing_1

Siren[m]: which dockerfile did you use to build the binary that crashed?

here: github.com/cornfeedhobo/docker-monero/blob/master/Dockerfile

same unbound version that we use for release binaries

<Siren[m]> "It did not crash this time and..." <- It's not normal for someone to give monero-wallet-rpc a view only wallet and try to transfer but maybe it would be better if this case was handled

If it's possible to detect that a wallet is view only, maybe it's better for monero-wallet-rpc to not start without the `--restricted-rpc` option

* When a view only wallet is supplied, maybe it's better for monero-wallet-rpc to not start without the `--restricted-rpc` option

selsta: fixed 8178 (rebased and updated tests)

jberman[m]: was something wrong with the tests before?

i just saw that it timed out

was my fault for not updating the tests. without those changes (specifically the ones that tell the tests to mine more blocks to the mock chain), it would get stuck in an infinite loop in the multisig and transfer tests because there weren't enough outputs in the mock chain to construct a 16 member ring

like this: monero-project/monero #8178/files#diff-3e721ec1e10d7442bda5082e8a672d83b748c85cc3650ed2f098d814184ca9cfR85

probably shouldn't have been infinite looping and should have failed, I didn't dig deeper into the root cause there

ok great, so the fail previously was expected

yep yep. I needed to rebase to repro the failure locally, then I made the changes to the tests in 8178 to fix the failure (specifically needed this change from master so functional tests would use the updated higher ring size rules: github.com/monero-project/monero/bl…src/hardforks/hardforks.cpp#L74-L75)