MIME-Version: 1.0
In-Reply-To: <CACV3+OU3wT6ZZ+ffUOEXpnmu9p0kf42fEBv3fPxnGPJ88BVwAg@mail.gmail.com>
References: <CACV3+OU3wT6ZZ+ffUOEXpnmu9p0kf42fEBv3fPxnGPJ88BVwAg@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
Date: Thu, 27 Apr 2017 21:41:17 +0300
Message-ID: <CAE28kUTQtU17W4xbSgOKvpBWCppoZS1B+iBs_JUAd6nYe=hcgw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11454bd06fa08b054e2a4d50
Subject: Re: [bitcoin-dev] Trustless Segwit activation bounty protocol (aka.
 bribing the miners)
Precedence: list

--001a11454bd06fa08b054e2a4d50
Content-Type: text/plain; charset=UTF-8

>
> 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.

--001a11454bd06fa08b054e2a4d50
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div>2B. If Segwit has not acti=
vated at height H, Input 1 of the Bounty Payout is not valid since it spend=
s a P2WPKH output, preventing the miner from including the Bounty Payout tr=
ansaction 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 a=
n issue since it is a very small amount).</div></div></blockquote><div><br>=
</div><div>It&#39;s a small amount by itself, but miners who are aware of B=
ounty Payout Transaction will try to include both these transactions (and b=
oth are valid both on SW and non-SW chains by definition of SW being a soft=
 fork).</div><div><br></div><div>If you set timelock of BPT to (H+1) then y=
ou 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=
.</div><div><br></div><div>Still, there is a chance that same miner will mi=
ne both blocks, so game-theoretically it makes sense to insert SAT into you=
r block since your expected payoff is positive.</div><div><br></div><div>So=
 I&#39;m afraid miners will just grab these bounties regardless of segwit a=
ctivation.</div></div></div></div>

--001a11454bd06fa08b054e2a4d50--