summaryrefslogtreecommitdiff
path: root/07/a98542b0630f9908d77cb6ac9ebdf3bd78dac6
blob: 9f5c0b45c098b779f2b2d5a243470ca409e18a4d (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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <bip@mattwhitlock.name>) id 1Yqhur-0000W0-Tp
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 13:02:09 +0000
X-ACL-Warn: 
Received: from resqmta-po-05v.sys.comcast.net ([96.114.154.164])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
	(Exim 4.76) id 1Yqhun-0007Rq-K8
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 13:02:09 +0000
Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234])
	by resqmta-po-05v.sys.comcast.net with comcast
	id RQoQ1q00253iAfU01QoVA8; Fri, 08 May 2015 12:48:29 +0000
Received: from crushinator.localnet
	([IPv6:2601:6:4800:47f:1e4e:1f4d:332c:3bf6])
	by resomta-po-10v.sys.comcast.net with comcast
	id RQoM1q00N2JF60R01QoU7z; Fri, 08 May 2015 12:48:29 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com>
Date: Fri, 08 May 2015 08:48:16 -0400
Message-ID: <47719888.P2f3pq4RTK@crushinator>
User-Agent: KMail/4.14.7 (Linux/3.18.11-gentoo; KDE/4.14.7; x86_64; ; )
In-Reply-To: <CAGKSKfW7fJB6n3B-OoyXOep7hAQqWGGDTiZCkpJ7vXxWRFgveA@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
	<CAP63atbdFSw0rDeuwgtjsDYsXnKSHNN9=zedzip2MsZ0hSY59w@mail.gmail.com>
	<CAGKSKfW7fJB6n3B-OoyXOep7hAQqWGGDTiZCkpJ7vXxWRFgveA@mail.gmail.com>
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 [96.114.154.164 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: 1Yqhun-0007Rq-K8
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:02:09 -0000

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.

I saw it. I apologize for not including it in my list. I should have, for sake of discussion, even though I have a problem with it.

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.

Perhaps I am misunderstanding your proposal. Could you describe it more explicitly?