-
xmr-pr
crlsim opened issue #6925: There were 0 blocks in the last 20 minutes,v0.17.1.1
-
xmr-pr
-
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
-
needmoney90
the volume of support requests has grown immensely in the past two months, I'm doing what I can to stem the tide
-
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
-
Inge-
(that I've seen in the CLI after 17.something)
-
xmr-pr
bitcodernull opened issue #6926: Node stops syncing at 2210720
-
xmr-pr
-
fluffypony
figured out the DNS issue
-
fluffypony
always good to have fresh eyes
-
selsta
nice
-
binaryFate
hello
-
binaryFate
I should just update site right?
-
selsta
yep
-
binaryFate
done
-
fluffypony
oh and DNS recs are done, forgot to mention that
-
selsta
yep, tested it and shows up, thanks
-
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)?
-
selsta
yes
-
selsta
show_transfers showed it as failed
-
selsta
and a couple minutes later it got confirmed
-
selsta
I thought in unrestricted mode it should not switch to failed as long as it is in the mempool?
-
aubergine
Hi
-
aubergine
The following RPC api call returns an error
-
aubergine
"{\"jsonrpc\":\"2.0\",\"id\":\"0\",\"method\":\"import_multisig_info\",\"params\":{\"info\":[\""multisig_info"\"]}}"
-
aubergine
{"code":-1,"message":"Error calling import_multisig"}
-
aubergine
what can be the error?
-
aubergine
hi
-
aubergine
has the import_multisig_info RPC call changed recently?
-
moneromooo
Not that I know of.
-
aubergine
then the following RPC call should return normal
-
aubergine
"{\"jsonrpc\":\"2.0\",\"id\":\"0\",\"method\":\"import_multisig_info\",\"params\":{\"info\":[\""multisig_info"\"]}}"
-
moneromooo
Bump logs (--log-level 1 should be enough).
-
aubergine
instead I get {"code":-1,"message":"Error calling import_multisig"}
-
m2049r
Inge-: argh. hope that gets fixed soon. i am considering removing the "failed" state and pretending its just in the pool.
-
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
-
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.
-
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!"
-
moneromooo
No, it might be the next in the chain.
-
Inge-
argh
-
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?
-
sech1
or rather prefer peers which did relay some data
-
moneromooo
That seems like a good idea at first glance...
-
sech1
if peer relayed a tx which later ended up in a mined blocks -> up his rank
-
sech1
because fake peers can relay some fake data, but mined blocks are more reliable source of data
-
Inge-
if a peer gave you a higher block than your top -> up your rank
-
Inge-
their*
-
sech1
block height is not reliable test, they can change it in the next update
-
moneromooo
If it passes verification, you don't really care.
-
sech1
ok, then if it's a valid tx then up peer's rank - even simpler to implement
-
sech1
this still doesn't prevent passive attacks where normal nodes are running, but with added "logging"
-
moneromooo
Txes might be enough. No PoW though. I could see someone sending txes for 0.000000001 and not caring if they get mined.
-
sech1
but active attacks where peers drop transactions are more annoying
-
selsta
m2049r: we had this with GUI but then failed transactions stay as pending and people also get confused
-
selsta
is latest monerujo based on v0.17.1.1 ?
-
shermand100
Are there any known issues with v0.17.x.x (any minor) running on 32-bit systems?
-
selsta
no
-
selsta
CLI I assume?
-
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 ...
-
shermand100
0x722b9462)
-
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
-
hyc
run under gdb
-
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
-
hyc
what is the complete error message?
-
hyc
if you pasted it here, it seems to have been truncated. use a pastebin
-
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"
-
shermand100
The complete message displayed in the terminal (not gdb) at point of crash is
pastebin.com/CmhUSDwA
-
hyc
that error message is a kernel error
-
hyc
so gdb of monerod would be irrelevant
-
hyc
sounds like whatever version of kernel you're running, you need an upgrade.
-
hyc
if it still happens, it means your hardware is failing
-
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