<p​lowsof:matrix.org> ill have a try

.merge+ 9042 9043

Added

<p​lowsof:matrix.org> hbs ill be honest, i got to the 2nd exchange_multisig_keys step, i closed the wallet on accident with ctrl+c.. and.. now my head hurts

vtnerd: do you have an idea about `Exception: boost::wrapexcept<boost::bad_weak_ptr>`? It's quite spammy and we often get issues about it. It seems someone looked into it here, is there something we can change so that the stacktrace doesn't print in this case? monero-project/monero #8132#issuecomment-1753587618

The exception itself doesn't seem to cause any harm, it would just be good if we could avoid printing the exception.

<v​tnerd:monero.social> I'll look at this tomorrow. I'm not familiar with the issue, so I don't have much to say other than preventing the exception might be useful too, we should be checking for weak_ptr failures (at least I recall seeing some checks)

thank you

UkoeHB: can you reply here? afterwards I can add it to the merge queue monero-project/monero #8990#discussion_r1359678679

.merge+ 8990

Added

Hey, quick question: Is `reserve_size` in getblocktemplate the size in bytes?

Is that something I'd use for adding arbitrary data to a block? I'm trying to write a mining proxy, so I suppose I'd reserve_size of the data I want to put in the block?

And then, my proxy should modify blockhashing_blob to include that data?

yes, yes, yes and yes

Sweet, thanks for the confirmation :)

except blockhashing_blob doesn't have this data directly. Reserved bytes are in blocktemplate_blob

aha

So I should modify blocktemplate_blob rather than blockhashing_blob?

They're in tx_extra field of the coinbase tx, which is then hashed with other transactions into merkle root hash which is what's in the blockhashing_blob

ok gotcha

If you modify blocktemplate_blob, you have to update blockhashing_blob too

Yep so I replace the coinbase tx?

(In the Merkle tree as well)

yes

Thanks

<h​bs:matrix.org> selsta: It worked with 0.18.3.1 when I did the process without quitting monero-wallet-cli, if I do after prepare_multisig or the first exchange_multisig_keys (which is what I did before), then when I re-enter monero-wallet-cli it says that the wallet is a 2/3 multisig which is not yet finalized, but the second exchange_multisig_keys fails with the 'Failure to derive public key' me<clipped message>

<h​bs:matrix.org> ssage, probably what plowsof experienced also when hitting Ctrl-C

hbs: what about v0.18.2.2, can you reproduce the same issue?

<h​bs:matrix.org> yes same issue with 0.18.2.2

<h​bs:matrix.org> basically attempt to create 2/3 multisig by launching and quitting monero-wallet-cli at each step (init, prepare_multisig, make_multisig, exchange_multisig_keys, exchange_multisig_keys), the last exchange_multisig_keys fails

dns records for auto-update have been updated to v0.18.3.1

<p​lowsof:matrix.org> thanks!

Rucknium: did you take a look at the theory behind monero-project/monero #9023 ? can I add it to merge queue?

.merge+ 8922

Added

.merges

Why how

it never ends

<s​packle_xmr:matrix.org> Apologies for the newbie question, but when trying to compile Monero from source on a fresh/updated install of Ubuntu 22.04 I get the error:

<s​packle_xmr:matrix.org> -- Found Boost Version: 1.74.0

<s​packle_xmr:matrix.org> CMake Error at CMakeLists.txt:886 (message):

<s​packle_xmr:matrix.org> Boost older than 1.62 is too old to link with OpenSSL 1.1 or newer

<s​packle_xmr:matrix.org> Which seems contradictory, any advice on resolving this?

Do not use boost < 1.62 with openssl >= 1.1. Applying logic: use boost >= 1.62 or openssl < 1.1.

There may be other rules, but the one in the message above can be transformed to the variant above.

<s​packle_xmr:matrix.org> Indeed, but as it found boost version 1.74 I would think things should work, no?

(well, not quite logic, since I am assuming one other premise)

Oh, I did not see that. Then do you have two boost versions installed ? If not, you may need to clear any CMakeCache.txt file in your build tree.

If you do, you need to setup your paths so that it only finds 1.74.0.

<s​packle_xmr:matrix.org> I'll poke around. I didn't believe I'd done anything bizarre, as I literally only updated/upgraded and installed the dependencies per the readme. Thanks for the quick reply.

I guess the test could also be buggy but I feel it'd have been spotted before.

hyc: lmdb patch also relevant for release?

yes, just PR'd that too

ty

low impact, we don't build mdb_load

but if anyone has ever built mdb_dump/load themselves and tried to dump and reload their blockchain DB, load would fail

(he says, while currently doig exactly that ;)

nice to see the OS doing its thing. have loaded 30GB of data so far, process size went up as high as 450MB and shrank back down to 10MB. the marvels of mmap'd shared memory

<s​packle_xmr:matrix.org> Please ignore my above question. It is a 'me' problem.

<r​ucknium:monero.social> selsta: I think the theory is correct. The effect would be small at current ring size and transaction volume. With larger ring size and/or lower transaction volume, the effect could become larger.

<r​ucknium:monero.social> I wanted to use the closed-form formula of wallet2's decoy selection algorithm that jeffro256 and I developed to run some simulation on how large the effect is. I will put it in my work queue for this week.

rucknium: thanks, should I wait with adding it to the queue or can I add it anyway even if you don't have run the simulations yet?

<r​ucknium:monero.social> Let me run the simulations first. Thanks.