diff options
author | Tier Nolan <tier.nolan@gmail.com> | 2015-07-02 14:13:35 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-07-02 13:13:37 +0000 |
commit | 7588742b0501c1ec8d71092424562de78139198b (patch) | |
tree | 4fd343e874ed6901c31b291186fc954ee679468f | |
parent | 041de54ba71cbcb3977ccb70939779c8708b6570 (diff) | |
download | pi-bitcoindev-7588742b0501c1ec8d71092424562de78139198b.tar.gz pi-bitcoindev-7588742b0501c1ec8d71092424562de78139198b.zip |
Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
-rw-r--r-- | 5d/1737e9ac22a42876b5769bb62051eee51a62b3 | 185 |
1 files changed, 185 insertions, 0 deletions
diff --git a/5d/1737e9ac22a42876b5769bb62051eee51a62b3 b/5d/1737e9ac22a42876b5769bb62051eee51a62b3 new file mode 100644 index 000000000..81e62159b --- /dev/null +++ b/5d/1737e9ac22a42876b5769bb62051eee51a62b3 @@ -0,0 +1,185 @@ +Return-Path: <tier.nolan@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F02FBCC + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 2 Jul 2015 13:13:36 +0000 (UTC) +Received: by qkbp125 with SMTP id p125so51125934qkb.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CAAUFj10D37A1kfqFNPWz6bOMYSFXQbecJ+RxxOnw6HtwUg70mg@mail.gmail.com> + <CAOG=w-swH-_cD00Xy5yCN7LebeQSh-oG0gXFM6LxNSDwQZ64Tw@mail.gmail.com> + <1854821.ToCRAf8eXU@crushinator> +Date: Thu, 2 Jul 2015 14:13:35 +0100 +Message-ID: <CAE-z3OUqxjnRjWPtSzbSFoxPNGoPQyQ8G=e-yegm9JAZ+SzyBw@mail.gmail.com> +From: Tier Nolan <tier.nolan@gmail.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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 +> + +--001a1135ad28f94af50519e43460 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div><div>I wonder if that would be a viable way for payme= +nt 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.=C2=A0 <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.=C2=A0 The payment processor combines lots of small double s= +pend 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.= +=C2=A0 First seen safe would be incompatible, if the double spender gets th= +eir transaction into the system first.<br><br></div><div>A 1BTC fee transac= +tion 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.=C2=A0 The transaction would be pub= +lic and all miners could include it in their block.<br></div></div><div cla= +ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jul 2, 2015 at 5:= +57 AM, Matt Whitlock <span dir=3D"ltr"><<a href=3D"mailto:bip@mattwhitlo= +ck.name" target=3D"_blank">bip@mattwhitlock.name</a>></span> wrote:<br><= +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.<br> +<span class=3D"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 pul= +l<br> +> request implementing it:<br> +><br> +> <a href=3D"https://github.com/bitcoin/bitcoin/pull/1647" rel=3D"norefe= +rrer" target=3D"_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&= +#39;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=3D"mailto:d= +kbryant@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.=C2=A0 If accepted, this could also add<= +br> +> > flexibility into any future fee schedules.<br> +> ><br> +> > <a href=3D"https://github.com/d4n13/bips/blob/master/bip-00nn.med= +iawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/d4n13/bips/= +blob/master/bip-00nn.mediawiki</a><br> +</span><div class=3D"HOEnZb"><div class=3D"h5">____________________________= +___________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</div></div></blockquote></div><br></div> + +--001a1135ad28f94af50519e43460-- + |