Age | Commit message (Collapse) | Author |
|
BIP 174: require creator to initialize empty output fields
|
|
This partially reverts c0991047e25a35d1ddf241f304a079e9893eed69.
|
|
bip-0141: clarify the sigop count calculation for CHECKMULTISIG
|
|
BIP 174: Reformat, reorganize, and mark final
|
|
|
|
bip39: discourage from using localized wordlists
|
|
README: Link BIP 2 for submissions
|
|
Update bip-0079.mediawiki
|
|
BIP-0085: fix typo
|
|
Mention that public nonce is ''R'' and private nonce is ''s''
|
|
BIP-322: minor clarification
|
|
BIP 0085: Add link to JavaScript library implementation
|
|
BIP8: allow some MUST_SIGNAL blocks to not signal
|
|
BIP8: Make signalling during LOCKED_IN recommended rather than mandatory
|
|
|
|
Co-authored-by: andrewtoth <andrewstoth@gmail.com>
|
|
Co-authored-by: andrewtoth <andrewstoth@gmail.com>
|
|
Co-authored-by: andrewtoth <andrewstoth@gmail.com>
|
|
|
|
Also change the phrasing to more clearly indicate when block-relay-only peering
was deployed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"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.
|
|
|
|
|
|
signature types
|
|
|
|
|
|
Add Portuguese wordlist to BIP39
|
|
|
|
Signed-off-by: koushiro <koushiro.cqx@gmail.com>
|
|
e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2 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 e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2
harding:
ACK e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2
jnewbery:
ACK e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2
laanwj:
re-ACK e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2
jonatack:
ACK e549ed3
hebasto:
ACK e549ed36e8bbb0d15b1bd245cc5bb2c5664d5aa2, 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`.
|
|
|
|
|
|
|
|
Non minimal encodings are rejected by the bitcoin-core client because it
only checks against a specific encoding
|
|
|
|
|
|
|
|
|
|
Add Python-HDWallet on Other Implementation.
|
|
|
|
BIP-322: switch to using tx based approach
|