Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F02FBCC for ; Thu, 2 Jul 2015 13:13:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6DF6C1C3 for ; Thu, 2 Jul 2015 13:13:36 +0000 (UTC) Received: by qkbp125 with SMTP id p125so51125934qkb.2 for ; Thu, 02 Jul 2015 06:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=09Oc1+6Ocq+rNo4j8k9is9alhPY7Nk8mKhS333Cyx/w=; b=DIsEEHiTNrbjiIokg3lnlm6EFDpZdM7/hGSU8/KWmD2kTAOQPb+twYSeSTHeT7s0XG qEyPrBWlaL7zv7jWV8wvgNT/Ca14kVdTihEdDC95ZxXeeK2rgyiMuA2oImwtEiMg7JJf npND7O8/gPKLhQePqUAA3zFZovXgsLeFytNlDKR7JRgLuL4ICdA/cs1wSlhuXDEsWXqZ v0A/1yWP0BMTXFH4FZPIrV7u0j5x76l25s2Nq1rdlc+d9peOJ8jPeWss/MyGI1/KRl2X dktVU4+azhh6KgiLqfDwm7888+j+nWzOKCmrbwhcAAAhVeSJ+fCIT/DOE/1Cl+0GAVHm PfZg== MIME-Version: 1.0 X-Received: by 10.140.237.147 with SMTP id i141mr44853819qhc.25.1435842815542; Thu, 02 Jul 2015 06:13:35 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Thu, 2 Jul 2015 06:13:35 -0700 (PDT) In-Reply-To: <1854821.ToCRAf8eXU@crushinator> References: <1854821.ToCRAf8eXU@crushinator> Date: Thu, 2 Jul 2015 14:13:35 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1135ad28f94af50519e43460 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 13:13:37 -0000 --001a1135ad28f94af50519e43460 Content-Type: text/plain; charset=UTF-8 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 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" 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 > --001a1135ad28f94af50519e43460 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wonder if that would be a viable way for payme= nt 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.=C2=A0
=
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.=C2=A0 The payment processor combines lots of small double s= pend 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.= =C2=A0 First seen safe would be incompatible, if the double spender gets th= eir transaction into the system first.

A 1BTC fee transac= tion in nearly every block would also be a boost for network security.
<= br>
It avoids Peter Todd's complaint that mining pools might = make secret deals with payment services.=C2=A0 The transaction would be pub= lic and all miners could include it in their block.

On Thu, Jul 2, 2015 at 5:= 57 AM, Matt Whitlock <bip@mattwhitlock.name> wrote:
<= blockquote class=3D"gmail_quote" style=3D"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 functio= nality. 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 pul= l
> request implementing it:
>
> https://github.com/bitcoin/bitcoin/pull/1647 >
> The points regarding sweep transaction UI is out of scope for a BIP I&= #39;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.=C2=A0 If accepted, this could also add<= br> > > 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/mail= man/listinfo/bitcoin-dev

--001a1135ad28f94af50519e43460--