The choice of not encrypting with P is deliberate since, I believe (according to my extremely superficial knowledge of quantum computers), that not providing the encryption key along with the message might confer some level of quantum resistance, in the case that the keys (C, D) and (C',D') are assumed to have been exchanged securely e.g. Notice that the pair (P,R) in this context works only as an identifying tag that saves on scanning time for multiple keys. When replying back to (C',D'), he repeats the process above, encrypting his reply with E' and signing with his signing key v. Verify that it is properly signed by computing Verify(sig, V').Decrypt the message contents by computing msg := Dec(ct, e).If so, he proceeds as follows: (Here I am assuming the sender's subaddress (C', D') is included in the message, since it should be hidden.) User (C, D) scans the message pool and checks, for each message, whether P - H(c*R)*G belongs to his hash table. Find suitable nonce such that the hash value H(ct, sig, (P,R), nonce) is low enough.Compute the signature sig := Sign(ct, v').Compute the ciphertext ct := Enc(msg, E).Pick a random r, and compute P := H(r*C)*G + D.For Monero uses, C is the view key, and D the spend key, as normal.įor messaging purposes, let E = e*G := C+D = (c+d)*G be the encryption key, and V = v*G := D = d*G be the verifying key.įor user (C' ,D') = (c'*G, d'*G), with encrypting and verifying keys (E',V') = (e'*G, v'*G) := ((c'+d')*G, d'*G) to send a message msg to (C, D), he proceeds as follows: Let the user pick random a, b to form a family of subaddresses in the usual way. This could make the claim that cryptocurrencies make payments as easy as sending an email a reality for users of the system. If that is achieved, Monero users may seamlessly and directly message other users they are transacting with, and conversely users that are chatting to each other may seamlessly send tips to each other. Also, Bitmessage nodes have to try to decrypt every single message to check whether they are the intended recipient, so they suffer from the same problem Monero had before the adoption of subaddresses.Ĭonsidering that these applications that Monero already have for Bitmessage-style messaging, and that the problem of scanning for multiple keys has already been solved in Monero, it would perhaps be a natural step to enable direct messaging between Monero addresses as viewed as Bitmessage-like addresses. This will likely use the MMS as well.īitmessage, however, is based on Bitcoin's cryptography and, to my knowledge, does not currently support Ed25519 cryptographic primitives. Participants will need to colaborate by messaging each other to coordinate the signing of different rings of a single transaction and generating corresponding bulletproofs required. (iii) recently a version of Monero coinjoin has come under consideration. (ii) multisig participants use Bitmessage to coordinate wallet creation and spending from it (MMS) (i) broadcasting Monero transactions to break link to originating IP address (Noether’s Gate) Some Monero applications already make use of Bitmessage messaging system. Bitmessage also uses Dandelion for broadcasting its messages to protect user's IP addresses. Bitmessage is metadata free since no information about sender or receiver is included, and the message is just a ciphertext that each user tries to decrypt with their own keys. Messages are kept by nodes for a determined period of time depending on the PoW applied to each message. Proof of work on each message is used to deter spam abuse. The Bitmessage protocol is based on the Bitcoin messaging layer protocol in which every node storesĪll the messages in the network, thus behaving as a collective inbox.
0 Comments
Leave a Reply. |