cron: update bips submodule and build

Author: github-actions[bot]

bips

@@ -91,7 +91,7 @@ A hardcoded increase to max block size (2MB, 8MB, etc.), rejected because:
 Allow miners to vote for max block size, rejected because:
 *  overly complex and political
 *  human involvement makes this slow to respond to changing transaction volumes
-*  focuses power over max block size to a relatively small group of people 
+*  focuses power over max block size to a relatively small group of people
 *  unpredictable transaction fees caused by this would create uncertainty in the ecosystem
 
 

web/content/104/index.md

@@ -31,22 +31,22 @@ note = "THIS FILE IS AUTOMATICALLY GENERATED - NOT MEANT FOR EDITING"
 <h2>Abstract</h2>
 
 
-A method of altering the maximum allowed block size of the Bitcoin protocol 
+A method of altering the maximum allowed block size of the Bitcoin protocol
 using a consensus based approach.
 
 <h2>Motivation</h2>
 
 
-There is a belief that Bitcoin cannot easily respond to raising the 
-blocksize limit if popularity was to suddenly increase due to a mass adoption 
-curve, because co-ordinating a hard fork takes considerable time, and being 
-unable to respond in a timely manner would irreparably harm the credibility of 
+There is a belief that Bitcoin cannot easily respond to raising the
+blocksize limit if popularity was to suddenly increase due to a mass adoption
+curve, because co-ordinating a hard fork takes considerable time, and being
+unable to respond in a timely manner would irreparably harm the credibility of
 bitcoin.
 
 Additionally, predetermined block size increases are problematic because they
-attempt to predict the future, and if too large could have unintended 
-consequences like damaging the possibility for a fee market to develop 
-as block subsidy decreases substantially over the next 9 years; introducing 
+attempt to predict the future, and if too large could have unintended
+consequences like damaging the possibility for a fee market to develop
+as block subsidy decreases substantially over the next 9 years; introducing
 or exacerbating mining attack vectors; or somehow affect the network in unknown
 or unpredicted ways. Since fixed changes are hard to deploy, the damage could be
 extensive.
@@ -55,15 +55,15 @@ Dynamic block size adjustments also suffer from the potential to be gamed by the
 larger hash power.
 
 Free voting as suggested by BIP100 allows miners to sell their votes out of band
-at no risk, and enable the sponsor the ability to manipulate the blocksize. 
+at no risk, and enable the sponsor the ability to manipulate the blocksize.
 It also provides a cost free method or the larger pools to vote in ways to
 manipulate the blocksize such to disadvantage or attack smaller pools.
 
 
 <h2>Rationale</h2>
 
 
-By introducing a cost to increase the block size ensures the mining community 
+By introducing a cost to increase the block size ensures the mining community
 will collude to increase it only when there is a clear necessity, and reduce it
 when it is unnecessary. Larger miners cannot force their wishes so easily
 because not only will they have to pay extra a difficulty target, then can be
@@ -84,7 +84,7 @@ honest.
 The initial block size limit shall be 1MB.
 
 Each time a miner creates a block, they may vote to increase or decrease the
-blocksize by a maximum of 10% of the current block size limit. These votes will 
+blocksize by a maximum of 10% of the current block size limit. These votes will
 be used to recalculate the new block size limit every 2016 blocks.
 
 Votes are cast using the block's coinbase transaction scriptSig.
@@ -98,7 +98,7 @@ If a miner votes for an increase, the block hash must meet a difficulty target
 which is proportionally larger than the standard difficulty target based on the
 percentage increase they voted for.
 
-Votes proposing decreasing the block size limit do not need to meet a higher 
+Votes proposing decreasing the block size limit do not need to meet a higher
 difficulty target.
 
 Miners can vote for no change by voting for the current block size.

web/content/105/index.md

@@ -61,14 +61,20 @@ https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&
 
 <h3>Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners</h3>
 
+
 ```
-  
   TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period
   TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty)
-  
+```
+
+
+```
   TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period
   TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty)
-  
+```
+
+
+```
   If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > TotalBlockSizeInLastButOneDifficulty) )
       MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty
   Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSizeInLastButOneDifficulty) )

web/content/106/index.md

@@ -44,7 +44,7 @@ Over the next few years, large infrastructure investments will be made into:
 1.  General efficiency improvements to transactions and the blockchain
 
 
-*  While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network. 
+*  While there is a consensus between Bitcoin developers, miners, businesses and users that the block size needs to be increased, there is a lingering concern over the potential unintended consequences that may augment the trend towards network and mining centralization (largely driven by mining hardware such as ASICs) and thereby threaten the security of the network.
 *  In contrast, failing to respond to elevated on-chain transaction volume may lead to a consumer-failure of Bitcoin, where ordinary users - having enjoyed over 6 years of submitting transactions on-chain at relatively low cost - will be priced out of blockchain with the emergence of a prohibitive 'fee market'.
 *  These two concerns must be delicately balanced so that all users can benefit from a robust, scalable, and neutral network.
 
@@ -62,7 +62,7 @@ Over the next few years, large infrastructure investments will be made into:
 *  **Phase 2**
     *  In 2020, the maximum block size will be increased dynamically according to sustained increases in transaction volume
     *  Every 4032 blocks (~4 weeks), a CHECK will be performed to determine if a raise in the maximum block size should occur
-        *  This calculates to a theoretical maximum of 13 increases per year 
+        *  This calculates to a theoretical maximum of 13 increases per year
     *  IF of the last >= 3025 blocks were >=60% full, the maximum block size will be increased by 10%
     *  The maximum block size can only ever be increased, not decreased
 *  The default `limitfreerelay` will also be raised in proportion to maximum block size increases
@@ -72,8 +72,8 @@ Over the next few years, large infrastructure investments will be made into:
 
 For example:
 *  When the dynamic rules for increasing the block size go live on January 1st 2020, the starting maximum block size will be 6 MB
-*  IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB. 
-*  The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year. 
+*  IF >=3025 blocks are >= 3.6 MB, the new maximum block size become 6.6 MB.
+*  The theoretical maximum block size at the end of 2020 would be ~20.7 MB, assuming all 13 increases are triggered every 4 weeks by the end of the year.
 
 
 <h2>Rationale</h2>
@@ -88,21 +88,21 @@ For example:
         *  Setting the parameter too high may set the trigger sensitivity too low, causing transaction delays that are trying to be avoided in the first place
         *  Between September 2013-2015, the standard deviation measured from average block size (n=730 data points from blockchain.info) was ~ 0.13 MB or 13% of the maximum block size
                 *  If blocks needed to be 90% full before an increase were triggered, normal variance in the average block size would mean some blocks would be full before an increase could be triggered
-        *  Therefore, we need a _safe distance_ away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit. 
+        *  Therefore, we need a _safe distance_ away from the maximum block size to avoid normal block size variance hitting the limit. The 60% level represents a 3 standard deviation distance from the limit.
     *  Why 3025 blocks?
         *  The assessment period is 4032 blocks or ~ 4 weeks, with the threshold set as 4032 blocks/0.75 + 1
         *  Increases in the maximum block size should only occur after a sustained trend can be observed in order to:
         *   Demonstrate a market-driven secular elevation in the transaction volume
-        *   Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions   
+        *   Increase the cost to trigger an increase by spam attacks or miner collusion with zero fee transactions
         *  In other words, increases to the maximum block size must be conservative but meaningful to relieve transaction volume pressure in response to true market demand
     *  Why 10% increase in the block size?
         *  Increases in the block size are designed to be conservative and in balance with the number of theoretical opportunities  to increase the block size per year
-        *  Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community 
+        *  Makes any resources spent for spam attacks or miner collusion relatively expensive to achieve a minor increase in the block size. A sustained attack would need to be launched that may be too costly, and ideally detectable by the community
 
 
 <h2>Deployment</h2>
 
-Similar deployment model to BIP101:  
+Similar deployment model to BIP101:
 <blockquote>Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks.</blockquote>
 
 <h2>Acknowledgements</h2>

web/content/107/index.md

@@ -94,7 +94,7 @@ SPV (simple payment validation) wallets are compatible with this change.
 <h2>Rationale</h2>
 
 
-In the short term, an increase is needed to handle increasing transaction volume. 
+In the short term, an increase is needed to handle increasing transaction volume.
 
 The limits on signature operations and amount of signature hashing done prevent possible CPU exhaustion attacks by "rogue miners" producing very expensive-to-validate two megabyte blocks. The signature hashing limit is chosen to be impossible to reach with any non-attack transaction or block, to minimize the impact on existing mining or wallet software.
 

web/content/109/index.md

@@ -95,13 +95,13 @@ address with the following redeemscript.
 ```
 
 
-At any time funds can be spent using signatures from any two of Alice, 
+At any time funds can be spent using signatures from any two of Alice,
 Bob or the Escrow.
 
 After 30 days Alice can sign alone.
 
 The clock does not start ticking until the payment to the escrow address
-confirms. 
+confirms.
 
 
 <h3>Retroactive Invalidation</h3>
@@ -277,7 +277,7 @@ The 2-way pegged sidechain requires a new REORGPROOFVERIFY opcode, the semantics
 <h2>Specification</h2>
 
 
-Refer to the reference implementation, reproduced below, for the precise 
+Refer to the reference implementation, reproduced below, for the precise
 semantics and detailed rationale for those semantics.
 
 ```
@@ -294,7 +294,7 @@ static const uint32_t SEQUENCE_LOCKTIME_TYPE_FLAG = (1 << 22);
 /* If CTxIn::nSequence encodes a relative lock-time, this mask is
  * applied to extract that lock-time from the sequence field. */
 static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
-   
+
 case OP_NOP3:
 {
     if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
@@ -337,7 +337,7 @@ case OP_NOP3:
 
     break;
 }
-    
+
 bool TransactionSignatureChecker::CheckSequence(const CScriptNum& nSequence) const
 {
     // Relative lock times are supported by comparing the passed

web/content/112/index.md

@@ -65,14 +65,17 @@ BIP68 (sequence numbers) and BIP112 (CHECKSEQUENCEVERIFY).
 <h2>Specification</h2>
 
 
-The values for transaction locktime remain unchanged. The difference is only in 
-the calculation determining whether a transaction can be included. Instead of 
-an unreliable timestamp, the following function is used to determine the current 
+The values for transaction locktime remain unchanged. The difference is only in
+the calculation determining whether a transaction can be included. Instead of
+an unreliable timestamp, the following function is used to determine the current
 block time for the purpose of checking lock-time constraints:
 
 ```
     enum { nMedianTimeSpan=11 };
-    
+```
+
+
+```
     int64_t GetMedianTimePast(const CBlockIndex* pindex)
     {
         int64_t pmedian[nMedianTimeSpan];

web/content/113/index.md

@@ -435,7 +435,7 @@ transaction preimages.
 
 
 The Taproot/Schnorr BIPs use Tagged Hashes
-(`SHA256(SHA256(tag)||SHA256(tag)||msg)`) to prevent taproot leafs, branches,
+(`SHA256(SHA256(tag)||SHA256(tag)||msg)`) to prevent taproot leaves, branches,
 tweaks, and signatures from overlapping in a way that might introduce a security
 <a href="vulnerability" target="_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016091.html</a>.
 
@@ -545,7 +545,7 @@ The preimage argument passed to CHECKTEMPLATEVERIFY may be unknown or otherwise
 However, requiring knowledge that an address is spendable from is incompatible with sender's ability
 to spend to any address (especially, OP_RETURN). If a sender needs to know the template can be spent
 from before sending, they may request a signature of an provably non-transaction challenge string
-from the leafs of the CHECKTEMPLATEVERIFY tree.
+from the leaves of the CHECKTEMPLATEVERIFY tree.
 
 <h4>Forwarding Addresses</h4>
 

web/content/119/index.md

@@ -103,7 +103,7 @@ An illustration of the PoP data structure and its original payment is shown belo
  |input2 4,ffffffff     | 1,pay to B              |
  |                      | 4,pay to C              |
  +------------------------------------------------+
- 
+
   PoP(T)
  +-------------------------------------------------------------+
  | inputs               | outputs                              |