"Variable length string identifier" is not defined anywhere, and the suggestion
to use "0x00" is also deeply unclear. I assumed it meant a nul-terminated
string!
Be explicit: you mean it must be a compact siz1\e unsigned int length, followed
by that many identifier bytes, followed by a compact size unsigned int subtype,
followed by optional keydata.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since the sigOpCount calculation was copied from P2SH, and P2SH
restricts the use of CHECKMULTISIG with pushed integers the reference
implementation would not take into account the number of public keys for
17 to 20 keys (not representable with an OP_N) even for P2WSH.
Therefore it fallbacks to accounting for 20 sigops in this case, which
this sentence seemed to mismatch with.
Btcd and Libbitcoin use the same calculation as in Bitcoin Core.
Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
This message, valid between version/verack for peers with version >= 70017,
would allow establishing at the time of connection that no transactions will be
announced/requested between those peers.
e549ed36e8 BIP155: change when sendaddrv2 is to be sent (Vasil Dimov)
Pull request description:
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`.
ACKs for top commit:
MarcoFalke:
ACK e549ed36e8
harding:
ACK e549ed36e8
jnewbery:
ACK e549ed36e8
laanwj:
re-ACK e549ed36e8
jonatack:
ACK e549ed3
hebasto:
ACK e549ed36e8, I believe that the establishing of connection invariants in a such manner--in response to the `version` and prior to sending the `verack`--is the right way both for new `addrv2` message and for other future features.
Tree-SHA512: ec8c40a7f857cc8b7df10812cb34d526299b6908b06049dfea24e25d830fc2d01bf4c052e9e4cd575ce4a1b93032cbe27323a390fe7fb90803a5975dd363d150
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`.
Using the same threshold for MUST_SIGNAL as STARTED means that any chain
that would have resulted in activation with lockinontimeout=false will
also result in activation with lockinontimeout=true (and vice-versa).
This reduces the ways in which a consensus split can occur, and avoids
a way in which miners could attempt to discourage users from setting
lockinontimeout=true.
