Fix malformed HTML reported by HTML Proofer

_includes/_meetings.html

@@ -5,7 +5,7 @@
     {% assign post=default_post %}
     {% capture year %}{{post.date | date: '%Y' }}{% endcapture %}
     {% if forloop.first == true %}<li><b>{{year}}</b><ul>{% assign old_year = year %}{% endif %}
-    {% if year != old_year %}</ul><li><b>{{year}}</b><ul>{% assign old_year = year %}{% endif %}
+    {% if year != old_year %}</ul></li><li><b>{{year}}</b><ul>{% assign old_year = year %}{% endif %}
     {% for t_post in translated_posts %}
       {% if t_post.name == post.name %}{% assign post=t_post %}{% break %}{% endif %}
     {% endfor %}
@@ -16,5 +16,5 @@
     <div class="desc">{{ post.desc }}</div>
   </li>
   {% endfor %}
-  </ul>
+  </ul></li>
 </ul>

_includes/_scripts.html

@@ -1,5 +1,3 @@
-</body>
-
 <script src="/assets/js/scripts.js"></script>
 {% if site.owner.google.analytics %}
 <script>

_posts/ja/releases/2017-09-01-release-0.15.0.md

@@ -724,7 +724,7 @@ Coin Age Priorityの削除 {#removal-of-coin-age-priority}
 - #10502 `1ad3d4e` scripted-diff: Remove BOOST_FOREACH, Q_FOREACH and PAIRTYPE (jtimon)
 - #10377 `b63be2c` Use rdrand as entropy source on supported platforms (sipa)
 - #9895 `228c319` Turn TryCreateDirectory() into TryCreateDirectories() (benma)
-- #10602 `d76e84a` Make clang-format use C++11 features (e.g. A<A<int>> instead of A<A<int> >) (practicalswift)
+- #10602 `d76e84a` Make clang-format use C++11 features (e.g. `A<A<int>>` instead of `A<A<int> >`) (practicalswift)
 - #10623 `c38f540` doc: Add 0.14.2 release notes (MarcoFalke)
 - #10276 `b750b33` contrib/verifybinaries: allow filtering by platform (knocte)
 - #10248 `01c4b14` Rewrite addrdb with less duplication using CHashVerifier (sipa)

_posts/zh_CN/releases/2016-02-23-release-0.12.0.md

@@ -126,7 +126,7 @@ RPC:Random-cookie RPC身份验证
 
 比特币核心有一个基于币值和时间的启发式“优先级”系统。
 这项计算是用来广播不支付最低手续费的交易，可以用作另一种为已挖出的区块排序交易的方式。
-比特币核心将会根据'-limitfreerelay=<r>'（默认`r=15` kB/min）和'-blockprioritysize=<s>'来广播费用足够的交易。
+比特币核心将会根据`-limitfreerelay=<r>`（默认`r=15` kB/min）和'-blockprioritysize=<s>'来广播费用足够的交易。
 
 在比特币核心0.12版本中，当更高的最小手续费生效时，内存池大小将被限制。，即使根据启发式优先级排名，交易不符合这个更高的有效最低手续费时，将不会被广播或挖取。
 
@@ -196,7 +196,7 @@ RPC:Random-cookie RPC身份验证
 
 但是，重新扫描及部分RPC如'importwallet'、'importaddress'、 'importprivkey'是被禁用的。
 
-开启区块删减可以通过在命令行或'bitcoin.conf' 文件内的'prune=<N>'来设置。其中的'N'为用来分配初始块和撤销数据的MiB的数量。
+开启区块删减可以通过在命令行或'bitcoin.conf' 文件内的`prune=<N>`来设置。其中的'N'为用来分配初始块和撤销数据的MiB的数量。
 
 值为0会禁用删减，0之上的最小值为550。
 您的钱包对高值或低值的安全性是一致的。
@@ -366,7 +366,7 @@ Changelog
 ### 配置及命令行选项
 
 - \#6164 `8d05ec7` Allow user to use -debug=1 to enable all debugging (lpescher)
-- \#5288 `4452205` Added -whiteconnections=<n> option (Josh Lehan)
+- \#5288 `4452205` Added `-whiteconnections=<n>` option (Josh Lehan)
 - \#6284 `10ac38e` Fix argument parsing oddity with -noX (Wladimir J. van der Laan)
 - \#6489 `c9c017a` Give a better error message if system clock is bad (Casey Rodarmor)
 - \#6462 `c384800` implement uacomment config parameter which can add comments to user agent as per BIP-0014 (Pavol Rusnak)

_releases/0.12.0.md

@@ -364,7 +364,7 @@ Detailed release notes follow. This overview includes changes that affect behavi
 ### Configuration and command-line options
 
 - #6164 `8d05ec7` Allow user to use -debug=1 to enable all debugging (lpescher)
-- #5288 `4452205` Added -whiteconnections=<n> option (Josh Lehan)
+- #5288 `4452205` Added `-whiteconnections=<n>` option (Josh Lehan)
 - #6284 `10ac38e` Fix argument parsing oddity with -noX (Wladimir J. van der Laan)
 - #6489 `c9c017a` Give a better error message if system clock is bad (Casey Rodarmor)
 - #6462 `c384800` implement uacomment config parameter which can add comments to user agent as per BIP-0014 (Pavol Rusnak)

_releases/0.13.0.md

@@ -386,7 +386,7 @@ Low-level ZMQ changes
   listeners to detect lost notifications.
   The sequence number is always the last element in a multi-part ZMQ notification and
   therefore backward compatible. Each message type has its own counter.
-  PR [#7762](https://github.com/bitcoin/bitcoin/pull/7762).
+  PR #7762.
 
 
 0.13.0 Change log

_releases/0.14.0.md

@@ -260,7 +260,7 @@ Low-level RPC changes
 
  - A new RPC command `getmemoryinfo` has been added which will return information
    about the memory usage of Bitcoin Core. This was added in conjunction with
-   optimizations to memory management. See [Pull #8753](https://github.com/bitcoin/bitcoin/pull/8753)
+   optimizations to memory management. See Pull #8753
    for more information.
 
  - A new RPC command `bumpfee` has been added which allows replacing an

_releases/0.15.0.md

@@ -750,7 +750,7 @@ Low-level RPC changes
 - #10502 `1ad3d4e` scripted-diff: Remove BOOST_FOREACH, Q_FOREACH and PAIRTYPE (jtimon)
 - #10377 `b63be2c` Use rdrand as entropy source on supported platforms (sipa)
 - #9895 `228c319` Turn TryCreateDirectory() into TryCreateDirectories() (benma)
-- #10602 `d76e84a` Make clang-format use C++11 features (e.g. A<A<int>> instead of A<A<int> >) (practicalswift)
+- #10602 `d76e84a` Make clang-format use C++11 features (e.g. `A<A<int>>` instead of `A<A<int> >`) (practicalswift)
 - #10623 `c38f540` doc: Add 0.14.2 release notes (MarcoFalke)
 - #10276 `b750b33` contrib/verifybinaries: allow filtering by platform (knocte)
 - #10248 `01c4b14` Rewrite addrdb with less duplication using CHashVerifier (sipa)

_releases/0.16.0.md

@@ -343,7 +343,7 @@ Testing changes
 - #11362 `c6223b3` Remove nBlockMaxSize from miner opt struct as it is no longer used (gmaxwell)
 - #10825 `28485c7` Set regtest JSON-RPC port to 18443 to avoid conflict with testnet 18332 (fametrano)
 - #11303 `e542728` Fix estimatesmartfee rounding display issue (TheBlueMatt)
-- #7061 `8c2de82` Add RPC call "rescanblockchain <startheight> <stopheight>" (jonasschnelli)
+- #7061 `8c2de82` Add RPC call "rescanblockchain `<startheight>` `<stopheight>`" (jonasschnelli)
 - #11055 `95e14dc` RPC getreceivedbyaddress should return error if called with address not owned by the wallet (jnewbery)
 - #12366 `93de37a` http: Join worker threads before deleting work queue (laanwj)
 - #12315 `758a41e` Bech32 addresses in dumpwallet (fivepiece)

logs/2016-05-zurich-meeting-notes.html

@@ -94,7 +94,7 @@
 
 <p>There was javascript input validation that was doing address checking. That took a long time. If people are reimplementing parts of the protocol, well.. oh it sucks so they rewrite it from scratch which is dumb. I would be inclined to pick a fixed-length format. If some addresses have different lengths... every type of address would have the same length. The problem is that the moment someone says oh yeah let's have the bright idea of... if it's a scriptpubkey, it can't be a fixed length. With amount, yeah amount is fine. Whatever we go pick, we probably do want a fixed length format because of what people write. With base58 checks, leading zeroes get stripped, so the addresses are not all the same size. But there's a fixed maximum length, and people do hard-code that in and stuff. Ignoring the fact that it can encode arbitrary scriptpubkeys, it is fixed length. The moment we want to encode something else, it just breaks it, come across another pubkey type and it has another length. The stored field that someone is using might just be enough, with the recovery characters knocked off, for it to still work. So nullifying the ... well all we can do is tell people not to do that.</p>
 
-<p>You feed it an array of base32, it computes the checksum, ... ... It could be part of the spec. Even though it encodes an arbitrary scriptpubkey, it has a maximum size. Nobody is going to implement what the spec says, though. There's an implicit one in the protocol, and it's 10,000 bytes. Pay-to-witness scripthash address, and pay-to-witness pubkeyhash format, but the format actually just encodes a scriptpubkey but it's just the standard for those two but not for arbitrary scriptpubkeys which I think would be dangerous. Other people can later extend it, it becomes easier to extend because all you have to do is remove a limitation. The risk is that what people will implement oh it's a scriptpubkey. If you limit it that much, one of the reasons to have something encoding an arbitrary scriptpubkey, so if in the network we deploy script versiontype 5 with just MAST or something, it will take forever to upgrade the entire industry. We don't want to create that problem. We're not going to want to do this again. If we have a new thing again, like lightning, changing an address type is the most difficult thing. Address type being extensible, lightning.... confidential transactions is a good example-- no I don't think that's a good example either, so what's a good example is MAST. You would have to extend for blinding. CT is not a good example because, the payer will need additional processing infrastructure, I can't create a new address type now that is generic for CT. But for MAST I can encode the raw scriptpubkey. Right. It's unrealistic to say we'll never have to have new address types in the future. We can include a lua interpreter or something. It's a new address. You give someone, when you want them to pay you, you give them a virtual agent who acts on your behalf to negotiate the protocol for you, it can barter and stuff.... <humor>petertodd's on it. Whenever you want someone to pay you, you just send petertodd. P2PT - pay-to-petertodd.</humor></p>
+<p>You feed it an array of base32, it computes the checksum, ... ... It could be part of the spec. Even though it encodes an arbitrary scriptpubkey, it has a maximum size. Nobody is going to implement what the spec says, though. There's an implicit one in the protocol, and it's 10,000 bytes. Pay-to-witness scripthash address, and pay-to-witness pubkeyhash format, but the format actually just encodes a scriptpubkey but it's just the standard for those two but not for arbitrary scriptpubkeys which I think would be dangerous. Other people can later extend it, it becomes easier to extend because all you have to do is remove a limitation. The risk is that what people will implement oh it's a scriptpubkey. If you limit it that much, one of the reasons to have something encoding an arbitrary scriptpubkey, so if in the network we deploy script versiontype 5 with just MAST or something, it will take forever to upgrade the entire industry. We don't want to create that problem. We're not going to want to do this again. If we have a new thing again, like lightning, changing an address type is the most difficult thing. Address type being extensible, lightning.... confidential transactions is a good example-- no I don't think that's a good example either, so what's a good example is MAST. You would have to extend for blinding. CT is not a good example because, the payer will need additional processing infrastructure, I can't create a new address type now that is generic for CT. But for MAST I can encode the raw scriptpubkey. Right. It's unrealistic to say we'll never have to have new address types in the future. We can include a lua interpreter or something. It's a new address. You give someone, when you want them to pay you, you give them a virtual agent who acts on your behalf to negotiate the protocol for you, it can barter and stuff.... &lt;humor&gt;petertodd's on it. Whenever you want someone to pay you, you just send petertodd. P2PT - pay-to-petertodd.&lt;/humor&gt;</p>
 
 <p>We can't hope to cover all possible future cases, but we can cover a lot of stuff like a lot of new segwit descriptors, but we can't cover stealth addresses or CT. We should cover the things that can be covered and not design further. Being able to put the amounts under it would be super useful. With a different prefix, it would have to be optional yeah with a different prefix. You can only store 288 bits of data, so change to a different code or something.....</p>