Messages with same content #748
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-03#748
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
If the client receives several messages with the same content it shows only one message in the inbox (acknowledgement is sent like normal). Even if one message is already in the trash and the inbox is empty.
Can someone confirm that ?
Yes, that is how it works. Until messages include a UUID, that is how duplicates are detected: unique(sender + receiver + subject + message).
Ok, i see! So a UUID is planed for the future?
Yes, it would be needed for message-continuation since 256 kB for messages is a limit some people will want to work-around some day.
(A way to remove messages from trash (via api) would be helpful until there is a UUID or unique(sender + receiver + subject + message + time).
@Atheros1 Could we please disable this behavior? I think it may cause great confusion for the users. There was forum thread some days ago: https://bitmessage.org/forum/index.php?topic=4258, also I experienced the same problem recently: https://www.reddit.com/r/bitmessage/comments/2utvh8/email_to_bitmessage_gateway_service_launched_in/corsak8
I think the current behavior is completely nonintuitive.
Yes, I think that that would be a good idea. I can take it out.
Actually, how about this: The signature of a message, or a hash thereof, can be used as a temporary UUID since it contains a randomly generated component. We can store the hash of the signature and check if it is unique instead of the sender + receiver + subject + message.
Why we can't just use inventory hash (hash of the object message payload) to distinguish duplicated objects? If some component of the object was changed, then it would be another inventory hash.
Because the inventory hash includes the nonce which can be changed by attackers. The attacker would simply find the next nonce and rerelease the object. The object would have a different inventory hash and would show up as a duplicate message in the recipient's client.
Ah, I see. Haven't thought at all about that kind of attack vector.
So yes, you are right, it can be some hash of the rest of the object or just the signature.
Also, I'm wondering what is the original motivation to sign everything except the nonce? I know several appliances where it can be useful (e.g. doing the POW and encryption on a different computers), but at the same time it allows some kind of replay attacks.
Is your question "Why sign the time?"? Or is your question "Why not sign the nonce?"?
Why not sign the nonce?
We cannot sign the nonce because the nonce covers the signature. We cannot create the nonce without having the signature first.
Re: Atheros1: "Because the inventory hash includes the nonce which can be changed by attackers."
I suspected it is something like this, this sounds like the infamous malleability attack on Bitcoin. I thought that this is the reason why it was implemented like this (to prevent the attack from flooding inbox), but I don't know that much about the protocol, so I'll wait until someone else fixes it properly.
Indeed, it is similar to the malleability attack. Any part of any object can be changed by anyone if the attacker is willing to recompute the POW. The only part of the object that the attacker can change that won't result in the object being rejected by the receiver is the nonce.
Cool, thanks!
👍