Precedence of work / Priority of work

BM-NBACvhWaK4JpFY4hMcWDqt7JtVx78c1z
Jun 30 23:08

Does bitmessage place priority of sending messages before receiving and decoding messages? If send is not top priority an attacker could DDoS an individual address by constantly flooding it with incoming objects from a botnet. If address can be hanged or slowed due to incoming objects DDoS is serious threat. I guess that the protocol should prioritize sending of a locally composed message before all other operations. Nothing incoming to a node should have any effect of slowing down PoW and sending of outgoing original messages. If this is not the case then a permanent DDoS of an individual bm-address is trivial to implement. I didn't see anything about precedence of work or priority of work in the protocol paper. Please advise me if this concern is unfounded or already mitigated in the bitmessage protocol. ~ cl!Q

[chan] bitmessage
Jul 1 00:22

You are right, it seems to be an oversight of the protocol design. However I have not yet come across an implementation that does not use multithreading which effectively mitigates your concern.

[chan] bitmessage
Jul 1 00:50

If one dedicate thread were kept running strictly and only for sending original objects with high priority and the remaining threads multitask that might be perfect enough.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 1 05:38

> Does bitmessage place priority of sending messages before receiving > and decoding messages? Those happen in separate threads. > I didn't see anything about precedence of work or priority of work > in the protocol paper. Please advise me if this concern is unfounded > or already mitigated in the bitmessage protocol. Some parts were synchronous in the past, but now they happen in separate threads. > ~ cl!Q Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 16 20:43

My understanding is that sending requires proof-of-work (is computationally expensive) while receiving/decoding does not. So a DDoS should be significantly more expensive for the attacker than for the target. Abraham Lincoln Bitmessage core developer

[chan] bitmessage
BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY

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
checkdeps.py error Oct 21 22:04 3
BM slow suddenly? Oct 21 15:47 9