path: root/d8/7b42735bd9bb9939fff7833cf639312e7d015a

Return-Path: <shum@canndrew.org>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 492C1C0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 09:17:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 3AD3720411
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 09:17:47 +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 BCJwxLCuFyGn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 09:17:46 +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 D705820410
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 27 Mar 2020 09:17:45 +0000 (UTC)
Received: from shum by canndrew.org with local (Exim 4.84_2)
 (envelope-from <shum@canndrew.org>)
 id 1jHl7O-00020s-R0; Fri, 27 Mar 2020 05:17:34 -0400
Date: Fri, 27 Mar 2020 05:17:34 -0400
From: Andrew Cann <shum@canndrew.org>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <20200327091734.GA6531@canndrew.org>
References: <PS2P216MB0179EC99BDE0E3388F2627F89DF30@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
 <F713CAAC-1997-4645-A166-57358E520594@voskuil.org>
 <CAGLBAhdTMbZPwqV9YLMyHdNzLbN2DLjiOe6cBUbkwR_x4cGRmQ@mail.gmail.com>
 <20200323125922.GA29881@canndrew.org>
 <CAGLBAhcUgTEWnraFem0YwODc61B4nwbzddHJtE0D7ZCjUNWfYg@mail.gmail.com>
 <C_qo1AhQuklVr4owEXVgLXsvJomb9Usd1NP2zf_D_23r6Cmz9-iB7ygSfNihJp3FIfAf4c1P41fT3qQP7SFiKdCfXxpogcstHsOnpgLgbok=@protonmail.com>
 <20200325152302.GA3355@canndrew.org>
 <v1t2DhGSHFng23jy0XTRkoVJrhA_6x_QuHFWdrcxQnMS8Sdcbe7eksRtvjf6JCb8YLoHf2W5y29j3XbBIVfDALSBjoiMqxPUWKsQyGLOR_A=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR"
Content-Disposition: inline
In-Reply-To: <v1t2DhGSHFng23jy0XTRkoVJrhA_6x_QuHFWdrcxQnMS8Sdcbe7eksRtvjf6JCb8YLoHf2W5y29j3XbBIVfDALSBjoiMqxPUWKsQyGLOR_A=@protonmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Mailman-Approved-At: Fri, 27 Mar 2020 15:14:34 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: Fri, 27 Mar 2020 09:17:47 -0000


--T4sUOijqQbZv57TR
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> To change the supply is far too big a change.

It would also be a big change if bitcoin became unusable due to mining prof=
its
dropping low enough for a state actor with a warehouse full of asics to mou=
nt a
51% attack and mine empty blocks all day.

> What happens if I own a few million Bitcoin and then accidentally lose my
> private keys in a tragic ear-cleaning accident?
> Then the vote of that UTXO containing a few million Bitcoins will remain
> forever fixed and unable to change according to whatever you believe would
> make us as a community decide to change the inflation rate.

All that matters is whether the long-term rate of deflation due to lost coi=
ns
is less or greater than the rate of inflation. This determines whether the
proportion of coins whose signaled inflation rate is fixed in time would te=
nd
towards zero or one. I think it's /fairly/ safe to assume that it would rem=
ain
less. People obviously have a pretty strong incentive to not lose their coi=
ns -
particularly people who are holding massive amounts of bitcoin - and as bit=
coin
becomes more mainstream, regular users will necessarily be using forms of
protection against losing their coins (whatever they might be). Contrast th=
is
against the inflation rate which should remain high enough to prevent very
wealthy entities from being able to mount a 51% attack. What proportion of =
the
total market cap of bitcoin do you think your least favorite government cou=
ld
plausibly be willing to spend to take down bitcoin for a month? And do you
think it's less or greater than the proportion of all bitcoins that get los=
t in
a month?

> It is helpful to remember that as a UTXO gets buried deeper, its security=
 is
> inevitably better, and once I have a sufficient level of security in my
> ownership of the coin, I will not particularly care about any improved
> security and will not be interested in paying for more.

If we're talking about the possibility of your coin becoming worthless beca=
use
someone out there can unwind transactions at will and prevent you from spen=
ding
it then you should definitely be interested.

> If I want to *spend* my Bitcoins on something --- and nothing has value u=
ntil
> I actually utilize it --- then I *will* pay transaction fees. The receive=
r of
> the coin would want to ensure that the received UTXO is deeply buried to =
the
> point that it has sufficient security for the receiver, before releasing =
or
> providing me with whatever I am exchanging the coin for.
>
> Thus, if I find that there are no miners at all, I could offer a high fee=
 to
> get my transaction mined. Of course, you might say that this only pays for
> one block.
>
> But in most cases I will have more value remaining beyond what I spend to=
 the
> receiver, i.e. I have a change output from that transaction.
>
> In such a case, I can  pay for more blocks by re-spending the change outp=
ut
> to myself, paying a transaction fee each time, until the original transac=
tion
> that spends to the receiver is deeply buried and the receiver credits it =
and
> then releases the product or service I am exchanging *for*. Alternately t=
he
> receiver can do the same for its *own* UTXO, and will increase the paymen=
t it
> demands from me in order to perform this itself; thus I still end up payi=
ng
> for the security of the *transaction* and not the security of the *holdin=
g*.

In your example though it's just you or the receiver paying for blocks. In =
that
case you're only paying for your own security and so there's no tragedy of =
the
commons and the system works. But once you have a thousand people putting
transactions in every block and everyone is collectively paying for everyon=
e's
collective security then, without some mechanism to force everyone to pay t=
heir
fair share, you're inviting Moloch to the party.

Here's a better explanation than I could write of the phenomenon I'm talking
about:

> As a thought experiment, let=E2=80=99s consider aquaculture (fish farming=
) in a lake.
> Imagine a lake with a thousand identical fish farms owned by a thousand
> competing companies. Each fish farm earns a profit of $1000/month. For a
> while, all is well.
>=20
> But each fish farm produces waste, which fouls the water in the lake. Let=
=E2=80=99s
> say each fish farm produces enough pollution to lower productivity in the
> lake by $1/month.
>=20
> A thousand fish farms produce enough waste to lower productivity by
> $1000/month, meaning none of the fish farms are making any money. Capital=
ism
> to the rescue: someone invents a complex filtering system that removes wa=
ste
> products. It costs $300/month to operate. All fish farms voluntarily inst=
all
> it, the pollution ends, and the fish farms are now making a profit of
> $700/month =E2=80=93 still a respectable sum.
>=20
> But one farmer (let=E2=80=99s call him Steve) gets tired of spending the =
money to
> operate his filter. Now one fish farm worth of waste is polluting the lak=
e,
> lowering productivity by $1. Steve earns $999 profit, and everyone else e=
arns
> $699 profit.
>=20
> Everyone else sees Steve is much more profitable than they are, because h=
e=E2=80=99s
> not spending the maintenance costs on his filter. They disconnect their
> filters too.
>=20
> Once four hundred people disconnect their filters, Steve is earning
> $600/month =E2=80=93 less than he would be if he and everyone else had ke=
pt their
> filters on! And the poor virtuous filter users are only making $300. Steve
> goes around to everyone, saying =E2=80=9CWait! We all need to make a volu=
ntary pact
> to use filters! Otherwise, everyone=E2=80=99s productivity goes down.=E2=
=80=9D
>=20
> Everyone agrees with him, and they all sign the Filter Pact, except one
> person who is sort of a jerk. Let=E2=80=99s call him Mike. Now everyone i=
s back using
> filters again, except Mike. Mike earns $999/month, and everyone else earns
> $699/month. Slowly, people start thinking they too should be getting big
> bucks like Mike, and disconnect their filter for $300 extra profit=E2=80=
=A6
>=20
> A self-interested person never has any incentive to use a filter. A
> self-interested person has some incentive to sign a pact to make everyone=
 use
> a filter, but in many cases has a stronger incentive to wait for everyone
> else to sign such a pact but opt out himself. This can lead to an undesir=
able
> equilibrium in which no one will sign such a pact.

Won't a thousand bitcoin-spenders, individually paying for their transactio=
ns
but collectively paying for their security, end up falling into the same
dynamic?

 - Andrew


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

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

iQIcBAEBAgAGBQJefcSuAAoJEJQq94U5BTTO5aUQAI3PKH1/8iOOMACvQZp+sU/S
n9I98636kcibcnwlJysbzQAirjSLDJMdEZEQUzeRZFEGOgiurk5NVQ30Y5PdWDYv
rPfzWIqEAgziiOPzpE7QjH1e2148e3YNv1NddP1+I6rgZKCa6OeywTOY47DnVzcq
fEtRr4C0Xbh3p3H1HsIji6Z1k7DHSbVbzrAyaZWbu51AcymZEQVYe8EvC+WqjRwW
y776P99DL6GimDp204Ow0n219wZ7ZHEzI/bzNxffwCsQvv75EQfPlpAfHtA0TFbx
etgAzsCgRzlJqN4cb2n+Jpbhknjn6XtovtdkftqbUJpAG495nq2h4mKnWPLMkagx
4gVUzrZ+UQLBiYyxZs46hlezBVmLe5VDL1kNnmtkS4/yZEPYUoPC9K3295cXQ8W6
QSD0nWFWFFD3JiztQWKR1SjC09vjj1AUtN8Saz2h/wJ6JUyUGL6ZXbdQpmkHl8ZM
8z2xR5kvV49BbrEJgVLhKudrijwrgqPZ+r4ex3KJ0Pb0lrm7kkV7jtIkgu2M8ehe
NBmDFsho+s0dNcIcnoED/XZB049PrP5f6WbV/PtZC/xt7+en8nNNZDIgO6CufB+n
9NAElKNvOO+QR8yLQau5StTBMpP7NF1U+wkgypCORMEgx1Ubusn80kGfpvw9YOda
D4EFpxh8HLpZvN8DnZID
=kggM
-----END PGP SIGNATURE-----

--T4sUOijqQbZv57TR--