Move existing "regtest / testnet" texts to the new subsection and link to it
Move Bitcoin Core setup instructions in devel-examples
Add a consistent introduction for devel-(guide/ref/examples)
Fix autocrossref.rb to not add links inside {% highlight %} code blocks
No apparent privacy is added by the implementation we link to, and the
press release I read indicates they don't plan to fix it, so I'm
removing our link to it.
Several reviewers kindly provided feedback via IRC tonight, resulting in
the following changes:
* Mention that compressed keys are used in the offical secp256k1
documentation with the prefix bytes used by Bitcoin. I could not find
a publicly-available officialish document defining the prefix bytes,
but they're used repeatedly in the offical SECG documentation we
autoxref "secp256k1" to, so I went with that.
* Remove the mention that Bitcoin Core uses OpenSSL. While true, there
is an effort to slowly move away from using OpenSSL for EC in
Bitcoin Core.
* Change the phrasing of the relative curve location for 0x02 & 0x03 to
a form more correct for actuality instead of the illustrated
abstraction.
* Drop quotes around "uncompressed" since that's the term used in the
official secp256k1 docs, not something Bitcoin-specific.
Based on feedback from @luke-jr. (Thanks!)
* Use "may" to indicate that full peers don't need to track unconfirmed txes.
* Change the example given for why non-mining peers might want to track
unconfirmed txes.
* Note that txes also get dropped from mempool when memory needs
to be freed.
* Remove paragraph about storing non-relay/non-mine txes.
* Clarify a few places where payment request was used instead of
PaymentRequest.
* Clarify that payment isn't necessarily verified until the merchant
says so. Suggested by @saivann (thanks!)
Describe the essential functions of a wallet program and how multiple
programs can work together to fulfill those functions, as in the case of
a signing-only wallet.
* Remove the QR Code error corrections subsection.
* Remove the non-example Payment Protocol text from developer examples.
* Update reference links and autocrossrefs to reflect above deletions
* Fix CSS padding problems reported by @saivann
* Remove all HTML comments from autocrossref text to allow easy checking
for broken link definitions: find _site -name '*.html' | xargs grep '\]\['
* Add PNG versions of guide and example SVG icons. (optipng run)
* Add new icons for Developer Guide and Developer Examples so we don't
keep reusing the book icon.
* Update payment protocol links to point to developer examples when
appropriate.
Two minor changes suggested by iwilcox on IRC (thanks!):
* s/brute-force find/brute-force/ in HD wallet section
* Correct mistaken assertion that the keypool isn't refreshed until all
keys are used. If the wallet is unencrypted or unlocked, the keypool
is refreshed after each time a key is used.
* Remove contentious sentence about mining non-standard txes possibly
creating orphaned blocks and loss of block reward. Suggested by
@luke-jr (thanks!)
* Remove unnecessary value judgement ("unfortunately") against
non-standard redeemScripts. Mention that they can be used deliberately
by someone who wants to easily receive payment to a non-standard
output script. Suggested by @luke-jr (thanks!)
Based on a discussion tonight on IRC with comments from @gmaxwell,
bitcoin428, and kadoban.
* Add a new introduction to the Standard Transaction section which
explains the purpose behind standard transactions so readers
understand that these aren't limitations for limitation's sake. More
specifically, note that bug-prevention isn't the only reason for
standard transactions---thanks to @gmaxwell for explaining the forward
compatablity reason to me.
* Make it clear that isStandard() only applies to loose transactions and
that it doesn't apply to txes in blocks. Thanks to bitcoin428 for
pointing out this source of confusion.
* Make it cleare that a non-standard redeemScript is a script that would
not pass isStandard(). Thanks to kadoban for pointing out the absense
of that information.
* Add new Developer Examples page
* Add a transaction tutorial describing in detail how to make various
different transactions.
* Add a new "multicode" CSS class to allow combination of consecutive
code blocks into a single code block. This lets us use pygments
highlighting for multiple different types of code within the same
aparent block of code.
* Get autocrossref to ignore code blocks so we don't need to endcrossref
every time we encounter a code block. This makes the source much more
readable and maintainable.
Two unrelated minor additions which were requested at nearly the same
time.
* @mikehearn requested we add a link to @gavinandresen's PaymentRequest
generator. Added to _includes/guide_payment_processing.md with link
definition in _includes/references.md
* @Burrito-Bazooka requested we mention that the block reward halves
every 210,000 blocks. Added to _includes/ref_block_chain.md
* Correct misinformation about the dust limit. Reported by @dbilitch and
confirmed by @gmaxwell. Thanks!
* Drop reported minimum relay fee from 10,000 to 1,000 satoshis.
**Suggested by @cbeams:**
_includes/ref_block_chain.md:
* Mention that coinbase is the first transaction in a block.
**Suggested by @gmaxwell:**
_includes/ref_core_rpcs-abcdefg.md:
* Mention that you need to unlock your wallet when you run out of
keys in the keypool.
* Remove erroneous assertion that txindex=1 would allow
`getreceivedbyaddress` to check balances of addresses not
belonging to this wallet.
_includes/ref_transactions.md:
* Clarify that OP_RETURN scripts aren't usually executed because
they always return false.
en/developer-reference.md
* Add a warning about using block chain or mempool data in
executable context.
As suggested by @gmaxwell (thanks!), I tried to make clearer the benefit
of hardened keys:
* Described hardened keys as a solution in the first sentence of the
Hardened Keys subsection.
* Reordered the text so that the problem is described before the
solution, making the presence of a solution clearer.
* Added a prefatory sentence to the description of the two key
derivation formulas again describing the hardened formula as a
solution.
As suggested by @vbuterin (thanks!), I added a paragraph describing that
HD wallets don't use normal derivation on the master key so they don't
have an effective master public key. (See end of the diff.)
This is a fairly large diff because of the reordering, but no new
clauses were added besides those described above.
_includes/guide_wallets.md:
* Fix formula given for normal child key derivation to state that public
keys must also be provided to the HMAC hash function. This required
updating both text and images.
* Add one-paragraph warning about ancestor key compromise when the
ancestor extended public key is compromised along with a descended
private key. Update img/dev/en-hd-private-parent-to-private-child.*
to help illustrate this warning.
en/developer-reference.md:
* Remove %include% of previously-removed file which caused new versions
of Jekyll to die.
