Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6B6E4C002D for ; Thu, 3 Nov 2022 13:32:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 3F4A760A7B for ; Thu, 3 Nov 2022 13:32:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3F4A760A7B Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=Os2K+fv8 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEMFNW9DXDtR for ; Thu, 3 Nov 2022 13:32:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org DD141606C0 Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) by smtp3.osuosl.org (Postfix) with ESMTPS id DD141606C0 for ; Thu, 3 Nov 2022 13:32:31 +0000 (UTC) Received: by mail-vs1-xe35.google.com with SMTP id z189so1886362vsb.4 for ; Thu, 03 Nov 2022 06:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HY1wD1b/ty6FqBTbca7m1j4Qbv0HNpx1clvVe1WnB8g=; b=Os2K+fv80CNgsN4/c2pADpReSa6/r+Bi18pe0DFiOesj9ZGh/OQU1ki3omLL4qDHt6 RTvcqc32KGQhlFyo8AzaRwJEdzUBKYbcvaN4oSgkJLqjwjpkq3IWqPc90epc71XHn0ks hkPZMdspFrigscFvmje75u+7oo6BokzT2/RrnutdbAd/d0i7McqTAfdH5wbXsXHXqEiD +uPeJF8z6+lWgxsgtTvq74gUxlX2Q4eC1+yjtmtZC9Zr20C6mJYic3dhZWi3GcMbL8Tx O6hqVt5KTwfJeh3AZhu0cuW2QyphRFX28groG/ig/Lkrag15eHA2DbNxGSyw5XlgFTMr RNfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HY1wD1b/ty6FqBTbca7m1j4Qbv0HNpx1clvVe1WnB8g=; b=M7wEyB4Yc/zjeLQXQWY2dgA0b9EQ13jq3FQIbZRc93gw38t/ChQFOTXC6Tysj1VLsc 9ZqudYzBKUBtzSSaCmXltzOYhWrExRtkXmpi8Qv9QkMKAQOeeSzvXESiYSllegQHAXRC FxiML+ike4gA9WncZYznb2+HarDg6A1jarxbRsL/szSji1gTfZovqUKcBs0heacS1/r1 0hA7i0XBp06T0qGrKKxlHL2C35OrPGznqAPcHCxs5S2QoUfPXQuWFoWsAdoffi09N6D/ eYdgzPABnr/03fXW6vFT32ky1vXB+VMmZroLlUVP0QdhHPQd3QWc/zqbUzk9kJylqr+V 28sg== X-Gm-Message-State: ACrzQf0+MTGC28o0FszcY1bfcuw1q/NkRsYr4VtJdJKXIrq8Rr/51/F5 yZ8+KCuU4hNy8Xl5nXt/sCNWX6nXhniiy1gMD0WVsrkppVx/ X-Google-Smtp-Source: AMsMyM43yfN1Tiymd3brF+qm0QODw+v6LyCEPDvzuDEH+5XyWZWJLpGa4BeCgtTiD8Ssv076XwnxbIsd4ujwImygKEU= X-Received: by 2002:a05:6102:14aa:b0:3ac:b1ee:5529 with SMTP id d42-20020a05610214aa00b003acb1ee5529mr16479120vsv.40.1667482350363; Thu, 03 Nov 2022 06:32:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Thu, 3 Nov 2022 09:32:20 -0400 Message-ID: To: alicexbt , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000029a9e505ec90fd32" X-Mailman-Approved-At: Thu, 03 Nov 2022 14:05:19 +0000 Subject: Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2022 13:32:33 -0000 --00000000000029a9e505ec90fd32 Content-Type: text/plain; charset="UTF-8" actually, peter makes an important point here technically, all we need is for *miners* to consistently mine "full rbf" as long as they do, businesses that accept 0conf will have to adjust their risk accordingly, and the problem of misaligned incentives is resolved i don't think it matters what non-mining users do nearly as much On Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Peter, > > > tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees > to > > reward miners that turn on full-RBF. I'm starting small, just > ~$100/block in > > times of congestion. Miner and pool profit margins are pretty small, on > the > > order of $1k/block in many cases, so I know it doesn't take that much > more > > money to make a difference. > > I appreciate this effort and perhaps this was all that was needed in > addition to Bitcoin Core's inclusion of full rbf support. Making it default > right away or enabling preferential peering with service flag in a bitcoin > core release was unnecessary. > > > If you'd like to donate to this effort, send BTC to > > bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m > > Sorry, I don't trust you based on some of the things you support on > Twitter. Hopefully, others will donate and help this bounty. > > /dev/fd0 > > Sent with Proton Mail secure email. > > ------- Original Message ------- > On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > I'm now running a full-RBf bounty program for miners. > > > > tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees > to > > reward miners that turn on full-RBF. I'm starting small, just > ~$100/block in > > times of congestion. Miner and pool profit margins are pretty small, on > the > > order of $1k/block in many cases, so I know it doesn't take that much > more > > money to make a difference. > > > > Why should you do this? Full-RBF/zeroconf has been discussed to death. > But > > tl;dr: You'll earn more money, and help transition Bitcoin to a more > secure > > mempool policy based on economic incentives rather than trust. > > > > > > If you're a miner and want to participate, the easiest way to so is to > use the > > mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 release (eg the > > 24.0rc3 tag), or use the mempoolreplacement=fee option in Bitcoin Knots. > > > > You can also just modify the code yourself by removing the opt-in RBF > check. > > For example against the v23.0 tag: > > > > $ git diff > > diff --git a/src/validation.cpp b/src/validation.cpp > > index 214112e2b..44c364623 100644 > > --- a/src/validation.cpp > > +++ b/src/validation.cpp > > @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, > Workspace& ws) > > // check all unconfirmed ancestors; otherwise an opt-in ancestor > > // might be replaced, causing removal of this descendant. > > if (!SignalsOptInRBF(*ptxConflicting)) { > > - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, > "txn-mempool-conflict"); > > + // return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, > "txn-mempool-conflict"); > > } > > > > ws.m_conflicts.insert(ptxConflicting->GetHash()); > > > > > > Once you've enabled full-RBF, you need a full-RBF peer. I'm running a > few of > > them: > > > > cup.nop.lol > > mug.nop.lol > > jar.nop.lol > > jug.nop.lol > > > > These nodes run a preferential peering patch ( > https://github.com/bitcoin/bitcoin/pull/25600) > > to ensure that full-RBF nodes are interconnected to each other and > replacements > > can easily propagate. Also feel free to contact me if you'd like to peer > with a > > private node. > > > > > > If you'd like to donate to this effort, send BTC to > > bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m > > > > > > ...and yes, I'm well aware that miners could collect this bounty in > other ways, > > eg by raising minimum fees. Doing that also breaks zeroconf, so I'm not > too > > concerned. > > > > -- > > https://petertodd.org 'peter'[:-1]@petertodd.org > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000029a9e505ec90fd32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
actually, peter makes an important point here

technically, all we need is for *miners* to consistently mine "= full rbf"

as long as they do, businesses that= accept 0conf=C2=A0will have to adjust their risk accordingly, and the prob= lem of misaligned incentives is resolved

i don'= ;t think it matters what non-mining users do nearly as much
=C2= =A0=C2=A0

On Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev <= ;bitcoin-dev@lists= .linuxfoundation.org> wrote:
Hi Peter,

> tl;dr: I'm broadcasting full-RBF replacements paying extremely hig= h fees to
> reward miners that turn on full-RBF. I'm starting small, just ~$10= 0/block in
> times of congestion. Miner and pool profit margins are pretty small, o= n the
> order of $1k/block in many cases, so I know it doesn't take that m= uch more
> money to make a difference.

I appreciate this effort and perhaps this was all that was needed in additi= on to Bitcoin Core's inclusion of full rbf support. Making it default r= ight away or enabling preferential peering with service flag in a bitcoin c= ore release was unnecessary.

> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m

Sorry, I don't trust you based on some of the things you support on Twi= tter. Hopefully, others will donate and help this bounty.

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via bitcoin-dev <= ;bitcoin-dev@lists.linuxfoundation.org> wrote:


> I'm now running a full-RBf bounty program for miners.
>
> tl;dr: I'm broadcasting full-RBF replacements paying extremely hig= h fees to
> reward miners that turn on full-RBF. I'm starting small, just ~$10= 0/block in
> times of congestion. Miner and pool profit margins are pretty small, o= n the
> order of $1k/block in many cases, so I know it doesn't take that m= uch more
> money to make a difference.
>
> Why should you do this? Full-RBF/zeroconf has been discussed to death.= But
> tl;dr: You'll earn more money, and help transition Bitcoin to a mo= re secure
> mempool policy based on economic incentives rather than trust.
>
>
> If you're a miner and want to participate, the easiest way to so i= s to use the
> mempoolfullrbf=3D1 option in the upcoming Bitcoin Core v24 release (eg= the
> 24.0rc3 tag), or use the mempoolreplacement=3Dfee option in Bitcoin Kn= ots.
>
> You can also just modify the code yourself by removing the opt-in RBF = check.
> For example against the v23.0 tag:
>
> $ git diff
> diff --git a/src/validation.cpp b/src/validation.cpp
> index 214112e2b..44c364623 100644
> --- a/src/validation.cpp
> +++ b/src/validation.cpp
> @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, = Workspace& ws)
> // check all unconfirmed ancestors; otherwise an opt-in ancestor
> // might be replaced, causing removal of this descendant.
> if (!SignalsOptInRBF(*ptxConflicting)) {
> - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, "tx= n-mempool-conflict");
> + // return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, "= ;txn-mempool-conflict");
> }
>
> ws.m_conflicts.insert(ptxConflicting->GetHash());
>
>
> Once you've enabled full-RBF, you need a full-RBF peer. I'm ru= nning a few of
> them:
>
> cup.nop.lol
> mug.nop.lol
> jar.nop.lol
> jug.nop.lol
>
> These nodes run a preferential peering patch (http= s://github.com/bitcoin/bitcoin/pull/25600)
> to ensure that full-RBF nodes are interconnected to each other and rep= lacements
> can easily propagate. Also feel free to contact me if you'd like t= o peer with a
> private node.
>
>
> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
>
>
> ...and yes, I'm well aware that miners could collect this bounty i= n other ways,
> eg by raising minimum fees. Doing that also breaks zeroconf, so I'= m not too
> concerned.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000029a9e505ec90fd32--