mirror of
https://github.com/seigler/dash-docs
synced 2025-07-27 17:56:16 +00:00
Merge remote-tracking branch 'refs/remotes/bitcoin-dot-org/master'
This commit is contained in:
Cøbra
commit
c2befaecd2
33 changed files with 3093 additions and 2218 deletions
12
README.md
12
README.md
|
|
@ -870,3 +870,15 @@ Below the YAML front matter, enter the content of the post in Markdown
|
|||
format. Images should be placed in `img/blog/free` if they are
|
||||
MIT-licensed or `img/blog/nonfree` if they have a more restrictive
|
||||
copyright license.
|
||||
|
||||
### Developer PGP keys
|
||||
|
||||
The site hosts the PGP keys for several Bitcoin Core contributors. Here
|
||||
are some notes about updating those keys based on previous experience:
|
||||
|
||||
1. If a key is revoked, update the key with the revocation immediately.
|
||||
Anyone with commit access to the site repository may do this without
|
||||
prior review, but they should post the commit ID to an open issue or
|
||||
PR so other people can review it. After the revoked key is uploaded,
|
||||
discussion about verifying/adding a replacement key may continue at a
|
||||
slower pace.
|
||||
|
|
|
|||
|
|
@ -4,9 +4,9 @@
|
|||
|
||||
title: "Vulnerability in UPnP library used by Bitcoin Core"
|
||||
shorturl: "upnp-vulnerability"
|
||||
active: true
|
||||
banner: "WARNING: serious vulnerability in UPnP library used by Bitcoin Core (click here to read)"
|
||||
bannerclass: "alert"
|
||||
active: false
|
||||
#banner: "WARNING: serious vulnerability in UPnP library used by Bitcoin Core (click here to read)"
|
||||
#bannerclass: "alert"
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
|
|
|||
Binary file not shown.
|
|
@ -323,9 +323,9 @@ devsearches:
|
|||
- 'WalletPassphrase': "/en/developer-reference#walletpassphrase"
|
||||
- 'WalletPassphraseChange': "/en/developer-reference#walletpassphrasechange"
|
||||
|
||||
## Op codes currently implemented in Bitcoin Core master branch. After
|
||||
## Opcodes currently implemented in Bitcoin Core master branch. After
|
||||
## we document them on Bitcoin.org, these links will be updated
|
||||
"Op codes":
|
||||
"Opcodes":
|
||||
- "OP_0 (OP_FALSE)": "https://en.bitcoin.it/wiki/Script#Constants"
|
||||
- "OP_PUSHDATA1": "https://en.bitcoin.it/wiki/Script#Constants"
|
||||
- "OP_PUSHDATA2": "https://en.bitcoin.it/wiki/Script#Constants"
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ optional:
|
|||
- data carrier transactions
|
||||
|
||||
not_to_be_confused_with_capitalize_first_letter:
|
||||
- OP_RETURN (an op code used in one of the outputs in an OP_RETURN transaction)
|
||||
- OP_RETURN (an opcode used in one of the outputs in an OP_RETURN transaction)
|
||||
|
||||
links_html_or_markdown_style_capitalize_first_letter:
|
||||
- "[Null data transaction](/en/developer-guide#term-null-data) --- Bitcoin.org Developer Guide"
|
||||
|
|
|
|||
|
|
@ -4,31 +4,31 @@
|
|||
|
||||
required:
|
||||
#-------------40 characters-------------#
|
||||
title_max_40_characters_no_formatting: Op Code
|
||||
title_max_40_characters_no_formatting: Opcode
|
||||
|
||||
summary_max_255_characters_no_formatting: >
|
||||
Operation codes from the Bitcoin Script language which push data
|
||||
or perform functions within a pubkey script or signature script.
|
||||
|
||||
synonyms_shown_in_glossary_capitalize_first_letter:
|
||||
- Op code
|
||||
- Data-pushing op code
|
||||
- Non-data-pushing op code
|
||||
- Opcode
|
||||
- Data-pushing opcode
|
||||
- Non-data-pushing opcode
|
||||
|
||||
optional:
|
||||
synonyms_and_pluralizations_not_shown_in_glossary:
|
||||
- op codes
|
||||
- opcodes
|
||||
- opcode
|
||||
- opcodes
|
||||
- data-pushing op codes
|
||||
- data-pushing opcodes
|
||||
- non-data-pushing op codes
|
||||
- data-pushing opcodes
|
||||
- non-data-pushing opcodes
|
||||
- non-data-pushing opcodes
|
||||
|
||||
not_to_be_confused_with_capitalize_first_letter:
|
||||
|
||||
links_html_or_markdown_style_capitalize_first_letter:
|
||||
- "[Op codes](/en/developer-reference#op-codes) --- Bitcoin.org Developer Reference"
|
||||
- "[List of op codes](https://en.bitcoin.it/wiki/Script) --- Bitcoin Wiki"
|
||||
- "[Opcodes](/en/developer-reference#opcodes) --- Bitcoin.org Developer Reference"
|
||||
- "[List of opcodes](https://en.bitcoin.it/wiki/Script) --- Bitcoin Wiki"
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ optional:
|
|||
not_to_be_confused_with_capitalize_first_letter:
|
||||
- P2PK output (an output paying a public key directly)
|
||||
- P2PKH address, P2PKH output (an address comprising a hashed pubkey, and its corresponding output)
|
||||
- P2SH multisig (a particular instance of P2SH where the script uses a multisig op code)
|
||||
- P2SH multisig (a particular instance of P2SH where the script uses a multisig opcode)
|
||||
|
||||
links_html_or_markdown_style_capitalize_first_letter:
|
||||
- "[P2SH](/en/developer-guide#term-p2sh) --- Bitcoin.org Developer Guide"
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ required:
|
|||
|
||||
summary_max_255_characters_no_formatting: >
|
||||
A P2SH output where the redeem script uses one of the multisig
|
||||
op codes. Up until Bitcoin Core 0.10.0, P2SH multisig scripts
|
||||
opcodes. Up until Bitcoin Core 0.10.0, P2SH multisig scripts
|
||||
were standard transactions, but most other P2SH scripts were
|
||||
not.
|
||||
|
||||
|
|
|
|||
246
_events.yml
246
_events.yml
|
|
@ -1,210 +1,18 @@
|
|||
- date: 2015-09-02
|
||||
title: "Bitcoin Wednesday Conference"
|
||||
venue: "De Balie"
|
||||
address: "Leidseplein, Kleine-Gartmanplantsoen 10"
|
||||
city: "Amsterdam"
|
||||
country: "The Netherlands"
|
||||
link: "http://www.bitcoinwednesday.com/event/bitcoin-wednesday-27/"
|
||||
|
||||
- date: 2015-09-10
|
||||
title: "Consensus 2015"
|
||||
venue: "TimesCenter"
|
||||
address: "242 W 41st St"
|
||||
- date: 2015-11-12
|
||||
title: "The Future of Money: Cashing out on Cash"
|
||||
venue: "Thomson Reuters"
|
||||
address: "3 Times Square"
|
||||
city: "New York"
|
||||
country: "United States"
|
||||
link: "http://www.coindesk.com/events/consensus-2015/"
|
||||
|
||||
- date: 2015-09-12
|
||||
title: "Bitcoinference Summer 2015"
|
||||
venue: "Amsterdam Science Park"
|
||||
address: "Science Park 205, 1098 XH"
|
||||
city: "Amsterdam"
|
||||
country: "Netherlands"
|
||||
link: "http://bitcoinference.com/"
|
||||
|
||||
- date: 2015-09-12
|
||||
title: "Scaling Bitcoin Conference"
|
||||
venue: "Centre Mont-Royal"
|
||||
address: "2200 rue Mansfield Montréal Québec, H3A 3R8"
|
||||
city: "Montreal"
|
||||
country: "Canada"
|
||||
link: "https://scalingbitcoin.org/montreal2015/"
|
||||
|
||||
- date: 2015-09-12
|
||||
title: "Blockstack Summit 2015"
|
||||
venue: "D'Agostino Hall, New York University"
|
||||
address: "108 W 3rd St"
|
||||
city: "New York"
|
||||
country: "United States"
|
||||
link: "http://blockstack.org/summit"
|
||||
|
||||
- date: 2015-09-15
|
||||
title: "NYC Fintech eXtravaganza"
|
||||
venue: "Microsoft Technology Center"
|
||||
address: "640 8th Ave"
|
||||
city: "New York"
|
||||
country: "United States"
|
||||
link: "http://www.eventbrite.com/e/nyc-fintech-extravaganza-fintechx-tickets-17816557804"
|
||||
|
||||
- date: 2015-09-16
|
||||
title: "Finovate New York 2015"
|
||||
venue: "New York Hilton Midtown"
|
||||
address: "1335 Avenue of the Americas"
|
||||
city: "New York"
|
||||
country: "United States"
|
||||
link: "http://fall2015.finovate.com/"
|
||||
|
||||
- date: 2015-09-18
|
||||
title: "Bitcoin Thrill Day 2015"
|
||||
venue: "Walibi Holland"
|
||||
address: "SPIJKWEG 30"
|
||||
city: "Biddinghuizen"
|
||||
country: "The Netherlands"
|
||||
link: "https://thrilldays.bitcoinembassy.nl/"
|
||||
|
||||
- date: 2015-09-18
|
||||
title: "Blockchain@Birmingham"
|
||||
venue: "Learning Center LG14@ University of Birmingham"
|
||||
address: "Edgbaston, Birmingham, WestMidlands, UK"
|
||||
city: "Birmingham"
|
||||
country: "United Kingdom"
|
||||
link: "https://blockchainbirmingham.wordpress.com"
|
||||
|
||||
- date: 2015-09-23
|
||||
title: "Finance 2.0: Crypto"
|
||||
venue: "EWZ-Unterwerk Selnau"
|
||||
address: "Selnaustreet 25"
|
||||
city: "Zurich"
|
||||
country: "Switzerland"
|
||||
link: "http://www.finance20.ch/crypto2015/"
|
||||
|
||||
- date: 2015-09-24
|
||||
title: "Bitcoin Conference Kiev"
|
||||
venue: "NSC Olimpiyskiy"
|
||||
address: "Velyka Vasylkivska str., 55"
|
||||
city: "Kyiv"
|
||||
country: "Ukraine"
|
||||
link: "http://bitcoinconf.com.ua/en"
|
||||
|
||||
- date: 2015-09-28
|
||||
title: "Bitcoin and Blockchain Regulation"
|
||||
venue: "The London Escalator"
|
||||
address: "69-89 Mile End Rd"
|
||||
city: "London"
|
||||
country: "United Kingdom"
|
||||
link: "http://bblf.info/"
|
||||
|
||||
- date: 2015-10-02
|
||||
title: "Digital Economy Conference"
|
||||
venue: "Holland Performing Arts Center"
|
||||
address: "1200 Douglas Street"
|
||||
city: "Omaha"
|
||||
country: "United States"
|
||||
link: "http://digitaleconomy.io/"
|
||||
|
||||
- date: 2015-10-02
|
||||
title: "Hacker Congress"
|
||||
venue: "Paralelni Polis"
|
||||
address: "Delnicka 43"
|
||||
city: "Prague"
|
||||
country: "Czech Republic"
|
||||
link: "http://www.hcpp.cz/eng/"
|
||||
|
||||
- date: 2015-10-06
|
||||
title: "Fintech: Law and Disruption"
|
||||
venue: "New York Law School Events Center"
|
||||
address: "185 West Broadway"
|
||||
city: "New York"
|
||||
country: "United States"
|
||||
link: "http://www.nyls.edu/center-for-business-and-financial-law/cbfl_events/conferences/"
|
||||
|
||||
- date: 2015-10-06
|
||||
title: "Blockchain Conference New York"
|
||||
venue: "Barclays Accelerator"
|
||||
address: "43 West 23rd Street"
|
||||
city: "New York"
|
||||
country: "United States"
|
||||
link: "http://www.blockchain-newyork.com/"
|
||||
|
||||
- date: 2015-10-07
|
||||
title: "Bitcoin Wednesday Conference"
|
||||
venue: "De Balie"
|
||||
address: "Leidseplein, Kleine-Gartmanplantsoen 10"
|
||||
city: "Amsterdam"
|
||||
country: "The Netherlands"
|
||||
link: "http://www.bitcoinwednesday.com/event/bitcoin-wednesday-28/"
|
||||
|
||||
- date: 2015-10-08
|
||||
title: "Alt Convention"
|
||||
venue: "Hilton Batumi, Radisson Blu Batumi, Sheraton Batumi, Divan Suites, Leogrand"
|
||||
address:
|
||||
city: "Batumi"
|
||||
country: "Georgia"
|
||||
link: "http://altconvention.com"
|
||||
|
||||
- date: 2015-10-16
|
||||
title: "DevCore Workshop: Developing the Developers"
|
||||
venue: "Draper University"
|
||||
address: "44 E Third Ave"
|
||||
city: "San Mateo, CA"
|
||||
country: "USA"
|
||||
link: "http://bitcoinfoundation.org"
|
||||
link: "http://rsvp.thomsonreuters.com/node/839"
|
||||
|
||||
- date: 2015-10-21
|
||||
title: "Fintech Jersey 2015"
|
||||
venue: "Radisson Blu Waterfront Hotel"
|
||||
address: "Rue de L'etau JE2 3WF"
|
||||
city: "St. Helier"
|
||||
country: "United Kingdom"
|
||||
link: "http://www.eventbrite.co.uk/e/fintechjersey-2015-tickets-18417288606?aff=es2"
|
||||
|
||||
- date: 2015-10-25
|
||||
title: "Money 20/20"
|
||||
venue: "The Venetian Las Vegas"
|
||||
address: "3355 Las Vegas Blvd. South"
|
||||
city: "Las Vegas"
|
||||
country: "United States"
|
||||
link: "http://www.money2020.com"
|
||||
|
||||
- date: 2015-11-03
|
||||
title: "BL0CKCHA1N: The Blockchain Forum"
|
||||
venue: "Novotel Paris Centre Tour Eiffel"
|
||||
address: "61 quai de Grenelle, 75015"
|
||||
city: "Paris"
|
||||
country: "France"
|
||||
link: "http://www.bl0ckcha1n.com"
|
||||
|
||||
- date: 2015-11-04
|
||||
title: "Bitcoin Wednesday Conference"
|
||||
venue: "De Balie"
|
||||
address: "Leidseplein, Kleine-Gartmanplantsoen 10"
|
||||
city: "Amsterdam"
|
||||
country: "The Netherlands"
|
||||
link: "http://www.bitcoinwednesday.com/event/bitcoin-wednesday-29/"
|
||||
|
||||
- date: 2015-11-09
|
||||
title: "MTBIT - Bitcoin & Remittances Miami Beach"
|
||||
venue: "Eden Roc Hotel"
|
||||
address: "4525 Collins Avenue"
|
||||
city: "Miami Beach"
|
||||
country: "United States"
|
||||
link: "http://www.imtconferences.com/mtbit/"
|
||||
|
||||
- date: 2015-11-10
|
||||
title: "Bank Innovation Israel"
|
||||
venue: "Dan Tel Aviv"
|
||||
address: "Ha-Yarkon St 99"
|
||||
city: "Tel Aviv-Yafo"
|
||||
country: "Israel"
|
||||
link: "http://bankinnovationisrael.com/"
|
||||
|
||||
- date: 2015-11-10
|
||||
title: "Fintech Startups Conference"
|
||||
venue: "Great American Music Hall"
|
||||
address: "859 O'Farrell St"
|
||||
city: "San Francisco"
|
||||
country: "United States"
|
||||
link: "http://www.fintechstartupsconference.com/sftickets"
|
||||
- date: 2015-11-20
|
||||
title: "Practical workshop"
|
||||
venue: "Las Naves"
|
||||
address: "Joan Verdeguer 16"
|
||||
city: "Valencia"
|
||||
country: "Spain"
|
||||
link: "http://avalbit.org/actividades/taller-practico-bitcoin/"
|
||||
|
||||
- date: 2015-11-24
|
||||
title: "ADCCA Fintech Summit"
|
||||
|
|
@ -214,6 +22,14 @@
|
|||
country: "Australia"
|
||||
link: "http://www.adccasummit.com/"
|
||||
|
||||
- date: 2015-12-03
|
||||
title: "Moneylab#2 Economies of Dissent"
|
||||
venue: "Pakhuis De Zwijger"
|
||||
address: "Piet Heinkade 179"
|
||||
city: "1019 HC Amsterdam"
|
||||
country: "The Netherlands"
|
||||
link: "http://networkcultures.org/moneylab/"
|
||||
|
||||
- date: 2015-12-02
|
||||
title: "Bitcoin Wednesday Conference"
|
||||
venue: "De Balie"
|
||||
|
|
@ -222,6 +38,14 @@
|
|||
country: "The Netherlands"
|
||||
link: "http://www.bitcoinwednesday.com/event/bitcoin-wednesday-30/"
|
||||
|
||||
- date: 2015-12-04
|
||||
title: "laBITconf 2015: Latin American Bitcoin Conference"
|
||||
venue: "EBC Campus Dinamarca"
|
||||
address: "Dinamarca 32, Col. Juarez, Del. Cuauhtemoc"
|
||||
city: "Mexico D.F."
|
||||
country: "Mexico"
|
||||
link: "http://www.labitconf.com/"
|
||||
|
||||
- date: 2015-12-06
|
||||
title: "Scaling Bitcoin: Phase 2"
|
||||
venue: "Hong Kong Cyberport"
|
||||
|
|
@ -230,6 +54,14 @@
|
|||
country: "China"
|
||||
link: "https://scalingbitcoin.org/hongkong2015/"
|
||||
|
||||
- date: 2015-12-08
|
||||
title: "Santa Claus Bitcurex Bitcoin Event"
|
||||
venue: "Centrum Golf"
|
||||
address: "Burakowska 15"
|
||||
city: "Warsaw"
|
||||
country: "Poland"
|
||||
link: "https://www.facebook.com/events/979552578733820/"
|
||||
|
||||
- date: 2015-12-09
|
||||
title: "Inside Bitcoins Seoul"
|
||||
venue: "Korea International Exhibition Center (KINTEX)"
|
||||
|
|
@ -246,10 +78,10 @@
|
|||
country: "United States"
|
||||
link: "http://insidebitcoins.com/san-diego/2015?utm_source=bitcoinorg&utm_medium=eventlisting&utm_campaign=bitcoinorgeventlistingibsd"
|
||||
|
||||
- date: 2016-01-25
|
||||
- date: 2016-01-21
|
||||
title: "The North American Bitcoin Conference"
|
||||
venue: "Miami Design District"
|
||||
address: "NW 36th Street"
|
||||
venue: "James L Knight Center"
|
||||
address: "400 SE 2nd Ave"
|
||||
city: "Miami, Florida"
|
||||
country: "United States of America"
|
||||
link: "http://www.btcmiami.com"
|
||||
|
|
|
|||
|
|
@ -12,23 +12,23 @@ http://opensource.org/licenses/MIT.
|
|||
|
||||
{% autocrossref %}
|
||||
|
||||
Bitcoin Core RPCs accept and return hashes in the reverse of their
|
||||
normal byte order. For example, the Unix `sha256sum` command would display the
|
||||
SHA256(SHA256()) hash of mainnet block 300,000's header as the
|
||||
following string:
|
||||
Bitcoin Core RPCs accept and return the byte-wise reverse of computed
|
||||
SHA-256 hash values. For example, the Unix `sha256sum` command displays the
|
||||
SHA256(SHA256()) hash of mainnet block 300,000's header as:
|
||||
|
||||
> /bin/echo -n '020000007ef055e1674d2e6551dba41cd214debbee34aeb544c7ec670000000000000000d3998963f80c5bab43fe8c26228e98d030edf4dcbe48a666f5c39e2d7a885c9102c86d536c890019593a470d' | xxd -r -p | sha256sum -b | xxd -r -p | sha256sum -b
|
||||
5472ac8b1187bfcf91d6d218bbda1eb2405d7c55f1f8cc820000000000000000
|
||||
|
||||
The string above is also how the hash appears in the
|
||||
The result above is also how the hash appears in the
|
||||
previous-header-hash part of block 300,001's header:
|
||||
|
||||
<pre>02000000<b>5472ac8b1187bfcf91d6d218bbda1eb2405d7c55f1f8cc82000\
|
||||
0000000000000</b>ab0aaa377ca3f49b1545e2ae6b0667a08f42e72d8c24ae\
|
||||
237140e28f14f3bb7c6bcc6d536c890019edd83ccf</pre>
|
||||
|
||||
However Bitcoin RPCs use the reverse byte order for hashes, so if you
|
||||
However, Bitcoin Core's RPCs use the byte-wise reverse for hashes, so if you
|
||||
want to get information about block 300,000 using the `getblock` RPC,
|
||||
you need to reverse the byte order:
|
||||
you need to reverse the requested hash:
|
||||
|
||||
> bitcoin-cli getblock \
|
||||
000000000000000082ccf8f1557c5d40b21edabb18d2d691cfbf87118bac7254
|
||||
|
|
@ -36,27 +36,20 @@ you need to reverse the byte order:
|
|||
(Note: hex representation uses two characters to display each byte of
|
||||
data, which is why the reversed string looks somewhat mangled.)
|
||||
|
||||
The rational for the reversal is unknown, but it likely stems from
|
||||
Bitcoin's use of hash digests (which are byte arrays in C++) as integers
|
||||
The rationale for the reversal is unknown, but it likely stems from
|
||||
Bitcoin Core's use of hashes (which are byte arrays in C++) as integers
|
||||
for the purpose of determining whether the hash is below the network
|
||||
target. Whatever the reason for reversing header hashes, the reversal
|
||||
also extends to other hashes used in RPCs, such as TXIDs and merkle
|
||||
roots.
|
||||
|
||||
Off-site documentation such as the Bitcoin Wiki tends to use the terms
|
||||
big endian and little endian as shown in the table below, but they
|
||||
aren't always consistent. Worse, these two different ways of
|
||||
representing a hash digest can confuse anyone who looks at the Bitcoin
|
||||
Core source code and finds a so-called "big endian" value being stored
|
||||
in a little-endian data type.
|
||||
|
||||
As header hashes and TXIDs are widely used as global identifiers in
|
||||
other Bitcoin software, this reversal of hashes has become the standard
|
||||
way to refer to certain objects. The table below should make clear where
|
||||
each byte order is used.
|
||||
|
||||
|---------------+---------------------|-----------------|
|
||||
| Data | Internal Byte Order ("Big Endian") | RPC Byte Order ("Little Endian") |
|
||||
| Data | Internal Byte Order | RPC Byte Order |
|
||||
|---------------|---------------------|-----------------|
|
||||
| Example: SHA256(SHA256(0x00)) | Hash: 1406...539a | Hash: 9a53...0614 |
|
||||
|---------------|---------------------|-----------------|
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ The `decodescript` RPC {{summary_decodeScript}}
|
|||
- n: "→<br>`asm`"
|
||||
t: "string"
|
||||
p: "Required<br>(exactly 1)"
|
||||
d: "The redeem script in decoded form with non-data-pushing op codes listed. May be empty"
|
||||
d: "The redeem script in decoded form with non-data-pushing opcodes listed. May be empty"
|
||||
|
||||
- n: "→<br>`type`"
|
||||
t: "string"
|
||||
|
|
|
|||
|
|
@ -118,8 +118,8 @@ The `getblock` RPC {{summary_getBlock}}
|
|||
|
||||
- n: "→<br>`previousblockhash`"
|
||||
t: "string (hex)"
|
||||
p: "Required<br>(exactly 1)"
|
||||
d: "The hash of the header of the previous block, encoded as hex in RPC byte order"
|
||||
p: "Optional<br>(0 or 1)"
|
||||
d: "The hash of the header of the previous block, encoded as hex in RPC byte order. Not returned for genesis block"
|
||||
|
||||
- n: "→<br>`nextblockhash`"
|
||||
t: "string (hex)"
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ The `gettxout` RPC {{summary_getTxOut}}
|
|||
- n: "→ →<br>`asm`"
|
||||
t: "string"
|
||||
p: "Required<br>(exactly 1)"
|
||||
d: "The pubkey script in decoded form with non-data-pushing op codes listed"
|
||||
d: "The pubkey script in decoded form with non-data-pushing opcodes listed"
|
||||
|
||||
- n: "→ →<br>`hex`"
|
||||
t: "string (hex)"
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ OP_2 [A's pubkey] [B's pubkey] [C's pubkey] OP_3 OP_CHECKMULTISIG
|
|||
|
||||
{% autocrossref %}
|
||||
|
||||
(Op codes to push the public keys onto the stack are not shown.)
|
||||
(Opcodes to push the public keys onto the stack are not shown.)
|
||||
|
||||
`OP_2` and `OP_3` push the actual numbers 2 and 3 onto the
|
||||
stack. `OP_2`
|
||||
|
|
@ -100,7 +100,7 @@ OP_0 [A's signature] [B's or C's signature] [serialized redeem script]
|
|||
|
||||
{% autocrossref %}
|
||||
|
||||
(Op codes to push the signatures and redeem script onto the stack are
|
||||
(Opcodes to push the signatures and redeem script onto the stack are
|
||||
not shown. `OP_0` is a workaround for an off-by-one error in the original
|
||||
implementation which must be preserved for compatibility. Note that
|
||||
the signature script must provide signatures in the same order as the
|
||||
|
|
|
|||
|
|
@ -369,7 +369,7 @@ can be used to require multiple signatures before a UTXO can be spent.
|
|||
|
||||
In multisig pubkey scripts, called m-of-n, *m* is the *minimum* number of signatures
|
||||
which must match a public key; *n* is the *number* of public keys being
|
||||
provided. Both *m* and *n* should be op codes `OP_1` through `OP_16`,
|
||||
provided. Both *m* and *n* should be opcodes `OP_1` through `OP_16`,
|
||||
corresponding to the number desired.
|
||||
|
||||
Because of an off-by-one error in the original Bitcoin implementation
|
||||
|
|
@ -454,7 +454,7 @@ in a P2SH output, the network sees only the hash, so it will accept the
|
|||
output as valid no matter what the redeem script says.
|
||||
This allows payment to non-standard scripts, and as of Bitcoin Core
|
||||
0.11, almost all valid redeem scripts can be spent. The exception is
|
||||
scripts that use unassigned [NOP op codes][]; these op codes are
|
||||
scripts that use unassigned [NOP opcodes][]; these opcodes are
|
||||
reserved for future soft forks and can only be relayed or mined by nodes
|
||||
that don't follow the standard mempool policy.
|
||||
|
||||
|
|
@ -481,8 +481,8 @@ conditions:
|
|||
currently non-standard.
|
||||
|
||||
* The transaction's signature script must only push data to the script
|
||||
evaluation stack. It cannot push new OP codes, with the exception of
|
||||
OP codes which solely push data to the stack.
|
||||
evaluation stack. It cannot push new opcodes, with the exception of
|
||||
opcodes which solely push data to the stack.
|
||||
|
||||
* The transaction must not include any outputs which receive fewer than
|
||||
1/3 as many satoshis as it would take to spend it in a typical input.
|
||||
|
|
|
|||
|
|
@ -343,7 +343,7 @@ Curve (EC) defined in secp256k1. In their traditional uncompressed form,
|
|||
public keys contain an identification byte, a 32-byte X coordinate, and
|
||||
a 32-byte Y coordinate. The extremely simplified illustration below
|
||||
shows such a point on the elliptic curve used by Bitcoin,
|
||||
x<sup>2</sup> = y<sup>3</sup> + 7, over a field of
|
||||
y<sup>2</sup> = x<sup>3</sup> + 7, over a field of
|
||||
contiguous numbers.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -65,25 +65,28 @@ fe9f0864 ........................... Nonce
|
|||
<!-- source for heights: my (@harding) own headers dump and counting
|
||||
script -->
|
||||
|
||||
* **Version 3** blocks will be introduced when sufficient numbers of
|
||||
miners switch to using Bitcoin Core 0.10.0 and other versions that
|
||||
create version 3 blocks. As described in draft BIP66, this soft fork
|
||||
change requires strict DER encoding for all ECDSA signatures used in
|
||||
transactions appearing in version 3 or later blocks. Transactions that
|
||||
do not use strict DER encoding have been non-standard since Bitcoin
|
||||
Core 0.8.0.
|
||||
* **Version 3** blocks were introduced in Bitcoin Core 0.10.0 (February
|
||||
2015) as a soft fork. When the fork reach full enforcement (July
|
||||
2015), it required strict DER encoding of all ECDSA signatures in new
|
||||
blocks as described in BIP66. Transactions that do not use strict DER
|
||||
encoding had previously been non-standard since Bitcoin Core 0.8.0
|
||||
(February 2012).
|
||||
|
||||
* **Version 4** blocks will likely be introduced in the near-future as
|
||||
specified in draft BIP62. Possible changes include:
|
||||
* **Version 4** blocks will likely be introduced in the near future as
|
||||
specified in BIP65. These blocks will support the new
|
||||
`OP_CHECKLOCKTIMEVERIFY` opcode described in that BIP.
|
||||
|
||||
* Reject version 4 blocks that include any version 2 transactions
|
||||
that don't adhere to any of the version 2 transaction rules.
|
||||
These rules are not yet described in this documentation; see
|
||||
BIP62 for details.
|
||||
The mechanism used for the version 2, 3, and 4 upgrades is commonly
|
||||
called IsSuperMajority() after the function added to Bitcoin Core to
|
||||
manage those soft forking changes. See BIP34 for a full description of
|
||||
this method.
|
||||
|
||||
* A soft fork rollout of version 4 blocks identical to the rollout
|
||||
used for version 3 blocks (described briefly in BIP62 and in more
|
||||
detail in BIP34).
|
||||
As of this writing, a newer method called *version bits* is being designed
|
||||
to manage future soft forking changes, although it's not known whether
|
||||
version 4 will be the last soft fork to use the IsSuperMajority()
|
||||
function. Draft BIP9 describes the version bits design as of this
|
||||
writing, although it is still being actively edited and may
|
||||
substantially change while in the draft state.
|
||||
|
||||
{% endautocrossref %}
|
||||
|
||||
|
|
|
|||
|
|
@ -1003,12 +1003,12 @@ example, TXIDs will be in internal byte order).
|
|||
section is individually compared to the filter.
|
||||
|
||||
* **Signature Script Data:** each element pushed onto the stack by a
|
||||
data-pushing op code in a signature script from this transaction is
|
||||
data-pushing opcode in a signature script from this transaction is
|
||||
individually compared to the filter. This includes data elements
|
||||
present in P2SH redeem scripts when they are being spent.
|
||||
|
||||
* **PubKey Script Data:** each element pushed onto the the stack by a
|
||||
data-pushing op code in any pubkey script from this transaction is
|
||||
data-pushing opcode in any pubkey script from this transaction is
|
||||
individually compared to the filter. (If a pubkey script element
|
||||
matches the filter, the filter will be immediately updated if the
|
||||
`BLOOM_UPDATE_ALL` flag was set; if the pubkey script is in the P2PKH
|
||||
|
|
|
|||
|
|
@ -9,14 +9,14 @@ http://opensource.org/licenses/MIT.
|
|||
|
||||
The following subsections briefly document core transaction details.
|
||||
|
||||
#### OP Codes
|
||||
#### OpCodes
|
||||
{% include helpers/subhead-links.md %}
|
||||
|
||||
{% autocrossref %}
|
||||
|
||||
The op codes used in the pubkey scripts of standard transactions are:
|
||||
The opcodes used in the pubkey scripts of standard transactions are:
|
||||
|
||||
* Various data pushing op codes from 0x00 to 0x4e (1--78). These aren't
|
||||
* Various data pushing opcodes from 0x00 to 0x4e (1--78). These aren't
|
||||
typically shown in examples, but they must be used to push
|
||||
signatures and public keys onto the stack. See the link below this list
|
||||
for a description.
|
||||
|
|
@ -67,18 +67,18 @@ The op codes used in the pubkey scripts of standard transactions are:
|
|||
|
||||
* [`OP_RETURN`][op_return]{:#term-op-return}{:.term} terminates the script in failure when executed.
|
||||
|
||||
A complete list of OP codes can be found on the Bitcoin Wiki [Script
|
||||
A complete list of opcodes can be found on the Bitcoin Wiki [Script
|
||||
Page][wiki script], with an authoritative list in the `opcodetype` enum
|
||||
of the Bitcoin Core [script header file][core script.h]
|
||||
|
||||
|
||||
**<span id="signature_script_modification_warning">Signature script modification warning</span>:**
|
||||
Signature scripts are not signed, so anyone can modify them. This
|
||||
means signature scripts should only contain data and data-pushing op
|
||||
codes which can't be modified without causing the pubkey script to fail.
|
||||
Placing non-data-pushing op codes in the signature script currently
|
||||
means signature scripts should only contain data and data-pushing opcodes
|
||||
which can't be modified without causing the pubkey script to fail.
|
||||
Placing non-data-pushing opcodes in the signature script currently
|
||||
makes a transaction non-standard, and future consensus rules may forbid
|
||||
such transactions altogether. (Non-data-pushing op codes are already
|
||||
such transactions altogether. (Non-data-pushing opcodes are already
|
||||
forbidden in signature scripts when spending a P2SH pubkey script.)
|
||||
|
||||
|
||||
|
|
@ -341,7 +341,7 @@ has the following format.
|
|||
| 32 | hash (null) | char[32] | A 32-byte null, as a coinbase has no previous outpoint.
|
||||
| 4 | index (UINT32_MAX) | uint32_t | 0xffffffff, as a coinbase has no previous outpoint.
|
||||
| *Varies* | script bytes | compactSize uint | The number of bytes in the coinbase script, up to a maximum of 100 bytes.
|
||||
| *Varies* (4) | height | script | The [block height][/en/glossary/coinbase]{:#term-coinbase-block-height}{:.term} of this block as required by BIP34. Uses script language: starts with a data-pushing op code that indicates how many bytes to push to the stack followed by the block height as a little-endian unsigned integer. This script must be as short as possible, otherwise it may be rejected.<br/><br/> The data-pushing op code will be 0x03 and the total size four bytes until block 16,777,216 about 300 years from now.
|
||||
| *Varies* (4) | height | script | The [block height][/en/glossary/coinbase]{:#term-coinbase-block-height}{:.term} of this block as required by BIP34. Uses script language: starts with a data-pushing opcode that indicates how many bytes to push to the stack followed by the block height as a little-endian unsigned integer. This script must be as short as possible, otherwise it may be rejected.<br/><br/> The data-pushing opcode will be 0x03 and the total size four bytes until block 16,777,216 about 300 years from now.
|
||||
| *Varies* | coinbase script | *None* | The [coinbase field][/en/glossary/coinbase]{:#term-coinbase-field}{:.term}: Arbitrary data not exceeding 100 bytes minus the (4) height bytes. Miners commonly place an extra nonce in this field to update the block header merkle root during hashing.
|
||||
| 4 | sequence | uint32_t | Sequence number.
|
||||
|
||||
|
|
|
|||
|
|
@ -164,7 +164,7 @@ bitcoins even if this parameter is set to `1` or higher.{% endcapture %}
|
|||
- n: "{{DEPTH}} → → → →<br>`asm`"
|
||||
t: "string"
|
||||
p: "Required<br>(exactly 1)"
|
||||
d: "The signature script in decoded form with non-data-pushing op codes listed"
|
||||
d: "The signature script in decoded form with non-data-pushing opcodes listed"
|
||||
|
||||
- n: "{{DEPTH}} → → → →<br>`hex`"
|
||||
t: "string (hex)"
|
||||
|
|
@ -209,7 +209,7 @@ bitcoins even if this parameter is set to `1` or higher.{% endcapture %}
|
|||
- n: "{{DEPTH}} → → → →<br>`asm`"
|
||||
t: "string"
|
||||
p: "Required<br>(exactly 1)"
|
||||
d: "The pubkey script in decoded form with non-data-pushing op codes listed"
|
||||
d: "The pubkey script in decoded form with non-data-pushing opcodes listed"
|
||||
|
||||
- n: "{{DEPTH}} → → → →<br>`hex`"
|
||||
t: "string (hex)"
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ http://opensource.org/licenses/MIT.
|
|||
[bitcoin URI]: /en/developer-guide#term-bitcoin-uri "A URI which allows receivers to encode payment details so spenders don't have to manually enter addresses and other details"
|
||||
[certificate chain]: /en/developer-examples#term-certificate-chain "A chain of certificates connecting a individual's leaf certificate to the certificate authority's root certificate"
|
||||
[coinbase block height]: /en/developer-reference#term-coinbase-block-height "The current block's height encoded into the first bytes of the coinbase field"
|
||||
[data-pushing op code]: https://en.bitcoin.it/wiki/Script#Constants "Any op code from 0x01 to 0x4e which pushes data on to the script evaluation stack"
|
||||
[data-pushing opcode]: https://en.bitcoin.it/wiki/Script#Constants "Any opcode from 0x01 to 0x4e which pushes data on to the script evaluation stack"
|
||||
[fiat]: /en/developer-guide#term-fiat "National currencies such as the dollar or euro"
|
||||
[intermediate certificate]: /en/developer-examples#term-intermediate-certificate "A intermediate certificate authority certificate which helps connect a leaf (receiver) certificate to a root certificate authority"
|
||||
[key index]: /en/developer-guide#term-key-index "An index number used in the HD wallet formula to generate child keys from a parent key"
|
||||
|
|
@ -21,8 +21,8 @@ http://opensource.org/licenses/MIT.
|
|||
[msg_block]: /en/developer-reference#term-msg_block "The block header hash data type identifier of an inventory on the P2P network"
|
||||
[msg_filtered_block]: /en/developer-reference#term-msg_block "An alternative to the block header hash data type identifier of an inventory on the P2P network used to request a merkle block"
|
||||
[network]: /en/developer-guide#term-network "The Bitcoin P2P network which broadcasts transactions and blocks"
|
||||
[op_checkmultisig]: /en/developer-reference#term-op-checkmultisig "Op code which returns true if one or more provided signatures (m) sign the correct parts of a transaction and match one or more provided public keys (n)"
|
||||
[op_checksig]: /en/developer-reference#term-op-checksig "Op code which returns true if a signature signs the correct parts of a transaction and matches a provided public key"
|
||||
[op_checkmultisig]: /en/developer-reference#term-op-checkmultisig "Opcode which returns true if one or more provided signatures (m) sign the correct parts of a transaction and match one or more provided public keys (n)"
|
||||
[op_checksig]: /en/developer-reference#term-op-checksig "Opcode which returns true if a signature signs the correct parts of a transaction and matches a provided public key"
|
||||
[op_dup]: /en/developer-reference#term-op-dup "Operation which duplicates the entry below it on the stack"
|
||||
[op_equal]: /en/developer-reference#term-op-equal "Operation which returns true if the two entries below it on the stack are equivalent"
|
||||
[op_equalverify]: /en/developer-reference#term-op-equalverify "Operation which terminates the script in failure unless the two entries below it on the stack are equivalent"
|
||||
|
|
@ -376,7 +376,7 @@ http://opensource.org/licenses/MIT.
|
|||
[mozrootstore]: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
|
||||
[native irc client]: https://en.wikipedia.org/wiki/List_of_IRC_clients
|
||||
[netcat]: https://en.wikipedia.org/wiki/Netcat
|
||||
[nop op codes]: https://en.bitcoin.it/wiki/Script#Reserved_words
|
||||
[nop opcodes]: https://en.bitcoin.it/wiki/Script#Reserved_words
|
||||
[offline transactions]: http://bitcoin.stackexchange.com/a/34122/21052
|
||||
[open a pull request]: https://github.com/bitcoin-dot-org/bitcoin.org#working-with-github
|
||||
[open an issue]: https://github.com/bitcoin-dot-org/bitcoin.org/issues/new
|
||||
|
|
|
|||
|
|
@ -412,8 +412,8 @@ following three major goals during the next quarter:
|
|||
providing definitions for the over 150 specialized terms and
|
||||
synonyms used in Bitcoin development
|
||||
|
||||
* Documentation for at least the most common op codes, and possibly
|
||||
all the enabled op codes. This section will be essentially a more
|
||||
* Documentation for at least the most common opcodes, and possibly
|
||||
all the enabled opcodes. This section will be essentially a more
|
||||
detailed version of the [Bitcoin Wiki script
|
||||
page](https://en.bitcoin.it/wiki/Script)
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Bitcoin Foundation][], we've added two major new features to the
|
|||
A new [glossary section][] has been added to the Bitcoin.org Developer
|
||||
Documentation, and with it comes a fully-Javascript search engine that
|
||||
helps you look up glossary entries, Bitcoin Core RPCs, Bitcoin BIPs,
|
||||
Script-language op codes, and Bitcoin P2P protocol messages.
|
||||
Script-language opcodes, and Bitcoin P2P protocol messages.
|
||||
|
||||
## Developer glossary main page
|
||||
|
||||
|
|
@ -69,7 +69,7 @@ they appear in the search:
|
|||
|
||||
* Glossary entries (Bitcoin.org)
|
||||
* RPCs (Bitcoin.org)
|
||||
* Op codes (Bitcoin Wiki)
|
||||
* Opcodes (Bitcoin Wiki)
|
||||
* BIPs (just notable and non-withdrawn BIPs; GitHub.com BIPs repo)
|
||||
* Bitcoin P2P protocol messages (Bitcoin.org)
|
||||
|
||||
|
|
|
|||
195
_releases/0.10.3.md
Normal file
195
_releases/0.10.3.md
Normal file
|
|
@ -0,0 +1,195 @@
|
|||
---
|
||||
# This file is licensed under the MIT License (MIT) available on
|
||||
# http://opensource.org/licenses/MIT.
|
||||
|
||||
## Required value below populates the %v variable (note: % needs to be escaped in YAML if it starts a value)
|
||||
required_version: 0.10.3
|
||||
## Optional release date. May be filled in hours/days after a release
|
||||
optional_date: 2015-10-14
|
||||
## Optional title. If not set, default is: Bitcoin Core version %v released
|
||||
optional_title: Bitcoin Core version %v released
|
||||
## Optional magnet link. To get it, open the torrent in a good BitTorrent client
|
||||
## and View Details, or install the transmission-cli Debian/Ubuntu package
|
||||
## and run: transmission-show -m <torrent file>
|
||||
#
|
||||
## Link should be enclosed in quotes and start with: "magnet:?
|
||||
optional_magnetlink:
|
||||
|
||||
## The --- below ends the YAML header. After that, paste the release notes.
|
||||
## Warning: this site's Markdown parser commonly requires you make two
|
||||
## changes to the release notes from the Bitcoin Core source tree:
|
||||
##
|
||||
## 1. Make sure both ordered and unordered lists are preceded by an empty
|
||||
## (whitespace only) line, like the empty line before this list item.
|
||||
##
|
||||
## 2. Place URLs inside angle brackets, like <http://bitcoin.org/bin>
|
||||
|
||||
---
|
||||
{% githubify https://github.com/bitcoin/bitcoin %}
|
||||
Bitcoin Core version 0.10.3 is now available from:
|
||||
|
||||
<https://bitcoin.org/bin/bitcoin-core-0.10.3/>
|
||||
|
||||
This is a new minor version release, bringing security fixes and translation
|
||||
updates. It is recommended to upgrade to this version as soon as possible.
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
|
||||
<https://github.com/bitcoin/bitcoin/issues>
|
||||
|
||||
Upgrading and downgrading
|
||||
=========================
|
||||
|
||||
How to Upgrade
|
||||
--------------
|
||||
|
||||
If you are running an older version, shut it down. Wait until it has completely
|
||||
shut down (which might take a few minutes for older versions), then run the
|
||||
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
|
||||
bitcoind/bitcoin-qt (on Linux).
|
||||
|
||||
Downgrade warning
|
||||
------------------
|
||||
|
||||
Because release 0.10.0 and later makes use of headers-first synchronization and
|
||||
parallel block download (see further), the block files and databases are not
|
||||
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:
|
||||
|
||||
* Blocks will be stored on disk out of order (in the order they are
|
||||
received, really), which makes it incompatible with some tools or
|
||||
other programs. Reindexing using earlier versions will also not work
|
||||
anymore as a result of this.
|
||||
|
||||
* The block index database will now hold headers for which no block is
|
||||
stored on disk, which earlier versions won't support.
|
||||
|
||||
If you want to be able to downgrade smoothly, make a backup of your entire data
|
||||
directory. Without this your node will need start syncing (or importing from
|
||||
bootstrap.dat) anew afterwards. It is possible that the data from a completely
|
||||
synchronised 0.10 node may be usable in older versions as-is, but this is not
|
||||
supported and may break as soon as the older version attempts to reindex.
|
||||
|
||||
This does not affect wallet forward or backward compatibility.
|
||||
|
||||
Notable changes
|
||||
===============
|
||||
|
||||
Fix buffer overflow in bundled upnp
|
||||
------------------------------------
|
||||
|
||||
Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow in
|
||||
the XML parser during initial network discovery.
|
||||
|
||||
Details can be found here: <http://talosintel.com/reports/TALOS-2015-0035/>
|
||||
|
||||
This applies to the distributed executables only, not when building from source or
|
||||
using distribution provided packages.
|
||||
|
||||
Additionally, upnp has been disabled by default. This may result in a lower
|
||||
number of reachable nodes on IPv4, however this prevents future libupnpc
|
||||
vulnerabilities from being a structural risk to the network
|
||||
(see <https://github.com/bitcoin/bitcoin/pull/6795>).
|
||||
|
||||
Test for LowS signatures before relaying
|
||||
-----------------------------------------
|
||||
|
||||
Make the node require the canonical 'low-s' encoding for ECDSA signatures when
|
||||
relaying or mining. This removes a nuisance malleability vector.
|
||||
|
||||
Consensus behavior is unchanged.
|
||||
|
||||
If widely deployed this change would eliminate the last remaining known vector
|
||||
for nuisance malleability on SIGHASH_ALL P2PKH transactions. On the down-side
|
||||
it will block most transactions made by sufficiently out of date software.
|
||||
|
||||
Unlike the other avenues to change txids on transactions this
|
||||
one was randomly violated by all deployed bitcoin software prior to
|
||||
its discovery. So, while other malleability vectors where made
|
||||
non-standard as soon as they were discovered, this one has remained
|
||||
permitted. Even BIP62 did not propose applying this rule to
|
||||
old version transactions, but conforming implementations have become
|
||||
much more common since BIP62 was initially written.
|
||||
|
||||
Bitcoin Core has produced compatible signatures since a28fb70e in
|
||||
September 2013, but this didn't make it into a release until 0.9
|
||||
in March 2014; Bitcoinj has done so for a similar span of time.
|
||||
Bitcoinjs and electrum have been more recently updated.
|
||||
|
||||
This does not replace the need for BIP62 or similar, as miners can
|
||||
still cooperate to break transactions. Nor does it replace the
|
||||
need for wallet software to handle malleability sanely[1]. This
|
||||
only eliminates the cheap and irritating DOS attack.
|
||||
|
||||
[1] On the Malleability of Bitcoin Transactions
|
||||
Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek
|
||||
<http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf>
|
||||
|
||||
Minimum relay fee default increase
|
||||
-----------------------------------
|
||||
|
||||
The default for the `-minrelaytxfee` setting has been increased from `0.00001`
|
||||
to `0.00005`.
|
||||
|
||||
This is necessitated by the current transaction flooding, causing
|
||||
outrageous memory usage on nodes due to the mempool ballooning. This is a
|
||||
temporary measure, bridging the time until a dynamic method for determining
|
||||
this fee is merged (which will be in 0.12).
|
||||
|
||||
(see <https://github.com/bitcoin/bitcoin/pull/6793>, as well as the 0.11.0
|
||||
release notes, in which this value was suggested)
|
||||
|
||||
0.10.3 Change log
|
||||
=================
|
||||
|
||||
Detailed release notes follow. This overview includes changes that affect external
|
||||
behavior, not code moves, refactors or string updates.
|
||||
|
||||
- #6186 `e4a7d51` Fix two problems in CSubnet parsing
|
||||
- #6153 `ebd7d8d` Parameter interaction: disable upnp if -proxy set
|
||||
- #6203 `ecc96f5` Remove P2SH coinbase flag, no longer interesting
|
||||
- #6226 `181771b` json: fail read_string if string contains trailing garbage
|
||||
- #6244 `09334e0` configure: Detect (and reject) LibreSSL
|
||||
- #6276 `0fd8464` Fix getbalance * 0
|
||||
- #6274 `be64204` Add option `-alerts` to opt out of alert system
|
||||
- #6319 `3f55638` doc: update mailing list address
|
||||
- #6438 `7e66e9c` openssl: avoid config file load/race
|
||||
- #6439 `255eced` Updated URL location of netinstall for Debian
|
||||
- #6412 `0739e6e` Test whether created sockets are select()able
|
||||
- #6694 `f696ea1` [QT] fix thin space word wrap line brake issue
|
||||
- #6704 `743cc9e` Backport bugfixes to 0.10
|
||||
- #6769 `1cea6b0` Test LowS in standardness, removes nuisance malleability vector.
|
||||
- #6789 `093d7b5` Update miniupnpc to 1.9.20151008
|
||||
- #6795 `f2778e0` net: Disable upnp by default
|
||||
- #6797 `91ef4d9` Do not store more than 200 timedata samples
|
||||
- #6793 `842c48d` Bump minrelaytxfee default
|
||||
|
||||
Credits
|
||||
=======
|
||||
|
||||
Thanks to everyone who directly contributed to this release:
|
||||
|
||||
- Adam Weiss
|
||||
- Alex Morcos
|
||||
- Casey Rodarmor
|
||||
- Cory Fields
|
||||
- fanquake
|
||||
- Gregory Maxwell
|
||||
- Jonas Schnelli
|
||||
- J Ross Nicoll
|
||||
- Luke Dashjr
|
||||
- Pavel Vasin
|
||||
- Pieter Wuille
|
||||
- randy-waterhouse
|
||||
- ฿tcDrak
|
||||
- Tom Harding
|
||||
- Veres Lajos
|
||||
- Wladimir J. van der Laan
|
||||
|
||||
And all those who contributed additional code review and/or security research:
|
||||
|
||||
- timothy on IRC for reporting the issue
|
||||
- Vulnerability in miniupnp discovered by Aleksandar Nikolic of Cisco Talos
|
||||
|
||||
As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
|
||||
|
||||
{% endgithubify %}
|
||||
|
|
@ -88,6 +88,11 @@ Details can be found here: http://talosintel.com/reports/TALOS-2015-0035/
|
|||
This applies to the distributed executables only, not when building from source or
|
||||
using distribution provided packages.
|
||||
|
||||
Additionally, upnp has been disabled by default. This may result in a lower
|
||||
number of reachable nodes on IPv4, however this prevents future libupnpc
|
||||
vulnerabilities from being a structural risk to the network
|
||||
(see https://github.com/bitcoin/bitcoin/pull/6795).
|
||||
|
||||
Test for LowS signatures before relaying
|
||||
-----------------------------------------
|
||||
|
||||
|
|
@ -122,6 +127,20 @@ only eliminates the cheap and irritating DOS attack.
|
|||
Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek
|
||||
http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf
|
||||
|
||||
Minimum relay fee default increase
|
||||
-----------------------------------
|
||||
|
||||
The default for the `-minrelaytxfee` setting has been increased from `0.00001`
|
||||
to `0.00005`.
|
||||
|
||||
This is necessitated by the current transaction flooding, causing
|
||||
outrageous memory usage on nodes due to the mempool ballooning. This is a
|
||||
temporary measure, bridging the time until a dynamic method for determining
|
||||
this fee is merged (which will be in 0.12).
|
||||
|
||||
(see https://github.com/bitcoin/bitcoin/pull/6793, as well as the 0.11
|
||||
release notes, in which this value was suggested)
|
||||
|
||||
0.11.1 Change log
|
||||
=================
|
||||
|
||||
|
|
@ -144,6 +163,8 @@ git merge commit are mentioned.
|
|||
- #6789 `b4ad73f` Update miniupnpc to 1.9.20151008
|
||||
- #6785 `b4dc33e` Backport to v0.11: In (strCommand == "tx"), return if AlreadyHave()
|
||||
- #6412 `0095b9a` Test whether created sockets are select()able
|
||||
- #6795 `4dbcec0` net: Disable upnp by default
|
||||
- #6793 `e7bcc4a` Bump minrelaytxfee default
|
||||
|
||||
Credits
|
||||
=======
|
||||
|
|
@ -158,6 +179,7 @@ Thanks to everyone who directly contributed to this release:
|
|||
- Gregory Maxwell
|
||||
- Jonas Schnelli
|
||||
- J Ross Nicoll
|
||||
- Luke Dashjr
|
||||
- Pavel Janík
|
||||
- Pavel Vasin
|
||||
- Peter Todd
|
||||
|
|
@ -177,4 +199,5 @@ And those who contributed additional code review and/or security research:
|
|||
- Vulnerability in miniupnp discovered by Aleksandar Nikolic of Cisco Talos
|
||||
|
||||
As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
|
||||
|
||||
{% endgithubify %}
|
||||
|
|
|
|||
|
|
@ -66,6 +66,15 @@ id: about-us
|
|||
<p>Thomas Pryds<span>Danish</span></p>
|
||||
</div>
|
||||
|
||||
<h3 id="service_contributors">{% translate service_contributors %}</h3>
|
||||
|
||||
<div class="credit">
|
||||
<p><a href="https://www.browserstack.com/">BrowserStack</a><span>Browser testing</span></p>
|
||||
<p><a href="https://github.com/">GitHub</a><span>Repository hosting</span></p>
|
||||
<p><a href="https://www.transifex.com/">Transifex</a><span>Translation tools</span></p>
|
||||
<p><a href="https://travis-ci.org/">Travis CI</a><span>Continuous integration</span></p>
|
||||
</div>
|
||||
|
||||
<h3 id="inactive-contributors">{% translate inactive_contributors %}</h3>
|
||||
|
||||
<div class="credit">
|
||||
|
|
|
|||
|
|
@ -749,83 +749,6 @@ wallets:
|
|||
privacyaddressreuse: "checkpassprivacyaddressrotation"
|
||||
privacydisclosure: "checkfailprivacydisclosureaccount"
|
||||
privacynetwork: "checkpassprivacynetworksupporttorproxy"
|
||||
- ninki:
|
||||
title: "Ninki Wallet"
|
||||
titleshort: "Ninki"
|
||||
compat: "mobile desktop windows mac linux android ios"
|
||||
level: 3
|
||||
platform:
|
||||
desktop:
|
||||
text: "walletninki"
|
||||
link: "https://chrome.google.com/webstore/detail/ninki-wallet/ojjnofoknpfkbbamkfililnkoeoiohih"
|
||||
source: "https://github.com/Ninkip2p/NinkiWalletCRX"
|
||||
screenshot: "ninki.png"
|
||||
os:
|
||||
- windows
|
||||
- mac
|
||||
- linux
|
||||
check:
|
||||
control: "checkpasscontrolmulti"
|
||||
validation: "checkfailvalidationcentralized"
|
||||
transparency: "checkfailtransparencynew"
|
||||
environment: "checkpassenvironmenttwofactor"
|
||||
privacy: "checkpassprivacybasic"
|
||||
privacycheck:
|
||||
privacyaddressreuse: "checkpassprivacyaddressrotation"
|
||||
privacydisclosure: "checkfailprivacydisclosureaccount"
|
||||
privacynetwork: "checkfailprivacynetworknosupporttor"
|
||||
mobile:
|
||||
text: "walletninki"
|
||||
link: "https://play.google.com/store/apps/details?id=com.ninki.wallet&hl=en"
|
||||
source: "https://github.com/Ninkip2p/NinkiCordova"
|
||||
screenshot: "ninki.png"
|
||||
os:
|
||||
- android
|
||||
- ios
|
||||
check:
|
||||
control: "checkpasscontrolmulti"
|
||||
validation: "checkfailvalidationcentralized"
|
||||
transparency: "checkfailtransparencynew"
|
||||
environment: "checkpassenvironmenttwofactor"
|
||||
privacy: "checkpassprivacybasic"
|
||||
privacycheck:
|
||||
privacyaddressreuse: "checkpassprivacyaddressrotation"
|
||||
privacydisclosure: "checkfailprivacydisclosureaccount"
|
||||
privacynetwork: "checkfailprivacynetworknosupporttor"
|
||||
ios:
|
||||
text: "walletninki"
|
||||
link: "https://itunes.apple.com/us/app/ninki-wallet/id965528267?mt=8"
|
||||
source: "https://github.com/Ninkip2p/NinkiCordova"
|
||||
screenshot: "ninki.png"
|
||||
os:
|
||||
- ios
|
||||
check:
|
||||
control: "checkpasscontrolmulti"
|
||||
validation: "checkfailvalidationcentralized"
|
||||
transparency: "checkfailtransparencynew"
|
||||
environment: "checkpassenvironmenttwofactor"
|
||||
privacy: "checkpassprivacybasic"
|
||||
privacycheck:
|
||||
privacyaddressreuse: "checkpassprivacyaddressrotation"
|
||||
privacydisclosure: "checkfailprivacydisclosureaccount"
|
||||
privacynetwork: "checkfailprivacynetworknosupporttor"
|
||||
android:
|
||||
text: "walletninki"
|
||||
link: "https://play.google.com/store/apps/details?id=com.ninki.wallet&hl=en"
|
||||
source: "https://github.com/Ninkip2p/NinkiCordova"
|
||||
screenshot: "ninki.png"
|
||||
os:
|
||||
- android
|
||||
check:
|
||||
control: "checkpasscontrolmulti"
|
||||
validation: "checkfailvalidationcentralized"
|
||||
transparency: "checkfailtransparencynew"
|
||||
environment: "checkpassenvironmenttwofactor"
|
||||
privacy: "checkpassprivacybasic"
|
||||
privacycheck:
|
||||
privacyaddressreuse: "checkpassprivacyaddressrotation"
|
||||
privacydisclosure: "checkfailprivacydisclosureaccount"
|
||||
privacynetwork: "checkfailprivacynetworknosupporttor"
|
||||
---
|
||||
|
||||
<!-- Note: this file exempt from check-for-subheading-anchors check -->
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ en:
|
|||
maintenance: "Maintenance"
|
||||
documentation: "Documentation"
|
||||
sponsorship: "Sponsorship"
|
||||
service_contributors: "Service Contributors"
|
||||
translation: "Translation"
|
||||
inactive_contributors: "Inactive Contributors"
|
||||
owners: "Domain Owners"
|
||||
|
|
@ -641,10 +642,6 @@ en:
|
|||
privacy:
|
||||
title: "Privacy Policy - Bitcoin"
|
||||
pagetitle: "Privacy Policy"
|
||||
datacollect: "Data collected"
|
||||
datacollecttxt: "Bitcoin.org collects anonymized server logs. These logs include IP addresses with replaced last byte, time of the visit, requested page, user agent and referer url. Bitcoin.org does not collect data using cookies."
|
||||
datause: "Usage of data"
|
||||
datausetxt: "Collected data may be used to provide transparent public stats."
|
||||
privacytxt1: "This page informs you of our policies regarding the collection, use and disclosure of personal information we receive from users of our site (http://bitcoin.org). We use your personal information to better understand your usage of the site, and to collect traffic statistics."
|
||||
privacytxt2: "By using the site, you agree to the collection and use of information in accordance with this policy."
|
||||
privacylogdata: "Log Data"
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ page](/en/vocabulary).</span>
|
|||
{% when 'b' %}
|
||||
See also: [Bitcoin Improvement Proposals (BIPs)](https://github.com/bitcoin/bips#readme)
|
||||
{% when 'o' %}
|
||||
See also: [Op codes](https://en.bitcoin.it/wiki/Script#Words)
|
||||
See also: [Opcodes](https://en.bitcoin.it/wiki/Script#Words)
|
||||
{% when 'p' %}
|
||||
See also: [P2P protocol messages](/en/developer-reference#data-messages)
|
||||
{% when 'r' %}
|
||||
|
|
|
|||
|
|
@ -1090,10 +1090,47 @@ automatically started minimized in the task bar.
|
|||
#### Bitcoin Core Daemon {#osx-daemon}
|
||||
{:.no_toc}
|
||||
|
||||
If you can provide instructions and screenshots for running the latest
|
||||
version of Bitcoin Core daemon on OS X Yosemite, please [open an
|
||||
issue](https://github.com/bitcoin-dot-org/bitcoin.org/issues/new) and we'll tell
|
||||
you what we need.
|
||||
The Bitcoin Core daemon (bitcoind) is not included in the .dmg file you may have downloaded to install Bitcoin-QT. Bitcoind, along with its support binaries, is instead included in the OS X .tar.gz file listed on the official Bitcoin Core download page. To download this file using Terminal, execute the following command:
|
||||
|
||||
curl -O https://bitcoin.org/bin/bitcoin-core-{{site.DOWNLOAD_VERSION}}/bitcoin-{{site.DOWNLOAD_VERSION}}-osx64.tar.gz
|
||||
|
||||
{{verifyReleaseSignatures}}
|
||||
|
||||
Extract bitcoind and its support binaries from the archive we just downloaded by running this command in Terminal:
|
||||
|
||||
tar -zxf bitcoin-{{site.DOWNLOAD_VERSION}}-osx64.tar.gz
|
||||
|
||||
Now we'll move the executables into your default path to make running and stopping bitcoind easier. To move the executables, run these commands (note that we have to use `sudo` to perform these commands since we are modifying directories owned by root):
|
||||
|
||||
sudo mkdir -p /usr/local/bin
|
||||
sudo cp bitcoin-{{site.DOWNLOAD_VERSION}}/bin/bitcoin* /usr/local/bin/.
|
||||
|
||||
To clean up the directory we've been working in, run:
|
||||
|
||||
rm -rf bitcoin-{{site.DOWNLOAD_VERSION}}*
|
||||
|
||||
Before we can run bitcoind, we need to make sure that it has a place to store the blockchain and a config file that contains a username and password for the daemon. The commands below will set up your bitcoin directory and give bitcoind a default username and a random password (you do not need to remember the password for standard operation).
|
||||
|
||||
mkdir ~/Library/Application\ Support/Bitcoin
|
||||
touch ~/Library/Application\ Support/Bitcoin/bitcoin.conf
|
||||
chmod 600 ~/Library/Application\ Support/Bitcoin/bitcoin.conf
|
||||
echo "rpcuser=bitcoinrpc" >> ~/Library/Application\ Support/Bitcoin/bitcoin.conf
|
||||
echo "rpcpassword=$(cat /dev/urandom | env LC_CTYPE=C tr -dc a-zA-Z0-9 | head -c45)" >> ~/Library/Application\ Support/Bitcoin/bitcoin.conf
|
||||
|
||||
You should now be able to start up your full node by running `bitcoind -daemon` in any Terminal window. If you need to stop bitcoind for any reason, the command is `bitcoin-cli stop`
|
||||
|
||||
<div class="box" markdown="1">
|
||||
*Optional: Start Your Node At Login*
|
||||
|
||||
Starting your node automatically each time you login to your computer makes it easy for you to contribute to the network. The easiest way to do this is to tell Bitcoin Core Daemon to start at login. In OS X, the way to start background programs at login is using a Launch Agent. Here is how to install a Launch Agent for Bitcoin Core daemon on your machine:
|
||||
|
||||
mkdir ~/Library/LaunchAgents
|
||||
curl https://raw.githubusercontent.com/bitcoin/bitcoin/master/contrib/init/org.bitcoin.bitcoind.plist > ~/Library/LaunchAgents/org.bitcoin.bitcoind.plist
|
||||
|
||||
The next time you login to your desktop, Bitcoin Core daemon will be automatically started.
|
||||
</div>
|
||||
|
||||
{{installFinished}}
|
||||
|
||||
## Network Configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,10 @@
|
|||
/* jshint ignore:start */
|
||||
|
||||
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
|
||||
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
|
||||
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
|
||||
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
|
||||
ga('create', 'UA-46627233-1', 'auto');
|
||||
ga('send', 'pageview');
|
||||
|
||||
/* jshint ignore:end */
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
id: cookie-notification
|
||||
# This file is licensed under the GNU General Public License Version 3 available on
|
||||
# http://www.gnu.org/licenses/gpl-3.0.en.html
|
||||
---
|
||||
|
||||
(function () {
|
||||
|
|
|
|||
4531
pieterwuille.asc
4531
pieterwuille.asc
File diff suppressed because it is too large
Load diff
Loading…
Add table
Add a link
Reference in a new issue