path: root/fc/821f619ff23b0d36edcdbdca65209ed1fa871d

Return-Path: <shum@canndrew.org>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3AD31C07FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 29 Mar 2020 08:11:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 28F7487669
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 29 Mar 2020 08:11:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id amZGM3w0V1sg
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 29 Mar 2020 08:11:38 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from canndrew.org (canndrew.org [199.167.29.165])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 82697852C7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 29 Mar 2020 08:11:38 +0000 (UTC)
Received: from shum by canndrew.org with local (Exim 4.84_2)
 (envelope-from <shum@canndrew.org>) id 1jIT2e-0003w9-Qj
 for bitcoin-dev@lists.linuxfoundation.org; Sun, 29 Mar 2020 04:11:36 -0400
Date: Sun, 29 Mar 2020 04:11:36 -0400
From: Andrew Cann <shum@canndrew.org>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20200329081136.GA15016@canndrew.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz"
Content-Disposition: inline
In-Reply-To: <s3Ca4bxK08bu1hHG3byopx9GWrcrR57zKOtuXsT86eDoydG2UQWrVqphBAQ9BTVh3Yb3cF34d1lMD3iVHmEtb4PbX6wu2cCyeNvkEKA7NCY=@protonmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Mailman-Approved-At: Sun, 29 Mar 2020 12:53:17 +0000
Subject: Re: [bitcoin-dev] Block solving slowdown
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sun, 29 Mar 2020 08:11:40 -0000


--3V7upXqbjpZ4EhLz
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

> Fortunately in our case, only the top 4,000,000 weight worth of transactions
> gets in a block. Every bitcoin spender has an incentive to spend as little
> as possible to get into this top 4,000,000 weight and no more, but they still
> have to outbid every other user who wants the same security. Some bitcoin
> spender will then decide that overpaying slightly to ensure that they do not
> drop out of the top 4,000,000 weight even in case of a "slow" block.
>
> Thus, there will always be a need for *some* block weight limit, and that is
> what ensures that miners can get paid.

Yes, but how does this ensure that miners get paid *enough*? Every individual
making a transaction needs the miners to get paid enough for the transaction to
be meaningful, but they each individually only have the incentive to pay the
market rate for block space which is set purely by supply and demand.

It's the same as the fish farming analogy. Everyone making a transaction could
collectively decide how much miners need to get paid and agree to split the
costs. But then each individual has the incentive to renege on the agreement
and only pay the minimum they need to get their transaction included in the
block while everyone else pays for the transaction's security. My voting idea
is one potential way they could break the Nash equilibrium.

> Now it was brought up earlier that people are moving transactions offchain,
> but that is perfectly fine, because every offchain mechanism first needs an
> onchain setup, and will at some point need an onchain teardown. This
> allows increasing the effective capacity, while still ensuring that onchain
> fees remain at a level that will still ensure continued healthy operation of
> the blockchain layer. Basically, the offchain mechanism does not remove
> onchain fees, it only amortizes the onchain fees to multiple logical
> transactions.

I concede that every bitcoin user pays transaction fees, if not directly then
indirectly, so whether miners get paid through transaction fees or a block
reward is irrelevant. My concern is that moving things off-chain reduces the
transaction fees by reducing demand for block-space and that this could cause
miner revenue to drop lower than what's required to keep the network secure.

Is there any good reason to think this won't happen?

 - Andrew


--3V7upXqbjpZ4EhLz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJegFg4AAoJEJQq94U5BTTONlkP/12qC3JkkxP5XPXGL+kfIs8o
RtSZSrCo/I5xVKyD/5U6TP/0jWX6EzXvovlz4itbNM6mBfBJd6wJOw/srarKtl7E
zwe2+qqfXNHo0NrCQlSFceMTcyKMMj52+DC6w74OuVl4sdUXEEcIE1qiMn9C4RKP
r6S9BXoWpVvsYsv8ShkgIBWv/p3A6hrfY5woQRoOgD09t3Tpg4RZ+ApNjUZfsqK0
gm6joL26CwxjX0/ZpJOVddML9kWpqjiGzbPU0/KWWOjUlVaSIOdKzZxwvDaoyyUw
yysXmGHKRpgbPXnPPQgCAcXbFU3HbdeyXAmXaJxqm9A4DPvXMTpei7rCfsMmqBsJ
dAMDQk2gCXiW24q5URm9fonXbLCmTq/kFFMv3VqEMDDk0WWkkT5x9E6hBZYylEfS
0u4hFmmEvGwhzDRqAmrUFlBP6fNL3iufN8mKUtBjTGsR336PLfIdSRxQNUUOXJ20
UKX0UTX3z8zdADcmr7SV/r1umSiv2nlRUNLDj8E/qsElQa1i7+Aiy66Exyu3T4zr
6ggiXGa7shIrQRDp64NLvopnQ0XfAeNNozVAlMxxPAjHVGWWB9ndH3A4Vh+7HyQ2
Aj+uhwgeMdDtgUuVnjuhYddTYxEYI3VaDfKziyCPt0QY81OO5dHpJElo6ir846w8
gMmiYtCY/88UzfOQHPRi
=QKtw
-----END PGP SIGNATURE-----

--3V7upXqbjpZ4EhLz--