From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5B308C0177 for ; Wed, 25 Mar 2020 15:24:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 3E96A204FC for ; Wed, 25 Mar 2020 15:24:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuxBkmb19j4n for ; Wed, 25 Mar 2020 15:24:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from canndrew.org (canndrew.org [199.167.29.165]) by silver.osuosl.org (Postfix) with ESMTPS id 95A7825B04 for ; Wed, 25 Mar 2020 15:23:12 +0000 (UTC) Received: from shum by canndrew.org with local (Exim 4.84_2) (envelope-from ) id 1jH7ry-0000vG-4e; Wed, 25 Mar 2020 11:23:02 -0400 Date: Wed, 25 Mar 2020 11:23:02 -0400 From: Andrew Cann To: ZmnSCPxj Message-ID: <20200325152302.GA3355@canndrew.org> References: <20200323125922.GA29881@canndrew.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Thu, 26 Mar 2020 04:32:22 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Block solving slowdown question/poll 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: Wed, 25 Mar 2020 15:24:16 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, thanks for the replies. > Anyway, yes, your idea is fundamentally broken because a zero block reward > happens because creating even one more satoshi will push the amount of > bitcoin over 21,000,0000, breaking the meaning of "bitcoin," or, if you > like, creating a fundamental contradiction in our use of the term.=20 I wouldn't really consider that fundamentally broken. It changes the meanin= g of "bitcoin", but so does every upgrade to the protocol. The worst problem I c= an see with this is that there's probably a lot of software out there which assumes a cap of 21M. But we'd have years to find and fix those bugs. > They already do so, via an implicit "field", known as the transaction fee. > This makes the vote for how much security is needed to be costly to the > voter, which is appropriate: you pay for your security. This isn't the same thing though, economically / game-theoretically speakin= g. Transaction fees are only paid when bitcoins get moved. There's no on-going cost for people holding bitcoins (assuming they're doing their day-to-day transactions almost entirely off-chain, which is something that's only goin= g to become more common). More to the point, the transaction fee is only set by = the current demand for block space. If transaction fees drop too low to maintai= n a secure hash rate then people *could* willingly pay more than they need to to get their transactions mined, but it's unlikely they will since it'd be che= aper to just pay the minimum and hope that everyone else covers the costs of kee= ping the network secure for them. With the voting idea everyone decides what everyone pays (via dilution) to = keep the network secure. Choosing to signal a high inflation rate doesn't mean y= ou pay more than everyone else, just that you might shift the median, so there= 's no tragedy-of-the-commons problem. Also, votes are weighted by the value of the utxo, so people both vote and pay in proportion to the amount of bitcoin they're holding. Does this make sense? Or is there some game-theoretic reason I'm not seeing= for why transaction fees can never drop dangerously low in the first place? - Andrew --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJee3dVAAoJEJQq94U5BTTOII4QALov5cydHP1EA307fCQqbRwh mpsFDLWXAoh2HdMnW55/eJ75gzZBV1hvWhOeJGwNEatzfnfusKMwpbFTxH+H7CDo 1fjuRKLE0he9taQoMm5Wbjk/zeiDhDuW51Uah+b19aOhYt8GsTH5z2oX7lAyt0jZ itUU1IS0prWYq+54DgyiLe5e0v3PlTzKfe2/+gl5sayrQ+42WMy5ohY6BiQC8/VB xO1r34HkcEUNbqkg1wL0PDUPShpZ2Fq6f2UbpVecXS1GvV6dmBE2u+TQPM5qOMBr IhqxMZtsxjlmuv8Ty2isNacfxggM1rvKo4HM1JKqvyhvBuaCD/oNImO788YTS0M+ GKS4YlUbYrT8OcZ1riBiv3D97M0kr6ClXokhGO0fXHRmo8Hu6mrnqbrnzQ6FiSfx ancongHNBbgm+xWhbe10k1liz1ztUTXAkFaBnK6oT2LfgU48MHzNgxsMBgeSU/5+ vmA44M37QC+V2wCYS/fLqG4rT+A77dTnxwPWBo4Zt+akjXvEcNXjzQ/PH+mAnH3d BtD4Qz820o6QF4xHXLDWSniMFZ3a9fW/MOd0mhj/rEHIF6FcYH6NLkhcTUi+jMyy CkNoAse3PuvsQciDSCMY3ddyQJbjlzoSBity5sQEbdH1onHm5lLlJpij3zcqoElT gkWclt8G7ToH7fUZYLAn =Q003 -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ--