summaryrefslogtreecommitdiff
path: root/48/10a4ec0f6e1d092e5ac746eca55f1376654029
blob: e312b1a378e78ac843f61a5355958fbd9c72e369 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <bip@mattwhitlock.name>) id 1YqiGx-0003tf-4H
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 13:24:59 +0000
X-ACL-Warn: 
Received: from resqmta-ch2-11v.sys.comcast.net ([69.252.207.43])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
	(Exim 4.76) id 1YqiGv-0004U5-QB
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 13:24:59 +0000
Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102])
	by resqmta-ch2-11v.sys.comcast.net with comcast
	id RRQl1q0062D5gil01RQsEz; Fri, 08 May 2015 13:24:52 +0000
Received: from crushinator.localnet
	([IPv6:2601:6:4800:47f:1e4e:1f4d:332c:3bf6])
	by resomta-ch2-06v.sys.comcast.net with comcast
	id RRQq1q00F2JF60R01RQrWH; Fri, 08 May 2015 13:24:52 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
Date: Fri, 08 May 2015 09:24:49 -0400
Message-ID: <6997846.HngUFLFEeM@crushinator>
User-Agent: KMail/4.14.7 (Linux/3.18.11-gentoo; KDE/4.14.7; x86_64; ; )
In-Reply-To: <47719888.P2f3pq4RTK@crushinator>
References: <16096345.A1MpJQQkRW@crushinator>
	<CAGKSKfW7fJB6n3B-OoyXOep7hAQqWGGDTiZCkpJ7vXxWRFgveA@mail.gmail.com>
	<47719888.P2f3pq4RTK@crushinator>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [69.252.207.43 listed in list.dnswl.org]
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YqiGv-0004U5-QB
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2015 13:24:59 -0000

On Friday, 8 May 2015, at 8:48 am, Matt Whitlock wrote:
> On Friday, 8 May 2015, at 3:32 pm, Joel Joonatan Kaartinen wrote:
> > It seems you missed my suggestion about basing the maximum block size on
> > the bitcoin days destroyed in transactions that are included in the block.
> > I think it has potential for both scaling as well as keeping up a constant
> > fee pressure. If tuned properly, it should both stop spamming and increase
> > block size maximum when there are a lot of real transactions waiting for
> > inclusion.
> 
> My problem with it is that "bitcoin days destroyed" is not a measure of demand for space in the block chain. In the distant future, when Bitcoin is the predominant global currency, bitcoins will have such high velocity that the number of bitcoin days destroyed in each block will be much lower than at present. Does this mean that the block size limit should be lower in the future than it is now? Clearly this would be incorrect.

I feel a need to point out something that may be obvious to some but not to others: the cumulative total number of "bitcoin days destroyed" since the genesis block is bounded by the cumulative total number of "bitcoin days created" since the genesis block. (You can't destroy something that hasn't yet been created.) After all coins have been mined, bitcoin days will be created at a rate of 21M bitcoin days per day. In the long run, bitcoin days will be destroyed at a rate not exceeding 21M bitcoin days per day. This is so because bitcoin days cannot be destroyed at a rate faster than they are created for an indefinitely long time. This upper limit on the rate of bitcoin days destruction is irrespective of bitcoin adoption and the growth in demand for space in the block chain.

Even ignoring the fact that "bitcoin days destroyed" is bounded whereas demand for block-chain space is not, we'd still have to answer the question of whether the rate of bitcoin days destroyed is a good estimator of demand for block-chain space. Why would it be? Suppose some day Satoshi moves his 1M coins to a new address. Would this huge destruction of bitcoin days imply anything about future demand for space in the block chain? No.