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).
1. CHECKSIG / CHECKSIGADD is confused
Only the first OP-code for the first public key should be "CHECKSIG" and the following (second to n-th) OP-codes should be "CHECKSIGADD".
It is confusing because it is only specified the first and last OP-codes, so I specified the second OP-code clearly.
(I recommend to describe why only the first OP-code should be "CHECKSIG", not "CHECKSIGADD".)
2. Order of the signatures in witness
In the original sentence, the stack status after the all witness elements are pushed will be
| w_n |
| : |
| w_1 |
and then, the first element of the script, "<pubkey_1>" will be pushed to the stack
| pubkey_1 |
| w_n |
| : |
| w_1 |
so the "pubkey_1" and "w_n" won't match.
The order of either "pubkey_i"s or "w_i"s should be inverted.
- Separate nonce generation into getting a random byte string and converting it to a suitable scalar ...
- ... to make clear that the byte string can be generated differently.
- Make the warning a little bit more prominent and improve writing
