| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Mandate to send `sendaddrv2` to the peer before sending our `verack`
to them.
This way we know that the peer does not support `addrv2` if we did not
receive `sendaddrv2` from them before receiving their `verack`.
|
|
6ef71b344c51aebe1dab5ac47f87d8f926462a65 BIP155: Small text improvements (Hennadii Stepanov)
562f1d71883d1daa0dd5f438d25986fb18465800 BIP155: Mention SHA3-256 explicitly (Hennadii Stepanov)
Pull request description:
It seems better to clarify that `CHECKSUM` in Tor onion v3 address uses SHA3-256 hash function.
ACKs for top commit:
vasild:
ACK 6ef71b344
laanwj:
ACK 6ef71b344c51aebe1dab5ac47f87d8f926462a65
Tree-SHA512: b88c7dfeeda2a99cfe1042c9f4e7cbeb6047882bf97ce9c1dd5e1f4a30203a9a03702638cc4b6c3b573f6c0a05b73a5ca43a77352a5ca24a32d19be129f8b317
|
|
BIP155: clarify variable integer format and change time to fixed 32 bit
|
|
The Bitcoin Core source code has `VARINT` type which is different than
the "variable integer" format used all over the P2P protocol and also
for the "services" field in this BIP. The latter is called `CompactSize`
in some BIPs and also in the Bitcoin Core source code, thus use the word
`CompactSize` to refer to it and link to its documentation.
|
|
|
|
|
|
32 bit unsigned can represent time up to year 2106
(32 bit signed is limited to just 2038).
So, we don't need to have "time" encoded as variable integer which would
take 5 bytes instead of 4.
|
|
Change signaling of support for the new `addrv2` messages to be done via
a dedicated message `sendaddrv2` instead of protocol bump.
The drawback of using a protocol bump is that the protocol version is
not a bitmask and if a node wants to announce support for `addrv2` this
would imply support for all prior features included in that protocol
version.
|
|
* Increase the maximum length of an address from 32 to 512 bytes and
clarify that the entire message should be rejected if it contains
a longer address.
(from https://github.com/bitcoin/bips/pull/766#issuecomment-519248699)
* Remove a contradiction about unknown address types - "MUST ignore" VS
"MAY store and gossip".
* Recommend gossiping addresses for networks to which the node is not
currently connected to.
(from https://github.com/bitcoin/bips/pull/766#issuecomment-545067608)
* Clarify that the entire message should be rejected if it contains an
address with unexpected size (e.g. IPv4 address with length 5).
|
|
|
|
|
