05:02:19 "And are there any other reason..." <- here we go: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319 05:02:27 as expected 05:13:41 "... simple mode" by implementing a trusted community node system" incompetent to solve problem with proper code -> add trusted nodes 05:13:43 bs 05:14:37 "Create a more thorough UI for warning users of GUI mode of high fees" instead of removing fee prediction unsuitable for decentralized untrusted env, bs 05:15:08 "Draft a formal Levin/Cryptonote protocol specification" it's impossible without code reading which is already hard for some reason, unreachable goal 05:17:23 "Continue to remove dead code" start to read not dead code would be better, but it's hard for some reason; bs 05:17:39 "Misc developing / reviews" without code reading ? how is it possible ? 05:17:40 bs 05:18:33 "Unclear protocols cause bugs and choke out emerging projects which wish to incorporate into the ecosystem. " code written by people who don't read code leads such bugs 05:19:53 It's literally this https://en.wikipedia.org/wiki/Influence_peddling 05:23:46 Users suffer from incompetent developers and they are using it as a leverage to do more bs work: https://github.com/monero-project/monero/issues/8298 05:23:49 facepalm 05:39:54 "All of these points do not directly affect the end-user experience but will ultimately improve the developer experience, reducing friction in the future, contributing to the long-term health of the codebase." incompetent developer is going to improve long-term health of the codebase without reading it; and state explicitly that end-user isn't the target 05:39:54 facepalm 06:04:49 "It's always a nice thing to have your code compile on all your targets." warnings != can't compile, the code can be compiled; as soon it can't be someone would just submit minimum patch to fix it 06:05:01 instead of doing all that noise just for the case of work simulation 06:25:09 "https://github.com/monero-project/monero/pull/8307" this is a removal of something that is already implemented and could be used 06:25:41 and it was merged already 06:26:29 And thin here "https://github.com/monero-project/monero/pull/8335" you tried to remove create_ec_ssl_certificate 06:26:59 which not only could be used, but it's even better than RSA in some performance benchmarks 06:27:21 "https://github.com/monero-project/monero/pull/8335#issuecomment-1128071304" and this comment was about stopping you from removing arbitrary things left and right 06:28:23 "... @hyc suggested the idea while I was working on moving certain parts of the codebase to OpenSSL 3.0" and you wrapped it into this 06:28:58 So it shows neither you, neither your PR reviewers, neither code merger have any knowledege about code base 06:29:04 full chain is compromised 06:29:05 facepalm 06:31:54 And these removal balanced with "more placebo test, more trivial docs, relocation of code into separate files" 06:32:04 Do you really believe it helps ? 06:33:16 And also people who don't write code like plowsof are calling this as "talented dev" 06:33:19 double facepalm 06:37:22 and then UkoeHB asks me to be decent and don't ask critical questions in such environment 06:37:25 Are you really sure that I'm wrong ? 07:05:08 Is master supposed to build currently? 07:11:21 "Is master supposed to build..." <- yes unless you have unexpected environment setup, but in that case you can use docker with depends 07:13:08 Yes. If it doens't, paste the error on paste.debian.net and the URL here. 07:13:55 Sometimes, it doesn't due to several patches being merged in one session, and they conflict a bit. Typically very easy to fix. 07:19:02 Errors: https://basilisk-design.co.uk/pastebin/paste.php?id=23 07:20:06 Blocked by captcha, but I'm building here, and I'll see if I can fix once I get to the error. 07:22:45 "https://github.com/monero-project/monero/pull/8211/commits/801568d0c6dadfcf4992eaf7ed5565e5682ad248" this change 07:23:11 Pastebin: https://paste.debian.net/1241249/ 07:24:05 Deleting captcha infested account :( 07:25:26 Odd one. What OS ? 07:26:14 And I've just built levin_notify just fine, without that error. 07:27:29 OS: Slackware x64 14.2 07:28:42 v0.17.3.2 builds just fine. 07:28:57 $ ./usr/bin/monerod --version 07:28:57 Monero 'Oxygen Orion' (v0.17.3.2-release) 07:29:01 Good data point. 07:30:04 The relevant change I see if the switch from byte_slice. 07:31:54 Looks a bit annoying to cherry pick though. 07:33:11 I'll wait for a tag or branch for v0.18 :) 07:33:19 Sorry, no quick fix here then. We might have to wait for a coder who has the problem. 07:35:41 They key problem is in "no known conversion for argument 2 from ‘const __gnu_cxx::__normal_iterator >’ to ‘std::basic_string::iterator {aka __gnu_cxx::__normal_iterator >}’" 07:35:53 aka the compiler couldn't convert const char* to char* 07:36:45 Actually, try to revert 801568d0c6dadfcf4992eaf7ed5565e5682ad248 07:37:02 I would try to rewrite "m_cache.erase(m_cache.begin(), result[0].second);" as "m_cache.erase(0, result[0].second - m_cache.begin());" or something like that 07:37:44 That patch says it "refactors" but there's no factoring I can see. Sigh. 07:37:44 sech1: I would try to firstly identify the source of problem instead of doing random bit flipping 07:37:45 I'm on gcc 5.5.0 if that means anything. 07:38:20 I hate how people use "refactor" for "rewrite how I like" nowadays. Factoring is taking various similar/identical bits of code and merging them. 07:38:34 moneromooo: +1 07:38:54 ooo123ooo1234[m] Did you read what I wrote? I found the source of problem - const char* vs char* incompatibility 07:39:05 older compiler doesn't have enough definitions in headers probably 07:40:11 oh yes, 801568d0c6dadfcf4992eaf7ed5565e5682ad248 is the culprit 07:42:21 https://github.com/monero-project/monero/commit/2499269696192ce30dd125ddee90a80d4326dff9 07:42:29 "However, this in not necessary as of C++11, so I removed the conversion 07:42:29 altogether." 07:42:53 I'm not an C++ expert, is it true? gcc 5.5.0 does support C++11 though 07:44:17 sech1: Don't underestimate, you're pretty C++ expert in current environment 07:44:31 "iterator erase( const_iterator first, const_iterator last );" is available since C++11, the compiler should've used that instance 07:44:37 Various compilers have bugs and "missing bits" in their standards compliance, especially when they're building up support so it wold not be super surprising. 07:45:13 converting first argument from iterator to const_iterator should've been done implicitly by the compiler 07:45:55 so better advice to admin_ would be to update the compiler 07:49:53 gcc 5.5.0 is the latest on Slackware 14.2 - I'll try on Slackware 15.0 (gcc 11.2.0), as soon as I have made install packages for the dependencies not available standard. 08:25:07 Building with gcc 11.2.0 is a lot more noisy than gcc 5.5.0 - The amount of warnings are scary. 09:10:23 Building master on Slackware 15, gcc 11.2.0 was successful, with a lot less warnings, compared to building release-17. 09:10:38 Only missing dependency was unbound. 09:11:28 $ ./usr/bin/monerod --version 09:11:29 Monero 'Oxygen Orion' (v0.17.0.0-6e60919e6) 11:03:39 "Building master on Slackware 15,..." <- Do you still have access to that env with gcc5 ? 11:19:27 "so better advice to admin_ would..." <- Not better since it isn't related to compiler version 11:19:52 Proof? 11:20:00 "ooo123ooo1234 Did you read..." <- It isn't the source of problem 11:20:25 sech1: I have, I have, wait a bit 11:22:52 https://mirrors.atviras.lt/slackware/slackware64-14.2/patches/source/gcc/gcc.SlackBuild - gcc package in slackware14.2 11:23:32 "https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html" info about gcc configuration for versions starting from 5.0 11:24:05 So it is about compiler version 11:25:04 "--with-default-libstdcxx-abi=gcc4-compatible" this flag during gcc package combpilation adds macro -D_GLIBCXX_USE_CXX11_ABI=0 which disable some features of c++11 11:25:38 "--enable-libstdcxx-dual-abi" but this flag is enabled too, so it's possible to set manually that macro to default value 1 11:25:43 and everything will work as expected 11:25:50 including -std=c++11 11:26:00 Btw, that macro breaks build for even the latest gcc version 11:26:00 In essence it's about C++11 support 11:26:17 sech1: So you are not right 11:26:42 sech1: In essense it's about knowledge of your environment 11:26:50 The code that triggered the error is C++11 compliant, so no need to fix it 11:28:02 sech1: yes, that code is compatible with c++11 11:28:52 If it's not hard to support more compilers, why not. As long as it's not MSVC :D 11:29:56 sech1, "https://godbolt.org/z/e5s7ohWMc" proof 11:31:39 "In essence it's about C++11..." <- If this would be a competition then I would won. 11:39:17 Who cares, I care about the code more. If it's standard-compliant, fixing of any compilation errors in exotic environments should be done outside the code - by whoever is compiling it. 11:39:45 Or we'll end up with a million more #ifdefs and macros 11:40:25 Plus, it's C++11 we're talking about. It's been 11 years, we can just ignore non-compliant environments 11:40:53 we moved to c++14 11:40:53 sech1: Look I've already suggested compilation via docker in the fist step - initial approximation from me 11:40:53 your suggestion to change that line or revert that patch - further approximation by you 11:40:53 and just to add 1 macro which is absolutely safe in that environment - the next approximation from me 11:41:14 My suggestion was made before I learned that the code was in fact correct 11:41:16 In this particular case even precision of initial approximation would be enough 11:41:36 But in everything related to decentral protocol I want as detailed as possible, since it's very important 11:41:37 now that we updated the macOS SDK we could even move to C++17 without issues but that's something for the future 11:41:47 And in cryptography the devil in details, it's also very important 11:42:46 This is why we do audits for all cryptography implementations 11:42:58 lol rip multisig 11:43:33 sech1: No. You can't audit code without learning it. If you don't believe me then let's setup competition with auditors 11:43:33 I'm ready 11:43:34 hahahaha 11:43:59 Did you remeber what auditors find in randomx ? 11:44:01 nothing 11:44:02 What? Auditors _do_ learn everything about the code they audit 11:44:13 it's part of their job 11:44:26 plus they are selected so that they already have necessary background knowledge 11:44:37 sech1: They can learn everything within limited scope 11:45:00 But they will never have time for learning full graph of code without spending on par with people who developed it 11:45:01 Auditors did find a number of issues in randomx 11:45:17 sech1: Call at least 1 which is critical 11:45:55 does every audit _have_ to find something critical? 11:46:07 you're welcome to read through: https://github.com/tevador/RandomX/tree/master/audits 11:46:23 sech1: I've read it at that time, no need to repeat 11:47:25 sech1: Critical for the goal of project. This is the only thing everyone should optimize code for 11:47:45 And it's reasonable to check whether code achieve the goal 11:48:03 We've been checking it for 2.5 years so far (with RandomX) 11:48:44 sech1: I mean if nothing critical is found then work is done properly. And the goal of auditors is to check it. 11:49:42 sech1: If there are a lot of resources to check not critical things too, then great. But it's not necessary 11:58:04 * spirobel[m] uploaded an image: (176KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/cpVUzQrzGBAjNJGtxBvBGvKd/Screenshot%20from%202022-05-18%2019-57-06.png > 11:58:44 I am on the latest version of monero-javascript. I get this error recently when trying to create transactions 11:59:12 anyone has an idea where I could look next to troubleshoot? 12:00:00 You did not paste the error. I assume some picture that got filtered. Setting log level to 2 might help. 12:01:00 Uncaught (in promise) RuntimeError: Aborted(Assertion failed: R == dbg_R, at: /Users/woodser/git/monero-javascript/external/monero-cpp/external/monero-project/src/crypto/crypto.cpp,450,generate_tx_proof). Build with -sASSERTIONS for more info. 12:01:34 https://github.com/monero-project/monero/blob/master/src/crypto/crypto.cpp#L450 12:02:19 it looks like wrong secret key 12:02:20 was provided 12:02:36 That looks like passing a keypair that's not consistent. Is there a stack trace ? 12:02:45 I took a look at this but I have no idea what it means to be honest. I fed it the typical info: "{accountIndex: 0 12:02:45 address: "5F2AGUyXjR3bvX38GaAsARaQ1exeBCVkUbPTfGssBfXQ5VPor4eA144YpUE7FNg5bLcpEuehNne23MkG8ZMCkPEegmCBqDwCTM3QChKCmS" 12:02:45 amount: "250000000000" 12:02:46 relay: false}" 12:03:56 Also, is this a view only wallet ? 12:07:01 This should be a normal wallet similar to the one I created before. creating transactions and relaying them worked before but it stopped working now. There are many degrees of freedom to debugging this. Because monero-javascript versions changed in between and I worked on other parts of the app in between. 12:07:25 I have a javascript stacktrace but its probably not of much help 12:07:40 All I know is it fails somewhere after createTx(config) is called 12:07:46 try git bisect 12:08:00 (if you use git) 12:09:38 are you able to confirm the previous version of monero-javascript works with your current setup, to isolate the issue to the last version? 12:09:53 if you're able to run the code from the terminal, you'll usually get a more informative stacktrace than the browser 12:13:38 before that I was on v0.6.4 and it also didnt work. It was the same error. I thought the wallet might be corrupted so I made a new wallet and got new money from the stagenet faucet. Everything worked. The transactions arrived the balance got added to the wallet but I can still not createTx without issue. In the beginning I thought its because I pass the txconfig from parsepaymenturi to createTx but with the object like above it also does 12:13:38 not work. I dont think its coming from updates in monero-javascript. 12:14:27 I am just looking for some inspiration 🙂 12:14:35 spirobel[m]: 1 detailed log would be better than 1000 of words 12:15:11 Well, the secret key does not match the public key AFAICT. You could log both, and call secret_key_to_public_key in a temp program to see if they match. 12:15:47 I *think* secret to public is just mul G... 12:16:48 the secret key should be in the keysData of the wallet file, right? 12:17:00 What's interesting is where this is called, which is some C++. 12:17:15 Dunno. That's what following the stack trace will tell you. 12:17:59 Probably, though. Unless it's deduced on the fly from kes in the wallet file. 12:18:59 the issue is that I dont really have the stack trace and it would take a lot of time to get it. I am just calling a javascript lib after all. My guess is that the spend key got corrupted. The view key is also in keysdata, right? so it seems like some part of it got corrupted and openwallet still worked ... 12:19:10 so probably the spend key just got lost somewhere 12:19:49 selsta: c++17 isn't fully supported yet by even clang (exotic features like pmr are unsupported) 12:20:01 You are calling... a very high level function, right ? If so, there's a lot of call stack betewen that and generate_tx_proof. 12:20:42 https://moneroecosystem.org/monero-javascript/MoneroWalletFull.html I am calling createTx here 12:21:25 If you can repro without javascript (ie, load that wallet with monero-wallet-cli) then you can use gdb to break on the assert, then see the stack. 12:21:53 UkoeHB according to https://en.cppreference.com/w/cpp/compiler_support indeed clang doesn't fully support C++17, but GCC does 12:22:11 https://clang.llvm.org/cxx_status.html 12:23:17 >Clang 5 and later implement all the features of the ISO C++ 2017 standard. 12:23:36 selsta: not the C++17 STL though 12:25:09 although the missing bits don't seem too important 12:25:14 "the issue is that I dont..." <- "the issue is that I dont really have the stack trace" it must be fixable somehow for web development, otherwise web dev is absolute nightmare 12:27:42 "selsta: c++17 isn't fully..." <- Reduction of target platforms makes writing code easier, not upgrade to some c++ standard 12:28:29 Which isn't compatible with goal of this project otherwise we're targeting linux users with rolling distro 12:28:54 does anyone have reorg logs that go farther back? https://github.com/monero-project/research-lab/issues/102#issuecomment-1129711324 12:28:59 Okay I just did this: Window.wallets['monerochans stash'].isViewOnly().then((x)=> console.log(x)) and it returned false. so it seems like it is opened as a normal wallet. 12:29:20 things we can try:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/f761d400c8afe4f2259daddd21bb86c96623cd3b) 12:29:46 UkoeHB: Current p2p network is very centralized. Logs can't be used as a justification for random bits flipping in protocol 12:31:23 part of p2p network with mining nodes which are directly related to number of reorgs 12:32:11 other nodes have almost 0 impact on mining 12:35:53 * things we can try:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/89c42f0b61d50e1b0383f1405cbbd3b05e06ce25) 12:49:44 ooo123ooo1234[m] 10 blocks lock time was randomly chosen to begin with 12:50:16 and reorgs can be seen by every node, so all logs are relevant 12:51:56 sech1: I mean it would be better to do more analysis for the next change even if prev approximation (10 blocks) was not analysed properly 12:52:17 so we need logs to have data about historical reorgs 12:52:34 I definitely remember seeing reorgs bigger than 5 blocks some time in 2019 or 2020 12:53:04 sech1: I mean logs reflect current p2p network of miners (minexmr 40%, ...) which is closer to not ideal state of network 12:54:03 minexmr runs many nodes in different parts of the world though, so it's multiple miners from network's perspective 12:54:07 same for other big pools 12:54:16 And since the goal is to make it more decentralized synchronization latency will be bigger, not smaller 12:54:50 time to propagate a block is a measurable metric 12:55:08 sech1: This network is controlled by single in which case it's reasonable to connect all owned nodes to each other for better connectivity 12:55:13 if we figure out that it takes < 10 seconds (for example), we can estimate the probability of network mining 5 blocks in those 10 seconds 12:55:24 If the same nodes would be run by untrusted parties, situation would be worse 12:55:45 sech1: Yes, I'm sure that proper measurements will prove my point 12:55:51 I was talking about block propagation (re minexmr as single/multiple miners) 12:56:26 what really matters is block propagation to big pools' nodes 12:56:27 > <@woodser:haveno.network> things we can try:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/02d58c481ce504bdfac042131f62ebe2b08b196d) 12:56:33 alt chains won't get propagated, so you'll only get an alt chain if you're connected to a node for which that chain is currently the main chain. 12:56:54 So you probably do not have all the alt chains in your log range. 12:57:03 right, and alt chains get created because the rest of the network doesn't propagate their blocks quick enough 12:57:19 my node is well connected 12:57:45 sech1: Yes, but I went further and there are some edge cases that could be abused in general case 12:58:29 10 blocks is also a protection against someonw who'd keep a local chain without propagating, if they have 50% or close. 12:58:46 So it requires some modelling of network, choosing parameters, and proving that it's secure within it 12:59:06 I'm not clear when it's worth "starting over" while you have more than 1 and fewer than 10 on your way to a 10 though. 12:59:39 iirc there's a paper that looks into this kind of "selfish mining" 12:59:42 So you would never see those "temporarily withheld" chains now because there's no point (assuming 10 blocks is enoiugh of a deterrent). 13:00:32 But if the lock goes low enough that some people think it's worth trying, then you'd likely get the attempts made, and thus have an inordinate number of chains of that length compared to what you saw before. 13:00:57 basically it's about the odds of you finding a block with a higher pow value before the rest of the network can find the next block on top of the chain tip 13:00:57 merope: There are many projects with different consensus protocol architecture which can be used for the sake of learning 13:01:09 not only that paper which is very narrow scope 13:01:13 High hash rate miners currently don't try to build on their blocks, and will update to the current head, resetting their "local height". 13:02:35 @ooo123ooo1234 - Slackware 15 comes with gcc 11.2.0 - Slackware 14.2 comes with gcc 5.5.0 13:02:42 moneromooo: +1 13:02:57 https://www.researchgate.net/publication/309451429_On_the_Security_and_Performance_of_Proof_of_Work_Blockchains 13:04:11 moneromooo I don't see the incentive for big miners to do reorgs specifically bigger than the lock time. They could just do a reorg of any size to orphan other blocks and get all rewards to themselves. 13:04:53 (also available on moneroresearch.info 13:04:53 ) 13:05:30 sech1 but that is effectively a 51% attack, no? 13:05:32 It allows them to render any tx spending early (right after 10 blocks) invalid. One of those txes might be one of theirs. 13:05:44 ah, so double spending 13:06:24 then we need to calculate probability that a 40% miner can build an N-block chain faster than the rest of the network 13:06:25 I suppose that should really be "more than the number of confirmations your recipient uses" though. 13:06:30 Which might not be 10. 13:06:41 Kraken has 15 confirmations for deposits 13:07:38 In any case, it allows for invalidating random txes which either spend asap or randomly use an extremely young 10 blck fake out. Less annoying though. 13:07:49 xmr.to accepted even 0-conf transactions up to 0.1 BTC equivalent 13:08:51 "@ooo123ooo1234 - Slackware 15..." <- monero master should be compilable on slackware 14.2 with -DCMAKE_CXX_FLAGS="-D_GLIBCXX_USE_CXX11_ABI=0"; if it still makes sense you can test 13:11:24 sech1: Any such number has corresponding probability of double spending. 13:12:13 XMR merchants can set their own confirmation limits which can be higher (Kraken as example) 13:12:35 it's all about acceptable level of risk for each XMR recipient 13:12:52 sech1: Yes, but higher confirmation limit means more troubles for users 13:13:40 And the only way to allow safely small confirmation limit is to learn how to calculate risk proprely -> analyse protcol -> improve it -> objectively smaller risk in the worst case 13:14:22 Both gcc 5.5.0 and 11.2.0 support c++ 11,14,17 13:14:46 sech1: There are of course limitations added by hardware of network participants, but there is still huge room for protocol improvement 13:15:06 TrasherDK: Did you check link about gcc dual-abi ? 13:42:41 UkoeHB, noncesense lab folks should have info on altchains. ping neptune isthmus 13:46:56 Yes, adding the flag didn't help. 13:46:59 cmake \ 13:47:00 -DBOOST_IGNORE_SYSTEM_PATHS=OFF \ 13:47:00 -DCMAKE_BUILD_TYPE=static \ 13:47:00 -DCMAKE_CXX_FLAGS="-D_GLIBCXX_USE_CXX11_ABI=0" 13:47:13 TrasherDK: Oh, sorry. IT must be 1 13:47:20 :) 13:47:21 typo 13:49:00 * HenryHollingwort uploaded an image: (13KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/nwqjpmlolOLjyHvGoGYYFJgo/image.png > 13:49:37 HenryHollingwort: where did you download monero? 13:50:15 hi everyone, i tried to compile master under mysys2 following the instructions and the build succeeded (seemingly) but when I go to run the binaries I receive the following error. Should that dependency have been statically linked? 13:50:15 * HenryHollingwort uploaded an image: (44KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/pBQlrHVKOVLjoEkfDDxyHXPn/image.png > 13:50:27 I cloned master directly from github 13:50:42 (using git cli) 13:50:58 * HenryHollingwort uploaded an image: (44KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/uBGRYKOrpYgueaVsVGIciRjV/image.png > 13:51:10 did you make sure to use the mingw64 msys2 shell? 13:51:16 don't use the git shell 13:51:27 * HenryHollingwort uploaded an image: (3KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/RJyiKyNIJXzHvzfPjbtoPdte/image.png > 13:51:58 what did you enter for make? 13:51:58 that shell is opened with the following command: "C:/msys64/msys2_shell.cmd -defterm -here -no-start -mingw64", 13:52:24 make release-static-win64 13:53:45 * HenryHollingwort uploaded an image: (6KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/vgTJdTliSOKtQZbypuorhgAL/image.png > 13:54:05 it seems to find the libunbound library :/ 13:55:07 we removed the unbound submodule in master, might related 13:55:08 * HenryHollingwort posted a file: (115KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/JysZhIREEXuhZCfWfVDEFbqN/build-log.txt > 13:56:06 HenryHollingwort: did you start monerod from explorer or msys2? 13:57:11 from explorer 13:57:27 check if starting from msys2 works 13:57:46 yep that works 13:57:54 * HenryHollingwort uploaded an image: (39KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/EAVkosaTPTihEgdYNwehloZz/image.png > 13:58:46 don't know a fix yet, have to try a bit around myself 13:59:23 should it work from explorer? I assume that mysys2 adds some stuff to PATH and then the dll is dynamically linked so it works from there? idk i don't know much about c/c++ building and native stuff haha 13:59:57 it should work from explorer 14:00:07 at least when you do release-static 14:00:22 yeah that makes sense 14:02:29 maybe a dumb question, but should running the current release in --testnet work (well without me and whoever is running the old version 'forking off')? The reason I ask was because I was working on the monero bounties bot and all my transactions seemed to not go through and then I remembered reading a post of reddit about the testnet having forked to master to test the upcoming release. When I realised that I assumed it was 14:02:29 probably why my daemon seemed to be acting funny 14:02:47 some cmake changes required probably, will take a look later 14:02:58 testnet requires master for now 14:03:14 release-0.17 will be on the wrong chain 14:03:31 great thanks, I thought that was the case 14:08:26 And my testnet daemon is down until I can build again :( 14:09:36 HenryHollingwort: can you tell me the path on Windows for monerod.exe? 14:10:05 C:\msys64\home\Henry\monero\build\MINGW64_NT-10.0-22000\master\release\bin 14:10:25 ty 14:12:29 I remember having similar .dll issues when compiling on Windows, and I somehow fixed it. I'll check in the evening when I'm back home. 14:17:28 I know nothing but just hand a little look around trying to see if anything obvious shows up and 14:17:28 https://github.com/monero-project/monero/blob/master/CMakeLists.txt#L1049 thre is a "-static" flag which the comment says will make the build 'as close to fully-static as we get' which makes me think that the '-static' should show up in the command that ultimately gets executed? but I don't see it in the makefile under /release (the build dir) 14:18:16 release-static-win64: 14:18:16 mkdir -p $(builddir)/release 14:18:16 cd $(builddir)/release && cmake -G "MSYS Makefiles" -D STATIC=ON -D ARCH="x86-64" -D BUILD_64=ON -D CMAKE_BUILD_TYPE=Release -D BUILD_TAG="win-x64" -D CMAKE_TOOLCHAIN_FILE=$(topdir)/cmake/64-bit-toolchain.cmake -D MSYS2_FOLDER=$(shell cd ${MINGW_PREFIX}/.. && pwd -W) $(topdir) && $(MAKE) 14:18:32 -D STATIC=ON should do the magic 14:18:41 unless the -static was what caused STATIC=ON i dunno :\ like I said I really have no clue about this kind of stuff 14:18:59 the makefile calls cmake which again calls make 14:20:24 https://github.com/monero-project/monero/blob/master/CMakeLists.txt#L1049 14:20:31 it sets "-static" there 14:22:50 make first time creates that makefile in /release, that then calls make again but at that stage STATIC is set so it will add the -static flag during the actual compilation 14:22:57 got it thanks 14:24:08 i've got to head to bed, but let me know if I can help with anything later :) even if it's just testing it again locally 14:27:42 fyi, my linode monerod has ~5 years worth of logs, 1082 reorgs. all but 4 had size 2, those 4 had size 3. 14:29:40 libunbound-8.dll => /mingw64/bin/libunbound-8.dll (0x7ffba0860000) 14:33:04 " with new abi within 14.2. So that refactoring made incompatible your env with master. 14:35:05 Yet another reason C++ sucks, compiler-version-dependent ABI... 14:35:39 hyc: yeah, yeah. I remember you were talking about it at least once here. 14:35:56 yeah, definitely not a new topic 14:40:09 C is not much better in terms of ABI: https://gankra.github.io/blah/c-isnt-a-language/ 15:00:15 meh. the arguments in that writeup are mostly immaterial, don't affect the majority of C or non-C progreammers 15:00:36 because in C only the language implementers need to know the fine details of the ABI 15:01:20 in C nobody else needs to be aware of them. in C++ most people don't know the details but they bump into the problems all the time. 15:02:55 he bitches about __int128 as an example. which is such an edge case on its own, nothing in reality uses inegers with 128 bits of dynamic range. 15:03:58 but mostly, "C ABI" is wrong perspective. The "ABI" is an assembly language calling convention. C was a user-friendly frontend to assembly language. 15:04:11 Language standards committees have lost sight of this fact. 15:05:35 his diatribe about parsing C header files is a misrepresentation, most of the complexity of definitions and includes is handled by the C preprocessor, not the compiler. the preprocessor isn't even a C-syntax-aware program. it's just a text processor like m4.\ 15:08:43 __int128 is a popular GCC extension. Many scientific programs use it (those which don't need more than 128 bits). Even p2pool uses it for 128:64 division and 64x64->128 multiplication 15:11:13 those uses are self-contained tho, so you never bump into the ABI boundary 15:33:04 sech1, did you check thesis of that author ? 15:33:12 https://gankra.github.io/blah/papers/thesis.pdf 15:33:23 I'm reading 4.2 Paranoia 15:33:26 now 15:51:32 "Paranoid solutions give the compiler and programmer rich information to optimize the program with. " hmm, rust lang is for paranoid solutions 16:02:43 If I would have unhealthy paranoia then I would love probably. But It looks like a waste of time for me to add all those specifiers with the hope to avoid memory unsafety. 16:07:04 reg Jeffs ccs proposal - i have edited / disappeared into the hedge like homer'd my comment. We need actual developers to read it and offer opinions.. we also try to discuss ccs ideas in community meetings (not this sunday , but next) x 16:07:09 "... Control is absolutely the greatest strength of naive interfaces. They empower excellent programmers to produce excellent code where it matters." it looks like exactly the case of lmdb or any other low level staff 16:07:14 e.g. firmware 16:08:38 s/staff/stuff/ 16:23:14 is there a way to set a password for specific accounts within a wallet? 16:23:34 no 16:38:28 "> <@woodser:haveno.network..." <- spirobel:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c70ac087c79decb82a704b2b24b368f43b7d10ac) 17:25:09 selsta Monero binaries compiled in mingw64 have dependency on libunbound-8.dll on my system too 17:25:33 yes, I reproduced it on CI, but didn't find a fix yet 17:25:44 As far as I can see, libunbound package in mingw installs only dll and headers 17:26:02 I saw .dll.a 17:26:04 that's what we get for preferring pre-installed libunbound to our vendored source 17:26:14 dll.a is just an import library for a dll 17:26:17 .dll.a is just declarations for dll functions 17:26:24 yes, import library 17:26:35 hyc: the vendored one was extremely outdated and full of (security) bugs 17:28:56 why didn't we just update it then? 17:29:41 I solved this problem by just adding the path to libunbound-8.dll to the system search path and successfully forgot about it :D 17:30:17 hyc: https://github.com/monero-project/monero/pull/7773 17:30:49 this is also the reason issue #8322 exists 17:31:30 gitian builds don't have this problem 17:31:39 so main problem is supporting autoconf from cmake? 17:31:39 (with the dll) 17:31:43 i mean the reason why we had a vendored unbound in the first place was because we applied our own security patches 17:31:50 gitian builds libunbound explicitly 17:32:00 but our own unbound become outdated and unmaintained 17:32:44 yeah. I recall we had that wonderful problem where unbound was writing errmsgs unconditionally to descripter 2 and overwriting the blockchain DB 17:33:52 and I tried autoconf from cmake, but it was a mess getting it supported for all OS and cross compiling 17:34:07 so I removed it completely, and everyone who wants to compile static bins without depends should deal with it themselves 17:34:16 heh, ok 17:35:14 I guess since we have depends working we can ignore it 17:35:34 manually compiling static unbound should be enough I think 17:35:49 yes 17:36:16 without any extra frills. like macosx's libunbound using libnghttp2 17:36:17 and setting UNBOUND_ROOT 17:37:09 sech1: do you know why some mingw packages contain static libs and some don't? 17:37:39 ask whoever made a specific package. I guess it's just how it is in open source 17:37:54 true :P 17:38:39 so the quick fix for me would be to compile latest static libunbound locally and make cmake find it? 17:39:01 yep 17:40:23 you might also have to compile expat, not sure 17:40:29 the lowest effort would prob be to cd contrib/depends; make HOST=x86_64-windows-pc (or whatever) unbound 17:40:46 then copy the resulting static libs to your windows box 17:40:56 at least I did that here https://github.com/monero-project/monero-gui/pull/3696/ 17:41:02 which was copied from depends 17:41:34 HOSTS="i686-w64-mingw32 x86_64-w64-mingw32" 17:42:25 that would ensure you get one built correctly anyway 18:27:52 ooo123ooo1234[m]: can you help me with https://paste.debian.net/hidden/29afb4ff/ ? I have this plus the binary, I want to find the code part where the segfault occurred. Do I have to use addr2line or something else? 18:31:31 it's the first segfault in many months so I'm curious 18:39:38 ip is the place you want. I expect the first number is the address, though from the wording I'd expect it to be ip. 18:40:06 addr2line should work from that ip if you're lucky. 18:40:19 (ie, if built with enough debug info) 18:40:46 ip/eip might point to the insn right after the one that borked, I can never remember. 18:42:36 If it doesn't work, you theoretically could rebuild with all debug info, without changing other flags, and grep the "Code" bitstring to find the new address the "f3" corresponds to. A bit of a pain in the arse though. 18:43:16 And that's assuming extra debug info doesn't change the emitted code. 18:43:55 You did check if there's a core ? It'd simplify a lot :D 18:45:03 ulimit was unfortunately set to 0 18:45:14 it did say core dumped but i did not find anything 20:31:46 "ooo123ooo1234: can you help me..." <- the binary is unavailale 20:33:13 ooo123ooo1234[m]: https://gui.xmr.pm/files/monerod_copy 21:23:57 Anyone else getting "Exception: boost::wrapexcept" with the new testnet code ? 21:24:14 i didn't get it yet 21:24:33 full log? 21:25:41 I'll post an issue on GH 21:28:25 https://github.com/monero-project/monero/issues/8341 21:35:49 Bad_weak_ptr sounds like it could be related to that segfault issue 21:43:00 my segfault wasn't testnet 21:45:54 these uncaught exceptions show up from time to time, don't know about that specific one 21:50:46 Okay it's not just testnet, it shows up on all 3 networks for me 22:48:31 "it's the first segfault in..." <- https://github.com/monero-project/monero/blob/master/external/db_drivers/liblmdb/mdb.c#L3080 22:48:34 https://paste.debian.net/hidden/d17b5fb9/ 22:49:13 hmmmm thanks 22:49:28 also ping hyc ^ 22:51:04 found interesting repo dedicated to lmdb 22:51:09 https://github.com/TeamSeri0us/pocs/blob/master/lmdb/lmdb%20initialization%20vuln/lmdb%20initialization%20vuln.md 22:51:29 probably all of them already fixed in upstream since 2019 23:01:01 "Bad_weak_ptr sounds like it..." <- "https://github.com/monero-project/monero/issues/8341", "It occurs every ~15 seconds while running monerod, no matter the network:" Open debugger and check what's going on there 23:01:08 if it's so easy to reproduce 23:01:35 "Bad_weak_ptr sounds like it..." <- It isn't related 23:02:41 I checked my logs and didn't see it but I'm not sure if depends binaries even print stack traces to logs 23:04:23 https://github.com/monero-project/monero/blob/master/contrib/depends/packages/unwind.mk 23:04:31 ok, should print them 23:05:56 "Anyone else getting "Exception..." <- Did you check history "https://github.com/monero-project/monero/issues?q=is%3Aissue+bad_weak_ptr+" ? 23:07:49 https://github.com/monero-project/monero/pull/6269 23:08:23 > > <@jeffro256:monero.social> Anyone else getting "Exception: boost::wrapexcept" with the new testnet code ? 23:08:23 > 23:08:23 > Did you check history "https://github.com/monero-project/monero/issues?q=is%3Aissue+bad_weak_ptr+" ? 23:08:36 Only for open issues, will take a look 23:08:46 Doesn't seem like they got too far 23:09:10 There's a ton of boost::shared_ptr 's in the tcp server code so it could be a lot of things 23:11:36 https://github.com/monero-project/monero/issues/6473 has some people reporting the same 23:12:54 but should be fine to keep your issue open jeffro256[m] as they are all closed 23:16:31 moneromooo The first trace is not at all similar to my trace, so it's probably unrelated. The second trace looks a lot more similar but moneromooo says its fixed, which it appears not to be 23:16:52 * @selsta 23:24:04 It appears to originate from safe_shared_from_this() in abstract_tcp_server2.inl