Here are some site that I've found helpful: monerodocs.org localmonero.co/knowledge monerooutreach.org

Also monero.stackexchange.com and reddit (in additional to the official site ofcourse).

Fork 2: Electric Boogaloo

Greetings, earthlings.

I wish to use both the Tor and the i2p-zero for a Monero node. Is this a good idea? I'd run it under Whonix so I2P can peer over Tor.

it's possible. however i don't see a rationale behind running i2p over tor, except wasting tor bandwidth

Any special 'trick' to get the daemon to hurry up and sync past block 2210720, or is it just a matter of waiting it out?

<rbrunner7> Blockchains are very un-funny, they don't offer such tricks ...

hehehe

Well... I thought maybe I could force it to connect to a safe, known peer or something that might help.

I'm being disconnected at block 2210720 despite running 0.17.1.0

Isn't this pretty bad? Is it happening to anyone else?

It's the v14 activation height

Height: 2210861/2210861 (100.0%) on mainnet, not mining, net hash 1.48 GH/s, v14, 8(out)+0(in) connections, uptime 3d 18h 41m 47s

on my v0.17.1.0 node right now

try cleaning your peer list

happening to me too ajsodasd

I removed ~/.bitmonero/p2pstate.bin. I'm checking again

sech1, just ban peers until you get some that are good?

seems all my peers are on 719 or 720

why would I ban peers if me node is good?

all my peers are at block 719 or 720

so I can't get past this height either

my peers: paste.debian.net/hidden/708df234

try them

how do I add a preferred peer?

some command line option, let me check

I am affected as well

--add-peer Manually add node to local peer list.

ah for startup

--add-priority-node ip:port

mkay

--add-priority-node=ip:port

you might need to change port number to 18081 in my list

this was just connections dump

or no, port 18080

I don't remember anything

sech1, can you type sync_info into your daemon and give me someone who is past block 720

thanks

seems --add-priority-node is not helping much

try --add-exclusive-node

I've restarted my node with 25in/25out peers limit

maybe it'll help someone

also enabled port 18080 for incoming connections finally :D

This node is in Hetzner DC with 1 Gbit connection

hey peeps, can you guys be pals and check out my node list website? monero.fail add some nodes if you know of any

well, out of 26 connected peers almost all are synced fine at block 2210884

I just saw that I have the same problem syncing beyond 2210720 with a monerod compiled from master yesterday

All of mine show 2210720. Even the ones in your paste that are past

It sees many other daemons that tell it the correct height, but it seems it does not like their blocks?

do you run official binaries?

master had a number of commits since the release, so maybe one of them broke something

Latest master, compiled myself on Linux

compile release-v0.17, not master

I see quite a bit of difference in commits between them

I run monero-linux-x64-v0.17.1.0.tar.bz2

Yeah, no doubt that this will run. Still strange that master does not seem to be able to sync. I see nothing useful at first glance with set_log 1

The only "Error" lines (in red) are: Setting timer on a shut down object ...

"monerod is now disconnected from the network" when I connect to peers at 2210888

I might be wrong but i don't think master should be used untill it gets the commits from the branch

Would it be fine to try out monero-linux-x64-v0.17.0.1.tar.bz2?

*17.1.0 that is the current version yes

I run 0.17.1.0, it should be preferred

I wanted to try in case that version can actually sync

any 0.17 version should sync

I am running the gui version and not able to sync

Height: 2210720/2210720 (100.0%) on mainnet, not mining, net hash 1.47 GH/s, v14 (forking now), 8(out)+18(in) connections, uptime 0d 0h 3m 24s

version

0.17.1.0-release

There were some sync problems in precedent versions of the GUI that should be resolved with 0.17.1 afaik.

Oh you are using that one already

yeah

0.17.1.0-release and I cannot sync

Someone posted this issue to Reddit too it seems

even added a bunch of priority nodes that supposedly show they are synced past 720 but my node ignores it or something

same

Selsta xiphon any idea? ^

I added nodes from sech1

tried --db-salvage too but it did not do anything

now when I do sync_info these nodes show up to 720

Mochi101 try to clean your peers again, stop monerod, pop a few blocks and start syncing again

try supportxmr node as an exclusive node

maybe to fix this try to pob blocks before the v13 fork and then start with "--add-exclusive-node" just until you are synced past 720..

or better pop 1000 blocks to be sure

Mochi101 was your node running through the both fork heights? My node didn't restart since October 15th

nah... this is just my local node... I turn it on only when I need it

my other one was fine

I somehow doubt that it's bad peers. I went up to "out_peers 50" but still no luck.

bitinfocharts.com is also stuck on the old chain^^ crazy though there are 2200+ tx in the last 24h and moer than 300blocks

hmm seems good so far with pop-bloocks 1000

Try the same. Of course it syncs the V12 blocks now, but let's wait

spedex Did it sync past 2210720?

miningpoolstats.stream/monero is also stuck, it shows difficulty 232.04G which is outdated

but on the other hand, it shows that all pools are doing fine

not quite there yet :) maybe 1000 was a bit excessive

but let's see

I don't see many problematic peers

no stuck again: Height: 2210720/2210720 (100.0%) on mainnet, not mining, net hash 1.47 GH/s, v14 (forking now), 7(out)+19(in) connections, uptime 0d 0h 4m 24s

No luck with my master-compiled daemon after dropping 1000.

trying to sync after popping 1000 blocks and with preferred nodes

er...priority-nodes

takes a bit... will let you know

I am really curious whether using known-good priority nodes will work. Somehow I doubt it. My daemon sees many other peers with the correct current height and still does not seem to want blocks from them.

Yes, it just says "monerod is now disconnected from the network" when I connect to peers at correct height

I tried to pop 1000 blocks, use the supportxmr node as an exclusive and it's the same

Alright, I compiled 0.17.1.0 in the meantime. Same problem.

That can't be good ...

nope

strange I have one node that is good... and my local node is bad

and both run official binaries?

yes

then it's something local

but the good one is linux and my local is windows

the good one was running the whole time though

so what if you stop the good one, pop 1000 blocks and start again?

nfw

Well, maybe, for whatever reason, it's not possible *anymore* to sync past that block. No conspiracy theories, I know, but what if somebody manages to disturb the network enough now?

That is part of my critical infrastructure.

I can try it with my node :shrug:

what was the command to pop blocks?

ok..popped 1000 blocks...added like 6 priority nodes and resynced... still can't get past block 720

./monero-blockchain-import --pop-blocks 1000

1k is too much

do 100

or wait forever

:D

No, 100 won't get you back to V12 blocks ...?

ok

1k then

Who was writing yesterday that Monero forks are oh so boring, nothing bad ever happens with them :)

ummm

dunno

:D

Maybe it helps to whisper "moneromooo" 3 times?

all right, syncing again

Height: 2209905/2210905 (99.9%) on mainnet, not mining, net hash 1.87 GH/s, v12, 17(out)+0(in) connections, uptime 0d 0h 0m 28s

damn, this is slow

I'm on HDD by the way

Big blocks now

To add suspense? :)

Also syncing from scratch on my Windows PC, but that one is R7 3700X + 32 GB RAM + Samsung 970 Pro NVMe SSD

fuck windows, use linux!

fuck Quotes

Definitely.

2210305, place your bets...

bad news

all my peers are 2210720 or below

good news, not all

2210645...

i have count load of peers all on 2210908

aaaannnddd... I'm stuck at 2210720

#metoo

fuck you all

calm down

We're not in pools.

3hehe

hehe

now I'm curious. updating my local toynode

what if this chain (past 720) is not the real chain at all?

"real chain"

:D

or maybe it's just syncing code that's broken

put ya back in chains

so better not restart working nodes

until moneromooo fixes it

910

blocks coming okey,

I even add M5M400's node as an exclusive node... doesn't do anything

ok, now my node banned everyone who's past 2210720

2020-10-18 09:53:13.920 I Synced 2175013/2210910 (98%, 35897 left)

M5M400 it'll get stuck at 2210720

ok let me sync again for test

popped some blocks on linux trying to reproduce

for all we know, restarting node might get it stuck at block 2210720 and probably further blocks if they have the problematic data in them

I think I found the problem: xmrchain.net/tx/c5151944f0583097ba0…7fabb3881278aa2f73b3b0a007c5d34e910

this tx shouldn't be there

maybe running daemon allowed it, but syncing code rejects it

rbrunner can you recompile the code, but change 2210720 to 2210721?

why shouldn't it be there?

as a fork height

Mochi101 because it's MLSAG

2210720 and up should be only CLSAG

mlsag tx in clsag only block? :D

seems like it

one more: xmrchain.net/tx/6f2f117cde6fbcf8d4a…c744726574ac38cf25d3322c996b21edd4c

can't sync after 720 too on linux my node was fully synced before and was online the whole time during both forks

yep, my node was fully synced and was running through both fork height

then I popped 1000 blocks and now can't sync past 720

so I put my bet on an off-by-one error somewhere in the code

Alright, can try that alternative fork height in about 1 hour, busy with lunch now ...

that brings an interesting question. The fix will be a consensus change. Granted that we in fact have 2 different fork heights in the code now, it can also be considered just as a fix, not a consensus change.

so we change from 2210720 to 2210721 if someone (rbrunner) confirms 2210721 works for syncing

How come it was fine for some nodes and not others though

Stuck at 2210720 too

Me too!

sech1: How did those transactions managed to get included in a block? A one off?

Mochi101 it was fine for everyone who was online

yes, I suspect an off-by-one error in the code that handles incoming blocks

but syncing code doesn't have this error

so they don't agree and we get this clusterfuck

I see

it wasn't an issue past few forks because old type transactions weren't issued at all after the first fork

but this time, they kept coming in

Tried already. Maybe your intuition about one-off error is correct, but by merely changing the fork height from 2210720 to 2210721 does not seem to help

0.17 should've rejected MLSAG right after 2210000

Stuck at 2210720 too. What can be done?

Presumably due to old wallet software being connected to an updated remote node?

fort1: Wait for a fix to be released I guess

rbrunner are you still stuck at 2210720? Tried connecting to known working nodes as exclusive peers?

my peer list all at 2210720!

so I should avoid restarting pool nodes, right?

yeap

Stuck yes, tried with good nodes no

M5M400 don't restart until moneromooo tells more

Right now it's just my speculation on what's happening under the hood

but MLSAG transactions in block 2210720 is certainly not ok

oki, thanks @dEBRUYNE

jonathancross: Those messages aren't getting through properly

They are displayed as links

@dEBRUYNE, should I keep the node running, or it does not make sens?

If it is stuck, I guess it doesn't make much sense to keep it running

oki

my 2 nodes are still fine, were running thru the fork

was also mining

few hundred H/s

What if ... moneromooo is on vacation for 1 month on some island in Townforge? :)

M5M400, when I connect to node.supportxmr.com as an exclusive node it doesn't seem to connect

hyc, you have an open node?

dEBRUYNE: just saying my linux node is syncing fine with release binaries.

(Hopefully you can see this?)

set loglevel to 1

Going offline now

Mochi101: yes, 173.255.205.142

jonathancross: Did you keep it running or?

hyc, 18081 ?

we need to confirm if changing 2210720 to 2210721 in hardfork.cpp helps

Mochi101: if you're doing --add-exclusive-node, you should use the p2p port (18080)

It'll take 6-10 hours for me to check... Syncing from scratch here

that's probably why node.supportxmr.com didn't work for you

ok

sech1: That should also work by using a synced chain and popping blocks, no?

Also, rbrunner reported this:

<rbrunner> Tried already. Maybe your intuition about one-off error is correct, but by merely changing the fork height from 2210720 to 2210721 does not seem to help

<dEBRUYNE> I had a working node, then I popped blocks and it's not working now

2020-10-18 10:30:22.108 E Ringct type 4 is not allowed from v14

2020-10-18 10:30:22.109 I Transaction with id= <6f2f117cde6fbcf8d4a6ef8974fcac744726574ac38cf25d3322c996b21edd4c> has at least one invalid output

2020-10-18 10:30:22.109 E Transaction verification failed: <6f2f117cde6fbcf8d4a6ef8974fcac744726574ac38cf25d3322c996b21edd4c>

2020-10-18 10:30:22.109 I transaction with hash c5151944f0583097ba0c88cd0f43e7fabb3881278aa2f73b3b0a007c5d34e910 not found in db

ok... so sech1 is correct it seems

yep, these 2 transactions in block 2210720

I popped 100 blocks, set log level to 1 and used a known good node as an exclusive

I had already some syncing problems with v0.16.0.3 about 1 week before the fork. Earlier it worked perfectly.

M5M400, are your blockchains pruned?

nope

pruning is for plebs

My working one is pruned.

:P

syncing so sloooow

Mine is not pruned

my public node is now pruned, because I ran out of disk space

and couldn't justify bumping up to the next size up Linode

Why if I pop 10 blocks and use a known good node as an exclusive does it still not sync though?

because there is a bug.

wasn't there a way to skip verifications for trusted sources?

or was that just for importing the .raw?

Email me your blockchain please M5M400

just for importing .raw

but that's a good idea M5M400

we can do an export of 2 blocks

and post that .raw file so people can import and get past the error

is it possible?

I'll try that now

didn't know partly exporting is possible

yes of course it is

well, great :)

obvs

:P

;)

Why 2 blocks, is 1 block not enough?

sech1: just in case.

but unfortunately, while export has a --block-stop option, it has no --block-start option. crazy.

I don't see any MLSAG transaction after 2210720

looks like I can only do an export starting from block 0

feature request time!

hyc just hack monero-blockchain-import to add block 2210720 unconditionally

Instead of shipping a db file, wouldn't it be possible to just write a script to send stuck nodes the block as if it's live?

*I understand it's not exactly that simple. My guess is you'd also need to do transmit the TXs so they enter the mempool (my first, uneducated guess, at why this split happened)

imagine if you could just slip a block into the chain at will

But if you lie to one stuck node saying it's new, wouldn't it rebroadcast it to any others it knows as well? Gets the current stuck nodes going again/provides a script to run to fix the problem?

oh! Here's one that give me 100000 XMR!

thinking so small, Mochi101

kayabaNerve: it would need to skip the verification

I think the fix basically needs to make those two transactions seen as valid

asymptotically: Not if we replicate the original conditions?

And use the MLSAG verification rules

Live nodes didn't fail.

I'm asking if it's possible to ejust tell the stuck nodes it is live.

dEBRUYNE that fix is better than changing fork height, but we also need to find the actual bug and fix it

Send the TXs so they enter the mempool, as if they're pending, and then sync the block.

So it fixes the current network before needing to ship out a new release for anyone syncing in the future

Mochi101 going by your debug output from before it should be enough to add a rule in cryptonote_core/blockchain.cpp:3070 to allow that transaction hash.

*And means existing nodes don't HAVE to upgrade so quickly/articially edit their DB files

unfortunately the .raw file format doesn't include block number in each block

so -import just counts all blocks in the file, to assign block number to each record

hacky.

wow

hyc rewrite monero-blockchain-import to import single block?

so the only way to import block number X is to have (X-1) records in front of it

Couldn't you use the last hash from the header?

*Still breaks compatibility. Just less so then a new format

Thought it sounds like a new method is being discussed...

hmm, I have one more thought. What if someone tries to use these 2 MLSAG transactions as decoys? Won't it break something again?

MLSAG outputs are still allowed as decoys no?

It's not like the non-RCT -> RCT change where you basically have two pools of outputs

^ This transaction also uses MLSAG outputs as decoys -> xmrchain.net/tx/e610bfb45f2ca4c57d8…eb1d275c49b9e0c5770f86e603d7865f0da

yes, they should be allowed anyway

Guess we'll see v0.17.2.0 soon lol

when it rains, it pours.

ok, this isn't so horrible. the raw file header format has fields for block start. it's just that export inits them to 0 and import ignores them

but we can add support for them without having to change the raw file format

right in the feels.

lol

can I be the one pretending to be his brother claiming that it never happened?

for sure

That'll give it some real depth.

is moneromooo in US somewhere? Still sleeping?

mooon

They are usually online at current daytime

hi, I'm here now

2210720 has 2 MLSAG tx

welcome to the party moneromooo

nodes can't sync

That seems... annoying.

A little.

but nodes that were online are at 2210950 now

so network kind of keeps working

just outdated nodes can't sync

my guess is an off-by-one error that allowed MLSAG in 2210720

moneromooo, if you want some relevant log: pastebin.com/LZ4Z9bSq

It's using a known good exclusive node

dEBRUYNE: care for some visible PSA on /r/monero if not there yet already?

adding an exception for these two transactions would allow nodes to sync. Or changing v14 height to 2210721. But I'm more worried about where this off-by-one error is hiding.

Happy Sunday everybody.

i am not a fan of adding an exception for 2txs betther then off by 1

changing v14 height is a more clean "fix" for sure

I just can't test if it really works, still syncing at 16% here

But that fork height fix only starts to work after most daemons put it into service, right?

M5M400: Seems like a good idea, not sure what to put there though?

rbrunner it'll start to work for anyone who's stuck and applies it

and then syncs using known working nodes

Not sure, I did try that. Edit the fork height, compile, try, yes?

--add-exclusive-node ???

and clear p2pstate.bin before that too

No. You mean I can't rely on nodes that tell me the correct current height to be "working"?

Because I have plenty of those.

rbrunner: Did you check if you were connected to a node that is actually past the 'stuck' height

just changing hardforks.cpp won't do the trick (at least for me)

if they tell you correct height above 720, you should be able to sync

Yes, that's what I mean. I had several nodes announcing the correct current height to my daemon, which did not budge.

we need to send out a message on monero-announce list soonish IMO. If we don't come up with specific plan within an hour or so, I'll just send a general warning

ah I think I know why

Version in block info?

because they already tell that 2210720 is v14

yep.

so these 2 tx must be added to the code as exceptions

binaryFate: ++

sech1: yep thats the same log output i had

Apparently monero php library isn't working anymore after new changes. Most wallet RPC functions accepting arrays are failing. An example:

Request have return error: Parse error. Request: {"jsonrpc":"2.0","method":"make_multisig","params":{"multisig_info":[null,null],"threshold":2,"password":"mypassword"},"id":0};

you got asked this a lot already I'm guessing. I'm running several nodes, one of them got stuck at the second fork block 2210720.

I need to wait for a patch?

yes, it requires a patch to sync after 2210720

but a different node synced just fine

yes, depends if it was running during fork and had 2 specifics tx in its mempool at that time

nodes that were online did fine, nodes that were offline can't sync now

none were offline though, just saying

aubergine: Are you already on the latest release 0.17.1.0. I am not sure, but I think there was a fix for that RPC problem.

paste.debian.net/hidden/80c30661 fixes it

btw is there some open source tool for making a pool ?

QUESTION: Problems Syncing my monerod v017.1.0 , stuck at block 2210720, new top block candidates get added. assumption: is this problem on my side ?.

No, new version will be out soon.

k, thnks..

If you know how to compile yourself you can fix it now

k, Network still OK, just client problem right ?

Network still okay, just new nodes can’t join it

(without applying this patch)

@Freneticks I think this might be outdated (github.com/Snipa22/nodejs-pool) but MoneroOcean maintains a fork at (github.com/MoneroOcean/nodejs-pool). There's probably other forks floating around, Idk, but I think most pools are using some version of this nodejs-pool

k, thnks, have a nice Sunday ...

MoneroArbo: nice thx !

@rbrunner yes no new updates yet

So I'm curious how this fork issue came about -- a bug or some more fundamental issue?

See the commit message.

Thank you. I don;t understand why the invalid block was accepted by other nodes, though

I guess I'm wondering if it's a bug that can be avoided next time or if it's some sort of inherent risk

Read the commit message, it says why.

moneromoo is this what you're saying I should be reading? monero-project/monero #6906/commits/1120df3c53bac08c0891cd034f529a345d8a12f3

Because I did and I don't feel it answered my question. Maybe I'm reading the wrong thing, or am just dumb

Yes.

"Miners with MLSAG txes which they'd already verified included

a couple in that block, but the consensus rules had changed

in the meantime, so that block is technically invalid and any

node which did not already have those two txes in their txpool

could not sync"

Maybe I misunderstood your question.

Yes, I saw that. But it says the block is technically invalid so I'm asking why it was accepted as valid

it says right there

I understand how it was produced but it seems like it should have been rejected by the network

" which did not already have those two txes in their txpool" Concentrate on this bit.

Because the those nodes already had verified that tx.

(with old rules)

I probably don't understand on a low enough level how the mempool works.It seems like you validate transactions when you get them, then when you get a block you just check to see if the TXs are in your mempool, and if they are it's valid?

based on what I'm hearing rn

why wouldn't you check TXs for validity when they're mined instead of when they're broadcast? or check twice

TXs were verified when they were added to the mempool

so all nodes just accepted new block and skipped verification of these TXs

cool, so, that seems like something that can be corrected going forward?

the proper fix would be to reset "verified" flags on these TXs in the mempool once fork height is hit

and nodes would verify them again with new rules once the block is mined

I'm not sure if mempool even has "verified" flag for transactions or just verifies them once and then assumes they're ok always

I agree sech1 that sounds reasonable. And I think answers my question as well so ty.

Hello all. My node got stuk (like everyone elses), i read the 'fix' on github but there are no instructions on what to do? It just says what's going on but no way to resolve it?

You have to compile monero yourself or wait until new release binaries are out

Oh, oopsie. So effectively the network has stagnated now?

No, the network runs fine

just new nodes can’t join

or they can if they compile themselves

Number of transactions dropped from 18k to 1.4k. But sure as long as blocks keep getting mined.

Number of transactions?

transactions per day

ah on this website bitinfocharts.com/comparison/monero-transactions.html#3m

The day isn't over yet of course.

don’t think that is related to this issue

You don't? Well people can't use their Monero right?

If they don't have a self-compiled client.

They can use public nodes that are synced up

Yea that's true.

number of transactions on that website is wrong

This site only shows completed day, the low number is for yesterday 17th. I think they did not update in time for the fork and only saw few hours worth of transactions before HF occured

I see @binaryFate

they show 1408 transactions on the top, this is supposed to be the rolling 24h number

But it's definitely more than 7000 in the last 720 blocks now

Nice price on OKEX xD

maybe 1408 is the number on the 0.16 chain, not sure if there is a zombie chain or not. Or just in 0.16 mempool

The fix-release is expected later today?

just before the second fork I used the status command and it showed block 2210719 as v14 already

and it also showed 1 block until fork

2210719 was v13.14

2210720 was v14.14

ok

other blocks between 2210000 and 2210719 displayed v13

closest I have prior to 2210719 is 2210478 and shows v13

FWIW

Hi. I switched my seed to monerujo, and when I tried to transfer my balance to another wallet, it gave me an error saying that I wasnt connected to the daemon. Then after closing the wallet and opening it again, my balance no longer appeared there and no transactions are shown. The seed is the right one since the address is the same.i switched to different wallets and nodes, but still nothing. I need help, please.

I just checked on my daemon 2210719 shows as v13.

** when it said that i wasnt connected to the daemon, and i went back, it didnt let me connect to any node, then i restored the wallet and i found it empty.

I have been hours trying. Since the wallet was created yesterday, I have been trying to even restore the height from two days ago, and nothing. A support agent from a wallet i was trying to restore my seed on, told me it might be due to the latest upgrade, but after trying on so many different wallets, Im starting to get paranoid.

Is it your node or a stranger's node ?

Tried monerujo, cakewallet, monero gui,...

I tried different nodes recomended by the wallet, i dont have my own

ak77: try node.supportxmr.com:18081

it's correctly synced

ak77: also set your restore height to from 1 month ago

I have already, but its not appearing

^that

Alright i will do that now selsta

or when did you first receive monero?

to that wallet?

Been using xmr for two years and its my first time having an issue

better restore from height 0 then :)

if it's an old wallet

selsta: i created the wallet yesterday as i exchanged some btc, so the wallet its fresh from yesterday only

do you have the transaction id?

did the service send you monero on the right chain?

M5M400: i meant from my own experience that i have never had an issue before, the wallet is brand new from yesterday

understood

the TX id from the incoming transaction would help a lot

selsta: will have to check with changenow.io as i switched the coins with them

First i sent to coinomi, and it didnt appear. Then i converted the 24 word seed to a 25 one and switched to monerujo, the balance appeared. Then right upon sending the xmr, it gave me an error saying i wasnt connected to the daemon. I closed the wallet to refresh it and then it wasnt connecting to any node at all. Restored the seed and found that there werent transactions and the balance was zero

it is possible that coinomi didn’t update for the hardfork

Gave me multiple errors upon trying to connect to a node. Will try to get the TX and be right back

Yes but when i changed my seed to a 25 word seed and restored the wallet on monerujo, the balance was there

sure, that is still possible though

as the address would not change

So even if coinomi hasnt updated it yet, the balance should be there

anyway, yes, first I would check the tx id

Yes sure. Thank you so much. One sec

Yep just check the transaction ids on a xmrchain or something

Also if it gave you the error that you were not connected to any daemon then the transaction was probably never broadcasted

nssy: it gave me the error upong trying to send it to another wallet. But why did the balance "disappear" then? Ill get the tx and send it here. I appreciate it.

Upon*

The balance and all the transactions**

Ok.

what's mean this error on monero-gui (testnet) : "Failed. Reason: double spend, invalid input"

Freneticks: which version are you using?

Go to Settings -> Wallet and press on "rescan"

selsta: latest 0.17.1

selsta: oh yeah it's working now thanks

you need to rescan outputs, I had the same issue

was a bug in v0.17.0.1

but fixed now

weird because i'm on 17.1

did you use v0.17.0.1 before?

selsta: nope I synced the blockchain today

(testnet)

not sure then

oh maybe addr destination (rpc wallet) was old

Still queuing to talk to a changenow support agent, will be back as soon as they answer

Think monero transactions are disabled on changenow by the way

Were disabled for a long time yeterday but eventually were available for a while and i was able to do the transaction.

what's the status with zmq is it usable ? Is there any doc ?

Freneticks: ZMQ.md

Hi again, finally they replied

4e5488e33e5eadfe845a6f30c14b6a7f5de263fda678275eb07c6bf59fe1f1bb thats the tx id

06ad34d7158dd7 (Transaction ID)

ak77: ok looks good

What do you mean

selsta: what should I do

set node.xmr.to 18081 or node.supportxmr.com 18081 as remote node

and then restore again

make sure to set your wallet creation height to 2020-09-01

monerod update today?

selsta: ok will do now

@selsta Do you have the xmr.to stagenet P2P onion address? Not the RPC which are on the website.

Hey there

selsta: i got it!!! :D

Or another stagenet P2P ;-)

Thank you everyone for your assistance. 👍

selsta: appreciate your help, it worked.

ak77: nice

boldsuck: onion stagenet?

no

Why is it that i needed to restore from a height way older than my wallet? selsta

I don’t know, maybe you mistyped the restore height?

I mean, i created the wallet yesterday and i was restoring from Oct 16th to be sure. I wasnt doing it wrong. You said to restore from september, interesting

That was just as a safety margin, is not necessary usually.

selsta: OK, thanks

Maybe there were issues with node.

selsta: thank you so much again. Love monero🍀

regarding the current issue with stuck sync, I don't think it's a good idea to keep saying it affected nodes that were offline during the two forks. I mentioned before, I had nodes that were all online and 1 got affected. Particularly because tx propagation was quite slow it could have affected any online nodes. The PR that fixes it says the proper

wording and maybe it's better to stick to that wording

agreed

Current ? It's not fixed ?

is there a new release?

no exchange is going to re-open before that plus some extra time

And yes, pedantically, if you were online and did not receive the tx, you'd be stuck, but you can always find spceial cases with everything, so...

it's not really pedant in this situation. Tx propagation is very slow lately

It's obvious to people if they're stuck.

you'd be surprised

exchanges will be receiving tickets months from now related to now being able to receive coins

related to not*

miningpoolstats.stream/monero and bitinfocharts.com/comparison/monero-transactions.html are both stuck

and I think they are both online 24/7

first one shows "Difficulty : 232.04 G", seconds one can't count transactions anymore

None of my 4 nodes were stuck

strangely, one of my two nodes kept stopping syncing in the hours before v13

I had to restart it at least 3 times

default 8 peers?

yeah

are there binaries out?

in a couple hours

haven't seen any yet. my build is nearly done

sweet

windows is compiling now, mac will be after that

Can't wait to spend some sweet moneroj

oh man... I think Mac users should have to wait.

at least a week

press <ctl><alt><del> if you disagree

lol

must be coincidence hey?

minko node was online and got stuck

any good public nodes to recommend?

node.xmr.to

node.supportxmr.com

Hello. Just wanted to get latest gui wallet, but sha256hash doesn't match the binary. Can anyone please check?

Was linux 64 bit wallet

Should be : b7b573ff3d2013527fce47643a6738eaf55f10894fa5b2cb364ba5cd937af92e

is : shasum -a 256 monero-gui-linux-x64-v0.17.1.0.tar.bz2

9076b731634e073430817cd590ea015a19a9cf3336c3c7a7bb16f1fd25b429f4 monero-gui-linux-x64-v0.17.1.0.tar.bz2

Try sha256sum directly

Same result

bluudz: you are looking at cli hashes

GUI hashes are underneath

Ah!

It is the unpleasant that what was supposed to be a joyous occasion has been filled with strife.

Has anything like this happened before?

Would it have been theoretically possible to completely lose transactions in blocks, if there were not many people who were able to sync.

There re no other hashe savailable, this is under the section to verify the download

Ah got it!

Its correct.

Hello again. I send transaction from my wallet (latest). 1hour later its still waiting for confirmation and block explorer is not showing the txid. Was the update quite recent and services don't support it yet, or what can be causing the issues?

What’s the block height your node is reporting? Are you using a local or remote node?

You’re likely being affected by this bug (or your remote node is):

2211328

Ah nvm then.

Its the remode node I'm connected through

Hmm yeah the TX must have never gotten propagated.

Can you try a different node and restart the wallet?

Which node did you use?

I don't see there is option to fill in the node by myself anymore. It just connects to random public node by the look of things.

I will try to switch and restart

No change. Strange is that I sent two transactions. One from my other account, that one went well and other from my main, which is stuck in pending and txid not recognized by any explorer

Can I rebroadcast from the gui wallet?

Or can it be that the other wallet I'm sending to haven't upgrade yet?

But that would certainly not stop the network from confirming

bluudz: Which wallet software are you using? The GUI?

Yes, latest gui

bluudz: You can simply try resending.

Make sure the blockheight in the bottom left corner is the same as on xmrchain.net

if not, wait a bit or click on the two arrow symbol to find a new node

Yes it is correct

Actually 1 block ahead

If I try resending and this transaction will propagate later I will send it twice.

It will not propagate again, it is a failed transaction. We will release v0.17.1.1 tomorrow that will correctly label them as "failed"

Ah ok

I will try to send again then

I tried sending 20+ times and it never failed for me :/ But some report it.

Not sure yet what the issue is but retrying usually solves it.

I sent again, just waiting whether it confirms

can take between couple seconds and 5 minutes to show up on xmrchain

due to dandelion

hopefully everyone will be forced to update to 0.17.1.1 which works better with dandelion than 0.17.0.x

there still are these troll nodes that drop transactions :/

12 minutes and no difference, txid not propagated

Did restart of the wallet so waiting for sync with remote node

But chain dont see that txid

hmmmm

Do you know how to manually set a remote node?

There used to be option in the gui to set up one, but I don't see it anymore.

But why would the first transaction go through?

That was just between my accounts in the gui tho

This one is to send out

Can you click on the door icon in the top left corner, then click on "Change wallet mode" and select advanced mode

then you can specify a remote node inside settings

Ok got it

Any specific I should set up?

node.xmr.to 18081

node.supportxmr.com 18081

it will take a bit to check the blocks again

How big is the chain if I would want to get full node at the moment?

30gb pruned

But the gui wont be getting pruned version will it?

not sure if I understand

pruned version also works with GUI

But if I choose to have local chain it will get pruned version by default?

no

but you only have to enter "prune_blockchain" on Settings -> Log once

and it will be pruned for all time

Ok thats good to know

Thanks

anyway, look out for v0.17.1.1 tomorrow

or use v0.17.1.1 CLI daemon to sync up initially

Well I will wait for this remote node and hope to be able to send the transaction today still

ok, do you know why it scans wallet blocks again?

usually just changing node should not cause that

A troll node can cause a rescan from scratch.

we added a bit protection to that in v0.17.1.0

Yes. Changing options to advanced didn't give me option to go back to my previous wallet so I just restored it from the seed again

That sounds weird.

Did you select "portable" mode?

Oh yes, I remember xiphon added a setting, you're right :)

No I don't know what is portable mode.

Is your wallet stored in default ~/monero/wallets ?

Yes I think do. I didn't changed the default path

But this is linux version

And on recent wallets screen nothing showed up?

No when I clikced the door I get back to options to create new wallet and such, let me double check

I meant door -> "Change wallet mode" -> Advanced mode -> Open wallet -> Open your previous wallet

Ah yes its there..

ok :) no new bug then

is the fluffypony talk for hcpp20 up yet?

Is there a way to reattach an instance of monerod to a terminal for realtime output of the status? I can query it every time with monerod status, and the command monerod itself just tries to start a new instance and fails.

have you considered using tmux or screen?

I have it started by a systemd service.

you should be able to detach and reattach whenever you want to check it

oh

TamaraneanGirl[m: tail -f ~/.bitmonero/bitmonero.log

does that work?

I need to grab 0.17.1.1 quickly, I can see the errors

But I guess I forgot tail could do that

I want to make a system tray icon too, so knowing that file might be helpful

does monero have a flag for the equivalent to blocksonly from bitcoin?

I don’t know what blockonly is.

it only downloads confirmed blocks. it doesn't download or relay unconfirmed transactions.

it saves massively on bandwidth

I don’t think monero has that, but you can limit bandwidth in general.

Surely most of those txes wlil end up in blcks soon, and will need downloading anyway a bit later, no ?

Not resending would save some, but it's really assholish to the rest of the network.

Maybe I'm misunderstanding what it does...

yeah maybe. i'm not exactly sure other than the fact that it supposedly reduces bandwidth on bitcoin by up to 80 percent

it could be that it doesn't relay blocks as well...

I could see that for upload.

Anyway, we don't have that.

I'm surprised bitcoin would have that, it centralizes massive AFAICT. You end up getting your txes from a few nodes only if most people start using this.

Again, assuming Im not misunderstanding what it does.

yeah i'm under the impression that it's not being a good network citizen

Should I build against master branch if I want to modify the Monero software?

If you want to merge upstream, yes.

If not, probably.