public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andrew Cann <shum@canndrew.org>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Block solving slowdown
Date: Sun, 29 Mar 2020 04:11:36 -0400	[thread overview]
Message-ID: <20200329081136.GA15016@canndrew.org> (raw)
In-Reply-To: <s3Ca4bxK08bu1hHG3byopx9GWrcrR57zKOtuXsT86eDoydG2UQWrVqphBAQ9BTVh3Yb3cF34d1lMD3iVHmEtb4PbX6wu2cCyeNvkEKA7NCY=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]

> 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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2020-03-29  8:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-21 18:40 [bitcoin-dev] Block solving slowdown question/poll Dave Scotese
2020-03-22  7:54 ` David A. Harding
2020-03-22 11:58   ` LORD HIS EXCELLENCY JAMES HRMH
2020-03-22 16:54     ` Eric Voskuil
2020-03-22 18:17       ` Dave Scotese
2020-03-23 12:59         ` Andrew Cann
2020-03-23 18:39           ` Dave Scotese
2020-03-24  7:42             ` ZmnSCPxj
2020-03-25 15:23               ` Andrew Cann
2020-03-26  1:42                 ` ZmnSCPxj
2020-03-27  9:17                   ` Andrew Cann
2020-03-28  2:12                     ` ZmnSCPxj
2020-03-29  8:11                       ` Andrew Cann [this message]
2020-03-30  2:59                         ` [bitcoin-dev] Block solving slowdown ZmnSCPxj
2020-03-31  2:06                           ` ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200329081136.GA15016@canndrew.org \
    --to=shum@canndrew.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox