-
unhappymeal[m]
Sorry if this is the wrong channel but I have reached out everywhere and had no luck. I was wondering if any devs could help me out with this, please. I sent a transaction to a Monero account that got left pending for 2 days, I was freaking out because the other party had not received their funds, I read through some forum posts and said that the issue could be caused by my Monero GUI software being of date. I then updated my Monero
-
unhappymeal[m]
GUI and the pending transaction switched to a failed transaction. On top of that, it reverted my Monero wallet to the balance it was at a couple of weeks ago which is around 3usd. The Monero is gone without a trace. Has anyone had this happen before? Is this a known issue?
-
elucidator
unhappymeal[m]: if you are still here, you can restore your wallet from scratch with your seed phrases and see if it restores your wallet balance.
-
selenze[m]
<elucidator> "unhappymeal: if you are still..." <- issue seems to be resolved with what you said...person posted on monero GUI too.
-
elucidator
cool ++
-
selenze[m]
but I wonder if you could enlighten this for me...would a transaction done Now...but based on version 17 of the GUI before the recent hard fork still work?
-
elucidator
the network wouldn't accept that transaction
-
elucidator
fork heights are hardcoded, hence such a transaction will only be accepted if it was made *before* the fork
-
roooooocc[m]
Is there any way of sending a 64 ascii char code on a xmr transaction?
-
selenze[m]
<elucidator> "fork heights are hardcoded..." <- understood, And hopefuly, it won't result in lost funds. In any way, I guess this must be clearly knowable in most of the public notifications to casual users especially during such events of hardfork.
-
elucidator
selenze[m]: i don't think you can lose funds since like the example above, either network or the node you connected will give an error since the signatures won't match for an outdated wallet client and post hardfork network/nodes
-
selenze[m]
thanks for clarifying that.
-
elucidator
sure thing, i'm sure *the* devs can shine more light if required/requested
-
selsta
grumblemobile: can you take a look at 8576 and 8566? would like to include them in the next release, they are both small
-
grumblemobile
Done.
-
selsta
sech1: is 8587 in addition to the threadpool changes?
-
sech1
yes
-
sech1
but they are independent of each other and can be merged in any order
-
sech1
I'm running both on my P2Pool node now
-
sech1
selsta It would be nice to include these two into v0.18.1.2
-
hyc
so moving the checkpoints check outside of the lock also improves concurrency?
-
sech1
yes, because the lock is not held during update_checkpoints() slow call
-
selsta
sech1: yes, we have to do another release super soon
-
selsta
an initialized variable in the wallet code that the compiler didn't complain about causes a large gui bug somewhere else :/
-
hyc
cool, building both patches on top ov v0.18.1.1 now on my rockpro64, will give it a whirl
-
selsta
uninitialized*
-
selsta
.merges
-
xmr-pr
8420
-
selsta
.merge+ 8582 8579 8577 8576 8574 8585 8586 8329
-
xmr-pr
Added
-
duggavo[m]
Bitcoin Customer Support looks like a scammer
-
sgp[m]
Does `check_tx_key` only work for transactions already in the blockchain or mempool? Suppose I sign a transaction on one device, send it to another, and want to confirm that the transaction is going to the correct address before broadcasting
-
sgp[m]
I suppose it would need to at least be in the local mempool with do not relay
-
duggavo[m]
Why do I keep having this error when trying to cross-compile Monero for both 64-bit and 32-bit Windows with make deps? I've tried with ubuntu 18 and ubuntu 22, and the issue persists with both the operating systems.
-
duggavo[m]
-
hyc
maybe your cross compiler is too old?
-
hyc
would be simpler to just use gitian
-
SerHack
duggavo[m]: have you seen this?
zeromq/libzmq #3859
-
duggavo[m]
SerHack: Yes, I've tried with
-
duggavo[m]
`CFLAGS=-lpthread && CXXFLAGS=-lpthread && LDFLAGS=-lpthread && make depends target=x86_64-w64-mingw32`
-
duggavo[m]
but the issue persists
-
hyc
adding a couple libraries isn't going to fix a compile error
-
duggavo[m]
hyc: Sorry,
github.com/monero-project/monero/tree/master/contrib/gitian does not explain how to cross-compile monero with gitian : (
-
hyc
windows builds are already part of the gitian build process
-
hyc
a default gitian invocation builds everything - linux, android, windows, freebsd, macosx
-
hyc
you can select to only build for windows if you want to skip the others
-
duggavo[m]
hyc: Really? This is why it was so slow! Last time I had tried, it was taking a lot and it wasn't showing compilation logs so after 2 hours i closed it because i thought it was stuck
-
duggavo[m]
Does gitian building cache stuff for re-building?
-
hyc
yeah, I doubt it would get stuck. it's a completely controlled build env, always succeeds.
-
duggavo[m]
* Does gitian building cache stuff for faster re-compiling?
-
hyc
yes, it caches for future builds.
-
duggavo[m]
hyc: It caches with docker too or just with "manual gitian building" ?
-
hyc
also with docker
-
duggavo[m]
Ok thanks
-
hyc
but if you use the dockrun script, the cache lives inside the"gitrun" docker image
-
hyc
if you invoke gitian directly, the cache is on your host
-
hyc
personally I recommend using the dockrun script. again, a more controlled runtime environment.
-
duggavo[m]
Any idea why the dockrun script gives this error?
paste.debian.net/1254691
-
selsta
duggavo[m]: how much ram do you have?
-
selsta
4 parallel builds with 2gb ram limit sounds wrong
-
selsta
you need 10gb ram for that
-
one-horse-wagon[
duggavo i closed it because i thought it was stuck
-
one-horse-wagon[
If you open a second terminal screen and use the "Top" command, you can see the cpu's "cooking" away in the usage category when it looks like nothing is going on.
-
one-horse-wagon[
selsta: On a Debian Linux laptop I have, it is rated for a maximum of 16gb of ram. I loaded it up with 32gb and it works just fine. Others reported on the web they got the same results which is why I tried it. It's useful for very intensive operations like gitian builds.