summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-02-24fix: define motivation, remove account creation blurb.Fonta1n3
2021-02-24fix: remove legacy referencesFonta1n3
2020-12-16remove bip44 stuffFonta1n3
2020-12-16Merge pull request #1 from ben-kaufman/patch-1Fontaine
Mention BIP 44 as the Multi-Account standard
2020-12-16Update bip-0048.mediawikiFonta1n3
2020-12-16Fix the tablebenk10
2020-12-16Update bip-0048.mediawikiFonta1n3
2020-12-16Mention BIP 44 as the Multi-Account standardbenk10
2020-12-16Update bip-0048.mediawikiFonta1n3
2020-12-16minorFonta1n3
2020-12-16typoFonta1n3
2020-12-16fixesFonta1n3
2020-12-16Create bip-0048.mediawikiFonta1n3
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-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-19Merge pull request #1019 from ajtowns/202010-bip8-trivialLuke Dashjr
BIP8: clarify timeoutheight behaviour and requirements
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-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
2020-10-06Merge #1002: BIP155: Mention SHA3-256 explicitlyWladimir J. van der Laan
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
2020-10-06bip-325: correct placement of challengeKarl-Johan Alm
2020-10-05Merge pull request #992 from Lucienest/patch-1Luke Dashjr
Update bip-0039.mediawiki
2020-10-05Merge pull request #987 from sipa/bip-taprootLuke Dashjr
Minor clarifications and fixes
2020-10-05Merge remote-tracking branch 'origin-pull/976/head'Luke Dashjr
2020-10-05Merge pull request #979 from dgenr8/patch-1Luke Dashjr
Update bip-0119.mediawiki
2020-10-05Merge pull request #997 from dergigi/patch-1Luke Dashjr
[Trivial] Fix typos
2020-10-05Merge pull request #1000 from ajtowns/202009-signet-genesisLuke Dashjr
BIP 325: update signet genesis block
2020-10-05Merge pull request #981 from apoelstra/2020-08-rename-hash-preimagesLuke Dashjr
BIP174: add `_IN_` to names of new hash preimage fields
2020-10-05Merge pull request #990 from dr-orlovsky/patch-3Luke Dashjr
BIp 174: fixing typo in rationale reference with closed tag
2020-10-05Merge pull request #978 from MarcoFalke/patch-1Luke Dashjr
BIP 325: Clarify that scriptWitness is a stack, not a byte string
2020-10-05Merge pull request #989 from dr-orlovsky/patch-2Luke Dashjr
BIP 174: rename responsibilities->roles to match Bitcoin Core
2020-10-05Merge pull request #971 from yahiheb/bip79-statusLuke Dashjr
Update bip79 status
2020-10-05Merge pull request #839 from pengpengliu/masterLuke Dashjr
BIP39: Add swift implementation
2020-10-05Merge pull request #985 from joshklop/patch-1Luke Dashjr
Fixing spelling in BIP 9
2020-10-05Merge pull request #969 from pacu/patch-1Luke Dashjr
Added MnemonicSwift as Swift impl for BIP-39
2020-10-05Merge pull request #975 from ysangkok/expire-bip-0124Luke Dashjr
Reject 124 (expired)
2020-10-05Merge pull request #974 from ysangkok/expire-bip-0135Luke Dashjr
Reject 135 (expired)
2020-10-05Merge pull request #973 from ysangkok/expire-bip-0114Luke Dashjr
Reject 114 (expired)
2020-10-01Merge pull request #967 from vasild/bip155_time_and_varintLuke Dashjr
BIP155: clarify variable integer format and change time to fixed 32 bit
2020-09-29BIP155: clarify that "services" uses CompactSizeVasil Dimov
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.
2020-09-27BIP155: Small text improvementsHennadii Stepanov
2020-09-27BIP155: Mention SHA3-256 explicitlyHennadii Stepanov
generated by cgit v1.2.3 (git 2.26.2) at 2024-07-08 04:45:49 +0000