> @sech1 jeffro256 for once I agree with ooo123, deprecated methods are not relevant for this PR review. As selsta commented there somewhere, boost 1.59 is still supported in Monero code, so we can use these methods.

We support Boost 1.58+, which means we should work to support newer versions as well, since most people's Boost build is going to be newer than 1.58. We already do this in practice with compatibility macros such as GET_IO_SERVICE, and since @ooo123ooo1234567 is completely rewriting all these connection methods, it should be done correctly THIS time

I know its annoying, and I know that how it was before this PR, but we don't want 2 giant rewrites: "connection: fix implementation" and "connection: fix implementation: fix implementation" :D

> "monero-project/monero #7760#discussion_r889421565", "potentially infinite while loop" potentially shallow comment

This is not a shallow comment because infinite while loops will waste CI build time and slow down feedback. Not to mention if you're running the tests locally trying out somone's new PR who touches the server code down the line and it deadlocks and then you sit there and sit there and then kill it early and then lose debug informatation

Also I'm getting to the "Correctness" soon™, I was just pointing out the glaring surface issues I see

<jeffro256[m]> "I know its annoying, and I..." <- It would be better to want working code firstly, before anything else including "glaring surface issues".

jeffro256[m]: 100% you're underestimate hardness of this part, otherwise you wouldn't waste time.

s/underestimate/underestimating/

<jeffro256[m]> "I know its annoying, and I..." <- There will not be even alternative implementation of fixes to added tests. Since my patch is correct and glaring issues are easy to fix, unlike correctness issues in PRs of others.

> jeffro256: can you stop writing those subjective comments and focus on checking whether problems from tests are solved and no others were introduced ?

With all due respect, I sense a double standard here in regards to PR #8365. PR #8365 passes all tests, solves a small, but well defined issue, and doesn't introduce any new problems. Of course, it is arguable if it is the BEST solution (I don't think it is). However you called the devs who approved "incompetent" and that they "blindly approved" of it. Yet when people scrutinize your PR, you become rather defensive. Please, it's a

large, complex PR, and I appreciate the work you're putting into it, but you have to be open to some review when the PR is so large

jeffro256[m]: we will close 8365

@selsta Cool

while it is correct, removing the RNG in the first place is even better

> <@jeffro256:monero.social> > jeffro256: can you stop writing those subjective comments and focus on checking whether problems from tests are solved and no others were introduced ?... (full message at libera.ems.host/_matrix/media/r0/do…7c8907d56c14267b94f9e51c00d0208e6a4)

> while it is correct, removing the RNG in the first place is even better

+1

All future PRs will be only bigger.

Even bigger than whole p2pool

hahahaha

<sech1> "Switching away from libuv..." <- But what if I told you there was a Rust libuv with minimal testing and minimal real world usage... but in Rust 👀

/s. Let's not suggest replacing entire frameworks :p

> > <@jeffro256:monero.social> > jeffro256: can you stop writing those subjective comments and focus on checking whether problems from tests are solved and no others were introduced ?... (full message at libera.ems.host/_matrix/media/r0/do…4be92d1bea0696a424c664f644cd6ec6c80)

all i know is that all current nodes run completely broken ssl code

and it results in bad user experience

Regarding infinite loops, the issue for me is they're impossible to debug. You have no idea if it's processing a small data set slowly, processing a large data set legitimately, or processing infinitely. There should be a specific message localized, as two infinite loops means you don't even know which triggered (assuming a lack of contextual logs)

> <@jeffro256:monero.social> > > <@jeffro256:monero.social> > jeffro256: can you stop writing those subjective comments and focus on checking whether problems from tests are solved and no others were introduced ?... (full message at libera.ems.host/_matrix/media/r0/do…c69fe2850e3a27012dc0b7a38ff93abbf5b)

> all i know is that all current nodes run completely broken ssl code

Yeah, firefox will not accept any connections to our nodes over SSL

* If there is at least 1 subjective change not present in old code with side negative effect then write test to demonstrate it.

ooo123ooo1234567: i think with your code it's better but not fully solved yet

kayabanerve[m]: You're talking about code outside of context. You and jeffro256 didn't even try to run test. facepalm

ooo123ooo1234567: Yes. I'm solely commenting on the theory of infinite loops.

kayabanerve[m]: Don't do it. Code can't reviewed outside of context. Should i prove it ?

* prove it or it's already obvious ?

* Code can't be reviewed outside, * prove it or it's already obvious ?

Based on the comment "potential", it sounds like it should never be practically. I'l saying it should therefore have an explicit execution boundary in case:

1) Context of how it's used is changed, as this means we have a context-dependent infinite loop

2) A bug is introduced within itself

It's a harmless change in your case which massively improves development work flow in the worst case.

I'm advocating for more robust development practices. The end.

jeffro256[m]: our code is full of deprecated boost code. if something gets removed we will have to update the code anyway. i don't think adding a large amount of #if is a good idea currently

kayabanerve[m]: How did you make conclusion whether it's harmless or not outside of context ?

If your loop should never be infinite in practice, you should be able to define an execution boundary. Any value outside of that boundary would be harmless yet cover the case where it is infinite.

If you can't define a boundary, you can't say it shouldn't be infinite because you can't say it should be finite.

kayabanerve[m]: context free comment; facepalm

I'm not saying place the limit directly on the boundary. I do understand a practical n=100, yet due to RNG, n may be much higher, yet then set a limit of 1000. We shouldn't be able to flip a coin 10 times in a row and always get tails unless the code is truly that poorly written.

I didn't say there was even a side effect, just that there are a lot of lines which were changed largely for stylistic reasons and not for practical reasons, despite you being such a strong proponent of minimal diffs. In these cases it would not make sense to be defensive of "shallow" criticisms of such changes

jeffro256[m]: if there is no side effect then it's not related to correctness

* is no negative side effect

Context:... (full message at libera.ems.host/_matrix/media/r0/do…bb38124e69a8e5e1b7492fed6678f5cf977)

* Context:... (full message at libera.ems.host/_matrix/media/r0/do…d1e978cb8fac16c012444686432595d98ef)

> > <@kayabanerve:matrix.org> Regarding infinite loops, the issue for me is they're impossible to debug. You have no idea if it's processing a small data set slowly, processing a large data set legitimately, or processing infinitely. There should be a specific message localized, as two infinite loops means you don't even know which triggered (assuming a lack of contextual logs)

>

> You're talking about code outside of context. You and jeffro256 didn't even try to run test. facepalm

I have tun the tests? I'm saying that it could very easily become a problem in the future. The entire point of a test is that you are challenging the code. You should NOT assume that it will pass by default

*run

> <@kayabanerve:matrix.org> Context:... (full message at libera.ems.host/_matrix/media/r0/do…1beff385f7727cda1548d36fc335cfcd492)

If you can't propose bounds and successfully add a finite limiter to any theoretical infinite loop, I'll tell you right now it should be assumed infinite, and those aren't acceptable

jeffro256: Your replies are screwed up and it's horrible for everyone D:

> <@jeffro256:monero.social> > > <@kayabanerve:matrix.org> Regarding infinite loops, the issue for me is they're impossible to debug. You have no idea if it's processing a small data set slowly, processing a large data set legitimately, or processing infinitely. There should be a specific message localized... (full message at libera.ems.host/_matrix/media/r0/do…aa4b4d5f2cd5db2800dd5e5e5b06e5ee6ad)

Sorry :/ . What does it look like ?

ooo123ooo1234567: You cannot assume people using your code will know its quirks to the degree you do

You should be able to define code with well established boundaries and expectations and know how to program defensively for when they are exceeded

kayabanerve[m]: can you look into code you're talking about at least ? it's context free comment; facepalm

If this should never be infinite, there should be no issue with a finite limit, and we should be able to move on. If there is an issue with providing a finite limit, you cannot successfully argue it's a safe to deploy infinite loop.

Do you want to link it? It really doesn't matter for the comments I'm making. If it's a potentially infinite loop, I will always have this comment.

one of the large issues tackled in #7760 is *deadlocks* and *race conditions*. These become a problem when you wait on them in an infinite loop

You need a backup condition in cases like this. Multithreaded code is not deterministic

kayabanerve[m]: there is infinite loop; it's just comment from jeffro256 which have even tried to verify; facepalm

jeffro256[m]: It's not actually replying via Matrix yet copying the entire original message and adding > to it to quote it. IRC gets the original message repeated and I got tagged because you replied to a message replying to me, yet your quote re-included my message as well including my nick

* there is no infinite loop;

* there is no infinite loop; it's just comment from jeffro256 which you haven't even tried to verify; facepalm

It may be your client is bugged. If it is, just stop using replies though.

And I don't blame you for it :p Just trying to stop multi-line IRC spam and extraneous pings

ooo123ooo1234567: There isn't one. Great. Then my commentary is void

Using fractal right now, I think it's in beta

noted

You never said there wasn't one. Jeffro commented there was a potential one and I commented on that.

kayabanerve[m]: Are you kidding ? You wasted my time with debate without understanding the context; is it ok ?

You could've just said Jeffro was wrong, and that there wasn't an infinite loop, instead of debating my commentary on the potential infinite loop.

Yes there is: monero-project/monero #7760#discussion_r889421565

Except I do want to hear jeffro256's comment still as I'm not convinced there isn't a potentially infinite loop. I think there isn't one with the context you've created, but...

kayabanerve[m]: It doesn't work with people. I tried

jeffro256: That looks like a sleep statement

So I have two comments.

1) That is potentially infinite.

2) Use sleep statements instead of maxing out a CPU.

The "potentially" part comes from calling some logic, then expecting a value to converge on something in the future. And doing a hard wait with no exit condition

You're assuming the rest of the code will successfully trigger those events. If it doesn't, the code is wrong. Your test should say it's wrong, not infinitely loop in wait.

This is not ideal for unit tests and can be easily changed

I'd make it a for loop with an inner sleep. If at the end, that condition still isn't met, panic.

> You're assuming the rest of the code will successfully trigger those events. If it doesn't, the code is wrong. Your test should say it's wrong, not infinitely loop in wait.

+1 you understand

kayabanerve[m]: I really feel like this is the definitive statement which jeffro256 has been trying to communicate

Yeah, still bugged, get a different client :p

in practice i've run this code for 1 year now on multiple nodes, it has been bug free

kayabanerve[m]: infinite loop in case if code is broken, which is not desired state of things. Why does it matter to optimize something for this ?

are you expecting that code will be broken again and don't want to waste time in that test ?

> in practice i've run this code for 1 year now on multiple nodes, it has been bug free

That's good, but it might not stay that way with future PRs and you may just not have hit a snag

ooo123ooo1234567: > infinite loop in case if code is broken

I explicitly said your test should error if the code is broken

Maybe it's better to focus on how to make code correct instead of optimizing test case for future broken code; facepalm

Your have a poorly written test.

Okay I'm getting on a flight so I'll talk later

Also, this is waiting for a condition. If that condition is 50ms away, you'll hammer a CPU thread for 50ms.

If you instead sleep for 10ms, you only make 5 requests.

If that condition should already be met, so this shouldn't need to be a loop, then make it an if statement. If it's not the case, panic

kayabanerve[m]: code with patch will no trigger that test ever again, why does it matter ?

Tests are written on the assumption code is wrong to prove it's correct

you're suggesting polishing of test that reproduce deep problem instead of learning the problem and studying the code that fixes it; facepalm

You're arguing for a test written on the premise the code is correct

That is a fundamental disagreeance with why tests exist which invalidate them

You've spent longer debating this then it would take for you to make your code more robust while reducing CPU utilization

If that condition should already be true, `while (condition);` -> `if (!condition) { panic(); }`

If that condition should be true in the near future, `for (int i = 0; condition; i++) { if (i == n) { panic(); } sleep(x); }

* If that condition should already be true, `while (condition);` -> `if (!condition) { panic(); }`

If that condition should be true in the near future, \`for (int i = 0; condition; i++) { if (i == n) { panic(); } sleep(x); }`

* sleep(x); }`

It's a simple change which makes your test more robust as it now tests for additional error cases it would've previously not brought up, simplifies debugging by explicitly erroring, and reduces CPU utilization (in the second case).

just to summaries: you're debating about minor detail in reproduction for a deep problem that is already solved; you didn't participate in identifying it, didn't participate in fixing it; do you really thing that it's useful to talk about it ?

This should not be a lengthy debate, and you shouldn't have claimed this isn't an infinite loop.

where to start in monero source code?

I literally just sent you a proposed set of modifications as my way to help you fix it

I can't comment on what n/x values you want as I don't know the timing on this.

GnetDotcom[m]: Depends on what you want to do! The GitHub is github.com/monero-project/monero

s/thing/think/

ooo123ooo1234567: So I do hear you saying this, which you briefly brought up in the past yet in a different way.

kayabanerve[m]: I want to understand the code

Will the test be deleted?

in general i think focus should be on getting current code reviewed on correctness, optimizations to existing tests can be done at a later date

selsta: Considering this is solely in the tests, I'm fine with it being merged. I'm more debating the theory around infinite loops.

if the whole code isn't approved yet focusing on minor test cases isn't going to bring us forward

kayabanerve[m]: it isn't infinite loop, read code or run it

it just ends in debate ans it is wrong focus

and*

it's more like synchronization barrier to trigger race condition

I'm willing to walk away from this. Thanks for refocusing selsta

GnetDotcom[m]: Right, yet the question remains, *why*

kayabanerve[m]: sorry, i just want these issues fixed :) and i think these loops aren't a good focus currently

Because it's a very large project and it'll take you a long time to understand every component. Is there a specific bug you want to fix, a specific feature you want to discuss, a specific part you want to work with...

kayabanerve[m]: it's called context free changes

s/changes/comments/

s/changes/comment/

selsta: No, no, nothing to be sorry about. It's a pointless conversation created by people who care more about arguing then solutions. Thanks for being the latter

kayabanerve[m]: you and jeffro256 are discussing unimportant test and avoiding to discuss solution; facepalm

s/to/checking/, s/discuss/actual/

kayabanerve[m]: it would enough for the beginning to check actual code, you've joined jeffro256 without understanding what you're talking about

* it would be enough for

anyway sech1 said he would do a review with focus on code correctness so we should wait on that

selsta: might be good to cleanly document all the things people want to follow-up and fix

<selsta> "in general i think focus..." <- this isn't even the case of optimization in test; there is no infinite loop

or improve*

UkoeHB: i think to know if this is even something to optimize it requires full code knowledge

that's why we have to wait for a full review

selsta: is it how public talk supposed to work ? everyone is telling without understanding and others blindly agree and shut up those disagree

* up those who disagree

selsta: the PR is never going to get updated unless there is a critical flaw, so you might as well start a list of all the code quality things to PR as follow-up

in the mean finding polite excuses to cover their incompetence

Where is located the PRNG in the source?

GnetDotcom[m]: The PRNG is one from keccak. I'll grab it now for you

src/crypto/random.c

UkoeHB: No. the only 1 important comment from vtnerd was included instantly, everything else will be included only after confirmed correctness, since it's optional and much easier changes

yes, ooo123ooo1234567 already offered to change code style later

UkoeHB: but sure, if anything remains that isn't a microoptimiization we can keep a list.

oh surprising

UkoeHB: there is no value in talking with people that can't firstly done the hardest part before leaving unimportant comments

<UkoeHB> "selsta: the PR is never going to..." <- with ability to exclude critical flaws it's possible to move very quickly in right direction, but with these unimportant comments even 1 such PR can't be merged

s/merged/verified properly/

* with ability to exclude all critical flaws it's possible to move very quickly in right direction, but with these unimportant comments even 1 such PR can't be verified properly

<ooo123ooo1234567> "there is no value in talking..." <- You're perfect daemon I presume?

<selsta> "it just ends in debate ans it is..." <- it's another time when someone is commenting on something without looking into it closely. it isn't wrong focus if others will stop commenting on something without looking into it closely.

> <@selsta:libera.chat> it just ends in debate ans it is wrong focus

* it's another time when someone is commenting on something without looking into it closely. it isn't wrong focus if others will stop writing context free comments.

<selsta> "anyway sech1 said he would do..." <- there is no need to wait for anything after that

yes, but we have to wait until he gets to it

selsta: who are we ?

* we ? and wait for what ?

well everyone has to wait until there is one full code review (e.g. done by sech1)

<kayabanerve[m]> "Your have a poorly written test...." <- define measure of poorness, It would be interesting to compare it across different tests

"monero-project/monero #7760/files/925c0364d2d8823132cda8cdc84619828c8e4607#r889636515", what's the reason to add any sleeps if correct should run as fast as possible ? it will be redundant and will slow down test with arbitrary sleep constant

you clearly don't understand the context

ooo123ooo1234567: I appreciate the PR. This is a minor nitpick about the test which isn't important. While I maintain all my theoretical commentary on infinite loops, I don't feel a need to debate this further.

I have no questions to your comments in general, but in that particular context it isn't right

kayabanerve[m]: I don't have questions to your theoretical opinion about infinite loops, it may be even equal to mine.

I already said I was fine moving on, this shouldn't be considered a blocker, and the discussion serves more to argue due to our struggles communicating than to accomplish anything. Dragging me back in after I've made all these statements is pointless.

kayabanerve[m]: If it's fine to move on, then don't add into the last reply something like "I think opponent is completely wrong, but I will not continue".

I said people, not you.

I acknowledged my own faults.

But when you drag me back into this, then yes, it is you specifically

*I said people in my original message walking away from this when I deferred to selsta's accurate dismissal.

kayabanerve[m]: without some conclusion it isn't clear even who is right or wrong, maybe it's me who wrong. But since you added supposition into your last reply, I've replied that it isn't true.

The only thing I said in the message you replied to is that dragging me back in was pointless because we settled this 20 minutes ago.

I also tried sending you a message privately to give my opinion on your communication, as I have before, because it seems a lot of people believe your skills there are much lower than your skills as a developer. I tried to reach out, in a non public setting where we wouldn't spam monero, and further acknowledged your talents and that this nitpick shouldn't be a blocker.

You can do whatever you want in this channel (including pinging me on old conversations). I'm truly done here for tonight. Feel free to reach out privately, where we don't damage this channel with off topic discussion.

kayabanerve[m]: acknowledge through achieved objective goals is more than enough for me, I don't expect anything from others. It isn't even clear who is better without explicit competition.

where is the BIGINT library?

* BIGINT library located in source?

GnetDotcom[m]: in general you can use `git grep` to find things

in the codebase

is there a backup source of entropy other than "CryptAcquireContext()" in src/crypto/random.c ??? because it might get outdated any date (docs.microsoft.com/en-us/windows/wi…pt/nf-wincrypt-cryptacquirecontexta)

s/outdated/removed/

There almost certainly is. They'd be really dumb to remove access to entropy without a replacement.

<GnetDotcom[m]> "is there a backup source of..." <- This API is deprecated. New and existing software should start using Cryptography Next Generation APIs. Microsoft may remove this API in future releases.

Feel free to file a bug about this btw, so someone can add code to use the new one.

hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

<MeowingCat> "hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii..." <- hi

what is CheckLinkerFlag.cmake?

i have never seen a code like Monero

really interesting

i think things i have to link correctly are libsodium and boost with libwallet_merged.a

how should i use Monero source in my CMake configuration?

Hello! I had a very specific question, if monerod is running from an ssd, does that ssd need 256-bit AES hardware-based encryption as some ssds lack that? Or would you insist my SSD have that feature? SSD is running on linux. Are there any dependancies in the Monero protocol that rely on 256-bit AES hardware-based encryption or can I use an SSD

without that safely?

It is not needed.

It is recommended that you encrypt your filesystem, but how you do so is your own business.

Monero has no idea whether your filesystem is encrypted in the first place.

monerod does not encrypt the chain itself, but monero-wallet-cli will encrypt the wallet data.

If mining (or verifying PoW), you'll want a CPU that has hardware AES if possible. Maybe you confused the two ?

In general, I would not trust a disk's encryption myself, I'd use software encryption (ie, dm-crypt).

In any case, encrypting's one filesystem is recommended.

I see, thank you for answering that. No, I understand that some CPU's have hardware AES (mine does), and SSD's most do have hardware AES but are expensive. The SSD is was looking at, not for mining, but for running a full node via monerod only. I will look into dm-crypt.

Since hardware level encryption is not necessary for running a node, I will be able to use a relatively inexpensive ssd which is still quite fast.

As a follow up question, in this instance running monerod, are there any read/write bandwidth recommendations?

Yes, as much as you can get.

monerod does a LOT of random acccess reads and writes.

At least for the initial sync. After that you should not have any trouble keeping up, but still.

I understand, thank you for confirming that. I was essentially tageting a minimum random read speed of 240000 iops and random write of 500000 iops

Also for capacity and performance, the most expensive 250gb with decent read/writes are the same cost as a 500gb which outperforms it, making more sense

I have been looking at 250gb for running a full node, but am debating weather to switch to 500gb as standard simply for the performance gain (capacity increase being incidental)

Wonder what recommendations you would have about minimum capacity

Considering that TBW (terabytes written) is also a concern

as well as the increasing blockchain size, efficient as it is

The chain's something like 140 GB IIRC. Or 47 GB pruned.

I don't have a size increase rate to offer.

Yes, I am aware. I am also estimating a growth of 40GB per year in my calculations

Not sure how accurate that might be

In any case cost is still a concern, and with significant perfomance gains with negligeble incremental costs from 250GB to 500GB, my thinking a switch to 500gb might be justified

Anyway, you may want to continue in #monero. You're in #monero-dev, which is for monero development.

Oh right, sorry about that. Thank you for answering my questions

i think i found static libraries that i should link

libwallet_merged.a, libepee.a, libeasylogging.a, liblmd.a, libunbound.a, libboost_serialization.a, libboost_thread.a, libboost_system.a, libboost_date_time.a, libboost_filesystem.a, libboost_chrono.a, libboost_program_options.a, libboost_regex.a

Might also need openssl.

moneromooo, yesssssss

and zlib

g++ -std=c++14 src/monero_api.cpp $(find ../monero -regex ".+\.a" -printf "%p ") -o monero_api.exe

im doing this

i have to make it correct order but

im curious about libsodium

Yeah, take it with a grain of salt.

there is no anyting for libsodium in Monero build

is that included in Monero static objects?

I found it. There is something for libsodium in Monero build.

you mean static objects???

im looking for .a extension

If you need that and you don't have it, you'll need to build it.

kayabanerve[m]: there is also boost multiprecision for uint128

Doh. I was thinking "there's no bigint code in monero..." and I forgot this one -_-

Thanks for the heads up. I'm honestly not sure where that's used, unless it's the difficulty code. I was aiming to give an answer comparable to ethereum

Technically the block hash is considered an integer when checking difficulty

due to tail emission, the total supply can exceed 2^64

And scalars/field elements are just really big integers :D

moneromooo, okiiii

UkoeHB: Also true, yet not currently coded in monero

In fact, I'm pretty sure the node will panic before then

It explicitly has a max blockchain height iirc

kayabanerve[m]: moneromooo updated it a couple years ago so there's no overflow (the block reward part I think(

That's WAY in the future (the block height hitting max).

To think we coded in planned obsolescence and 2022 nodes won't work in 2200 :(

I'm reasonably sure it's more like tens of thousands of years at least. I looked long ago.

moneromooo: Idk, doesn't seem scalable. Will the gw basic rewrite make this a priority?

(less than tens of thousands of years ago)

I think we can easily justify an extra 10% in funding if so. It's our future!

But yeah, absolutely not a concern in practice :p

Also, while I updated the thing to handle large supply, I wouldn't bet my life there are no bugs. There's always one more bug.

g++ -std=c++14 src/monero_api.cpp ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/lib/libwallet_merged.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/contrib/epee/src/libepee.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/external/easylogging++/libeasylogging.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/external/db_drivers/liblmdb/liblmdb.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/external

/unbound/libunbound.a -lsodium -lboost_serialization-mt -lboost_thread-mt -lboost_system-mt -lboost_date_time-mt -lboost_filesystem-mt -lboost_chrono-mt -lboost_program_options-mt -lboost_regex-mt -o monero_api.exe

im getting these linker errors :((((((

added more libraries

undefined reference to `randomx_dataset_item_count'

Jesus... git grep, or copy the link line as I said yesterday. Pull your weight.

moneromooo, :(( i don't understand what should i loook for in git grep?

g++ -std=c++14 -fstack-protector src/monero_api.cpp ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/lib/libwallet_merged.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/contrib/epee/src/libepee.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/external/easylogging++/libeasylogging.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok_/release/external/db_drivers/liblmdb/liblmdb.a ../monero/build/MINGW64_NT-10.0-22000/_dal_yok

_/release/external/unbound/libunbound.a -lsodium -lboost_serialization-mt -lboost_thread-mt -lboost_system-mt -lboost_date_time-mt -lboost_filesystem-mt -lboost_chrono-mt -lboost_program_options-mt -lboost_regex-mt -lssl -lcrypto -lz -lwsock32 -lws2_32 -o monero_api.exe

undefined reference to `cryptonote::get_transaction_prefix_hash(cryptonote::transaction_prefix const&, crypto::hash&)'

i have cryptonote objects

In a loop, if you get an undefined symbol S, git grep "S". If it's not a monero one, search on the web for which lib it's from. Add lib. Repeat.

cryptonote_basic/libcryptonote_basic.a, cryptonote_basic/libcryptonote_format_utils_basic.a, cryptonote_core/libcryptonote_core.a, cryptonote_protocol/libcryptonote_protocol.a,

Or, as I said, look at what libs monero-wallet-rpc links against, and use that list.

And make sure it's in the right order (that is a pain in the ass).

randomx_dataset_item_count thing is coming from a library called as "librandomx"

Right, you're doing it good now.

im googling names found everything but librandomx looks like not a common thing

i need to build it

because there is no a MSYS2 package

It's in monero. git grep, again. It's in external, this one.

oh okii but

i need to do something to have its object file right?

Yeah. Build monero.

i already built

im looking at *.a files

but there is no anything like librandomx

ohh foound

undefined reference to `google::protobuf::internal::WireFormatLite::UInt32Size(google::protobuf::RepeatedField<unsigned int> const&)'

google????????

I'm *not* googling that for you.

Didn't know we used protobug though

lol, nice typo.

Oh, that's probably trezor. You might want to configure without it.

protobuf??

looking

installed

gooood libusb

hidapi

this thing

unbelievable

third party things are making me crazy

< moneromooo> Oh, that's probably trezor. You might want to configure without it.

(trezor is a hardware wallet, support is optional)

(unless you want it ofc)

i should find the correct order of cryptonote libraries

damnnn

tooo few undefined reference errors

undefined reference to `__imp_CertFreeCertificateContext'

undefined reference to `GetNetworkParams'

only this left

i can't believe

it is done

built

build command

this is unbelievable

damn static libraries

i think it would be easier with seeing build commands doing by build system

now it is time to codeeeeeeeeeee

VERBOSE=1. Did I not say that yesterday ? If not, I hould have :)

Otherwise, ^Z while it links, ps.

Monero::WalletManager::recoveryWalle() wants a "path"

what is that?

moneromooo, thank youuu

A path is a string of directories, separated by /

ohh damn a filesystem path?

So either the path to the wallet file, or to the directory the wallet's in.

for what? wallet data?

i don't want it

What else. recoveryWallet ain't about an jpeg file is it.

i have private seed

im using the same private seed for ETH and BTC

it is encrypted and stored in Godot's abstracted resource filesystem

i just need to recover wallet from seed

and build/sign a TX

If you do not want to store that wallet in a file, you can pass "" IIRC, and it'll keep it in memory.

I added that for tests mostly, but it works also outwith tests.

i will use libwallet for only TXs because i already implemented key derivations in C# i will use it

Monero::Wallet* w = wm->recoveryWallet("", "...");

im doing this

butt std::string result = w->mainAddress(); is causing SIGSEGV :((((((((((((((((((((((

I assume you were taught about checking for errors ?

Like, returning NULL...

ummmmmmm

you mean

w is NULL?

Oh, good point! It might be!

i didn't think thattt

Monero logs various things, if you ask for them.

i can't use my debugger for Windows

because it doesn't support Windows :(((((((((((

OK, maybe monero is a bit too advanced for you then.

i will use VSCode

here github.com/rohanrhu/gdb-frontend

(set MONERO_LOGS=2 and you'll get logs)

you can use it on Linux for Monero development

(an env var)

if you have specific feature requests for Monero debugging tell meeeeeee

Fixing the logged stack traces. They tend to stop being useful and output just addresses, not symbols.

That could do with being more dependable.

ummmmm wdym with logged stack traces???

nvm

ohh you mean GDB shows only function addresses for stack traces?

my debugger has more features than usual things

i will do Windows support too buttttt i have to implement async mode for GDB on Windows

because GDB doesn't have async execution mode in Windows

here is a demonstration for an old version youtube.com/watch?v=4SezdE2Z130

nevermind, it's not about gdb

and not worth the time

Monero is huge im curious about how my debugger would work for Monero debugging

i will try it on Linux to understand the creation of Monero transaction

and i will implement it in C with zero dependencies

zerooooooo third party thingssssss

That'd be a worthy achievement.

i prepared VSCode for debugging

wallet is not NULL

Monero::Wallet::mainAddress() is causing SIGSEGV somehow

std::string mainAddress() const { return address(0, 0); }

here

is this thing an HD wallet thing?

Well, you get to debug. I'm not familiar with the wallet_api API.

maybe this is about empty path?

isn't Monero memory-safe?

why am i getting segfault

is there a place to broadcast signed transactions?

MeowingCat: There's remote nodes and xmrchain.net/rawtx

thank you

> is there a place to broadcast signed transactions?

If you run a node, I'd say that