summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-01-29Update bip-0350.mediawikiPieter Wuille
Co-authored-by: andrewtoth <andrewstoth@gmail.com>
2021-01-29Update bip-0350.mediawikiPieter Wuille
Co-authored-by: andrewtoth <andrewstoth@gmail.com>
2021-01-29Add BIP 350 (bech32m)Pieter Wuille
2021-01-26Add link to implementationSuhas Daftuar
Also change the phrasing to more clearly indicate when block-relay-only peering was deployed.
2021-01-25Combine Appendix with field listing tablesAndrew Chow
2021-01-25Mark BIP 174 as finalAndrew Chow
2021-01-15Include PSBT versions that can or must include fieldAndrew Chow
2021-01-15Specify procedure for new fields and versionsAndrew Chow
2021-01-15Explicitly specify PSBTv0Andrew Chow
2021-01-14Reformat BIP 174Andrew Chow
2021-01-13BIP 174: clarify format of proprietary extensions.Rusty Russell
"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>
2021-01-11bip-0141: clarify the sigop count calculation for CHECKMULTISIGAntoine Poinsot
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>
2021-01-06p2p: Add disabletx messageSuhas Daftuar
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.
2020-12-23bip-0322: remove the 'to_spend' transaction from serializationAndrew Poelstra
2020-12-23bip-0322: overhaul/rewrite verification rulesAndrew Poelstra
2020-12-23bip-0322: move "legacy" section up, separate "proof of funds", summarize the ↵Andrew Poelstra
signature types
2020-12-23bip-0322: replace motivation, add myself to the "thanks to" listAndrew Poelstra
2020-12-22bip39: discourage from using localized wordlistsPavol Rusnak
2020-12-20Merge pull request #998 from sabotag3x/masterLuke Dashjr
Add Portuguese wordlist to BIP39
2020-12-18README: Link BIP 2 for submissionsLuke Dashjr
2020-12-17Add a link of another Rust implmentation of BIP-0039koushiro
Signed-off-by: koushiro <koushiro.cqx@gmail.com>
2020-12-09Merge #1043: BIP155: change when sendaddrv2 is to be sentWladimir J. van der Laan
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
2020-12-08BIP155: change when sendaddrv2 is to be sentVasil Dimov
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`.
2020-11-30Remove the term "secret nonce", only refer to sOrfeas Litos
2020-11-30Say that public nonce is R and private nonce is sOrfeas Litos
2020-11-19Add BIP85-DRNG and other key derivationsEthan Kosakovsky
2020-11-18BIP34 specifies it requires minimal encoding.Greg-Griffith
Non minimal encodings are rejected by the bitcoin-core client because it only checks against a specific encoding
2020-11-16fixed input test case description as per output test case descriptionFerdinando M. Ametrano
2020-11-15fixed typosfametrano
2020-11-09BIP-322: minor clarificationKarl-Johan Alm
2020-11-07Update bip-0079.mediawikiPandaBread2
2020-11-03Update bip-0039.mediawikiMeheret Tesfaye
Add Python-HDWallet on Other Implementation.
2020-10-27fix typoRita Kitic
2020-10-24Merge pull request #1003 from kallewoof/202010-signmsgLuke Dashjr
BIP-322: switch to using tx based approach
2020-10-24BIP-322: switch to tx based approachKarl-Johan Alm
Co-authored-by: Stepan Snigirev <stepan.snigirev@mpq.mpg.de> Co-authored-by: Luke Dashjr <luke_github1@dashjr.org>
2020-10-21Update formattingrichard
2020-10-21Update bip-0085.mediawikirichard
2020-10-19Merge pull request #1019 from ajtowns/202010-bip8-trivialLuke Dashjr
BIP8: clarify timeoutheight behaviour and requirements
2020-10-17BIP8: allow some MUST_SIGNAL blocks to not signalAnthony Towns
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.
2020-10-17BIP8: Make signalling during LOCKED_IN recommended rather than mandatoryAnthony Towns
2020-10-17BIP8: clarify timeoutheight behaviour and requirementsAnthony Towns
When lockinontimeout is true, we don't transition directly from STARTED to LOCKED_IN, so don't imply that we do. If startheight or timeoutheight are not on a retarget boundary, they behave as if they had been rounded up to the next retarget boundary, so to keep things simple, require them to be at a boundary. If timeoutheight is less than two retarget periods later than startheight, behaviour when lockinontimeout is true (one retarget period of STARTED, one of MUST_SIGNAL, one of LOCKED_IN, then ACTIVE) will not match behaviour when lockinontimeout is false (one retarget period of STARTED, then either LOCKED_IN or FAILED), so disallow that as well.
2020-10-16Update bip-0085.mediawikirichard
2020-10-15BIP8: add note about keeping lockinontimeout=true peers connected to each otherAnthony Towns
2020-10-15BIP8: replace FAILING with MUST_SIGNALAnthony Towns
This removes the FAILING state and adds compulsory signalling during a new MUST_SIGNAL phase during the last retarget period prior to the timeout height. This ensures that if a deployment occurs using bip8 with lockinontimeout=false and timeoutheight=N, that a later deployment using bip8 with lockinontimeout=true and timeoutheight=K, where K<N that any chain where LOCKED_IN is reached prior to height K, will be accepted as valid by nodes using either set of deployment parameters. It also ensures that the soft-fork's changed rules are only enforced on chain a retarget period after signalling indicates enforcement is expected (which was not previously the case if the FAILING to ACTIVE transition took place).
2020-10-15BIP8: add dot file for generating states diagramAnthony Towns
2020-10-14Merge pull request #1013 from kallewoof/202010-signet-author-fixLuke Dashjr
bip-325: add Anthony Towns to authors and change status to Proposed
2020-10-14bip-325: add Anthony Towns to authorsKarl-Johan Alm
2020-10-14bip-325: status -> proposedKarl-Johan Alm
2020-10-08Merge pull request #991 from n1rna/bip49/fix-typoLuke Dashjr
Fix typo in BIP 49
2020-10-08Merge pull request #1005 from kallewoof/202010-signet-sigscriptLuke Dashjr
bip-325: correct placement of challenge
generated by cgit v1.2.3 (git 2.26.2) at 2024-10-30 21:29:42 +0000