From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yqf5e-0001Hf-7Z for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 10:01:06 +0000 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; Received: from mail-oi0-f44.google.com ([209.85.218.44]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yqf5b-0002UJ-RE for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 10:01:06 +0000 Received: by oift201 with SMTP id t201so54688511oif.3 for ; Fri, 08 May 2015 03:00:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=p4KnabVnTDpvxeKqWC6i4UfwzR98rp2znEGUMLFrCOg=; b=Sn0pHqzHD82UPtlydxa4tNM8Ry4UIcEgsQ6RGmnyXeyrYb/dPbXPCJ3SeBDYnVIGFk AfVyRlMjgjn4it8skPAy5ApSXgfSUEJSvaQizJLP8l2Tr1FKbNjxBtC4re8LuMCmczKL 1oHXH0IHs4mKb01CeJrdBxSEmwilffWVzY/qP+tTWcHYake5/m9tF7TZyld0CevUQPcq 5M5wq4j0By/8iPtZIix46wOwvLl3vm+9JeeeKsvZOY9Z32HhBPSxMra0gTMY9eGnh/VK RdKYsdxWDHMW5Vm8YX1qiyX5pt6vL67lWryL5SEUHKlmUXxvBfYiHbOWk6mPO8G+8rHg s5bQ== X-Gm-Message-State: ALoCoQmXQwvRiMaosyx817a75g2M42u5dlOgKf2JhfHeyBLP8hywlDShkHPEwTedO+Vkm7O/agKl X-Received: by 10.202.83.202 with SMTP id h193mr2308163oib.56.1431079258119; Fri, 08 May 2015 03:00:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.108.149 with HTTP; Fri, 8 May 2015 03:00:37 -0700 (PDT) In-Reply-To: References: From: Jeff Garzik Date: Fri, 8 May 2015 06:00:37 -0400 Message-ID: To: Tier Nolan Content-Type: multipart/alternative; boundary=001a113deff2d3943205158f1a71 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 AC_DIV_BONANZA RAW: Too many divs in a row... spammy template -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Yqf5b-0002UJ-RE Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 10:01:06 -0000 --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 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
That reminds me - I need to integrate the patch that autom= atically 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 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.

Mike Hearn = suggests one way of achieving it, but it doesn't actually create an ass= urance contract.=C2=A0 Miners can exploit the system to convert the pledges= into donations.

https://bitcointalk.org/= index.php?topic=3D157141.msg1821770#msg1821770

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

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.

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

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's interes= ts to maintain such a notice board.

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.

The assurance contract was sup= posed to mean "If the effective minting fee for block 1 million is 50 = BTC, then I will pay 0.1BTC".=C2=A0 By adding his 40BTC to the transac= tion the miner converts it to a pure donation.

The key point i= s that other miners don't get 50BTC reward if they find the bloc= k, so it doesn'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.

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_C= HECKLOCKTIMEVERIFY 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.=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.

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.=C2=A0 The = transaction could pay out to lots of 50BTC outputs but with the locktime in= creasing by for each output.=C2=A0

For high value transactions, it = isn't just the POW of the next block that matters but all the blocks th= at are built on top of it.=C2=A0

A pledger might want to say "= I will pay 1BTC if the next 100 blocks all have at least an effective minti= ng 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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment




--
Jeff Garzik
Bitcoin core developer and open source evangelis= t
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--001a113deff2d3943205158f1a71--