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 3E147900 for ; Thu, 30 Nov 2017 09:12:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E688BE4 for ; Thu, 30 Nov 2017 09:12:50 +0000 (UTC) Received: by mail-vk0-f43.google.com with SMTP id u84so2968238vke.10 for ; Thu, 30 Nov 2017 01:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=BniFJr0nhy2CKDoxbtL+aPG2c3sOsU6Ales1lTeGiLU=; b=SMc9Fn8upWyrctt2POhdMirgVaWn1KF2s1Jyc/161t5VlYRjSXNlqSZ53aAsNaNiLl 1AAOuAHqodkIuMKPIF2QrIY6FDTieiQ7hpXfRAx5m/nx3R80K8v9iMgw75QnsB/S0yaX +1CwlslIycLZtt/Qx95lczqIT/TnmAGFi/sUBB+EXkxcKkw88rwYNxlcyxmBOz8vjbCn Ix/WBp7PMLv9Z2WYheaxEKk7mfqPRwB1lQPC7czOjQSTsk+i8Huay8YboQu+DQpnUu7W BQVds9ix7deeasdV/kf7pn8WniHuk8drtI1tMNd8mjbRp9o9yW24B0NVMwnk+TytfZUZ HW8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=BniFJr0nhy2CKDoxbtL+aPG2c3sOsU6Ales1lTeGiLU=; b=ricxCny3Lcs227QjO/ealrDQTdQztM6NLFnymJXgv2Aj4CbP+hJoHjkGDc3YdUSK37 PCGu2dmRTcgpftAwQJ23zhY6BZdtxip4WOpb7j5AXZFV9h75ZW5rOdYSz2t94ryvrqjn xaNkvs2vA1STk577LsxfxUdetsJ9dAf2syZXoaMJl0TtUw5crNgL1WIzbfAxlq/7+B18 OKf3VOruqlYxmn5mU1RRweQwchH158QmY2ZG0GpogZQIGAWtmTbAOQARVEkSl871v4Sr D+CQ6pcveAAkR5qKqeBPZxBepvfkLaQVKSBH/ek0jXk9+59AS+eZPKUif2GGqNykBxDB jVUA== X-Gm-Message-State: AKGB3mK6iyMmnTpadl0RcF4cnhF+bdyGX79dXZc5+Z8jzd8YzHiaTNyY g4idUq9nj6UAB7GIxaCWbg1MnRau92yyASuWNHKNDQ== X-Google-Smtp-Source: AGs4zMad2m+yN+qnLXbXafrNR2EhiHEGxHl+FF4IJ6ZQPBZyZe5yWaFjnKmGD5toKYXG1VVpE07XaIhfTeQY8pErv5k= X-Received: by 10.31.165.150 with SMTP id o144mr1294078vke.124.1512033169121; Thu, 30 Nov 2017 01:12:49 -0800 (PST) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.85.148 with HTTP; Thu, 30 Nov 2017 01:12:48 -0800 (PST) In-Reply-To: References: From: Gregory Maxwell Date: Thu, 30 Nov 2017 09:12:48 +0000 X-Google-Sender-Auth: GDJ1Q2aq0J2AHSwlWW1vdZ_wLfo Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a1142d310ef2707055f2fa791" X-Spam-Status: No, score=-1.9 required=5.0 tests=AC_DIV_BONANZA,BAYES_00, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,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 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 09:12:52 -0000 --001a1142d310ef2707055f2fa791 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This idea presumes that the protocol has any ability to regulate fees. I believe the locally optimal strategy for both miners and payers alike is to accept (pay) zero fees natively in the protocol and instead accept (pay) their actual fees out-of-band or via OP_TRUE outputs which the miner can simply collect. Then the miner sets the fee threshold to ~0 and selects transactions on the basis of out of band fees. Miners today already accept out-of-band fees, and as far back as at least 2011 there were miners that would also accept fees in the form of additional transaction outputs which they were able to spend. On Thu, Nov 30, 2017 at 9:11 AM, Gregory Maxwell wrote= : > > > This idea presumes that the protocol has any ability to regulate fees. I > believe the locally optimal strategy for both miners and payers alike is = to > accept (pay) zero fees natively in the protocol and instead accept (pay) > their actual fees out-of-band or via OP_TRUE outputs which the miner can > simply collect. Then the miner sets the fee threshold to ~0 and selects > transactions on the basis of out of band fees. > > Miners today already accept out-of-band fees, and as far back as at least > 2011 there were miners that would also accept fees in the form of > additional transaction outputs which they were able to spend. > > > > On Thu, Nov 30, 2017 at 12:47 AM, William Morriss via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Comrades, >> >> Long term, tx fees must support hash power by themselves. The following >> is an economic approach to maximize total fee collection, and therefore >> hashpower. >> >> *Goals* >> Maximize total transaction fees >> Reduce pending transaction time >> Reduce individual transaction fees >> >> *Challenges* >> Validators must agree on the maximum block size, else miners can cheat >> and include extra transactions. >> Allowing too many transactions per block will increase the cost of the >> mining without collecting much income for the network. >> >> >> *Problem* >> In the transaction market, users are the demand curve, because they will >> transact less when fees are higher, and prefer altcoins. The block size = is >> the supply curve, because it represents miners' willingness to accept >> transactions. >> Currently, the supply curve is inelastic: >> >> =E2=80=8BIncreasing the block size will not affect the inelasticity for = any >> fixed block size. The downsides of a fixed block size limit are well-kno= wn: >> - Unpredictable transaction settlement time >> - Variable transaction fees depending on network congestion >> - Frequent overpay >> >> *Proposal* >> 1. Miners implicitly choose the market sat/byte rate with the >> cheapest-fee transaction included in their block. Excess transaction fee= s >> are refunded to the inputs. >> 2. Remove the block size limit, which is no longer necessary. >> >> *Benefits* >> - Dynamic block size limit regulated by profit motive >> - Transaction fees maximized for every block >> - No overpay; all fees are fair >> >> =E2=80=8BMiners individually will make decisions to maximize their block= -reward >> profit. >> Miners are incentivized to ignore low-fee transactions because they woul= d >> shave the profits of their other transactions and increase their hash ti= me. >> Users and services are free to bid higher transaction fees in order to >> reach the next block, since their excess bid will be refunded. >> >> The block size limit was added as a spam-prevention measure, but in orde= r >> for an attacker to spam the network with low-fee transactions, they woul= d >> have to offset the marginal cost of reducing the price with their own >> transaction fees. Anti-spam is thus built into the marginal system witho= ut >> the need for an explicit limit. >> >> Rarely, sections of the backlog would become large enough to be >> profitable. This means every so many blocks, lower-fee transactions woul= d >> be included en masse after having been ignored long enough. Low-fee >> transactions thus gain a liveness property not previously enjoyed: low-f= ee >> transactions will eventually confirm. Miners targeting these transaction= s >> would be at a noteworthy disadvantage because they would be hashing a >> larger block. I predict that this scheme would result in two markets: a >> backlog market and a real-time market. Users targeting the backlog marke= t >> would match the price of the largest backlog section in order to be >> included in the next backlog block. >> >> *Examples* >> >> Scenario 1 >> Sat/byte Bytes Reward >> 400 500000 200000000 >> 300 700000 210000000 >> 200 1000000 200000000 >> 100 1500000 150000000 >> 50 5000000 250000000 >> 20 10000000 200000000 >> A miner would create a 5MB block and receive 0.25 BTC >> >> Scenario 2 >> Sat/byte Bytes Reward >> 400 600000 240000000 >> 300 700000 210000000 >> 200 1000000 200000000 >> 100 1800000 180000000 >> 50 4000000 200000000 >> 20 10000000 200000000 >> A miner would create a 600KB block and receive 0.24 BTC >> >> Thanks, >> William Morriss >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > --001a1142d310ef2707055f2fa791 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This idea presumes that the protocol has any ability to regulate fees. I believe the locally optimal strategy for both=20 miners and payers alike is to accept (pay) zero fees natively in the=20 protocol and instead accept (pay) their actual fees out-of-band or via=20 OP_TRUE outputs which the miner can simply collect.=C2=A0 Then the miner se= ts the fee threshold to ~0 and selects transactions on the basis of out of band fees.

Miners today already accept out-of-band fees,=20 and as far back as at least 2011 there were miners that would also=20 accept fees in the form of additional transaction outputs which they=20 were able to spend.

On Thu, Nov 30, 2017 at 9:11 AM, Gregory Maxwell = <gmaxwell@gmail.= com> wrote:


This idea presumes that the protocol has any abil= ity to regulate fees. I believe the locally optimal strategy for both miner= s and payers alike is to accept (pay) zero fees natively in the protocol an= d instead accept (pay) their actual fees out-of-band or via OP_TRUE outputs= which the miner can simply collect.=C2=A0 Then the miner sets the fee thre= shold to ~0 and selects transactions on the basis of out of band fees.
<= br>
Miners today already accept out-of-band fees, and as far back as a= t least 2011 there were miners that would also accept fees in the form of a= dditional transaction outputs which they were able to spend.


On Thu, Nov 30, 2017 at 12:47 AM, William Morriss via b= itcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:
<= div class=3D"h5">
Comrades,

Long term, tx fees = must support hash power by themselves. The following is an economic approac= h to maximize total fee collection, and therefore hashpower.
<= div>

Goals
Ma= ximize total transaction fees
Reduce pending transaction time
<= /div>Reduce individual transaction fees

Cha= llenges
Validators must agree on the maximum block size, else= miners can cheat and include extra transactions.
Allowing too ma= ny transactions per block will increase the cost of the mining without coll= ecting much income for the network.

Problem
<= /div>In the transaction market, users are the demand curve, because they wi= ll transact less when fees are higher, and prefer altcoins. The block size = is the supply curve, because it represents miners' willingness to accep= t transactions.
Currently, the supply curve is inelastic:

=E2=80=8BIncreasing the block size will not affec= t the inelasticity for any fixed block size. The downsides of a fixed block= size limit are well-known:
- Unpredictable transactio= n settlement time
- Variable transaction fees depending on network= congestion
- Frequent overpay

Proposa= l
1. Miners implicitly choose the market sat/byte rate with t= he cheapest-fee transaction included in their block. Excess transaction fee= s are refunded to the inputs.
2. Remove the block size limit, whi= ch is no longer necessary.

Benefits
- Dynamic block size limit regulated by profit motive
- Transaction fees maximized for every block
- No overpay; a= ll fees are fair

=E2=80=8BM= iners individually will make decisions to maximize their block-reward profi= t.
Miners are incentivized to ignore low-fee transactio= ns because they would shave the profits of their other transactions and inc= rease their hash time.
Users and services are free to bid higher = transaction fees in order to reach the next block, since their excess bid w= ill be refunded.

The block size limit was added as= a spam-prevention measure, but in order for an attacker to spam the networ= k with low-fee transactions, they would have to offset the marginal cost of= reducing the price with their own transaction fees. Anti-spam is thus buil= t into the marginal system without the need for an explicit limit.

Rarely, sections of the backlog would become large eno= ugh to be profitable. This means every so many blocks, lower-fee transactio= ns would be included en masse after having been ignored long enough. Low-fe= e transactions thus gain a liveness property not previously enjoyed: low-fe= e transactions will eventually confirm. Miners targeting these transactions= would be at a noteworthy disadvantage because they would be hashing a larg= er block. I predict that this scheme would result in two markets: a backlog= market and a real-time market. Users targeting the backlog market would ma= tch the price of the largest backlog section in order to be included in the= next backlog block.

Examples

Scenario 1
=
Sat/byteBytesReward
400500000200000000
30070000021= 0000000
2001000= 000200000000
10= 01500000150000000
505000000250000000
2010000000
Sat/byteBytesReward
400600000240000000
300700000210000000
1000000200000000
1001800000180000000
504000000200000000
2010000000200000000
=
A miner would create a 600KB block and receive 0.24 BTC
<= /div>
Thanks,
William Morriss

_____________________________________= __________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev



--001a1142d310ef2707055f2fa791--