thanks ill try that

what autodetector?

hyc, if you run 'start_mining xmr_ADDRESS auto' in the daemon, it will cycle through a number of threads until it finds the optimal # to get the highest hashrate

optimal # of threads

I got a quick question about one of the unit tests for bulletproofs

the "invalid_gamma_0" test seems to also use an invalid amount (from the previous test). why? what are we testing?

gingeropolous: ah cool. a bit futile in the daemon though, since "optimal" will be impacted by other daemon activity

every other node and wallet interaction will consume CPU+memory, you really can't expect anything like optimal mining efficiency in an active daemon

hello

we’re considering making an auto-output-splitter in cake wallet - is there any danger to using transactions larger than 1in/2out?

we want to avoid an “early 2018 xwallet” situation where certain transactions stick out, but also don’t want to clog the blockchain with churn transactions

skrech: No default location for CLI config file. I write small shell scripts and batchfiles for such cases to avoid too much typing

Ups, wrong channel

Could somebody give me a screenshot of the CLI making a stagenet/testnet transaction? From transfer... to the message of success.

I tried to do it myself. I made the testnet transaction from the faucet and i mined it , but now i have to wait 58 blocks to unlock the balance and seems like i'm the only one transacting on stagenet atm

ErCiccione[m]: Like so?

rbrunner: yes, something like that, but with included the messages you get when you open the CLI

Is this for some kind of manual then?

it's for the download page of getmonero

this is what i made, but it's ugly AF:

would be cool to have something like that, but with a transfer at the bottom

Hmmm, if it's *that* public maybe put some effort into it ...

Also a simple paste would not be nice because not preserving color

? That is something i just made to show what i would like to have.

it shouldn't be a paste, but a screenshot

Yeah, that's what I mean

And I meant *me* to put some effort into it ...

ah ok. I misunderstood :)

moneromooo gingeropolous xmrchain.net is stuck and can't sync, this is how it's seen from other nodes: pastebin.com/raw/0dZikAZF

How about this: i.imgur.com/aeSdsaZ.png

2019-12-01 10:51:55.563 [P2P3] ERROR verify src/cryptonote_core/blockchain.cpp:1849 Block recognized as orphaned and rejected, id = <8f3ca1541334c185029047fc57d710fea4f7c9ba6da3c4512c05ff66246656b1>, height 1979078, parent in alt 0, parent in main 0 (parent <0d9fbbfb4db65c4b8978ce007b3ef5f34cfc28b288d795378902874536e4d1b4>, current top <25ee250bb678088722562c1fdf6f0014e62f8ae891b741769620f1ef7f666e61>, chain height 1979077)

Is the main issue it appears.

That's perfect. Thanks a lot rbrunner

The only detail that is not correct is the exact version number of the daemon, it's not proper release ...

There's a number of nodes with the same error.

rbrunner: not a big deal. IMO the point is to show how the cli and a transaction look like

Ok then. Glad to be of help.

jsut one detail rbrunner. Could you take another screenshot, but square this time? This one is rectangular and i would have to manipulate it a bit to show properly.

To clarfy: The GUI screenshot is 888x878. Your CLI screenshot is 1018x630

Looks like: pastebin.com/raw/9T0SyymW is the source of the auctual issue.

Daemon version: 0.15.0.1-6def88ad4

The remote listed as IP:PORT has blocks available out to 1979169, so it's clearly validated in their daemon, but the daemon on xmrchain isn't accepting it.

ErCiccione[m]: Ok will do. Perhaps in half an hour or so

may need to resync. would be nice to know how long ago it went bad

block 77

Well, 1979077 is the dead block.

rbrunner: thanks!

Popping off 500+ blocks hasn't helped so far.

Also, there's almost 2 dozen nodes effected already by whatever the heck this is.

Same block on blox. using the same monero version according to the reporter: blox.minexmr.com/search?value=0d9fb…5f34cfc28b288d795378902874536e4d1b4

hm.not 15.0.1-release?

Apparently not.

the commit ID is the same as the 15.0.1 tag though

so I can't imagine it's missing any fixes

Unlikely would be my suspicion in that case. It was clearly compiled, I've found the traces from Ginger's build script.

Theres 22 nodes effected at the moment based on the logs I'm seeing.

MDB_BAD_TXN is a runtime / memory error, shouldn't persist after a restart

That's the 7th restart so far.

but it means there was an earlier error that monerod didn't respond to

i.e., there was an earlier error and monerod ought ot have aborted the TXN at that point but kept on using the DB txn instead

xmrchain.net runs 0.15.0.1-6def88ad4, so not a release binary

Wellp, I'll start packaging an export from a known-good node.

maybe something borked during compilation and broke now

Interesting. There's a segfault during block popping.

but 6def88ad4 is the same as the v0.15.0.1 tag, so any difference from -release must be in its dependencies and not monero code itself

Block ID: 1973151 causes the pop-blocks to brick on that version.

can you let me get a copy of the DB to examine?

Yeah, I'll export it here in a sec.

blockchain-export may crash too if it's actually corrupted

Well, once I find somewhere to stick it.

Yeah, I'm just going to gzip the lmdb file

ok

ErCiccione[m]: Square, 882x882

Awesome. Thanks again rbrunner

You are welcome :)

Testnet without a new block since 2.5 hours. 10 blocks in the last 10 hours. Looks to me that somebody drove up difficulty (or held it up) and then left, about 16 hours ago.

I mean, people were on testnet testing miners, then the fork happened.

yeah, why waste power on testnet coins after you test successfully and mainnet switched

Snipa: "set_log 1", flush_cache bad-txs", then paste the resulting errors on verification.

I know the sxmr testnet pool had 300+kh/s pre-fork.

it's just everyone used testnet for testing (what a surprise), so it's stuck at 1+ MH/s now

moneromooo - I'll hand it off to ginger with those notes, it's 4 AM here, and I'm already up way too late.

Makes sense. Not nice anyway. Will take a while until becoming usable again

Just throw a couple miners on there and let em chug, not much worse than a normal network fork.

Yeah, my old notebook with 1/1000th of that 1 MH/s :) That will show it.

No real problem of course.

Make that 1/10,000 ...

no problem, diff will adjust in about 10 years :P

tevador: As a side note, do you have a current estimated hashrate for mainnet?

I think sech1 has a script to estimate it, I'd say 800 MH/s

Guess it is going to take a few days before more hash joins in

Because at 800 MH/s it should be quite profitable no?

XMR network hashrate 60 : 672.212 MH/s

XMR network hashrate 120: 661.608 MH/s

XMR network hashrate 360: 678.075 MH/s

right now

so it went down a bit

ok, im here. what can i do?

fix xmrchain.net?

it doesn't use official release binaries and got stuck today

well yeah i compiled the tag. it looks like they were trying to debug it

moneromooo, hyc , did Snipa get you everything you need?

No. Said they'd leave you to it :)

"set_log 1", flush_cache bad-txs", then paste the resulting errors on verification.

ok, well what do you need? :) oh

well data.mdb is packed up in a .gz now....

i guess i could unzip it and try and run it.

well, lemme get that file to a server for dload

Builds on some systems do not display -release since commit hash in version was expanded to 9 digits, instead they display the 9 digit hash even though it's a tagged build.

ermagerd this things on a spinny. everythings gonna take forever

ok, the sha256sum monerod bin in /bin/ matches the bin in /monero/build/release/bin . So its possible its on master and not release

this is worse than watching paint dry

what are you watching?

is that data.mdb downloadable yet?

moving this file around .

question - is the whole mdb needed for this kind of debugging? or could one slice it up somehow? this sort of slicing could be useful for debugging in the future when data.mdb is 9 gajillion terrabytes

well, if there are corrupted pages in the file then yes, we need to see the entire file to trace the corruption.

if the file was normal/non-corrupted, then yes, it's possible to use mdb_copy -c to only copy the most recent data.

gotcha

so the file is downloadable, but moneromooo wants me to try and run the daemon on it with flush_cache. so, i'm copying the file to a different location on snipas server. hopefully i can prop a temporary http so it canbe downloaded straight from that server. i might need to transfer it to my server if that doesn't work.

ok

you're moving the .gz now?

yeah. copying.

hyc, i pmd you the dload server

moneromooo, u as well.

sech1: looks like it has plateaued for now?

Estimated hashrate is 730-750 MH/s now

well i can't unzip this data.mdb until i get the other copy off this server

damn you limited HD space

anyone downloading that file? ima kill that server

hi - we’re considering making an auto-output-splitter in cake wallet (to mitigate the 20minute lock concern) - is there any danger to using transactions larger than 1in/2out? we want to improve UX while avoiding an “early 2018 xwallet” situation where certain transactions stick out. but we don’t want to clog the blockchain with churn transactions (which could happen if we only use 1/2)

No danger per se. Maybe best to make a x->16 tx to blend in with pools ?

Is "early 2018 xwallet" the people wanting to always have 3 outputs ?

ok if anyone wants that mdb its on 66.85.74.134:8964 now

Yes. They paid some wallet usage fee to themselves with the third output, also to gain wallet use statistics

One of the worst confidence-damaging moves I ever saw in Monero wallet space

hyc, ^

well, about four 3 ^

ok here goes nothing. all we need is "set_log 1", flush_cache bad-txs" right?

Yes.

well it seems snipa tried to pop blocks?

< Snipa> Popping off 500+ blocks hasn't helped so far.

well set_log 1 is going bonkers. couldn't see output of flush_cache bad-txs. tried to run it from other screen

It won't output anything IIRC. It'll just allow the tx to be verified again.

ok

hi. Sorry for being late. Did someone start a meeting?

No.

ok, ima swith to the 15.0.1 i compiled

Can we have one? It won't be long. :)

Or are you guys in the middle of something?

Sure, go ahead if you want.

Ok. Well just a few things to discuss, I guess.

hey, on the road atm. will check in again soon

1. How'd you think the release went? Anything of importance to discuss about it?

apparently some exchanges didn't update in time... ?

Snipa reported a couple dozen stuck nodes. I assume they're all his. Not sure whether it's related yet.

xmrchain.net node went down, but its syncronizing fine now

well, this is talking about the fork itself. Talking about the release.

But if there are things to note about the fork, we can discuss those too.

Nothing of note. That's good. :D

2. What's planned for the immediate future?

Merging stuff to master again :)

I guess some people have been batting back and forth the idea of moving to yearly releases from here on out.

trying to break rpc-payments is high on my list

But that needs to be discussed with the community at large.

GUI will do a point release in the next days. I guess CLI does not need one?

Not unless gingeropolous finds something that needs fixing with this sync issue.

selsta what does the point release do?

bug fixes

also compile Linux GUI with Trezor support

I'm definitely keen on annual releases

I think it's time

annual forks or releases?

fluffypony?

already?

I think we can aim for annual network upgrades in the future but let’s say we have CLSAG ready in 6 months I’m not sure if we should wait 6 months to deploy it.

But (hopefully) no more PoW changes.

I mean, there are a lot of big upgrades being worked on.

perhaps an "as needed" makes sense?

0.15 actually took 9 months since 0.14

it doesn't HAVE to have a set time frame, yeah?

maybe 9 months until the next release?

ErCiccione[m] what other big upgrades are being worked on?

9 months sounds good as a target IMO.

CLSAG. Sublinear signatures.

Ok. So this is something that can obviously be discussed further, but if there are any other opinions on this topic please feel free to speak up.

If you mean also non fork related: dandelion

Well, my opinion is that yearly feels long, but I'm also not the one doing the work so I'm trying to shut up.

moneromooo is there any way to enforce dandelion on a protocol level? Liek is that even possible?

None that come to mind.

CLSAG's been ready for a while, waiting for reviews. If it misses a release, waiting one more year feels harsh.

Alright. Anything else to discuss surrounding the release/fork?

You guys think everything went pretty smoothly this time, all things considered?

fork went smooth, no last minute binaries and also no issue with slow blocks this time

Yeah. A lot of issues from the past went fine this time around.

Alright, I won't hold you guys any longer. Thanks! We can break here. Just wanted to do an after-fork check in.

(test)

test

-=test=-

sorry. I think my matrix handle was relaying the irc chat in a messy order and late. No idea what's happening. Is the meeting over?

I think so.

Did you need a paste of what got said after your last line ?

Alright, then i lost all the conversation and i have to wait my matrix user to catch up -_-

that would be appreciated, yes

rehrar: the upgrades i was talking about were the ones mentioned by mooo. I too think would be a bit a pain to wait that long before they go live

I think annual fork is good. I guess that coincides with major releases but I don't know that it would have to

It has to, if people have to have code that's ready for the fork. Unless you're planning forks a year ahead, but that seems very unlikely.

luigi1111 not a fan of the 9 mo proporsal?

I was thinking every major release

like there could be non forking ones

9 mo is ok as a stepping stone I suppose

sorry meant annual forks

not annual releases lol

selsta: we definitely SHOULD wait 6 months to deploy it

it needs extensive testing on testnet + an audit or 2 or 3

right that’s not what I meant :P

ready = tested and audited

also some of this stuff can be deployed as soft forks

not CLSAG per se, but other things

selsta: we've traditionally taken a very short route with a lot of this stuff, I'd personally like to encourage a little bit more maturity of something like that before it goes live

I’m not even against 1 year forks

I think the added 1-2 month delay this fork was really important

whats the bang for buck for clsag?

hrm, xmrchain node is stuck on 1979077/1979413 again

ok moneromooo , im trying flush_cache bad-txs again

CLSAG saves maybe 25% space on average transactions, and 15-20% verification time

is the plan to bump up ringsize to effectively nullify, or we stickin with 11?

Depends what the consensus is

Would be a very small increase

is the 15.0.1 bind only available from getmonero.org?

I'd rather bump the ring size only if there's a convincing argument that it increases privacy more than epsilon. And I feel weird saying that given I like privacy all around...

gingeropolous: binary? yes

Perhaps it would be better to bump it in conjunction with a switch to a sublinear ring signature scheme (when that becomes feasible to implement)

ok moneromooo , ima try just using the release bins on the explorer node, unless you can think of something else i should try

Well, I just want to see the verification logs when it verifies the tx (because it's 99% going to be a tx that fails to verify).

well i ran that command. is it in the log files ... yeah.. ok i guess i gotta grep

any what the string would be/?

Yes. "verify" category, most likely.

Might be other interesting stuff a bit before/after too.

Silly question, but you didn't write bad-txs verbatim, right ?

I did.

I am personally in favor of 9-12 month schedule too fwiw

There's only one cache atm, but I left it open to have multiple caches that you'd want to differentiate.

With respect to CLSAG, I think it's better to fit the fork to CLSAG than the other way around

fluffypony: In a scenario where we would have annual HFs, would you still advocate for having a major release every 6 months?

To avoid confusion I guess we shouldn't bump the number then

Ah, I misread flush_cache for flush_txpool.

moneromooo its on xmrchain.net:8964

its 1e6 lines of log

ty

At what time did you run flush_cache ?

13:15:56 according to irc logs

Oh, there's a log showing it, nvm.

around there

u got the file? ima kill server

must've got it

dEBRUYNE: sure, or even more often

Yes, I have it, thanks.

And the tx doesn't get re-verified. Hrm.

<fluffypony> selsta: we definitely SHOULD wait 6 months to deploy it <= Transaction format also changes as far as I know, which means that third party wallets also have to perform work to ensure their wallets remain compatible

So we need to accomodate some time for that

yeah

good points :P

and how far out are the super-mega-awesome protocols that'll get us 1200 ringsize at 1 kb transactions?

Both Triptych and RCT 3.0's numbers looked quite feasible (as far as I could see) for ring size 128

which may also require ecosystem-wide tx format updated etc?

release should be whenever there's enough new stuff to make sense. some of the time that would include a fork. at least that's how i see it

Afaik, multisig has not been figured out though

i guess my point is that if triptych/rct3 is gonna happen, is it worth doing this twice in such close succession

Multisig is indeed unsolved with the sublinear ideas

Due to a key inversion step

moneromooo, any ideas for xmrchain node? or should i just try the release binary?

I don't see a reason for the failure so far.

ok. well the data.mdb is copied for further research, so ima try release bins

well that didn't do anything

Looks like it's missing a block between your current top and the one it's trying to add.

So it's a tx verification problem then. Would a level "2,*throttle*:ERROR" log be possible ? ^_^

it's *not* a tx verification problem

Fwiw the Triptych preprint is nearly complete

Finishing up the intro narrative and citations

moneromooo, files up on same port

Got it.

It's skipping some block because it was reported as invalid earlier. So I'd need a log with "2,*throttle*:ERROR" from the start.

ie, monerod --log-level "2,*throttle*:ERROR" --whatever-else-you-use

And I'll add a flush_cache for that block cache too :)

ah ok

ok its running with the new log level

i flushed and its up on the same port

moneromooo, ^

Got it, thanks.

no, thank YOU!!!!!!!!!!!!!!!!

Aha: Failed to query m_blocks: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid

Looks like we get that one a lot these days.

bad txn. bad bad

Yeah, I linked the blockID it appeared to be in last night before I passed out.

As it broke the pop-blocks tool.

Causes a real pretty segfault when you hit it.

Oh, I might want to look at the stack trace for that.

On the MDB file, assuming you snagged a copy, block 1973151 causes the segfault.

So any pop-blocks that tries to get past that block segfaults immedately

so what should i do to get this explorer working for the people again

resync

Or the more sensible answer: I'll copy in a clean MDB from a known good server.

Because that's way faster.

As we can't remove the bad block, we'd be resyncing from scratch.

any more debug etc needed from this mdb moneromooo hyc ? as Snipa mentioned, the data.mdb can be get gotten from my backup

How large ?

I'm still uncompressing the file

ok, u gonna take over Snipa with moving a new data.mdb?

I'm going to start the copy from one of sxmr's nodes in a sec, they're in the same DC so it should be fast.

nice.

i'll stop doin stuff on the server

paste.debian.net/hidden/a92477d4 will tell me where that error is coming from. It'll log on stderr.

moneromooo, u want us to run that on the existing data.mdb?

Yes.

Snipa, u seein this?

Yeah, it's a .patch that needs to be applied to the source I'd assume and monerod recompiled.

I'm not entirely here at the moment, so not super useful, just moving data for the most part.

yea yeah, i just wanna make sure you don't delete data.mdb

Nah, I'm copying to my home dir, then we can move it over again.

cause i don't think the server has enough room for ... ok

There's /just/ enough room for a second copy right now.

ok moneromooo what should i do with this patched bin?

Run it till it fails to add this block, and paste stderr where it should tell you the line at which it returned MDB_BAD_TXN.

ah, no special log level

and ther eit is

moneromooo, ^

Got it. I'll have another patch to add more info where it reported.

so far not looking like there's any corruption in the DB

paste.debian.net/hidden/e44bb798 (replaces the previous one)

can someone throw an estimate of the removal of integrated payment IDs from monero, if they are going to be removed at all?

i guess i would prefer them not to be removed since i have a project revolving around them but if there is a legit reason for their removal i obviously don't mind

There are no plans set for removal yet.

good enough for me

wow moneromooo , that errord out immediately

still scanning the data.mdb file here, but still no errors found

Thanks. Seems unlikely it's any race if it fails at startup.

I'll have to leave it to hyc now, since what sets the error flag needs knowing lmdb internals.

ok lessee where that tripped...

hang on moneromooo , i was running that patched bin on snipas new copied database

here's the patched bin on origina mdb paste.fedoraproject.org/paste/S~LNSTohbuKR7aCrFFApTQ

that's a bit weird since it's saying MDB_TXN_ERROR is set

but that only gets set in write txns

and line 10758 is an mdb_stat call, which is most likely in a read txn

probably would be more useful to get a stacktrace when that event occurs

I think it's a height() call.

But the one I put logs around doesn't show so I'm not sure.

might as well just use an assert or set a gdb breakpoint

anyway, that most likely means the MDB_TXN_ERROR flag was set before the height() call

so we're seeing the result of an ignored error, long after the fact

Right. But looking at what sets the error flag in mdb.c, I'm out of my depth :)

Alloc is unlikely, after that it's page juggling.

well, we could set breakpoints on each of the instances, there aren't many

gingeropolous: feeling up for it ? :)

sure!

ok

im always hungry for some copypasta

Run with gdb, but before the run command, put breakpoints. Let me go find the syntax again.

1800gosyntax

hmm, lemme apply that patch so my line numbers match yours

first: "list mdb_page_malloc"

Hrm, Should be: break mdb.c:1111 but it's not liking it.

Even with the path.

do the "list mdb_page_malloc" first to give gdb some file contet

theb "break 2031"

ok, so start gdb ./monerod , then put in list mdb_page_malloc run ?

or r

star gdb

then use list command

then use break command

don't run yet

because we want a few more breakpoints too

then "list mdb_page_loose"

then "break 2149"

then "list mdb_page_spill"

then "break 2369"

not a good start: Function "mdb_page_malloc" not defined.

then "list mdb_page_alloc"

then "break 2617"

and this only works on a debug build

?

Function "mdb_page_malloc" not defined. Works with mdb_env_sync0 (not static).

oh, well then i gotta recompile with debug

ok.

No symbol table is loaded. Use the "file" command.

It does that before it's loaded the process.

hyc, halp. need multipass

Try "run", then ^C after it's started monerod.

im an idiot

ok, still got Function "mdb_page_malloc" not defined.

but screw it, ima plow forward

how about any of the others?

well, i got No line 2031 in the current file.

ok, mdb_dump -a scanned the entire data file and had no errors

yeah the line number is no good if the list command failed

Alternatively, do the same thing I did for MDB_BAD_TXN but with MDB_ERROR, and add assert(0); after the printf. Then enable core dumps, run, load core post mortem.

yeah that'd work

MDB_TXN_ERROR

but I'm puzzled. my debug monerod has all of the symbols present.

gdb monerod

list mdb_page_malloc

^ works fine

hyc, do u just want access to the box?

that might be easier

ok, lets move to pm

fyi - becuase this debug build uses shared libs for the internal libs, you have to start the process before the symbols are present

so "break main"

"run"

then everything else shows up

ah

yeah i was surprised it didn't error out in compile. i usually have to edit the cmake.whatever file to get debug to build

ok took a few seconds, but hit a break at 6399

fyi paste.debian.net/1118956

now to figure out why this happened

and your running off of the old db at --data-dir /home/monerodaemon/.bitmonero.bak

correct hyc ?

yes

we're still getting stderr / stdout directed into the DB file

wasn’t mine also unbound? I forgot

I think it was, yes

y did this crop up now? i feel like i was running master for awhile

this is happening for over a month now but I think it triggers really unlikely

it happened twice on my DB

didn’t happen to others

snipa was saying this happened on 22 of his nodes?

Yup, it's happened to multiple so far.

I think we'll have to look into libunbound and see what it's doing

I've just been blowing em away and resyncing them.

Are you using your system's libinbound or the embedded one ?

how come poppin blocks doesn't fix it?

libunbound*

i dunno, hyc could tell yah :)

ldd monerod | grep libunbound

info shared says system libunbound

Hmm

selsta which are you using?

> Found libunbound shared library

so I guess system?

so maybe try another build using the bundled one instead?

I think our bundled version is more up to date ?

more up to date? Mine is 1.9.5

v1.7.3, I think.

So not really.

ok

but I think it was 1.9.4 the last time i had problems

it's definitely looking like an unbound bug

it still writes `sendto:` when exiting the daemon

lots of fixes recently including Fix Out of Bounds Write

not saying that it’s related :P

dang, that's a ton of out of bounds bugs

The one in Ubuntu 18.04 is v1.6.7, but I'm sure security updates (at least) are backported to it.

ok. hyc , are u still hacking around there? i'll try removing the system libunound and recompiling

and just fyi, i started another monerod process on different port bindings to resync using release bins into the default data dir