Re: [bitcoin-dev] Trustless Segwit activation bounty protocol (aka. bribing the miners)
Good morning all, As other explained, your scheme is broken. Unless we have a softfork first (OP_CHECKBIP9VERIFY: payment is valid only if a BIP9 proposal is active), it is not possible to create a softfork bounty in a decentralised way On the other hand, hardfork bounty is very simple. You just need to make sure your tx violates existing rules Perhaps, it's possible to invert the logic. When considering a softfork success/fail, the difference is this: There exists some tx, where if the softfork fails, the tx is valid, and if the softfork succeeds, the tx is invalid. So, an economic agent who wishes to push for a softork, can instead do: 1. Select block heights H1 and H2, where H1 < H2. 2. Create a valid Funding tx (valid in both softfork-pass and softfork-fail) with a single output, encumbered by the contract (CLTV H1 AND k1) OR (CLTV H2 AND k2), and transmit and put in block. 3. Create a Softfork Failure Refund tx. This tx has to be invalid if the softfork succeeds, but valid if the softfork fails. It provides k1, and is spendable on height H1. It outputs back to the economic agent. 4. Create a Softfork Success Payout tx. This tx has to be valid if the softfork fails. It outputs 0 to the economic agent, allowing any miner who includes it to get the payout as tx fee. If at block H1, softfork has passed, then the Softfork Failure Refund tx is invalid and cannot be used by the economic agent to spend the output. The miners can then wait for block H2 to include Softfork Success Payout tx in a block and claim the tx fee. The risk here for the miners is that since k2 is generated by the economic agent, the economic agent can create a different tx spending that output before H2. If at block H1, softfork has failed, then the Softfork Failure Refund is valid and the economic agent can get the Funding tx's output back to a normal output. The risk here for the economic agent is that miners can form a cartel to informally ignore the Softfork Failure Refund until block H2. Regards, ZmnSCPxj___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Trustless Segwit activation bounty protocol (aka. bribing the miners)
As other explained, your scheme is broken. Unless we have a softfork first (OP_CHECKBIP9VERIFY: payment is valid only if a BIP9 proposal is active), it is not possible to create a softfork bounty in a decentralised way On the other hand, hardfork bounty is very simple. You just need to make sure your tx violates existing rules > On 28 Apr 2017, at 01:48, Matt Bell via bitcoin-dev >wrote: > > Hello everyone, > > I've been thinking of an alternative to possibly get Segwit activated sooner: > bribing the miners. This proposal may not be necessary if everyone is already > set on doing a UASF, but miners seem to optimize for short-term profits and > this may make it easier for BitMain to accept its fate in losing the > ASICBoost advantage. > > Here is a possible trustless contract protocol where contributors could > pledge to a Segwit bounty which would be paid out to miners iff Segwit is > activated, else the funds are returned to the contributor: > > # Setup > > - The contributor picks a possible future height where Segwit may be > activated and when the funds should be released, H. > - The contributor chooses a bounty contribution amount X. > - The contributor generates 3 private keys (k1, k2, and k3) and corresponding > pubkeys (K1, K2, and K3). > - The contributor creates and broadcasts the Funding Transaction, which has 2 > outputs: > * Output 0, X BTC, P2SH redeem script: > CHECKLOCKTIMEVERIFY DROP > CHECKSIGVERIFY > * Output 1, 0.1 BTC, P2SH redeem script: > CHECKLOCKTIMEVERIFY DROP > CHECKSIGVERIFY > - The contributor builds the Segwit Assertion Transaction: > * nTimeLock set to H > * Input 0, spends from Funding Transaction output 1, signed with k2, > SIGHASH_ALL > * Output 0, 0.1 BTC, P2WPKH using K3 > - The contributor builds the Bounty Payout Transaction: > * nTimeLock set to H > * Input 0, spends from Funding Transaction output 0, signed with k1, > SIGHASH_ALL > * Input 1, spends from Segwit Assertion Transaction output 0, signed with > k3, SIGHASH_ALL > * No outputs, all funds are paid to the miner > - The contributor publishes the Segwit Assertion Transaction and Bounty > Payout Transaction (with signatures) somewhere where miners can find them > > # Process > > 1. After the setup, miners can find Funding Transactions confirmed on the > chain, and verify the other 2 transactions are correct and have valid > signatures. They can sum all the valid bounty contracts they find to factor > into their expected mining profit. > 2A. Once the chain reaches height H-1, if Segwit has activated, miners can > claim the bounty payout by including the Segwit Assertion and Bounty Payout > transactions in their block H. Since Segwit has activated, the output from > the Segwit Assertion tx can be spent by the Bounty Payout, so both > transactions are valid and the miner receives the funds. > 2B. If Segwit has not activated at height H, Input 1 of the Bounty Payout is > not valid since it spends a P2WPKH output, preventing the miner from > including the Bounty Payout transaction in the block. (However, the output of > the Segwit Assertion tx can be claimed since it is treated as > anyone-can-spend, although this is not an issue since it is a very small > amount). The contributor can reclaim the funds from Output 0 of the Funding > tx by creating a new transaction, signed with k1. > > # Notes > > - This is likely a win-win scenario for the contributors, since Segwit > activating will likely increase the price of Bitcoin, which gives a positive > return if the price increases enough. If it does not activate, the funds will > be returned so nothing is at risk. > - Contributors could choose H heights on or slightly after an upcoming > possible activation height. If contributors pay out to many heights, then the > bounty can be split among many miners, it doesn't have to be winner-take-all. > - If Segwit does not activate at H, the contributor has until the next > possible activation height to claim their refund without risking it being > taken by another miner. This could be outsourced by signing a refund > transaction which pays a fee to some third-party who will be online at H and > can broadcast the transaction. If the contributor wants to pay a bounty for a > later height, they should create a new contract otherwise a miner could > invalidate the payout by spending the output of the Segwit Assertion. > > Thanks, I'd like to hear everyone's thoughts. Let me know if you find any > glaring flaws or have any other comments. > Matt > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org
Re: [bitcoin-dev] Trustless Segwit activation bounty protocol (aka. bribing the miners)
On 27/04/17 18:48, Matt Bell via bitcoin-dev wrote: * No outputs, all funds are paid to the miner A transaction _must_ have at least one output [1]. You can get the same effect by adding a 0 satoshis OP_RETURN output. [1]: https://github.com/bitcoin/bitcoin/blob/a6548a47a5548b4b43510c548a9418673ab751de/src/validation.cpp#L465 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Trustless Segwit activation bounty protocol (aka. bribing the miners)
> > 2B. If Segwit has not activated at height H, Input 1 of the Bounty Payout > is not valid since it spends a P2WPKH output, preventing the miner from > including the Bounty Payout transaction in the block. (However, the output > of the Segwit Assertion tx can be claimed since it is treated as > anyone-can-spend, although this is not an issue since it is a very small > amount). > It's a small amount by itself, but miners who are aware of Bounty Payout Transaction will try to include both these transactions (and both are valid both on SW and non-SW chains by definition of SW being a soft fork). If you set timelock of BPT to (H+1) then you sort of discourage this behavior because a miner of block H might be not the same as miner of block (H+1), thus he cannot grab this bounty for sure. Still, there is a chance that same miner will mine both blocks, so game-theoretically it makes sense to insert SAT into your block since your expected payoff is positive. So I'm afraid miners will just grab these bounties regardless of segwit activation. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Trustless Segwit activation bounty protocol (aka. bribing the miners)
> > 2B. If Segwit has not activated at height H, Input 1 of the Bounty Payout > is not valid since it spends a P2WPKH output > If SegWit has not activated at height H, P2WPKH is an "anyone can spend" output. SegWit is a soft fork, all SegWit transactions must be interpreted as valid by old nodes. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Trustless Segwit activation bounty protocol (aka. bribing the miners)
Hello everyone, I've been thinking of an alternative to possibly get Segwit activated sooner: bribing the miners. This proposal may not be necessary if everyone is already set on doing a UASF, but miners seem to optimize for short-term profits and this may make it easier for BitMain to accept its fate in losing the ASICBoost advantage. Here is a possible trustless contract protocol where contributors could pledge to a Segwit bounty which would be paid out to miners iff Segwit is activated, else the funds are returned to the contributor: # Setup - The contributor picks a possible future height where Segwit may be activated and when the funds should be released, H. - The contributor chooses a bounty contribution amount X. - The contributor generates 3 private keys (k1, k2, and k3) and corresponding pubkeys (K1, K2, and K3). - The contributor creates and broadcasts the Funding Transaction, which has 2 outputs: * Output 0, X BTC, P2SH redeem script: CHECKLOCKTIMEVERIFY DROP CHECKSIGVERIFY * Output 1, 0.1 BTC, P2SH redeem script: CHECKLOCKTIMEVERIFY DROP CHECKSIGVERIFY - The contributor builds the Segwit Assertion Transaction: * nTimeLock set to H * Input 0, spends from Funding Transaction output 1, signed with k2, SIGHASH_ALL * Output 0, 0.1 BTC, P2WPKH using K3 - The contributor builds the Bounty Payout Transaction: * nTimeLock set to H * Input 0, spends from Funding Transaction output 0, signed with k1, SIGHASH_ALL * Input 1, spends from Segwit Assertion Transaction output 0, signed with k3, SIGHASH_ALL * No outputs, all funds are paid to the miner - The contributor publishes the Segwit Assertion Transaction and Bounty Payout Transaction (with signatures) somewhere where miners can find them # Process 1. After the setup, miners can find Funding Transactions confirmed on the chain, and verify the other 2 transactions are correct and have valid signatures. They can sum all the valid bounty contracts they find to factor into their expected mining profit. 2A. Once the chain reaches height H-1, if Segwit has activated, miners can claim the bounty payout by including the Segwit Assertion and Bounty Payout transactions in their block H. Since Segwit has activated, the output from the Segwit Assertion tx can be spent by the Bounty Payout, so both transactions are valid and the miner receives the funds. 2B. If Segwit has not activated at height H, Input 1 of the Bounty Payout is not valid since it spends a P2WPKH output, preventing the miner from including the Bounty Payout transaction in the block. (However, the output of the Segwit Assertion tx can be claimed since it is treated as anyone-can-spend, although this is not an issue since it is a very small amount). The contributor can reclaim the funds from Output 0 of the Funding tx by creating a new transaction, signed with k1. # Notes - This is likely a win-win scenario for the contributors, since Segwit activating will likely increase the price of Bitcoin, which gives a positive return if the price increases enough. If it does not activate, the funds will be returned so nothing is at risk. - Contributors could choose H heights on or slightly after an upcoming possible activation height. If contributors pay out to many heights, then the bounty can be split among many miners, it doesn't have to be winner-take-all. - If Segwit does not activate at H, the contributor has until the next possible activation height to claim their refund without risking it being taken by another miner. This could be outsourced by signing a refund transaction which pays a fee to some third-party who will be online at H and can broadcast the transaction. If the contributor wants to pay a bounty for a later height, they should create a new contract otherwise a miner could invalidate the payout by spending the output of the Segwit Assertion. Thanks, I'd like to hear everyone's thoughts. Let me know if you find any glaring flaws or have any other comments. Matt ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev