From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BC2F2BBD for ; Thu, 30 Nov 2017 06:13:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yb0-f179.google.com (mail-yb0-f179.google.com [209.85.213.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1123EE4 for ; Thu, 30 Nov 2017 06:13:16 +0000 (UTC) Received: by mail-yb0-f179.google.com with SMTP id s46so2305457ybi.8 for ; Wed, 29 Nov 2017 22:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RlA2SZO8eXPu7Fn6hrVkVhhOSJUd66sVQ8gm3KztAcY=; b=cqynYev9JJ2teeHgQzOHlHzHYLt6YTiAbiz0esrQ1sa3VRXb/V7LpCWw160w66YQE6 g8aDxNaTzQ7CkVFf+EuYBHQ5JwI0HdBC8FSn2BcmLCtmZbSv6gZSXE53FnYcrMvrgCGp 9oPLiNFFXp/baQmbAuEmHgerY40UmpTv+87SHpjCSgNhy5ncgIOSYE8QtXXr8SlkC+Ul quQN8GXG+nKuSGIpW+zLUwtV2eVyghlLo6MugH7HczjbAglNAYSfhD8PvH8YJFgsuiN3 JoPwT0WevUxsMfJmHpxZs6w/xtApaJjEEflfL9U90jPaAhsv+5jbWB5QMOBI+JraC9mO jKxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RlA2SZO8eXPu7Fn6hrVkVhhOSJUd66sVQ8gm3KztAcY=; b=fJZni9bswQ9E3UsEHoJnq//tKYd8G00vp1EE89Nk+3l68NoA1h8hdEYGf2CdpOqPsh /P/JvGc4r4vxfznvaxfmQKNxCGH5+247tc6dvC2MakFsjKem62NFP2sCGA4vi3ms4qGD euiPbvv+jihRubFKJzON2gS74+pP+iw8DK/T55wzH2JmU5bZTBCy0ZZOFsfOCzdVQ2/t sDvmVwZBHJVP1oJFLIcBpYjgyNo8WDYqo82xC09Vbr3K6ZnvuuFdwryYWXrAnWLgJtOp gmODZLbTd8ekY58j3DaWUuikTpkeYzclMPIllH9rFoD6BW09b/phyW167/mbhSna1Nn8 SNKQ== X-Gm-Message-State: AJaThX75QmryvL2th2pnDD690VcoMUMWHgxN5za+OWJyJT+3ofinguNt o7a2d2nmaGey3XwhpHqYQrcX0b3t9WyFCGOfUUE= X-Google-Smtp-Source: AGs4zMack4F5kTWYJJoRYyMf1OgMOxaZbfejiVN+xaTZ4u0qVVy062RmJ8ilLq0ciOfYGJhMmbmUXq1YRcWqmE6mPus= X-Received: by 10.37.87.67 with SMTP id l64mr824038ybb.415.1512022396190; Wed, 29 Nov 2017 22:13:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.43.195 with HTTP; Wed, 29 Nov 2017 22:13:15 -0800 (PST) In-Reply-To: References: From: William Morriss Date: Wed, 29 Nov 2017 22:13:15 -0800 Message-ID: To: Ben Kloester Content-Type: multipart/alternative; boundary="001a113e7f38d146e1055f2d259e" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, HTML_OBFUSCATE_05_10, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 30 Nov 2017 11:02:19 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP Idea: Marginal Pricing X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 06:13:17 -0000 --001a113e7f38d146e1055f2d259e Content-Type: text/plain; charset="UTF-8" On Wed, Nov 29, 2017 at 6:38 PM, Ben Kloester wrote: > Something similar to this has been proposed in this article by Ron Lavi, > Or Sattath, and Aviv Zohar, and discussed in this bitcoin-dev thread > https://lists.linuxfoundation.org/pipermail/bitcoin- > dev/2017-September/015093.html > > They only discussed changing the fee structure, not removing the block > size limit, as far as I know. > > "Redesigning Bitcoin's fee market" > https://arxiv.org/abs/1709.08881 > > *Ben Kloester* > Thanks. Marginal pricing is equivalent to the "Monopolistic Price Mechanism" discussed in https://arxiv.org/abs/1709.08881. The mechanism is the same, including the block size adjustment, but as you noted the prior discussion only concerns the fee structure. It looks like the prior proposal broke down because of Peter Todd's concern with out-of-band payments (https://lists.linuxfoundation.org/pipermail/ bitcoin-dev/2017-September/015103.html). Restated, miners can circumvent the system through out of band payments. Mark Friedenbach argues that out-of-band payments are penalized in part because the end-user could have just as easily bid higher instead of paying OOB. Peter Todd argues that a miner could mine only out-of-band transactions. Such transactions could have no on-chain fees and thus be disregarded by other miners. I believe this OOB scenario is imaginary. Either it would be more profitable for a miner to mine fairly, or cheaper for the end-user to pay the fee in-band. Consider MINFEE to the the effective fee paid for the block mined by the OOB-incentivized miner. Consider MARKFEE to the the market fee collected by non-OOB-incentivized miners. Call the OOB effective tx fee OOB. Then, For a user to prefer OOB: MINFEE+OOBMARKFEE It is impossible for both scenarios to be true. As previously argued by Mark Friedenbach, the system disincentivizes OOB tx fees. I don't think there is any more centralization pressure with marginal fees than before. What prevents miners from colluding to move tx fees OOB is the value of the on-band pending tx fees. The hashpower of individual miners is not impressive compared to the entire network, so individual miners could not offer a service to speed up confirmation that would be superior to simply doing a RBP. OOB fees are perhaps a symptom of the current setup, wherein there is no penalty for arbitrarily favoring individual transactions with lower fees. --001a113e7f38d146e1055f2d259e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 29, 2017 at 6:38 PM= , Ben Kloester <benkloester@gmail.com> wrote:
Something similar to this has been proposed=C2=A0 in this article by Ron Lavi, Or Sattath, and Aviv Zohar= , and discussed in this bitcoin-dev thread=C2=A0https://lists.linuxfoundation.org/pipermail/bitcoin-d= ev/2017-September/015093.html

They only discu= ssed changing the fee structure, not removing the block size limit, as far = as I know.

=C2=A0 =C2=A0 "Redesigning=C2=A0<= span class=3D"m_7355356485751430742gmail-m_2648373878203727864gmail-il" sty= le=3D"font-size:12.8px;background-color:rgb(255,255,255)">Bitcoin's=C2=A0fee=C2=A0market"
=C2=A0 =C2=A0=C2=A0https://arxiv.org/abs/1709.08881

Ben Kloester

=

Thanks. Marginal pricing = is equivalent to the "Monopolistic Price=20 Mechanism" discussed in https://arxiv.org/abs/1709.08881. The mechanism= =20 is the same, including the block size adjustment, but as you noted the prio= r discussion only concerns the fee structure.

= It looks like the prior proposal broke down because of Peter Todd's=20 concern with out-of-band payments=20 (https://lists.linuxfoundation.o= rg/pipermail/bitcoin-dev/2017-September/015103.html). Restated, miners can circumvent the system through out of band=20 payments. Mark Friedenbach argues that out-of-band payments are=20 penalized in part because the end-user could have just as easily bid=20 higher instead of paying OOB. Peter Todd argues that a miner could mine=20 only out-of-band transactions. Such transactions could have no on-chain=20 fees and thus be disregarded by other miners.

I believe this OOB scenario is imaginary. Either it would be more=20 profitable for a miner to mine fairly, or cheaper for the end-user to=20 pay the fee in-band. Consider MINFEE to the the effective fee paid for=20 the block mined by the OOB-incentivized miner. Consider MARKFEE to the=20 the market fee collected by non-OOB-incentivized miners. Call the OOB=20 effective tx fee OOB. Then,
For a user to prefer OOB: MINFEE+= OOB<MARKFEE
For a miner to prefer OOB: MINFEE+OOB>MARKFEE
It is impossible for both scenarios to be true. As previously argued by=20 Mark Friedenbach, the system disincentivizes OOB tx fees.

I don't think there is any more centralization pressure with marginal=20 fees than before. What prevents miners from colluding to move tx fees=20 OOB is the value of the on-band pending tx fees. The hashpower of=20 individual miners is not impressive compared to the entire network, so=20 individual miners could not offer a service to speed up confirmation that w= ould be superior to simply doing a RBP.=20 OOB fees are perhaps a symptom of the current setup, wherein there is no penalty for arbitrarily favoring individual transactions with lower fees.<= br>
--001a113e7f38d146e1055f2d259e--