<div dir="ltr"><div><div>I wonder if that would be a viable way for payment services to pay to protect against double spending.<br><br></div>If the payment processor was handling 1000 BTC every block and was willing to pay 0.1% fees, then it could create a transaction with 1BTC in fees. <br><br></div><div>If an attacker tried to double spend a transaction of 0.1BTC, then even if he was to spend the entire transaction to fees, the payment processor would be able to out bid him.<br><br></div><div>It kind of works like insurance. The payment processor combines lots of small double spend threats and protects them with a single transaction.<br><br></div><div>The processor could keep sending out a larger and large transaction (with fee) until eventually a block is found.<br><br></div><div>It requires RBF. First seen safe would be incompatible, if the double spender gets their transaction into the system first.<br><br></div><div>A 1BTC fee transaction in nearly every block would also be a boost for network security.<br><br></div><div>It avoids Peter Todd's complaint that mining pools might make secret deals with payment services. The transaction would be public and all miners could include it in their block.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 2, 2015 at 5:57 AM, Matt Whitlock <span dir="ltr"><<a href="mailto:bip@mattwhitlock.name" target="_blank">bip@mattwhitlock.name</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">PR#1647 only addresses miner policy, though, right? I believe the BIP is addressing the user-facing side of this functionality. CPFP mining policy does very little good if wallets don't offer any way for users to goose up incoming transactions.<br>
<span class="im HOEnZb"><br>
<br>
On Wednesday, 1 July 2015, at 9:52 pm, Mark Friedenbach wrote:<br>
> This is called child pays for parent and there is a three year old pull<br>
> request implementing it:<br>
><br>
> <a href="https://github.com/bitcoin/bitcoin/pull/1647" rel="noreferrer" target="_blank">https://github.com/bitcoin/bitcoin/pull/1647</a><br>
><br>
> The points regarding sweep transaction UI is out of scope for a BIP I'm<br>
> afraid. I suggest talking with wallet authors, and if agreement can be<br>
> found writing a pull request.<br>
> On Jul 1, 2015 9:44 PM, "Dan Bryant" <<a href="mailto:dkbryant@gmail.com">dkbryant@gmail.com</a>> wrote:<br>
><br>
> > This is a process BIP request to add functionality to the Bitcoin-Core<br>
> > reference implementation. If accepted, this could also add<br>
> > flexibility into any future fee schedules.<br>
> ><br>
> > <a href="https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki" rel="noreferrer" target="_blank">https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki</a><br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>