Published on: 2016-02-02T02:30:55+00:00
The discussion revolves around the inclusion of the "default_witness_commitment" in the standard protocol. One argument against including it is that it may lead to centralization of mining pools and make server-side implementation more susceptible to DoS attacks. However, there is also an argument for including it to simplify initial adoption and have a known-correct value to use. It is mentioned that libblkmaker can handle the heavy lifting for mining software. Ultimately, the decision to include or exclude "default_witness_commitment" depends on the specific implementation and goals.In the email exchange between Luke Dashjr and Cory Fields, they discuss the default witness commitment for GBT (GetBlockTemplate) protocol. Dashjr argues that including it could enable centralization, while Fields suggests that providing a known-working commitment would be beneficial for adoption. Dashjr expresses concerns about security and suggests leaving out the default witness commitment from the standard protocol. Fields seeks clarification on potential DoS vectors and the use of libblkmaker. Dashjr reassures that the burden on mining software is not significant and that libblkmaker can handle the heavy lifting. He also mentions the need to consider the sign bit when serializing heights and the risk of introducing bugs into working code.The conversation on February 1, 2016, between Cory Fields and Luke Dashjr delves into the use of "default_witness_commitment" within the GBT protocol. Dashjr argues against including it in the standard protocol, as it contradicts GBT's design principles by enabling and encouraging centralization. Fields raises the point that providing a known-working commitment can simplify the process. Dashjr acknowledges this but emphasizes the potential for bugs. They also discuss a bug introduced by ckpool, where a positive number was serialized as a signed one.Another discussion between Luke Dashjr and Cory Fields focuses on the omission of the "default_witness_commitment" key in the Bitcoin protocol. Fields believes that omitting it would encourage pools to build their own commitment, while Dashjr argues that it could increase vulnerability to DoS attacks. Dashjr suggests leaving it as a bitcoind-specific extension to promote adoption but recommends keeping it out of the standard protocol for now. Fields expresses concerns about the burden on mining software and the risk of bugs, but Dashjr highlights the capability of libblkmaker to handle the heavy lifting. Fields mentions fixing serialization or commitment creation bugs in mining/pool software.The email conversation discusses the absence of the "default_witness_commitment" key in the current reference implementation. The omission allows clients to create the commitment themselves instead of having it provided. However, this simplicity can encourage laziness and complicate server-side implementation, making it more vulnerable to DoS attacks. The burden on mining software increases, raising the odds of bugs. It is mentioned that serialization or commitment creation bugs related to mining/pool software have already been fixed in SegWit.Luke Dashjr has drafted a BIP for updating getblocktemplate for segregated witness. The draft does not include the "default_witness_commitment" key present in the current reference implementation. This omission allows clients to create their commitment instead of relying on provided values. However, excluding the key increases the burden on mining software and the likelihood of bugs. Cory supports this argument and plans to submit the change to the BIP, enabling mining software to handle more serialization and complex structure calculations. Links to related sources are provided.Luke-jr has announced the creation of an initial draft for a BIP regarding getblocktemplate for segregated witness. The draft is available on GitHub, and Luke-jr invites others to review and comment on the changes made, particularly with regard to sigoplimits handling. However, he notes that libblkmaker's reference implementation is currently incompatible with the "last output" rule in this BIP. Luke-jr expresses gratitude in advance for any feedback received.
Updated on: 2023-08-01T17:41:26.093139+00:00