01:16:08 -xmr-pr- crlsim opened issue #6925: There were 0 blocks in the last 20 minutes,v0.17.1.1
01:16:08 -xmr-pr- > https://github.com/monero-project/monero/issues/6925
04:52:36 <needmoney90> Hey guys, we have a new channel #monero-support that we've just spun up. If any of you code gurus want to help out, feel free to join up. It's currently got a bot that polls /r/monerosupport every half hour, but we're working on more functionality
04:53:21 <needmoney90> the volume of support requests has grown immensely in the past two months, I'm doing what I can to stem the tide
04:59:15 <Inge-> m2049r: saw the same "failed" on a tx sent from latest monerujo using a 17.1.1 node - which suddenly was sent. Guessing it is also a case of D++ delays
04:59:47 <Inge-> (that I've seen in the CLI after 17.something)
05:46:08 -xmr-pr- bitcodernull opened issue #6926: Node stops syncing at 2210720
05:46:09 -xmr-pr- > https://github.com/monero-project/monero/issues/6926
07:52:04 <fluffypony> figured out the DNS issue
07:52:07 <fluffypony> always good to have fresh eyes
08:04:03 <selsta> nice
08:49:40 <binaryFate> hello
08:49:59 <binaryFate> I should just update site right?
08:52:36 <selsta> yep
09:23:57 <binaryFate> done
10:33:19 <fluffypony> oh and DNS recs are done, forgot to mention that
10:39:55 <selsta> yep, tested it and shows up, thanks
13:17:46 <vtnerd> selsta : I'm little unsure what you meant - it was in your local mempool via non-restricted rpc for 6 minutes, before you saw it show up in an external block explorer (or similar)?
13:18:19 <selsta> yes
13:18:43 <selsta> show_transfers showed it as failed
13:18:55 <selsta> and a couple minutes later it got confirmed
13:19:18 <selsta> I thought in unrestricted mode it should not switch to failed as long as it is in the mempool?
15:34:46 <aubergine> Hi
15:35:31 <aubergine> The following RPC api call returns an error
15:35:31 <aubergine> "{\"jsonrpc\":\"2.0\",\"id\":\"0\",\"method\":\"import_multisig_info\",\"params\":{\"info\":[\""multisig_info"\"]}}"
15:35:44 <aubergine> {"code":-1,"message":"Error calling import_multisig"}
15:44:22 <aubergine> what can be the error?
16:14:19 <aubergine> hi
16:14:33 <aubergine> has the import_multisig_info RPC call changed recently?
16:19:55 <moneromooo> Not that I know of.
16:20:15 <aubergine> then the following RPC call should return normal
16:20:16 <aubergine> "{\"jsonrpc\":\"2.0\",\"id\":\"0\",\"method\":\"import_multisig_info\",\"params\":{\"info\":[\""multisig_info"\"]}}"
16:20:17 <moneromooo> Bump logs (--log-level 1 should be enough).
16:20:27 <aubergine> instead I get {"code":-1,"message":"Error calling import_multisig"}
16:25:55 <m2049r> Inge-: argh. hope that gets fixed soon. i am considering removing the "failed" state and pretending its just in the pool.
17:56:22 <Inge-> m2049r: It has been claimed that once all/most nodes upgrade to D++ support the median time-to-mempool could be ~3s - which would be awesome
17:57:02 <moneromooo> That's if they don't get routed to nodes that drop them on the floor, which the assholes seem to do, from what I've read here.
17:58:03 <Inge-> another trick up the scoring-sleeve then. if a tx sent to a peer node doesn't appear in the mempool - "You're an asshole!"
17:58:33 <moneromooo> No, it might be the next in the chain.
18:00:36 <Inge-> argh
18:03:21 <sech1> What if we rank peers by their "usefulness" and don't send tx to peers who haven't relayed any transactions or blocks before?
18:03:41 <sech1> or rather prefer peers which did relay some data
18:04:52 <moneromooo> That seems like a good idea at first glance...
18:05:48 <sech1> if peer relayed a tx which later ended up in a mined blocks -> up his rank
18:06:11 <sech1> because fake peers can relay some fake data, but mined blocks are more reliable source of data
18:06:18 <Inge-> if a peer gave you a higher block than your top -> up your rank
18:06:41 <Inge-> their*
18:06:54 <sech1> block height is not reliable test, they can change it in the next update
18:07:16 <moneromooo> If it passes verification, you don't really care.
18:07:48 <sech1> ok, then if it's a valid tx then up peer's rank - even simpler to implement
18:08:53 <sech1> this still doesn't prevent passive attacks where normal nodes are running, but with added "logging"
18:09:11 <moneromooo> Txes might be enough. No PoW though. I could see someone sending txes for 0.000000001 and not caring if they get mined.
18:09:14 <sech1> but active attacks where peers drop transactions are more annoying
20:25:27 <selsta> m2049r: we had this with GUI but then failed transactions stay as pending and people also get confused
20:25:41 <selsta> is latest monerujo based on v0.17.1.1 ?
22:29:41 <shermand100> Are there any known issues with v0.17.x.x (any minor) running on 32-bit systems?
22:29:55 <selsta> no
22:30:03 <selsta> CLI I assume?
22:31:20 <shermand100> Yeah. I compiled 0.17.1.1 which built fine, and runs for approx 30 minutes (Raspberry Pi 4) before: Message from syslogd@PiNodeXMR at Oct 21 07:55:39 ...
22:31:21 <shermand100> 0x722b9462)
22:32:11 <shermand100> I'd like to work through some sort on meaningfull debugging to find the source as it's very unusual my project encounters any issue with the official monero releases
22:33:26 <hyc> run under gdb
22:33:41 <shermand100> This also happns with the pre-compiled arnv7 32-bit from get monero. And when I checked out v0.17.1.0. I'm about go back further to try v0.17.0.1
22:33:59 <hyc> what is the complete error message?
22:34:18 <hyc> if you pasted it here, it seems to have been truncated. use a pastebin
22:34:27 <shermand100> Sure do you have a tip for doing this within the terminal. I've tried but this causes the window to crash so I'm unable to exit to use "bt full"
22:36:54 <shermand100> The complete message displayed in the terminal (not gdb) at point of crash is https://pastebin.com/CmhUSDwA
22:38:06 <hyc> that error message is a kernel error
22:38:21 <hyc> so gdb of monerod would be irrelevant
22:38:47 <hyc> sounds like whatever version of kernel you're running, you need an upgrade.
22:38:55 <hyc> if it still happens, it means your hardware is failing
22:40:04 <shermand100> Thanks, out of the scope of Monero then. Thanks for your help. Getting there bit by bit, each new problem is a new lesson