path: root/f9/6a8335ad48cbcb87b9e21624cfd5fa8b72439c

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EFF66C07FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 30 Mar 2020 03:00:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id DAF8285F7E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 30 Mar 2020 03:00:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id mYAgkZz0YnCe
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 30 Mar 2020 02:59:59 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
 [185.70.40.135])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id BBD4685E47
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 30 Mar 2020 02:59:58 +0000 (UTC)
Date: Mon, 30 Mar 2020 02:59:53 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=default; t=1585537196;
 bh=djJwE8Hy50r8gYCVF2o4ur6qHpO/iogF2yyTuiaLj/M=;
 h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
 b=AMzwzxTavqjzf/3dq2s8RpJ3tEeZX40f4OHPCMZW5DBqA67LBj04lQnxFAlW9UDhr
 0vC+Ha7zruZHknkkUT+tmEveO18H6FYCsieXtRugwDwMV5E1tDaZked0+Ex7LsTDRk
 boxLhu1PcquFJFM+ddpQYSuu3DauMXgFCXlucH64=
To: Andrew Cann <shum@canndrew.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <dUt3gYGhyaMYXiz6ZoS0whlq57ImbjYO8-z4lw4uZkqzMUHjmPoLtRSuQnM3h26wTpVFUsZWM9wH2yGWRPd-bEx2HhvWYuxKRTXYojw5hT4=@protonmail.com>
In-Reply-To: <20200329081136.GA15016@canndrew.org>
References: <20200329081136.GA15016@canndrew.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Mon, 30 Mar 2020 03:00:01 -0000

Good morning Andrew,

> > Fortunately in our case, only the top 4,000,000 weight worth of transac=
tions
> > gets in a block. Every bitcoin spender has an incentive to spend as lit=
tle
> > 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 bitco=
in
> > spender will then decide that overpaying slightly to ensure that they d=
o 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 individua=
l
> making a transaction needs the miners to get paid enough for the transact=
ion 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 pr=
otection to that something, proportional to the value you assign the someth=
ing

By forcing a competition for limited block space, Bitcoin forces users to h=
onestly 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 t=
he
> costs. But then each individual has the incentive to renege on the agreem=
ent
> and only pay the minimum they need to get their transaction included in t=
he
> 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 s=
ufficient to fit.
Since their agreement is just ink on a page, this participant spins up a ne=
w Bitcoin non-full node, connects to the Bitcoin network over TOR, then bro=
adcasts 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 n=
ew transaction is even more important than the others it currently has allo=
cated 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 c=
an 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 thei=
r 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 optio=
n called "all the options suck so I will not vote".
In this context, this implies that people can just sell their coins and for=
get the whole system, rather than deal with a mechanism which ensures that =
coins they own are always devalued continuously by others voting for devalu=
ation.
They can sell it for a coin where their held coins are not devalued by poli=
cy, i.e. your mechanism will never have widespread support necessary for re=
liably forking the chain.

>
> > Now it was brought up earlier that people are moving transactions offch=
ain,
> > but that is perfectly fine, because every offchain mechanism first need=
s an
> > onchain setup, and will at some point need an onchain teardown. This
> > allows increasing the effective capacity, while still ensuring that onc=
hain
> > fees remain at a level that will still ensure continued healthy operati=
on 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 bloc=
k
> 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 c=
ause
> miner revenue to drop lower than what's required to keep the network secu=
re.
>
> 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 th=
e heirs of the dead Lightning node will want to put them back into Lightnin=
g 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 t=
he long run.
It is helpful to remember as well that this is a long-run issue anyway.

Regards,
ZmnSCPxj