Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.218.44 as permitted sender)
	client-ip=209.85.218.44; envelope-from=jgarzik@bitpay.com;
	helo=mail-oi0-f44.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAE-z3OUiK_s-gJtnPquUZbG5aJkJjfo+VYKHgX+Bfcgem+6i9A@mail.gmail.com>
References: <CAE-z3OUiK_s-gJtnPquUZbG5aJkJjfo+VYKHgX+Bfcgem+6i9A@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Fri, 8 May 2015 06:00:37 -0400
Message-ID: <CAJHLa0MgiC6vMdy=zm85CE2pWkOqtk18ePjb9nZ2-KwGf+q+Mw@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=001a113deff2d3943205158f1a71
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Assurance contracts to fund the network
 with OP_CHECKLOCKTIMEVERIFY
Precedence: list

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

That reminds me - I need to integrate the patch that automatically sweeps
anyone-can-pay transactions for a miner.


On Thu, May 7, 2015 at 7:32 PM, Tier Nolan <tier.nolan@gmail.com> wrote:

> One of the suggestions to avoid the problem of fees going to zero is
> assurance contracts.  This lets users (perhaps large merchants or
> exchanges) pay to support the network.  If insufficient people pay for the
> contract, then it fails.
>
> Mike Hearn suggests one way of achieving it, but it doesn't actually
> create an assurance contract.  Miners can exploit the system to convert the
> pledges into donations.
>
> https://bitcointalk.org/index.php?topic=157141.msg1821770#msg1821770
>
> Consider a situation in the future where the minting fee has dropped to
> almost zero.  A merchant wants to cause block number 1 million to
> effectively have a minting fee of 50BTC.
>
> He creates a transaction with one input (0.1BTC) and one output (50BTC)
> and signs it using SIGHASH_ANYONE_CAN_PAY.  The output pays to OP_TRUE.
> This means that anyone can spend it.  The miner who includes the
> transaction will send it to an address he controls (or pay to fee).  The
> transaction has a locktime of 1 million, so that it cannot be included
> before that point.
>
> This transaction cannot be included in a block, since the inputs are lower
> than the outputs.  The SIGHASH_ANYONE_CAN_PAY field mean that others can
> pledge additional funds.  They add more input to add more money and the
> same sighash.
>
> There would need to be some kind of notice boeard system for these
> pledges, but if enough pledge, then a valid transaction can be created.  It
> is in miner's interests to maintain such a notice board.
>
> The problem is that it counts as a pure donation.  Even if only 10BTC has
> been pledged, a miner can just add 40BTC of his own money and finish the
> transaction.  He nets the 10BTC of the pledges if he wins the block.  If he
> loses, nobody sees his 40BTC transaction.  The only risk is if his block is
> orphaned and somehow the miner who mines the winning block gets his 40BTC
> transaction into his block.
>
> The assurance contract was supposed to mean "If the effective minting fee
> for block 1 million is 50 BTC, then I will pay 0.1BTC".  By adding his
> 40BTC to the transaction the miner converts it to a pure donation.
>
> The key point is that *other* miners don't get 50BTC reward if they find
> the block, so it doesn't push up the total hashing power being committed to
> the blockchain, that a 50BTC minting fee would achieve.  This is the whole
> point of the assurance contract.
>
> OP_CHECKLOCKTIMEVERIFY could be used to solve the problem.
>
> Instead of paying to OP_TRUE, the transaction should pay 50 BTC to "<1
> million> OP_CHECKLOCKTIMEVERIFY OP_TRUE" and 0.01BTC to "OP_TRUE".
>
> This means that the transaction could be included into a block well in
> advance of the 1 million block point.  Once block 1 million arrives, any
> miner would be able to spend the 50 BTC.  The 0.01BTC is the fee for the
> block the transaction is included in.
>
> If the contract hasn't been included in a block well in advance, pledgers
> would be recommended to spend their pledged input,
>
> It can be used to pledge to many blocks at once.  The transaction could
> pay out to lots of 50BTC outputs but with the locktime increasing by for
> each output.
>
> For high value transactions, it isn't just the POW of the next block that
> matters but all the blocks that are built on top of it.
>
> A pledger might want to say "I will pay 1BTC if the next 100 blocks all
> have at least an effective minting fee of 50BTC"
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

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

<div dir=3D"ltr">That reminds me - I need to integrate the patch that autom=
atically sweeps anyone-can-pay transactions for a miner.<br><br></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, May 7, 2015 at=
 7:32 PM, Tier Nolan <span dir=3D"ltr">&lt;<a href=3D"mailto:tier.nolan@gma=
il.com" target=3D"_blank">tier.nolan@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div><div><div>=
<div><div><div><div></div>One of the suggestions to avoid the problem of fe=
es going to zero is assurance contracts.=C2=A0 This lets users (perhaps lar=
ge merchants or exchanges) pay to support the network.=C2=A0 If insufficien=
t people pay for the contract, then it fails.<br><br></div><div>Mike Hearn =
suggests one way of achieving it, but it doesn&#39;t actually create an ass=
urance contract.=C2=A0 Miners can exploit the system to convert the pledges=
 into donations.<br><br><a href=3D"https://bitcointalk.org/index.php?topic=
=3D157141.msg1821770#msg1821770" target=3D"_blank">https://bitcointalk.org/=
index.php?topic=3D157141.msg1821770#msg1821770</a><br></div><div><br></div>=
Consider a situation in the future where the minting fee has dropped to alm=
ost zero.=C2=A0 A merchant wants to cause block number 1 million to effecti=
vely have a minting fee of 50BTC.<br><br></div>He creates a transaction wit=
h one input (0.1BTC) and one output (50BTC) and signs it using SIGHASH_ANYO=
NE_CAN_PAY.=C2=A0 The output pays to OP_TRUE.=C2=A0 This means that anyone =
can spend it.=C2=A0 The miner who includes the transaction will send it to =
an address he controls (or pay to fee).=C2=A0 The transaction has a locktim=
e of 1 million, so that it cannot be included before that point.<br><br></d=
iv><div>This transaction cannot be included in a block, since the inputs ar=
e lower than the outputs.=C2=A0 The SIGHASH_ANYONE_CAN_PAY field mean that =
others can pledge additional funds.=C2=A0 They add more input to add more m=
oney and the same sighash.=C2=A0 <br><br></div><div>There would need to be =
some kind of notice boeard system for these pledges, but if enough pledge, =
then a valid transaction can be created.=C2=A0 It is in miner&#39;s interes=
ts to maintain such a notice board.<br></div><div><br></div>The problem is =
that it counts as a pure donation.=C2=A0 Even if only 10BTC has been pledge=
d, a miner can just add 40BTC of his own money and finish the transaction.=
=C2=A0 He nets the 10BTC of the pledges if he wins the block.=C2=A0 If he l=
oses, nobody sees his 40BTC transaction.=C2=A0 The only risk is if his bloc=
k is orphaned and somehow the miner who mines the winning block gets his 40=
BTC transaction into his block.<br><br></div>The assurance contract was sup=
posed to mean &quot;If the effective minting fee for block 1 million is 50 =
BTC, then I will pay 0.1BTC&quot;.=C2=A0 By adding his 40BTC to the transac=
tion the miner converts it to a pure donation.<br><br></div>The key point i=
s that <u>other</u> miners don&#39;t get 50BTC reward if they find the bloc=
k, so it doesn&#39;t push up the total hashing power being committed to the=
 blockchain, that a 50BTC minting fee would achieve.=C2=A0 This is the whol=
e point of the assurance contract.<br><br></div><div>OP_CHECKLOCKTIMEVERIFY=
 could be used to solve the problem.<br><br></div><div>Instead of paying to=
 OP_TRUE, the transaction should pay 50 BTC to &quot;&lt;1 million&gt; OP_C=
HECKLOCKTIMEVERIFY OP_TRUE&quot; and 0.01BTC to &quot;OP_TRUE&quot;.<br><br=
></div><div>This means that the transaction could be included into a block =
well in advance of the 1 million block point.=C2=A0 Once block 1 million ar=
rives, any miner would be able to spend the 50 BTC.=C2=A0 The 0.01BTC is th=
e fee for the block the transaction is included in.<br></div><div><br></div=
><div></div><div>If the contract hasn&#39;t been included in a block  well =
in advance, pledgers would be recommended to spend their pledged input, <br=
><br></div><div>It can be used to pledge to many blocks at once.=C2=A0 The =
transaction could pay out to lots of 50BTC outputs but with the locktime in=
creasing by for each output.=C2=A0 <br><br>For high value transactions, it =
isn&#39;t just the POW of the next block that matters but all the blocks th=
at are built on top of it.=C2=A0 <br><br>A pledger might want to say &quot;=
I will pay 1BTC if the next 100 blocks all have at least an effective minti=
ng fee of 50BTC&quot;<br></div></div></div></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature">Jeff Garzik<br>Bitcoin core developer and open source evangelis=
t<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.com/" targe=
t=3D"_blank">https://bitpay.com/</a></div>
</div>

--001a113deff2d3943205158f1a71--