From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Andrew Cann <shum@canndrew•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block solving slowdown
Date: Mon, 30 Mar 2020 02:59:53 +0000 [thread overview]
Message-ID: <dUt3gYGhyaMYXiz6ZoS0whlq57ImbjYO8-z4lw4uZkqzMUHjmPoLtRSuQnM3h26wTpVFUsZWM9wH2yGWRPd-bEx2HhvWYuxKRTXYojw5hT4=@protonmail.com> (raw)
In-Reply-To: <20200329081136.GA15016@canndrew.org>
Good morning Andrew,
> > 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 paidenough? 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.
If your coins have no security, you cannot use them safely.
If you assign value to something, you will want to ensure some amount of protection to that something, proportional to the value you assign the something
By forcing a competition for limited block space, Bitcoin forces users to honestly assess how much security they are willing to pay for.
> 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.
Suppose everybody "agrees" to a reasonable fee level.
They divide up the block space among themselves and assign a fee.
Then suddenly one of the participants realizes they actually have to have a transaction added, but the block space they already agreed to use is not sufficient to fit.
Since their agreement is just ink on a page, this participant spins up a new Bitcoin non-full node, connects to the Bitcoin network over TOR, then broadcasts the extra transaction with a higher feerate.
This evicts one of the transactions in the next block (which could also be one that this cheating participant wants, but let us say that this sudden new transaction is even more important than the others it currently has allocated for the next block).
The other participants now have a risk that their transaction does not get included in the block.
Each one then re-assesses their security and timeliness requirements, and can then decide to bump their fee using RBF, if that is necessary.
This competition will then stabilize when each participant decides that the added fee to ensure their inclusion in the next block is too high for their security and timeliness requirements, and the risk they do not get their transaction confirmed is acceptable to them given the cost of getting their transaction confirmed.
All of the above is already how Bitcoin works today.
That is the only mechanism necessary, or even possible.
Always remember that any voting scheme always implicitly has an extra option called "all the options suck so I will not vote".
In this context, this implies that people can just sell their coins and forget the whole system, rather than deal with a mechanism which ensures that coins they own are always devalued continuously by others voting for devaluation.
They can sell it for a coin where their held coins are not devalued by policy, i.e. your mechanism will never have widespread support necessary for reliably forking the chain.
>
> > 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?
Death.
No Lightning node will last forever, and its channels will be eventually be closed.
Than, any onchain funds will be in the slow expensive onchain domain, so the heirs of the dead Lightning node will want to put them back into Lightning as fast as possible.
Given the number of economic nodes we expect to eventually exist (and thus possibly die) in the future, we can expect some level of such activity in the long run.
It is helpful to remember as well that this is a long-run issue anyway.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-03-30 3:00 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 ` [bitcoin-dev] Block solving slowdown Andrew Cann
2020-03-30 2:59 ` ZmnSCPxj [this message]
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='dUt3gYGhyaMYXiz6ZoS0whlq57ImbjYO8-z4lw4uZkqzMUHjmPoLtRSuQnM3h26wTpVFUsZWM9wH2yGWRPd-bEx2HhvWYuxKRTXYojw5hT4=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=shum@canndrew$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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