I wonder if that would be a viable way for payment services to pay to
protect against double spending.

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.

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.

It kind of works like insurance.  The payment processor combines lots of
small double spend threats and protects them with a single transaction.

The processor could keep sending out a larger and large transaction (with
fee) until eventually a block is found.

It requires RBF.  First seen safe would be incompatible, if the double
spender gets their transaction into the system first.

A 1BTC fee transaction in nearly every block would also be a boost for
network security.

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.

On Thu, Jul 2, 2015 at 5:57 AM, Matt Whitlock <bip@mattwhitlock.name> wrote:

> 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.
>
>
> On Wednesday, 1 July 2015, at 9:52 pm, Mark Friedenbach wrote:
> > This is called child pays for parent and there is a three year old pull
> > request implementing it:
> >
> > https://github.com/bitcoin/bitcoin/pull/1647
> >
> > The points regarding sweep transaction UI is out of scope for a BIP I'm
> > afraid. I suggest talking with wallet authors, and if agreement can be
> > found writing a pull request.
> > On Jul 1, 2015 9:44 PM, "Dan Bryant" <dkbryant@gmail.com> wrote:
> >
> > > This is a process BIP request to add functionality to the Bitcoin-Core
> > > reference implementation.  If accepted, this could also add
> > > flexibility into any future fee schedules.
> > >
> > > https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>