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
74
75
76
|
Return-Path: <thomas@thomaszander.se>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5108188B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Aug 2015 08:10:50 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from pmx.vmail.no (pmx.vmail.no [193.75.16.11])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id E1816EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Aug 2015 08:10:49 +0000 (UTC)
Received: from pmx.vmail.no (localhost [127.0.0.1])
by localhost (pmx.isp.as2116.net) with SMTP id 8038A44307
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Aug 2015 10:10:48 +0200 (CEST)
Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28])
by pmx.vmail.no (pmx.isp.as2116.net) with ESMTP id B16734481F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Aug 2015 10:10:46 +0200 (CEST)
Received: from pluto.localnet (unknown [81.191.183.21])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp.bluecom.no (Postfix) with ESMTPS id 9818FAA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Aug 2015 10:10:46 +0200 (CEST)
From: Thomas Zander <thomas@thomaszander.se>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Wed, 12 Aug 2015 10:10:45 +0200
Message-ID: <3295391.2gkoFVhbEs@pluto>
User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <CAPg+sBjGVk1jHraLZTroRneL6L1HxZ-bTGaLNwakcDSDDHqauA@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
<CALgxB7sLsod9Kb-pwxGwCtPpWXsUusDE1nJ7p4nbFMG8mDWFtg@mail.gmail.com>
<CAPg+sBjGVk1jHraLZTroRneL6L1HxZ-bTGaLNwakcDSDDHqauA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Fees and the block-finding process
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 12 Aug 2015 08:10:50 -0000
On Tuesday 11. August 2015 21.51.59 Pieter Wuille via bitcoin-dev wrote:
> If people are doing transactions despite being unreliable, there
> must be a use for them.
Thats one usage of the form unreliable.
Yes, if people start getting their transactions thrown out because of full
blocks or full memory pools, then its unreliable to send stuff.
Much more importantly is the software is unreliable at such loads. Bitcoin
core will continue to grow in memory consumption, and eventually crash. Or,
worse, crash the system its running on.
We know of some issues in the software with regards to running at > 100%
capacity, I'm sure we'll find more when it actually happens.
IT experts are serious when they say that they avoid maxing out a system like
the plague.
This, btw, is a good scenario where more centralization ends up happening when
blocks are always full and people need to upgrade their client every week to
keep up with the bugfixes.
|
