00:08:46 ill have a try 00:35:53 .merge+ 9042 9043 00:35:53 Added 01:03:09 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 02:06:56 vtnerd: do you have an idea about `Exception: boost::wrapexcept`? 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? https://github.com/monero-project/monero/issues/8132#issuecomment-1753587618 02:07:42 The exception itself doesn't seem to cause any harm, it would just be good if we could avoid printing the exception. 02:11:20 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) 02:13:03 thank you 02:47:02 UkoeHB: can you reply here? afterwards I can add it to the merge queue https://github.com/monero-project/monero/pull/8990#discussion_r1359678679 03:02:30 .merge+ 8990 03:02:30 Added 09:21:05 Hey, quick question: Is `reserve_size` in getblocktemplate the size in bytes? 09:23:13 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? 09:23:33 And then, my proxy should modify blockhashing_blob to include that data? 09:26:46 yes, yes, yes and yes 09:27:03 Sweet, thanks for the confirmation :) 09:27:05 except blockhashing_blob doesn't have this data directly. Reserved bytes are in blocktemplate_blob 09:27:13 aha 09:28:02 So I should modify blocktemplate_blob rather than blockhashing_blob? 09:28:03 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 09:28:16 ok gotcha 09:28:36 If you modify blocktemplate_blob, you have to update blockhashing_blob too 09:28:47 Yep so I replace the coinbase tx? 09:29:06 (In the Merkle tree as well) 09:29:56 yes 09:30:09 Thanks 10:36:36 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 10:36:36 ssage, probably what plowsof experienced also when hitting Ctrl-C 11:35:23 hbs: what about v0.18.2.2, can you reproduce the same issue? 11:47:52 yes same issue with 0.18.2.2 11:50:16 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 16:56:36 dns records for auto-update have been updated to v0.18.3.1 17:03:06 thanks! 17:03:53 Rucknium: did you take a look at the theory behind https://github.com/monero-project/monero/pull/9023 ? can I add it to merge queue? 17:10:17 .merge+ 8922 17:10:17 Added 17:10:37 .merges 17:10:38 -xmr-pr- 8922 8990 9028 9029 9030 9033 9034 9035 9036 9038 9039 9042 9043 9044 9045 9046 9047 9050 9051 17:12:24 Why how 17:12:40 it never ends 17:35:54 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: 17:35:54 -- Found Boost Version: 1.74.0 17:35:55 CMake Error at CMakeLists.txt:886 (message): 17:35:55 Boost older than 1.62 is too old to link with OpenSSL 1.1 or newer 17:35:56 Which seems contradictory, any advice on resolving this? 17:37:27 Do not use boost < 1.62 with openssl >= 1.1. Applying logic: use boost >= 1.62 or openssl < 1.1. 17:37:52 There may be other rules, but the one in the message above can be transformed to the variant above. 17:38:16 Indeed, but as it found boost version 1.74 I would think things should work, no? 17:38:25 (well, not quite logic, since I am assuming one other premise) 17:38:59 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. 17:39:25 If you do, you need to setup your paths so that it only finds 1.74.0. 17:41:06 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. 17:41:30 I guess the test could also be buggy but I feel it'd have been spotted before. 17:42:36 hyc: lmdb patch also relevant for release? 17:43:42 yes, just PR'd that too 17:43:50 ty 17:43:54 low impact, we don't build mdb_load 17:44:23 but if anyone has ever built mdb_dump/load themselves and tried to dump and reload their blockchain DB, load would fail 17:45:08 (he says, while currently doig exactly that ;) 17:55:32 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 18:23:07 Please ignore my above question. It is a 'me' problem. 21:57:41 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. 21:57:54 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. 22:09:21 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? 22:26:43 Let me run the simulations first. Thanks.