From 83596de8ca76a3873ea993fc806ede761b07d874 Mon Sep 17 00:00:00 2001
From: "Wladimir J. van der Laan" <laanwj@gmail.com>
Date: Mon, 18 Jul 2016 08:13:15 +0200
Subject: bip141: Change 'block cost' to 'block weight'

The term 'block cost' led to confusion about the unit that it is
expressed in, in that it expressed monetary cost. Change it to a more
general term 'block weight'.

This was discussed in the [2016-07-14 Bitcoin Core developer meeting](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-14-19.00.html).
---
 bip-0141.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'bip-0141.mediawiki')

diff --git a/bip-0141.mediawiki b/bip-0141.mediawiki
index 8fdc795..497cf7e 100644
--- a/bip-0141.mediawiki
+++ b/bip-0141.mediawiki
@@ -108,13 +108,13 @@ If the version byte is 1 to 16, no further interpretation of the witness program
 
 Blocks are currently limited to 1,000,000 bytes (1MB) total size. We change this restriction as follows:
 
-''Block cost'' is defined as ''Base size'' * 3 + ''Total size''. (rationale<ref>Rationale of using a single composite constraint, instead of two separate limits such as 1MB base data and 3MB witness data: Using two separate limits would make mining and fee estimation nearly impossible. Miners would need to solve a complex non-linear optimization problem to find the set of transactions that maximize fees given both constraints, and wallets would not be able to know what to pay as it depends on which of the two conditions is most constrained by the time miners try to produce blocks with their transactions in. Another problem with such an approach is freeloading. Once a set of transactions hit the base data 1MB constraint, up to 3MB extra data could be added to the witness by just minimally increasing the fee. The marginal cost for extra witness space effectively becomes zero in that case.</ref>)
+''Block weight'' is defined as ''Base size'' * 3 + ''Total size''. (rationale<ref>Rationale of using a single composite constraint, instead of two separate limits such as 1MB base data and 3MB witness data: Using two separate limits would make mining and fee estimation nearly impossible. Miners would need to solve a complex non-linear optimization problem to find the set of transactions that maximize fees given both constraints, and wallets would not be able to know what to pay as it depends on which of the two conditions is most constrained by the time miners try to produce blocks with their transactions in. Another problem with such an approach is freeloading. Once a set of transactions hit the base data 1MB constraint, up to 3MB extra data could be added to the witness by just minimally increasing the fee. The marginal cost for extra witness space effectively becomes zero in that case.</ref>)
 
 ''Base size'' is the block size in bytes with the original transaction serialization without any witness-related data, as seen by a non-upgraded node.
 
 ''Total size'' is the block size in bytes with transactions serialized as described in [[bip-0144.mediawiki|BIP144]], including base data and witness data.
 
-The new rule is ''block cost'' ≤ 4,000,000.
+The new rule is ''block weight'' ≤ 4,000,000.
 
 ==== Sigops ====
 
-- 
cgit v1.2.3

