Age | Commit message (Collapse) | Author |
|
|
|
|
|
BIP-322: switch to using tx based approach
|
|
Co-authored-by: Stepan Snigirev <stepan.snigirev@mpq.mpg.de>
Co-authored-by: Luke Dashjr <luke_github1@dashjr.org>
|
|
BIP8: clarify timeoutheight behaviour and requirements
|
|
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.
|
|
|
|
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).
|
|
|
|
bip-325: add Anthony Towns to authors and change status to Proposed
|
|
|
|
|
|
Fix typo in BIP 49
|
|
bip-325: correct placement of challenge
|
|
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
|
|
|
|
Update bip-0039.mediawiki
|
|
Minor clarifications and fixes
|
|
|
|
Update bip-0119.mediawiki
|
|
[Trivial] Fix typos
|
|
BIP 325: update signet genesis block
|
|
BIP174: add `_IN_` to names of new hash preimage fields
|
|
BIp 174: fixing typo in rationale reference with closed tag
|
|
BIP 325: Clarify that scriptWitness is a stack, not a byte string
|
|
BIP 174: rename responsibilities->roles to match Bitcoin Core
|
|
Update bip79 status
|
|
BIP39: Add swift implementation
|
|
Fixing spelling in BIP 9
|
|
Added MnemonicSwift as Swift impl for BIP-39
|
|
Reject 124 (expired)
|
|
Reject 135 (expired)
|
|
Reject 114 (expired)
|
|
BIP155: clarify variable integer format and change time to fixed 32 bit
|
|
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.
|
|
|
|
|
|
BIP155: include changes from followup discussions
|
|
|
|
werbs -> verbs
geografical -> geographical
|
|
Fixed some syntax,
|
|
Co-authored-by: MarcoFalke <falkemarco@gmail.com>
|
|
|
|
|
|
|
|
BIP 325: correct byte count for compact size
|
|
[Bitcoin Core uses "roles" instead of "responsibilities"](https://github.com/bitcoin/bitcoin/blob/master/src/psbt.h#L559) and it makes semantical sense (plus less verbose).
|
|
Also rename is_infinity to is_infinite is reference implementation,
to match the wording in BIP340.
|
|
|
|
|