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/