Published on: 2017-04-27T21:05:47+00:00
In a recent discussion, the possibility of creating bounties for softforks and hardforks was explored. It was highlighted that in a decentralized system, it is not feasible to create a bounty for a softfork unless there is a softfork implemented first. However, creating a bounty for a hardfork is relatively simple by ensuring that the transaction violates existing rules.To address this limitation, an alternative approach was suggested. Economic agents who wish to push for a softfork can select specific block heights (H1 and H2), where H1 precedes the activation of the proposed softfork and H2 follows it. They can then offer a bounty to the first person who creates a transaction that is valid at H1 but invalid at H2.Another proposal discussed involved activating Segwit through bribing miners. A trustless contract protocol was suggested, wherein contributors would pledge to a Segwit bounty. If Segwit is activated, the funds would be paid out to the miners, otherwise they would be returned to the contributors. The protocol entails the creation of three private keys and corresponding pubkeys, as well as the generation of a Funding Transaction with two outputs. Additionally, a Segwit Assertion Transaction and a Bounty Payout Transaction would be created. Miners can verify the correctness and validity of these transactions once Funding Transactions are confirmed on the blockchain. If Segwit activates at height H-1, miners can claim the bounty payout by including the Segwit Assertion and Bounty Payout transactions in their block H. On the other hand, if Segwit does not activate at height H, Input 1 of the Bounty Payout becomes invalid, preventing inclusion of the Bounty Payout transaction in the block. In such cases, contributors can reclaim the funds from Output 0 of the Funding tx by creating a new transaction signed with k1. This proposal is considered advantageous for contributors, as the activation of Segwit is likely to increase the price of Bitcoin, resulting in a positive return if the price rises sufficiently.During the discussion, the concept of transactions without any outputs was raised. However, it was pointed out that according to the validation.cpp file in the Bitcoin GitHub repository, a transaction must have at least one output. Nonetheless, a similar effect can be achieved by adding an OP_RETURN output with 0 satoshis.In the context of Segwit activation, if Segwit has not been activated at height H, Input 1 of the Bounty Payout becomes invalid as it spends a P2WPKH output. This prevents miners from including the Bounty Payout transaction in their block. However, the output of the Segwit Assertion transaction can still be claimed, as it is treated as an "anyone-can-spend" output. Although the amount may be small, miners who are aware of the Bounty Payout Transaction will attempt to include both transactions, as they are valid on both Segwit and non-Segwit chains due to the nature of Segwit being a soft fork. By setting the timelock of the Bounty Payout Transaction to (H+1), the miner of Block H may not be the same as the miner of Block (H+1), reducing the guarantee of capturing the bounty. However, there is still a possibility that the same miner may mine both blocks, making it strategically sensible to include the transaction since the expected payoff is positive. Consequently, miners may still strive to claim these bounties regardless of Segwit activation.In summary, it is evident that the activation of Segwit at a specific height plays a crucial role in determining the validity of certain transactions. Various proposals, such as implementing bounties for softforks and hardforks or bribing miners to activate Segwit, have been discussed. These proposals aim to incentivize desirable outcomes within the Bitcoin ecosystem while considering the potential benefits and risks involved.
Updated on: 2023-08-01T20:31:59.647539+00:00