diff options
| -rw-r--r-- | README.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0032.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0039.mediawiki | 3 | ||||
| -rw-r--r-- | bip-0141.mediawiki | 2 | ||||
| -rw-r--r-- | bip-0159.mediawiki | 22 | ||||
| -rw-r--r-- | bip-0173.mediawiki | 33 |
6 files changed, 40 insertions, 24 deletions
diff --git a/README.mediawiki b/README.mediawiki index bbdb1ba..1c1713e 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -710,7 +710,7 @@ Those proposing changes should consider that ultimately consent may rest with th |- | [[bip-0159.mediawiki|159]] | Peer Services -| NODE_NETWORK_LIMITED service bits +| NODE_NETWORK_LIMITED service bit | Jonas Schnelli | Standard | Draft diff --git a/bip-0032.mediawiki b/bip-0032.mediawiki index 6eba5f9..ab6ff9e 100644 --- a/bip-0032.mediawiki +++ b/bip-0032.mediawiki @@ -122,7 +122,7 @@ Each leaf node in the tree corresponds to an actual key, while the internal node ===Key identifiers=== -Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized ECSDA public key K, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself). +Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized ECDSA public key K, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself). The first 32 bits of the identifier are called the key fingerprint. diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki index c18d7de..add2a81 100644 --- a/bip-0039.mediawiki +++ b/bip-0039.mediawiki @@ -134,6 +134,9 @@ http://github.com/trezor/python-mnemonic ==Other Implementations== +Elixir: +* https://github.com/izelnakri/mnemonic + Objective-C: * https://github.com/nybex/NYMnemonic diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki index 7cc587a..b14daf4 100644 --- a/bip-0141.mediawiki +++ b/bip-0141.mediawiki @@ -249,7 +249,7 @@ Segregated witness fixes the problem of transaction malleability fundamentally, Two parties, Alice and Bob, may agree to send certain amount of Bitcoin to a 2-of-2 multisig output (the "funding transaction"). Without signing the funding transaction, they may create another transaction, time-locked in the future, spending the 2-of-2 multisig output to third account(s) (the "spending transaction"). Alice and Bob will sign the spending transaction and exchange the signatures. After examining the signatures, they will sign and commit the funding transaction to the blockchain. Without further action, the spending transaction will be confirmed after the lock-time and release the funding according to the original contract. It also retains the flexibility of revoking the original contract before the lock-time, by another spending transaction with shorter lock-time, but only with mutual-agreement of both parties. -Such setups is not possible with BIP62 as the malleability fix, since the spending transaction could not be created without both parties first signing the funding transaction. If Alice reveals the funding transaction signature before Bob does, Bob is able to lock up the funding indefinitely without ever signing the spending transaction. +Such setups are not possible with BIP62 as the malleability fix, since the spending transaction could not be created without both parties first signing the funding transaction. If Alice reveals the funding transaction signature before Bob does, Bob is able to lock up the funding indefinitely without ever signing the spending transaction. Unconfirmed transaction dependency chain is a fundamental building block of more sophisticated payment networks, such as duplex micropayment channel and the Lightning Network, which have the potential to greatly improve the scalability and efficiency of the Bitcoin system. diff --git a/bip-0159.mediawiki b/bip-0159.mediawiki index 2253922..79fd0fc 100644 --- a/bip-0159.mediawiki +++ b/bip-0159.mediawiki @@ -1,7 +1,7 @@ <pre> BIP: 159 Layer: Peer Services - Title: NODE_NETWORK_LIMITED service bits + Title: NODE_NETWORK_LIMITED service bit Author: Jonas Schnelli <dev@jonasschnelli.ch> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0159 @@ -13,7 +13,7 @@ == Abstract == -Define service bits that allow pruned peers to signal their limited services +Define a service bit that allow pruned peers to signal their limited services ==Motivation== @@ -21,36 +21,34 @@ Pruned peers can offer the same services as traditional peer except of serving a Bitcoin right now only offers the NODE_NETWORK service bit which indicates that a peer can serve all historical blocks. # Pruned peers can relay blocks, headers, transactions, addresses and can serve a limited number of historical blocks, thus they should have a way how to announce their service(s) -# Peers no longer in initial block download should consider connection some of its outbound connections to pruned peers to allow other peers to bootstrap from non-pruned peers +# Peers no longer in initial block download should consider connecting some of its outbound connections to pruned peers to allow other peers to bootstrap from non-pruned peers == Specification == -=== New service bits === +=== New service bit === -This BIP proposes two new service bits +This BIP proposes a new service bit {|class="wikitable" |- -| NODE_NETWORK_LIMITED_LOW || bit 10 (0x400) || If signaled, the peer <I>MUST</I> be capable of serving at least the last 288 blocks (~2 day / the current minimum limit for Bitcoin Core). -|- -| NODE_NETWORK_LIMITED_HIGH || bit 11 (0x800) || If signaled, the peer <I>MUST</i> be capable of serving at least the last 1152 blocks (~8 days) +| NODE_NETWORK_LIMITED || bit 10 (0x400) || If signaled, the peer <I>MUST</I> be capable of serving at least the last 288 blocks (~2 day / the current minimum limit for Bitcoin Core). |} -A safety buffer of additional 144 blocks to handle chain reorganizations <I>SHOULD</I> be taken into account when connecting to a peer signaling <code>NODE_NETWORK_LIMITED_*</code> service bits. +A safety buffer of additional 144 blocks to handle chain reorganizations <I>SHOULD</I> be taken into account when connecting to a peer signaling the <code>NODE_NETWORK_LIMITED</code> service bit. === Address relay === -Full nodes following this BIP <I>SHOULD</I> relay address/services (<code>addr</code> message) from peers they would connect to (including peers signaling <code>NODE_NETWORK_LIMITED_*</code>). +Full nodes following this BIP <I>SHOULD</I> relay address/services (<code>addr</code> message) from peers they would connect to (including peers signaling <code>NODE_NETWORK_LIMITED</code>). === Counter-measures for peer fingerprinting === -Peers may have different prune depths (depending on the peers configuration, disk space, etc.) which can result in a fingerprinting weakness (finding the prune depth through getdata requests). NODE_NETWORK_LIMITED supporting peers <I>SHOULD</I> avoid leaking the prune depth and therefore not serve blocks deeper then the signaled <code>NODE_NETWORK_LIMITED_*</code> thresholds. +Peers may have different prune depths (depending on the peers configuration, disk space, etc.) which can result in a fingerprinting weakness (finding the prune depth through getdata requests). NODE_NETWORK_LIMITED supporting peers <I>SHOULD</I> avoid leaking the prune depth and therefore not serve blocks deeper then the signaled <code>NODE_NETWORK_LIMITED</code> thresholds. === Risks === Pruned peers following this BIP may consume more outbound bandwidth. -Light clients (and such) who are not checking the <code>nServiceFlags</code> (service bits) from a relayed <code>addr</code>-message may unwillingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling <code>NODE_NETWORK_LIMITED_*</code> if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option. +Light clients (and such) who are not checking the <code>nServiceFlags</code> (service bits) from a relayed <code>addr</code>-message may unwillingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling <code>NODE_NETWORK_LIMITED</code> if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option. == Compatibility == diff --git a/bip-0173.mediawiki b/bip-0173.mediawiki index 425b8d7..90ed629 100644 --- a/bip-0173.mediawiki +++ b/bip-0173.mediawiki @@ -76,7 +76,7 @@ increase, but that does not matter when copy-pasting addresses.</ref> format cal A Bech32<ref>'''Why call it Bech32?''' "Bech" contains the characters BCH (the error detection algorithm used) and sounds a bit like "base".</ref> string is at most 90 characters long and consists of: -* The '''human-readable part''', which is intended to convey the type of data or anything else that is relevant for the reader. Its validity (including the used set of characters) is application specific, but restricted to ASCII characters with values in the range 33-126. +* The '''human-readable part''', which is intended to convey the type of data, or anything else that is relevant to the reader. This part MUST contain 1 to 83 US-ASCII characters, with each character having a value in the range [33-126]. HRP validity may be further restricted by specific applications. * The '''separator''', which is always "1". In case "1" is allowed inside the human-readable part, the last one in the string is the separator<ref>'''Why include a separator in addresses?''' That way the human-readable part is unambiguously separated from the data part, avoiding potential collisions with other human-readable parts that share a prefix. It also @@ -153,7 +153,7 @@ guarantees detection of '''any error affecting at most 4 characters''' and has less than a 1 in 10<sup>9</sup> chance of failing to detect more errors. More details about the properties can be found in the Checksum Design appendix. The human-readable part is processed by first -feeding the higher bits of each character's ASCII value into the +feeding the higher bits of each character's US-ASCII value into the checksum calculation followed by a zero and then the lower bits of each<ref>'''Why are the high bits of the human-readable part processed first?''' This results in the actually checksummed data being ''[high hrp] 0 [low hrp] [data]''. This means that under the assumption that errors to the human readable part only change the low 5 bits (like changing an alphabetical character into another), errors are restricted to the ''[low hrp] [data]'' @@ -182,11 +182,15 @@ to make. '''Uppercase/lowercase''' -Decoders MUST accept both uppercase and lowercase strings, but -not mixed case. The lowercase form is used when determining a character's -value for checksum purposes. For presentation, lowercase is usually -preferable, but inside QR codes uppercase SHOULD be used, as those permit -the use of +The lowercase form is used when determining a character's value for checksum purposes. + +Encoders MUST always output an all lowercase Bech32 string. +If an uppercase version of the encoding result is desired, (e.g.- for presentation purposes, or QR code use), +then an uppercasing procedure can be performed external to the encoding process. + +Decoders MUST NOT accept strings where some characters are uppercase and some are lowercase (such strings are referred to as mixed case strings). + +For presentation, lowercase is usually preferable, but inside QR codes uppercase SHOULD be used, as those permit the use of ''[http://www.thonky.com/qr-code-tutorial/alphanumeric-mode-encoding alphanumeric mode]'', which is 45% more compact than the normal ''[http://www.thonky.com/qr-code-tutorial/byte-mode-encoding byte mode]''. @@ -262,22 +266,33 @@ P2PKH addresses can be used. ===Test vectors=== -The following strings have a valid Bech32 checksum. +The following strings are valid Bech32: * <tt>A12UEL5L</tt> +* <tt>a12uel5l</tt> * <tt>an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1tt5tgs</tt> * <tt>abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw</tt> * <tt>11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqc8247j</tt> * <tt>split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w</tt> +* <tt>?1ezyfcl</tt> WARNING: During conversion to US-ASCII some encoders may set unmappable characters to a valid US-ASCII character, such as '?'. For example: + +<pre> +>>> bech32_encode('\x80'.encode('ascii', 'replace').decode('ascii'), []) +'?1ezyfcl' +</pre> -The following strings have an invalid Bech32 checksum (with reason for invalidity): +The following string are not valid Bech32 (with reason for invalidity): * 0x20 + <tt>1nwldj5</tt>: HRP character out of range * 0x7F + <tt>1axkwrx</tt>: HRP character out of range +* 0x80 + <tt>1eym55h</tt>: HRP character out of range * <tt>an84characterslonghumanreadablepartthatcontainsthenumber1andtheexcludedcharactersbio1569pvx</tt>: overall max length exceeded * <tt>pzry9x0s0muk</tt>: No separator character * <tt>1pzry9x0s0muk</tt>: Empty HRP * <tt>x1b4n0q5v</tt>: Invalid data character * <tt>li1dgmt3</tt>: Too short checksum * <tt>de1lg7wt</tt> + 0xFF: Invalid character in checksum +* <tt>A1G7SGD8</tt>: checksum calculated with uppercase form of HRP +* <tt>10a06t8</tt>: empty HRP +* <tt>1qzzfhee</tt>: empty HRP The following list gives valid segwit addresses and the scriptPubKey that they translate to in hex. |