HELP(!) - Impossible PoW recipient address msg

[chan] bitmessage
Jul 14 09:33

HELP(!) - Impossible PoW recipient address msg Tough Day, broken sleep. Zombie assistance request. Even the Nero double strength coffee shots aint workin' Sent a bunch of (short) messages to my home target system with ( I thought ) a different range of PoW private key settings. Starting with the lowest. Or so i thought. Screwed up - badly - all were created with an insane default Subsequent edited values are not the ones presented for first use by a sender elsewhere on the network. No surprise there. Is it possible to force propagation of the corrected PoW values in keys.dat over the network? If so - How? I can probably get remote shell access to the target system from here. Otherwise I'll have to reschedule the trial audience I'd planned to assemble later today. Operating from a laptop, away from home base. This BM is a daemon with no Qt GUI capability in the OS. Just a demo system really. Uses bmwrapper with a conventional email client. I may have some command line API tools somewhere but cant find 'em. Or remember the syntax and API commands to kill the queued items. It would be nice to send an RFC cancel email but i doubt that would work. How do I kill this queue - quickly - to avoid thermal issues with the laptoop - after restarting the daemon? It isnt in a VM so i cant throttle it to constrain resource usage. ( Sending this from the rather splendid BM GUI in a VM ) Anone else ever been in this situation - playing with PoW settings? Last recovered situations likethis 2 1/2 Years ago. But not remotely. Some people never learn... Helpppppp ;-) <*sigh*>

[chan] bitmessage
Jul 14 09:34


[chan] bitmessage
Jul 16 16:40

Shut down bitmessage then kill any remaining python process. use sqlite3 to delete the offending messages, and delete all rows in the object processor queue table. You might lose some data, but it will fix the problem.

Jul 16 16:40

If it is ok for the queued messages to stay in the send folder but be ignored, the easiest workaround is to reduce maxacceptablenoncetrialsperbyte and maxacceptablepayloadlengthextrabytes in keys.dat. A value of 10000 is reasonable on a low end machine. Shut down PyBitmessage prior to editing the file. You may have to kill the process forcibly if it's stuck in the PoW. Upon restarting, it won't do PoW for those messages, and if you want you can use RPC to delete them. This is probably the fastest way to resolve your issue. While it is in theory possible to update your pubkey metadata, it's complicated and I'm not aware of an existing description of the process (I have a vague idea how it could work but I never tried it and would have to do an investigation). I've known for a while that this behaves non-obviously and there is potential for improvement but it's very rare and not a high priority. Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 16 20:44

Using the GUI it is possible to delete outgoing messages regardless of their state. If PoW has not yet been started on a message then obviously it won't ever start but if PoW is currently being performed on a now deleted message then a simple restart of bitmessage should stop the PoW. Hopefully it should be quite similar with the API - just delete the messages as normal (getSentMessagesByAddress, trashSentMessage). I'm not sure how to go about restarting bitmessage remotely in the current situation though. However in the future in lieu of an API function to call, you can set up the API to run a script when API events occur. Just set apinotifypath in keys.dat to the desired script. This functionality is quite basic, there are only 2 events startingUp, and newMessage which are the arguments passed to the script. The script (which you would have to write) when called by the API would in turn connect to the API to try to retrieve a message from a particular sender, process the message for actions to take, and carry out those actions. An example action would be to send SIGINT or SIGTERM (these are supposed to work when bitmessage is in daemon mode) to bitmessage to get it to shutdown normally, then just start bitmessage again.

[chan] bitmessage
Jul 16 20:53

MANY Thanks Peter. I had actually compounded the stupidity - On closer inspection of those two magic numbers. For equipment with plenty of DRAM PyBM is almost always running from within a VM. But not on my "worst case" 7+ YO Dell laptop. Assigning resources to keep max temp of equipment in bounds is easy. Had not correctly changed ALL of the values from a daemon keys.dat inside a large Dev Workstation VM - deliberately running High PoW comms tests as an entropy feed for exotic key generation on the host. When it was transplanted to the Laptop host and edited ages ago. All is now in Harmony. Acceptable ratios of steam :- coffee cup(s) / ears / laptop now in effect. I did look, briefly, at a way to throttle PoW c/o some for of "listener" communicating with the daemon code, rather than an API extension. Some time ago. What would be the least invasive / spec changing code based way to do that? With physical access to the machine a magic key combo, held down to throttle "Up" and "Down" should be relatively easy. Wait states built into the compiled C PoW routine perhaps? Take this as a feature request; I broke a messages.dat file beyond all hope of repair using kill -9 five months ago. An "All or nothing" option for native Host running stuff is not good. ( daemons when the host also lacks Qt display capability to run the GUI, and/or large batches of messages need to be processed efficiently ). Needed while the exact private key demanded PoW network served dynamics are a mystery that people WILL find edge cases to fall off. And are obliged to run PyBM native on the Host because of insufficient resources to operate a VM solution. Earlier this morning I was standing a cliff edge. Good to have a push in the right direction of a decisive step ;-) Have a good afternoon Matey! You have significantly improved mine. Ta Muchly.

[chan] bitmessage

Subject Last Count
Tor replacement Nov 18 04:15 3
Alternative Bitmessage port for official assignment with IANA? Nov 18 02:20 1
codewordtest2 Nov 17 21:52 1
bitmessage history Nov 15 08:43 28
stream and pool diagram Nov 12 12:05 21
( ͠° ͟ ʖ ͡°) Nov 10 09:51 2
I'm back. Nov 9 17:55 1
streams and pools Nov 7 01:37 1
How to examine bitmessage objects Nov 7 00:45 5
Tor curve vs bm curve Nov 7 00:45 4
keys.dat values Nov 6 23:16 2
Bitmessage history Nov 6 08:08 9
Pseudo-mailinglist vs chans? Nov 5 21:47 2
bitmessage node rating? Nov 5 21:32 2
can I connect to both onions and standard? Nov 5 19:33 11
Bitmessage won't exit cleanly Nov 4 18:06 2
keys.dat must be encrypted Nov 4 12:09 12
Question Nov 3 20:09 5
It's actually not that hard to de-anonymize someone on bitmessage. Nov 3 19:49 8
It's actually not that hard to de-anonymize someone on Nov 2 14:18 1
Bitmessage snapshots Nov 2 13:14 3
Why chan address? Nov 1 06:26 2
HASH Q Oct 31 21:16 1
bitpetite scam Oct 31 08:34 2
GitHub Supports Islamic Clitoris Removal Oct 31 01:02 14
What exactly is the address of [chan] general? Oct 30 05:29 7
MiNode addr bug Oct 27 11:53 1
Hi, users ! Oct 27 07:18 5
No incoming connections now Oct 26 09:40 33
RE: bitmessage implementation in any other programming language Oct 23 17:01 1
disabled address still working Oct 23 12:47 8
apinotifypath Oct 22 01:11 1 error Oct 21 22:04 3
BM slow suddenly? Oct 21 15:47 9