path: root/9f/e06fe9d10ce39f56e7296fa20873a65caa604b

Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E68509FA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Mar 2017 09:34:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb0-f171.google.com (mail-yb0-f171.google.com
	[209.85.213.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 77D43AC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Mar 2017 09:34:33 +0000 (UTC)
Received: by mail-yb0-f171.google.com with SMTP id m133so6628005ybb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Mar 2017 02:34:33 -0700 (PDT)
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; 
	bh=6F8CF7NkJMq1mXAeK/rCAIUADwIeXppeKbDeaGhjmzQ=;
	b=QigIiZFMifFiJCzEJPj3dn2FXcTOLkKhRlNZjrCZ4tZLoIwy/PnL3NQV+YxS5vrftA
	pvZ/R+rh6WFJ7wSqMHHI0x0q5w0WniyCj4k7+Dopgjuev1pkCmpw/6KBiTe+N1OqAp6x
	ZoMMBhWiBZh0XjLLTIGQCYnZcXeVlliNIr4ipIoG4pOd4CuV+0vt3/UhpprXIlT6FLvi
	rDiNBjyOXODDuG2/4ErvlOcaFr1P4+3q87mjOMiUPK0pGs5FifDeo0ZYclZvRzgINuoK
	xGHs6Goo1kTSFnMJXy4kDUESskEZNM650h28iqR5bgJEHQFZs9A5Zb+QcDT6CcQrHkaH
	E5Qw==
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;
	bh=6F8CF7NkJMq1mXAeK/rCAIUADwIeXppeKbDeaGhjmzQ=;
	b=fNNK00YMXPy+CkenzATVoMLS1VtUu3N/YzzGjZTtk4UW6RVVcKxN6SimJmQDjVER7c
	pZ9CtfqE5I4R+AQhI88Bwggfs0XTg/zG+X+saEWgeSWuoEpQYg5exbiycupIXXsbRM35
	f1u5msFreC+EdffsUifkjJW60FUDDsOYJIUx8tD561olMEuMorKJiraG9qN0Kmvb8Fw9
	0wfwn6IbTHDXlwrTVsfUDMNZ79MDDAPMvLqCM2btzLtAa1nxIxNI937S2eOWyB6dA/lc
	J15BQDeUkrsiIYtpAm3gjZLCmHds9C27xrvnw/AzIoo8RM2rV/pXej/fCRsPlFRaF67z
	hwSA==
X-Gm-Message-State: AFeK/H3a710B2UZlCQpMcBiwRokOHzDgS5Bujzl2fQbUWiK3Gg82LK7oV1YUM6tJXxIG3PXRe0CcBall8ymEGQ==
X-Received: by 10.37.111.136 with SMTP id k130mr6560541ybc.156.1490866472359; 
	Thu, 30 Mar 2017 02:34:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.123.135 with HTTP; Thu, 30 Mar 2017 02:34:31 -0700 (PDT)
Received: by 10.37.123.135 with HTTP; Thu, 30 Mar 2017 02:34:31 -0700 (PDT)
In-Reply-To: <CAAt2M1-LZQ1yE1CezFA+hr+=de-RVJ7wzkq-t969BC7OL6dWwg@mail.gmail.com>
References: <CAAt2M1_x8zbN-vmgDEUQQvzrtonEKydb+B-P53ibCimVfnd-CA@mail.gmail.com>
	<CAAt2M1-yWfqp+Ap=XUMiNro9oz=00WcJBSY1uVH3SrQ6GQ7Rig@mail.gmail.com>
	<CAAt2M1-z5nS35sn37B_cH=S6oxFVf8Myptw-rMLCQ21a-uL9nw@mail.gmail.com>
	<CAAt2M1_Rnejikvxd-X9SLdprS9rpq6b25aau0OSrWJu2YABMXw@mail.gmail.com>
	<CAAt2M1_NbWM66dOdP7U9AMGdE4-NB2OyN-SWLkD-P32SPLYRmQ@mail.gmail.com>
	<CAAt2M19_xUJy+=7mkmNxWR=J_=cjAjAnwkzbeTfFEx5s9FBTew@mail.gmail.com>
	<CAAt2M19u9ZYjonPc_ViPFNzk_VBrUBJoB6yrqq_6=EAtvGt7HQ@mail.gmail.com>
	<CAAt2M19HO2PE88wKQLiV+WicwoTY=5HV1LcpYQcK2f=nhsL=Kg@mail.gmail.com>
	<CAAt2M1-_=oeeeFy5_gGdEz_iw=Eo3xzkF6R4fzpbM3x4C6pr2g@mail.gmail.com>
	<CAAt2M1_-kby6Cy+P5aofoQXwUWfk8=wDqMO3c=z=rAwDvzbwkA@mail.gmail.com>
	<CAAt2M1_eCcf7EoyTiJTHzUPaxWE_dY14oRsbYG7J1TDRQMUDvw@mail.gmail.com>
	<CAAt2M1-4K+6TAab6mv3PnBckZS=X6eCbfDwkMbXo45_d+dpo+A@mail.gmail.com>
	<CAAt2M1_kmvBsXOyX2k25JDHyQj8mwVG5vtat3nibG9Sv=NC-KQ@mail.gmail.com>
	<CAAt2M1-jZdvdz85tREdNdZJJK6btzsYvB3x9rMntB01rE-QC6Q@mail.gmail.com>
	<CAAt2M19UOmFya9jo25jWDpEDh6MEfKKHHtq3=QZP9XBkLbda7g@mail.gmail.com>
	<CAAt2M18Le_UNDFk+4x_=UdxX9SdoAQu6RpgCt5qDV79hJh_QUA@mail.gmail.com>
	<CAAt2M1_uRxkhsYY8c93LEh=knW1MQF7vNZ_xJbqSJihTFhEuqg@mail.gmail.com>
	<CAAt2M187ei5=CvaCjbsLuUM3cHjAb6qs=SeRQdjYBuJxsXSaWw@mail.gmail.com>
	<CAAt2M1885LuLJ-2=KL8sEMvutM_U3RFZ-nd25p_3k4-YkBrD=Q@mail.gmail.com>
	<CAAt2M19121uJiZu+ctJ0cHqJHp3JCvTHJYC6ACzP3_N+ZfxUHA@mail.gmail.com>
	<CAAt2M18VCKgcLDX2Y1Z+hHOehdEOhu4en9JOtNO63_8Y2Ne+rg@mail.gmail.com>
	<CAAt2M1--M7rT4khAFADopRig+GA+6n6_6hCK8LbV=cS_YAs+QA@mail.gmail.com>
	<CAAt2M1_2MaY55U7mNirP6KTjGbKRu_BMxwLFrRg5pdAd+83trg@mail.gmail.com>
	<CAAt2M1-dH3LFsPc-s1iPMQ8mWM4NqY5vmrpxuP1kdjHhNXEqLA@mail.gmail.com>
	<CAAt2M18Ty69L_7vfHv8sRmUEnW5K1VZzKRdxDMBANDt10LvD_A@mail.gmail.com>
	<CAAt2M1-Sq-+_0tgKOz_gQkCnBx2Lp=ugp2CQKaz97KHLvdcpdw@mail.gmail.com>
	<CAAt2M19Woysa0_HM7ZsiF14Tv4hVuRE69Eann=_fpOy2gTQV7A@mail.gmail.com>
	<CAAt2M1_itWrpDDVYXOaeQbk6r=B_K9Ow3dD9NvMtU_GGWH5mxA@mail.gmail.com>
	<CAAt2M18sQ-q_yyOVqM-am7rjPHz24hOmi+wo1pCVxuMTcNoHww@mail.gmail.com>
	<CAAt2M18062gaODy6FHqQw42Mhkg1Srs98W5xADcEgb9GcCn+Mw@mail.gmail.com>
	<CAAt2M1_GBXbOi=GUu7mohRqatZGue4DVtPO5CXZmtjKs-vEqEw@mail.gmail.com>
	<CAAt2M19UCAfTq+VyE178ASkjPb8EWm4o2zTPf7UGpNuKeeYcJg@mail.gmail.com>
	<CAAt2M19oxbgpeOMtonEe2xpoit2imPO4M5XZCw4Sap2VMT8zBQ@mail.gmail.com>
	<CAAt2M1_SriFNUcLJfsHNucr3rO8az4BkHVDX0e=_FAproGk6zw@mail.gmail.com>
	<CAAt2M19hjVSk1Lv-6qLgVTK1f283bQzRWy+yz-iiWi9_6z4s2w@mail.gmail.com>
	<CAAt2M19Lz_FKA-sDbC1P=1RMznd1tWSdpJsbZbH04SeZ-mqJxQ@mail.gmail.com>
	<CAAt2M1_+x7Sby-4ygyGPxQv87OhP2wpzP=hZEeUD_Aq9JPFsDw@mail.gmail.com>
	<CAAt2M1-cKQNsD-W4yZOkExx=K2d2YM2C93dmDEReFPP3VLa-2Q@mail.gmail.com>
	<CAAt2M1-x4H6FK6HL-8F-jr0nDg0VpZGCNkOVeWnP7e_UTUxX-w@mail.gmail.com>
	<CAAt2M195V7ynWe5tFd023hs4S06WWZGBXUFKLJfoc-U4Gw99HQ@mail.gmail.com>
	<CAAt2M18axXYYd4QDOo+q4_3Fb5-wyZRM9CzZ5G0vrdfMAmG25A@mail.gmail.com>
	<CAAt2M187Fvz0s=M5esfGe2q8O2CXdMAfBtTi+eVA9hQ86jYvVw@mail.gmail.com>
	<CAAt2M19Pc7LAW2SRCfSOWwNnUNR-dkVfn-6iTdLOBcasrqGs6A@mail.gmail.com>
	<CAAt2M18=qpQqPwy95vw+T5tkZTo457cp5ZHnJOkV+0kfCWW7Hg@mail.gmail.com>
	<CAAt2M19YGM6j3vRwuM5Oe9F0vjvbTjvqT0AT5-G6ZPQ8npo6uw@mail.gmail.com>
	<CAAt2M1_f+BbCEnkaPSCTMgw3oVkiueTr_dF0aDZS1XuZj2bxyg@mail.gmail.com>
	<CAAt2M185GrxytKYTwfZUGBmBH8OD2-VQUuxcja5HtFWLg2rsnw@mail.gmail.com>
	<CAAt2M18KpJqJpN+cBuXNYHbmsGMn7qa5ZZRP5JYTxLPWE2-G0w@mail.gmail.com>
	<CAAt2M1-NO2FErh15A67aigzULWeEPYB6yaR7_RynGr5_DCaRwQ@mail.gmail.com>
	<CAAt2M1-nLu69zUPrZhaxLYemd17nh-tMPa6+UYqoeGzufjjxEA@mail.gmail.com>
	<CAAt2M1-q8SeBPLFmjNZ-rtBbm2RN1NKN9H-3T0px3w21tEjHPQ@mail.gmail.com>
	<CAAt2M1--o0EgVwVi8dM5Rr-PdkPjmv90tE8K7keFMAmGWY7=aA@mail.gmail.com>
	<CAAt2M1_2Ajj1BfKRcHzABSt0sDYsc6PAeQfR=VPBG0c1Rmxn0g@mail.gmail.com>
	<CAAt2M18EVqAKz8K+QZhVfUZGjeAdP43mQQhmO6_D4i8377Bn+Q@mail.gmail.com>
	<CAAt2M19yftfzDLu1vRis_Ui_MZJN65Gy+Lyd+JMdaELfyc4atg@mail.gmail.com>
	<CAAt2M1_9V60dbDxvkmYVYPFZWVu6nNzWjS_E0icCKUq9jPZkXQ@mail.gmail.com>
	<CAAt2M1-9TJnpY6PAwjrOYU6WKTUY65uJ4Rg5mXXSbmb-NC+1dw@mail.gmail.com>
	<CAAt2M1-gyMP+t+z3DrTVQEQmDhm6jdXEs8=Vm9biUCT_bVWNzQ@mail.gmail.com>
	<CAAt2M18GKgjhUgSx0eo9XgQDehh2YgV0O2Q6Wbjkzk2dkAjy-w@mail.gmail.com>
	<CAAt2M19hUmRaL2QyB37i-3eHtS9RCxrDVUDJGi8qsMyF2DSujQ@mail.gmail.com>
	<CAAt2M1_5spX+8JsVykcc8O7jzk2a9cZBvgZm6UQwGDA4v3d+FA@mail.gmail.com>
	<CAAt2M1_0hjmtNwLvGbR_BGaMyhJ78+dBN7HxCkMAp-EbnLwhZg@mail.gmail.com>
	<CAAt2M18qRi6BQ+=2mabg1+qkgo5E9t-S5Co0uEtL76J_HOdtmg@mail.gmail.com>
	<CAAt2M1-McXyTYuMzD+ysv9ZUgPvSRSW7XjqhVKPZqLuS_DLZqw@mail.gmail.com>
	<CAAt2M19xJRUQG9ucpQoOQX=NJ9Vsv2wUTemDtNR672yOFNgWqg@mail.gmail.com>
	<CAAt2M182Ttc=Q2Zxu+_vtJ+Jp4hoWiY0wHtLd4pX5=iGJUvnAQ@mail.gmail.com>
	<CAAt2M18h6w9ctxudjaQLczkUXRRROXH=BmXL=ye45TvOs6w1Fg@mail.gmail.com>
	<CAAt2M1-ErU2SLLDFXWFshPABB5mEe-NcORwXvUHxyCP_i47NHw@mail.gmail.com>
	<CAAt2M1_9CP0DHGKw-t4s35Rgi-RR9Tw0rYtC1ogyNzvnZT1V+Q@mail.gmail.com>
	<CAAt2M1-uNX=VStfcVkRQGX4X1PQAvNKG_p7zCPCMnz=pERhuQg@mail.gmail.com>
	<CAAt2M1-eosLcpceRi=VK2+cjxoPDiWc78h8=xBFwFER+=Bd1aQ@mail.gmail.com>
	<CAAt2M18hRp8X9RwUTo5oouGGBrvf2FKs+D_jRhMMH+5RPi6Htg@mail.gmail.com>
	<CAAt2M19Ucc05MTtPwAV_gVfGY11shDTQ=42jCjLP-YD3jxGq1Q@mail.gmail.com>
	<CAAt2M1_2QqqYvf4YKyBZHru441cfv9eLP+W20L9TFhBA2iOz2w@mail.gmail.com>
	<CAAt2M18JmZupZwzD+TdQibHHpfgecps5pF+8SKkZVevhvBD=bg@mail.gmail.com>
	<CAAt2M1--V_5a6Wqj8BNF_rx4ejbep46iEEWSANu-qTxUsMgWGQ@mail.gmail.com>
	<CAAt2M19unyFm5qCDDhGMSSooHk9TeHJs6fAn8kocS9gYY0TvcQ@mail.gmail.com>
	<CAAt2M1_omDTW0XK4etoo+vbZLBGSCVGzBKKW3eVm_8GJGqNV9w@mail.gmail.com>
	<CAAt2M1-bqeqtB8S1BFQb-Tm2wx=QU8eVSu4gjxS=ZYyT=aL9xg@mail.gmail.com>
	<CAAt2M1-LBX=16yO3QdFpKSjFqLErQsW_suWb9fgGrHuHO81eZg@mail.gmail.com>
	<CAAt2M1-zxJJ9DdVMXRA9avarjjUbE_TgjhrD-JzwcTK6FtgGeg@mail.gmail.com>
	<CAAt2M19a=gd6Pg+BJQpwgdUi7MOUaNw497Zk0hw=FN2ZR2jsXg@mail.gmail.com>
	<CAAt2M18D6-hYanWVMUd3pK3BhRL4Q_zFSP_Z4=rPuah2X=o2WA@mail.gmail.com>
	<CAAt2M1-ETfspsYX4qAd_d==F9jTAsjHU8p9-Fs-P=KUYD8TRvg@mail.gmail.com>
	<CAAt2M18i=L4MFMC+uzNRPwUZbbzCZbuuk2SJTzQqTZLAU64+sw@mail.gmail.com>
	<CAAt2M1-quYTuhr9yXKyJzoxPg4vcLeRMTPX5GemJ+hGT4WbDwg@mail.gmail.com>
	<CAAt2M18mSF_xPOUmjCWAyOkX=vKC0EdSEvMiBC-eNeZa=2u0_g@mail.gmail.com>
	<CAAt2M19LrjODH+t3FJKfdtm2KOUTu1ZX_rF+EZhxoHc-Wi8Fow@mail.gmail.com>
	<CAAt2M18QjPrjh9nAjfaZ4QHOdvzC3-2sMoMwBna-Q4r+P=1d_A@mail.gmail.com>
	<CAAt2M19U5tXpERL9+Q5f4WMvCOMjoxn6VCemz=Urn4LHPZbfNA@mail.gmail.com>
	<CAAt2M1_s2x6H6_sFMBHj1N4Gaft-V3hFiKbSq1f4sCEmsz+NfA@mail.gmail.com>
	<CAAt2M18K2MUCa5eCoYsZntr9UaC9ie9rNdAzBi5XKgk_k+a-QA@mail.gmail.com>
	<CAAt2M19=HQos=aC4wo2drv-wH1_Br1BCLxKu5AkOJYQFmrkzFQ@mail.gmail.com>
	<CAAt2M1-ttJA=tPbVcj6xyGyt_B1jOi0s9f+KDcdEz5R+ewgbow@mail.gmail.com>
	<CAAt2M1_-uy4uzN9ViN8ogXYmjr7KPUWmsXuiVgQ_qMoeDDHPvg@mail.gmail.com>
	<CAAt2M18ws+P2Yg-6CF3Uff6gOU2NXubG6M2B2aq7XsBZk+BMVQ@mail.gmail.com>
	<CAAt2M1_qy4wqpT+Cs+owg8Hbf3GePv3XPGkW-EDJECYJrRmAZQ@mail.gmail.com>
	<CAAt2M1-Ty-DXGVd6GnWvWNkDg9MA3+Zqr6-kAOO-0D7iFZ4qeQ@mail.gmail.com>
	<CAAt2M198u71tFgdCQZcKJQBJWf4=PRjhA49CbXT8nX5AtqXkyQ@mail.gmail.com>
	<CAAt2M1-LZQ1yE1CezFA+hr+=de-RVJ7wzkq-t969BC7OL6dWwg@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 30 Mar 2017 11:34:31 +0200
Message-ID: <CAAt2M18Fx9LwKU385id0_gHunLa=uQUmCO+jGkvSqb_2uLeCyg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1148b8467e1edd054bef66e5
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, 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: [bitcoin-dev] Block size adjustment idea - expedience fees +
 difficulty scaling proportional to block size (+ fee pool)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 30 Mar 2017 09:34:35 -0000

--001a1148b8467e1edd054bef66e5
Content-Type: text/plain; charset=UTF-8

I had these following ideas as I was thinking about how to allow larger
blocks without incentivizing the creation of excessively large blocks. I
don't know how much of this is novel, I'd appreciate if anybody could link
to any relevant prior art. I'm making no claims on this, anything novel in
here is directly released into public domain.

In short, I'm trying to rely on simple but direct incentives to improve the
behavior of Bitcoin.

Feedback requested. Some simulations requested, see below if you're willing
to help. Any questions are welcome.

---

Expedience fees. Softfork compatible.

You want to really make sure your transaction gets processed quickly?
Transactions could have a second fee type, a specially labeled
anyone-can-spend output with an op_return value defining a "best-before"
block number and some function describing the decline of the fee value for
every future block, such that before block N the miners can claim the full
expedience fee + the standard fee (if any), between block N+1 and N+X the
miner can claim a reduced expedience fee + standard fee, afterwards only
the standard fee.

When a transaction is processed late such that not the full expedience fee
can be claimed, the remainder of the expedience fee output is returned to
the specified address among the inputs/outputs (could be something like
in#3 for the address used by the 3rd UTXO input). This would have to be
done for all remaining expedience fees within the last transaction in the
block, inserted there by the miner.

These additional UTXO:s does increase overhead somewhat, but hopefully not
by too much. If we're going to modify the transaction syntax eventually,
then we could take the chance to design for this to reduce overhead.

My current best idea for how to handle returned expedience fees in
multiuser transactions (coinjoin, etc) is to donate it to an agreed upon
address. For recurring donation addresses (the fee pool included!), this
reduces the number of return UTXO:s in the fee processing transaction.

The default client policy may be to split the entire fee across an
expedience fee and a fee pool donation, where the donation part becomes
larger the later the transaction gets processed. This is expected to slow
down the average inclusion speed of already delayed transactions, but they
remain profitable to include.

The dynamics here is simple, a miner is incentivized to process a
transaction with an expedience fee before a standard fee of the same
value-per-bit in order to not reduce the total value of the available fees
of all standing transactions they can process. The longer they wait, the
less total fees available.

Sidenote: a steady stream of expedience fees reduces the profitability of
block withholding attacks (!), at some threshold it should make it entirely
unprofitable vs standard mining. This is due to the increased risk of
losing valuable expedience fees added after you finished your first block
(as the available value will be reduced in your block #2, vs what other
miners can claim while still mining on that previous block).
(Can somebody verify this with simulations?)

---

Fee pool. Softfork compatible.

We want to smooth out fee payments too for the future when the subsidy
drops, to prevent deliberate forking to steal fees. We can introduce a
designated P2SH anyone-can-spend fee pool address. The miner can never
claim the full fees from his block or claim the full amount in the pool,
only some percentage of both. The remainder goes back into the pool (this
might be done at the end of the same expedience fee processing transaction
described above). Anybody can deliberately pay to the pool.

The fee pool is intended to act as a "buffer" such that it remains
profitable to not try to steal fees but to just mine normally, even during
relatively extreme fee value variance (consider the end of a big
international shopping weekend).

The fee value claimed by the miners between blocks is allowed to vary, but
we want to avoid order-of-magnitude size variation (10x). We do however
want the effect of expedience fees to have an impact. Perhaps some
logarithmic function can smooth it out? Forcing larger fees to be
distributed over longer time periods?

---

Block size dependent difficulty scaling. Hardfork required.

Larger blocks means greater difficulty - but it doesn't scale linearly,
rather a little less than linearly. That means miners can take a penalty in
difficulty to claim a greater number of high fee transactions in the same
amount of time (effectively increasing "block size bitrate"), increasing
their profits. When such profitable fees aren't available, they have to
reduce block size.

In other words, the users literally pay miners to increase block size (or
don't pay, which reduces it).

(Sidenote: I am in favor of combining this with the idea of a 32 MB max
blocksize (or larger), with softforked scheduled lower size caps (perhaps
starting at 4 MB max) that grows according to a schedule. This reduces the
risk of rapidly increasing load before we have functional second layer
scaling in place.)

In order for a miner to profit from adding additional transactions, their
fees must exceed the calculated cost of the resulting difficulty penalty to
make it worth it to create a larger block. Such loads are expected during
international shopping weekends.
With only a few available high value transactions the incentive becomes the
reverse, to create a smaller block with lower difficulty to faster claim
those fees.

To keep the average 10 minute block rate and to let this mechanism shift
the "block size bitrate" as according to the fee justified block size
changes, we set an Expected blocksize value that changes over time, and we
change the difficulty target into the Standard difficulty target, where
each block must reach a Scaled difficulty target .

In terms of math we do something like this:
Scaled difficulty = Standard difficulty * f(blocksize), where f would
likely be some logarithmic function, and blocksize is defined in terms of
units of Expected blocksize (a block 1.5x larger than Expected blocksize
gets a value of 1.5).

When we retarget the Standard difficulty and Expected blocksize we do this:
Standard difficulty = Network hashrate per 10 minutes (approximately same
as before, but now we take the Scaled difficulty of the last period's
previous blocks into consideration)
Standard blocksize = Recent average effective block bitrate = (sum of
recent (weighted!) block sizes / length of timeperiod) / number of blocks
in a retargeting period.

Thus, generating larger blocks drives up the long term standard block
bitrate, smaller blocks reduces it, in both cases we strive to average 1
block per 10 minutes.

Combining this with expedience fees makes it even more effective;

There's always a cutoff for where a miner stops including unprocessed
transactions and let the rest remain for the next block. For standard fees,
this would result in a fairly static block size and transactions backlog.
With expedience fees your transaction can bypass standard fees with same
value-per-bit, as explained above, because otherwise the miners reduces the
value of their future expected fees. The more people that do this, the
greater incentive to not delay transactions and instead increase the
blocksize. (Can somebody help with the math here? I want simulations of
this.)

(Sidenote: I'm in favor of RBF, replace-by-fee. This makes the above work
much more smoothly. Anybody relying on the security of unconfirmed
transactions for any significant value *have to* rely on some kind of
incentive protected multisignature transaction, including LN type second
layer schemes. The other option is just not secure.)

If load is low then you can add a high expedience fee to incentivize the
creation of a smaller block with your transaction, since difficulty will be
reduced for the smaller block. This means the miner has a higher chance of
beating the competition. Adding additional lower fee transactions may
reduce his average value-per-bit to become less profitable.

Miners simply aim to maximize their fees-per-bit, while also paying as
little as possible in mining costs.

To make this work as intended for those willing to explicitly pay to reduce
block size, one could tag such an expedience fee with a maximum allowed
blocksize (where the fee will be claimed in such a smaller block if it is
the more profitable option), such that it won't be countered by others
making more high expedience fees to increase blocksize. Note: I'm not
particularly in favor of this idea, just mentioning the possibility.

--001a1148b8467e1edd054bef66e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I had these following ideas as I was thinking about how t=
o allow larger blocks without incentivizing the creation of excessively lar=
ge blocks. I don&#39;t know how much of this is novel, I&#39;d appreciate i=
f anybody could link to any relevant prior art. I&#39;m making no claims on=
 this, anything novel in here is directly released into public domain.=C2=
=A0<div dir=3D"auto"><br></div><div dir=3D"auto">In short, I&#39;m trying t=
o rely on simple but direct incentives to improve the behavior of Bitcoin.=
=C2=A0<br><div dir=3D"auto"><br></div><div dir=3D"auto">Feedback requested.=
 Some simulations requested, see below if you&#39;re willing to help. Any q=
uestions are welcome.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">---</div><div dir=3D"auto"><br></div><div dir=3D"auto">Expedience fees.=
 Softfork compatible.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">You want to really make sure your transaction gets processed quickly? T=
ransactions could have a second fee type, a specially labeled anyone-can-sp=
end output with an op_return value defining a &quot;best-before&quot; block=
 number and some function describing the decline of the fee value for every=
 future block, such that before block N the miners can claim the full exped=
ience fee + the standard fee (if any), between block N+1 and N+X the miner =
can claim a reduced expedience fee + standard fee, afterwards only the stan=
dard fee.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">When a t=
ransaction is processed late such that not the full expedience fee can be c=
laimed, the remainder of the expedience fee output is returned to the speci=
fied address among the inputs/outputs (could be something like in#3 for the=
 address used by the 3rd UTXO input). This would have to be done for all re=
maining expedience fees within the last transaction in the block, inserted =
there by the miner.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">These additional UTXO:s does increase overhead somewhat, but hopefully no=
t by too much. If we&#39;re going to modify the transaction syntax eventual=
ly, then we could take the chance to design for this to reduce overhead.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">My current best idea=
 for how to handle returned expedience fees in multiuser transactions (coin=
join, etc) is to donate it to an agreed upon address. For recurring donatio=
n addresses (the fee pool included!), this reduces the number of return UTX=
O:s in the fee processing transaction.=C2=A0</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">The default client policy may be to split the entire f=
ee across an expedience fee and a fee pool donation, where the donation par=
t becomes larger the later the transaction gets processed. This is expected=
 to slow down the average inclusion speed of already delayed transactions, =
but they remain profitable to include.=C2=A0</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">The dynamics here is simple, a miner is incentivized t=
o process a transaction with an expedience fee before a standard fee of the=
 same value-per-bit in order to not reduce the total value of the available=
 fees of all standing transactions they can process. The longer they wait, =
the less total fees available.=C2=A0</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Sidenote: a steady stream of expedience fees reduces the profi=
tability of block withholding attacks (!), at some threshold it should make=
 it entirely unprofitable vs standard mining. This is due to the increased =
risk of losing valuable expedience fees added after you finished your first=
 block (as the available value will be reduced in your block #2, vs what ot=
her miners can claim while still mining on that previous block).=C2=A0</div=
><div dir=3D"auto">(Can somebody verify this with simulations?)=C2=A0</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">---</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">Fee pool. Softfork compatible.=C2=A0</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">We want to smooth out fee payments t=
oo for the future when the subsidy drops, to prevent deliberate forking to =
steal fees. We can introduce a designated P2SH anyone-can-spend fee pool ad=
dress. The miner can never claim the full fees from his block or claim the =
full amount in the pool, only some percentage of both. The remainder goes b=
ack into the pool (this might be done at the end of the same expedience fee=
 processing transaction described above). Anybody can deliberately pay to t=
he pool.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">The fee p=
ool is intended to act as a &quot;buffer&quot; such that it remains profita=
ble to not try to steal fees but to just mine normally, even during relativ=
ely extreme fee value variance (consider the end of a big international sho=
pping weekend).=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Th=
e fee value claimed by the miners between blocks is allowed to vary, but we=
 want to avoid order-of-magnitude size variation (10x). We do however want =
the effect of expedience fees to have an impact. Perhaps some logarithmic f=
unction can smooth it out? Forcing larger fees to be distributed over longe=
r time periods?=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">--=
-</div><div dir=3D"auto"><br></div><div dir=3D"auto">Block size dependent d=
ifficulty scaling. Hardfork required.=C2=A0</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Larger blocks means greater difficulty - but it doesn&#=
39;t scale linearly, rather a little less than linearly. That means miners =
can take a penalty in difficulty to claim a greater number of high fee tran=
sactions in the same amount of time (effectively increasing &quot;block siz=
e bitrate&quot;), increasing their profits. When such profitable fees aren&=
#39;t available, they have to reduce block size.</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">In other words, the users literally pay miners to =
increase block size (or don&#39;t pay, which reduces it).=C2=A0</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">(Sidenote: I am in favor of combini=
ng this with the idea of a 32 MB max blocksize (or larger), with softforked=
 scheduled lower size caps (perhaps starting at 4 MB max) that grows accord=
ing to a schedule. This reduces the risk of rapidly increasing load before =
we have functional second layer scaling in place.)=C2=A0</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">In order for a miner to profit from adding=
 additional transactions, their fees must exceed the calculated cost of the=
 resulting difficulty penalty to make it worth it to create a larger block.=
 Such loads are expected during international shopping weekends.=C2=A0</div=
><div dir=3D"auto">With only a few available high value transactions the in=
centive becomes the reverse, to create a smaller block with lower difficult=
y to faster claim those fees.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">To keep the average 10 minute block rate and to let this mechanism sh=
ift the &quot;block size bitrate&quot; as according to the fee justified bl=
ock size changes, we set an Expected blocksize value that changes over time=
, and we change the difficulty target into the Standard difficulty target, =
where each block must reach a Scaled difficulty target .=C2=A0</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">In terms of math we do something lik=
e this:</div><div dir=3D"auto">Scaled difficulty =3D Standard difficulty * =
f(blocksize), where f would likely be some logarithmic function, and blocks=
ize is defined in terms of units of Expected blocksize (a block 1.5x larger=
 than Expected blocksize gets a value of 1.5).=C2=A0</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">When we retarget the Standard difficulty and E=
xpected blocksize we do this:=C2=A0</div><div dir=3D"auto">Standard difficu=
lty =3D Network hashrate per 10 minutes (approximately same as before, but =
now we take the Scaled difficulty of the last period&#39;s previous blocks =
into consideration)</div><div dir=3D"auto">Standard blocksize =3D Recent av=
erage effective block bitrate =3D (sum of recent (weighted!) block sizes / =
length of timeperiod) / number of blocks in a retargeting period.=C2=A0</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">Thus, generating larger blo=
cks drives up the long term standard block bitrate, smaller blocks reduces =
it, in both cases we strive to average 1 block per 10 minutes.=C2=A0</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Combining this with expedience=
 fees makes it even more effective;</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">There&#39;s always a cutoff for where a miner stops including u=
nprocessed transactions and let the rest remain for the next block. For sta=
ndard fees, this would result in a fairly static block size and transaction=
s backlog.=C2=A0</div><div dir=3D"auto">With expedience fees your transacti=
on can bypass standard fees with same value-per-bit, as explained above, be=
cause otherwise the miners reduces the value of their future expected fees.=
 The more people that do this, the greater incentive to not delay transacti=
ons and instead increase the blocksize. (Can somebody help with the math he=
re? I want simulations of this.)=C2=A0</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">(Sidenote: I&#39;m in favor of RBF, replace-by-fee. This mak=
es the above work much more smoothly. Anybody relying on the security of un=
confirmed transactions for any significant value *have to* rely on some kin=
d of incentive protected multisignature transaction, including LN type seco=
nd layer schemes. The other option is just not secure.)=C2=A0</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">If load is low then you can add a hig=
h expedience fee to incentivize the creation of a smaller block with your t=
ransaction, since difficulty will be reduced for the smaller block. This me=
ans the miner has a higher chance of beating the competition. Adding additi=
onal lower fee transactions may reduce his average value-per-bit to become =
less profitable.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">M=
iners simply aim to maximize their fees-per-bit, while also paying as littl=
e as possible in mining costs.=C2=A0</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">To make this work as intended for those willing to explicitly =
pay to reduce block size, one could tag such an expedience fee with a maxim=
um allowed blocksize (where the fee will be claimed in such a smaller block=
 if it is the more profitable option), such that it won&#39;t be countered =
by others making more high expedience fees to increase blocksize. Note: I&#=
39;m not particularly in favor of this idea, just mentioning the possibilit=
y.=C2=A0</div><div dir=3D"auto"><br></div></div></div>

--001a1148b8467e1edd054bef66e5--