Assign BIP 145: getblocktemplate Updates for Segregated Witness

1 files changed, 98 insertions, 0 deletions

diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki
new file mode 100644
index 0000000..9274b6c
--- /dev/null
+++ b/bip-0145.mediawiki
@@ -0,0 +1,98 @@
+<pre>
+  BIP: 145
+  Title: getblocktemplate Updates for Segregated Witness
+  Author: Luke Dashjr <luke+bip22@dashjr.org>
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-01-30
+</pre>
+
+==Abstract==
+
+This BIP describes modifications to the getblocktemplate JSON-RPC call ([[bip-0022.mediawiki|BIP 22]]) to support segregated witness as defined by [[bip-0141.mediawiki|BIP 141]].
+
+==Specification==
+
+The notion of "cost" is introduced 
+
+===Block Template===
+
+The template Object is revised to include these keys:
+
+{| class="wikitable"
+!colspan=4| template
+|-
+! Key !! Required !! Type !! Description
+|-
+| costlimit || {{No}} || Number || total cost allowed in blocks
+|-
+| sigoplimit || {{No}} || Number || total sigop cost allowed in blocks divided by 4
+|-
+| version || {{Yes}} || Number || block version; clients MUST understand the implications of the version they use (eg, comply with [[bip-0141.mediawiki|BIP 141]] for version 5)
+|}
+
+====Transactions Object Format====
+
+The Objects listed in the response's "transactions" key is revised to include these keys:
+
+{| class="wikitable"
+!colspan=3|template "transactions" element
+|-
+! Key !! Type !! Description
+|-
+| txid || String || transaction id encoded in hexadecimal; required for transactions with witness data
+|-
+| cost || Number || numeric cost of the transaction, as counted for purposes of the block's costlimit; if key is not present, cost is unknown and clients MUST NOT assume it is zero, although they MAY choose to calculate it themselves
+|-
+| hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal
+|}
+
+Transactions with witness data may only be included if the template's block version is at least 5.
+
+===Block Assembly with Witness Transactions===
+
+When block assembly is done without witness transactions, no changes are made by this BIP, and it should be assembled as previously.
+
+When witness transactions are included in the block, the primary merkle root MUST be calculated with those transactions' "txid" field instead of "hash". A secondary merkle root MUST be calculated as per [[bip-0141.mediawiki#Commitment_structure|BIP 141's commitment structure specification]] to be inserted into the generation (coinbase) transaction.
+
+Servers MUST NOT include a commitment in the "coinbasetxn" key on the template. Clients MUST insert the commitment as an additional output at the end of the final generation (coinbase) transaction. Only if the template includes a "mutable" key (see [[bip-0023.mediawiki#Mutations|BIP 23 Mutations]]) including "generation", the client MAY in that case place the commitment output in any position it chooses, provided that no later output matches the commitment pattern.
+
+==Motivation==
+
+Segregated witness substantially changes the structure of blocks, so the previous getblocktemplate specification is no longer sufficient.
+It additionally also adds a new way of counting resource limits, and so GBT must be extended to convey this information correctly as well.
+
+==Rationale==
+
+Why doesn't "costlimit" simply redefine the existing "sizelimit"?
+* "sizelimit" is already enforced by clients by counting the sum of bytes in transactions' "data" keys.
+* Servers may wish to limit the overall size of a block, independently from the "cost" of the block.
+
+Why is "sigoplimit" redefined instead of a new "sigopcostlimit" being added?
+* The old limit was already arbitrarily defined, and could not be counted by clients on their own anyway. The concept of "sigop cost" is merely a change in the arbitrary formula used.
+
+Why is "sigoplimit" divided by 4?
+* To resemble the previous values. (FIXME: is this a good reason? maybe we shouldn't divide it?)
+
+Why is the witness commitment required to be added to the end of the generation transaction rather than anywhere else?
+* Servers which do not allow modification of the generation outputs ought to be checking this as part of the validity of submissions. By requiring a specific placement, they can simply strip the commitment and do a byte-for-byte comparison of the outputs. Placing it at the end avoids the possibility of a later output matching the pattern and overriding it.
+
+Why shouldn't the server simply add the commitment upfront in the "coinbasetxn", and simply send the client stripped transaction data?
+* It would become impossible for servers to specify only "coinbasevalue", since clients would no longer have the information required to construct the commitment.
+* getblocktemplate is intended to be a *decentralised* mining protocol, and allowing clients to be blinded to the content of the block works contrary to that purpose.
+* BIP 23's "transactions" mutations allow the client to modify the transaction-set on their own, which is impossible without the complete transaction data.
+
+==Reference Implementation==
+
+* [https://github.com/bitcoin/libblkmaker/tree/segwit libblkmaker]
+* [https://github.com/luke-jr/eloipool/tree/segwit Eloipool]
+* [https://github.com/bitcoin/bitcoin/pull/7404/files Bitcoin Core]
+
+==See Also==
+* [[bip-0022.mediawiki|BIP 22: getblocktemplate - Fundamentals]]
+* [[bip-0023.mediawiki|BIP 23: getblocktemplate - Pooled Mining]]
+* [[bip-0141.mediawiki|BIP 141: Segregated Witness (Consensus layer)]]
+
+==Copyright==
+
+This BIP is dual-licensed under the Open Publication License and BSD 2-clause license.