ephemeral message format

[surg0r]

No description provided.

[cyyber]

"The chance of a random 4 byte guess being successful is allowed_ephemeral_message_blockdepth/2^32"

The chance of a random 4 byte guess being successful doesn't depend upon allowed_ephemeral_message_blockdepth rather on numbers of blocks possible between timestamp of block header hash and TTL.

Example
ID : Any Random ID
PAYLOAD : Payload
TTL : Timestamp of 48 hours from current time
BLOCKHASH : RandomBlockHeaderHash
POW : PoW solution based on difficulty generated by current block height to the possible blocks at TTL.

The attacker may still wait for his Random Block Header Hash to be true, and then he broadcasts its ephemeral message.

So if

Current Block height is 1000
In 48 hours Block height will be 10,000
allowed_ephemeral_message_blockdepth is X
Now attacker creates ephemeral message
TTL - current time + 48 hours
Headerhash - RandomHeaderHash

based on the above content
if attacker has premined considering block height 1000 's timestamp

the chances of his success is
(10,000 - 1,000)/2^32 = 9,000 / 2^32

Still close to 0, but doesnt depend upon allowed_ephemeral_message_blockdepth

[surg0r]

The chance of a random 4 byte guess being successful doesn't depend upon allowed_ephemeral_message_blockdepth rather on numbers of blocks possible between timestamp of block header hash and TTL.

Well spotted. As discussed this attack vector would require huge resources to provide a fairly tiny chance of randomly pre-generating valid spam messages. Nine thousand in four billion is practically zero for the purposes of spam prevention. 2^40 would mitigate this further but I would suggest is not going to add much in terms of security given our existent messaging flood protections in place.

Agree @cyyber?

[surg0r]

Additionally it would be useful to decide the first supported POW algorithm and byte encoding now so we can add it to the QIP. I would suggest we stay away from pure SHA2_256. Although a modified version could work which favours rapid validation at the exclusion of existing SHA2_256 mining hardware?

[cyyber]

The chance of a random 4 byte guess being successful doesn't depend upon allowed_ephemeral_message_blockdepth rather on numbers of blocks possible between timestamp of block header hash and TTL.

Well spotted. As discussed this attack vector would require huge resources to provide a fairly tiny chance of randomly pre-generating valid spam messages. Nine thousand in four billion is practically zero for the purposes of spam prevention. 2^40 would mitigate this further but I would suggest is not going to add much in terms of security given our existent messaging flood protections in place.

Agree @cyyber?

Yes I agree, the attack vector requires huge resources. Although my comment was to correct the probability.

[cyyber]

Additionally it would be useful to decide the first supported POW algorithm and byte encoding now so we can add it to the QIP. I would suggest we stay away from pure SHA2_256. Although a modified version could work which favours rapid validation at the exclusion of existing SHA2_256 mining hardware?

Yes. we need to avoid SHA2_256, as well as, need to understand how the ASIC going to effect this PoW. If a mining algorithm could be mined by ASIC devices, then we may need higher difficulty, but that means, a normal CPU will need to work harder. Thus to keep this feasible for users, we need to ensure PoW algorithm is ASIC resistant.

[hadacnot]

Thanks for the QIP. Other than the POW spam prevention, would't it make sense to pay a QRL fee on chain to the node first relaying the message? I mean, what is the incentive for nodes to participate in the ephemeral network?
Maybe I am misunderstanding, and the fees would be paid to those external actors that you mention. But still, why would nodes participate?

[PQAdvantage]

Great point @hadacnot - I think it's important for us to consider appropriate fees associated with all of the new features coming online, including authentication, smart contracts and QRTs.

[surg0r]

@hadacnot @PQAdvantage

There is little incentive for an average node to route the traffic. In the same way there is little economic incentive to forward any transactions or blocks for any fully validating non-mining node!

Routing and storing ephemeral messages will be optional within the qrl-node configuration - with the default set to off.

To open a channel using ephemeral messages from A to B securely requires both parties to have confirmed a lattice tx in the chain - so in a sense useful traffic has already paid a toll to the network.

Currently the chain is a ledger of post-quantum secure value, following ephemeral messaging it also becomes a decentralised post-quantum public key repository for QRL accounts/identities. We are working with other parties such as keybase to integrate our chain for wider identity management purposes at the moment.

[IMac318]

The question of block # vs. unitary time for an expiry date is a good one. My initial reaction is that unitary time would easier for the user, but block # would be easier to code. If an exact (or close to exact) time was desired, then a simple conversion wouldn't work. I'm leaning towards unitary time being the better option.

[IMac318]

With these messages, there might be cases where a user doesn't want the message to be read until a certain time, but they might not be around to broadcast the message to the network at that time. I think that use is limited and wouldn't be worth making another field for in every message, but it is a feature that may be worth implementing in whatever application is made to broadcast the messages.

[surg0r]

With these messages, there might be cases where a user doesn't want the message to be read until a certain time, but they might not be around to broadcast the message to the network at that time. I think that use is limited and wouldn't be worth making another field for in every message, but it is a feature that may be worth implementing in whatever application is made to broadcast the messages.

@IMac318 @ch0ra

My original idea was to use layering to allow a message to be placed inside another message. The first message is opened by the receiver and may contain a TTR field (time to relay). When the TTR timestamp is reached the second message is released into the network.

Is that what you are referring to?

[cyyber]

This QIP is missing QIP number in its content.