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
BM bot sourcecode sample Jul 20 15:56 7
Network Size Jul 20 15:51 3
RE: BM bot sourcecode sample Jul 20 04:01 1
BitMessage need new improvements Jul 19 23:35 3
2 bugs while quitting Jul 19 19:03 1
Brute forcing BM addr's Jul 19 13:13 22
[Feature Request/Question] Blacklist counters Jul 19 12:01 1
raspberry pi Jul 18 17:13 3
Feature request (2) Jul 17 00:44 13
Bug report (UI shows deleted messages) Jul 17 00:20 3
ECC Curves: secp256k1 versus secp521r1 -> BitMessage Secure Station Jul 16 22:18 1
PyBitmessage message save folder Jul 16 21:00 5
HELP(!) - Impossible PoW recipient address msg Jul 16 20:53 6
ECC Curves: secp256k1 versus secp521r1 Jul 16 20:44 28
Precedence of work / Priority of work Jul 16 20:43 5
I need help Jul 16 16:42 1
Pre-commitment and "open source canary" Jul 16 16:41 2
Killing impossible PoW sent items (daemon) Jul 16 16:40 1
Feature request (1) Jul 13 13:45 6
Bitmessage statistics Jul 13 09:42 13
addr command problems and plans Jul 13 06:19 7
BM client 0.6.2 (OS X) does not show images Jul 12 04:16 24
bug in latest commits Jul 11 08:46 11
Bitmessage bug in latest v0.6 branch Jul 11 06:09 1
bmwrapper broadcasts Jul 10 14:27 5
Beamstat chanlist bug? Jul 10 06:10 3
FPGA Hardware backdoors risk and counter-measures, regarding « TOR/VPN fingerprinting family anonymity breach fix » with a custom FPGA based « Single Socket » Ethernet Controller. Jul 9 11:36 1
tor socks access issues continue (0.6dEV pYbm code @ 20170706) Jul 8 23:10 3
FPGA Hardware backdoors, regarding « TOR/VPN fingerprinting family anonymity breach fix » with a custom FPGA based « Single Socket » Ethernet Controller. Jul 8 14:10 3
BM-2NB prefix ? Jul 8 13:30 3
Jabit and Abit update Jul 8 07:45 1
Peer "Ratings" Jul 7 12:54 9
How to.. Jul 6 18:01 49
Is there a quick way to export a thread, or all threads of a chan in a readable manner. Jul 6 04:00 6
Dev-talk PML status / instructions pls Jul 5 21:04 5
BM db blob questions Jul 5 07:40 11
How to connect to more nodes Jul 5 07:34 13
P.P.S. Re: BM db blob questions Jul 5 03:21 2
bitmessage API TTL Jul 5 01:08 2
Re: Re: Re: Re: Religious garbage at this point Jul 4 22:28 7
Yes it's obvious my BM private keys have been stolen.... Jul 4 22:20 34
MiNode I2P support testing Jul 2 07:04 25
To the person running /wire:0.1.0/bmd:0.0.1/ on Jul 1 12:55 9
So you think God is a myth ... Jul 1 12:14 1
How to.. (Node Conns Encrypted) Jul 1 10:17 1
Any predictions? Jun 30 12:24 3
Hello ! Jun 30 10:03 18
If I had cash Jun 30 09:56 3
"addr" commands Jun 29 22:14 2
How to.. (DNS issues and asyncore/conventional Network Access behaviour) Jun 29 13:03 3
I2P peer discovery by publishing destinations as custom objects Jun 27 03:53 4
Confused Jun 25 21:29 6
Curious Jun 25 21:23 1
Question - BM mesage model alteration idea Jun 25 18:39 4
Privacy? I don't have anything to hide. Jun 25 18:30 4
Support (connections are "stuck" when using TOR+iptables) Jun 24 21:10 7
Wondering Jun 23 21:36 5