Thanks,
I just couldn't find where is the message sequence number comes from.
So if it's max 1GB and it's an incremental counter that cannot be reseted
without a rekeying than it's perfectly fine :).
Thanks for the answer!
On Mon, Jun 17, 2019 at 12:20 PM Jonas Schnelli
wrote:
> Hi Elichai
>
>
Hi Elichai
> About the nonce being 64bit. (rfc7539 changed it to 96bit, which djb later
> calls xchacha)
>
> You suggest that we use the "message sequence number" as the nonce for
> Chacha20, Is this number randomly generate or is this a counter?
> And could it be reseted without rekeying?
The
Hi everyone,
About the nonce being 64bit. (rfc7539 changed it to 96bit, which djb later
calls xchacha)
You suggest that we use the "message sequence number" as the nonce for
Chacha20, Is this number randomly generate or is this a counter?
And could it be reseted without rekeying?
If it is randoml
On 03/22/2019 02:04 PM, Jonas Schnelli via bitcoin-dev wrote:
> Proposal:
>
>
> BIP: ???
> Layer: Peer Services
> Title: Version 2 Peer-to-Peer Message Transport Protocol
> Author: Jonas Schnelli
> Status: Draft
> Type: Standards Track
> Created: 2019-03-08
> License: PD
>
>
>
Hi Dave
Thanks for the review...
>> Short Command ID
>>
>> To save valuable bandwidth, the v2 message format supports message command
>> short IDs for message types with high frequency. The ID/string mapping is a
>> peer to peer arrangement and MAY be negotiated between the initiating
On Sun, Mar 24, 2019 at 09:29:10AM -0400, David A. Harding via bitcoin-dev
wrote:
> Why is this optional and only specified here for some message types
> rather than being required by v2 and specified for all message types?
Gregory Maxwell discussed this with me on IRC[1]. My summary of our
conv
On Fri, Mar 22, 2019 at 10:04:46PM +0100, Jonas Schnelli via bitcoin-dev wrote:
> === v2 Messages Structure ===
>
> {|class="wikitable"
> ! Field Size !! Description !! Data type !! Comments
> [...]
> | 1-13 || encrypted command || variable || ASCII command (or one byte short
> command ID)
> [...
Hi
The overhauled version of the former BIP151 has fundamental differences and
deserves (requires?) a new BIP.
Calling it „v2 peer-to-peer message transport protocol“ is more accurate since
it is no longer only about encryption.
The formatted draft proposal can be found here:
https://gist.gith
