From: Jeff Garzik <jgarzik@bitpay•com>
To: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY
Date: Fri, 8 May 2015 06:00:37 -0400 [thread overview]
Message-ID: <CAJHLa0MgiC6vMdy=zm85CE2pWkOqtk18ePjb9nZ2-KwGf+q+Mw@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OUiK_s-gJtnPquUZbG5aJkJjfo+VYKHgX+Bfcgem+6i9A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4374 bytes --]
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/
[-- Attachment #2: Type: text/html, Size: 5512 bytes --]
next prev parent reply other threads:[~2015-05-08 10:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 23:32 Tier Nolan
2015-05-08 9:49 ` Mike Hearn
2015-05-08 10:01 ` Benjamin
2015-05-08 14:15 ` Tier Nolan
2015-05-08 14:54 ` Benjamin
2015-05-08 14:56 ` Tier Nolan
2015-05-08 15:03 ` Tier Nolan
2015-05-08 10:00 ` Jeff Garzik [this message]
2015-05-08 16:43 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJHLa0MgiC6vMdy=zm85CE2pWkOqtk18ePjb9nZ2-KwGf+q+Mw@mail.gmail.com' \
--to=jgarzik@bitpay$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=tier.nolan@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox