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
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
|
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 4EAC5FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Aug 2015 10:42:56 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from manxnetsf05.manx.net (outbound.manx.net [213.137.31.12])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8A2F218D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Aug 2015 10:42:55 +0000 (UTC)
Received: from adsl92.39.203.140.manx.net (EHLO coldstorage.localnet)
([92.39.203.140])
by manxnetsf05.manx.net (MOS 4.4.5a-GA FastPath queued)
with ESMTP id EFZ43295; Sun, 09 Aug 2015 11:42:53 +0100 (BST)
From: Thomas Zander <thomas@thomaszander.se>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Sun, 09 Aug 2015 12:42:53 +0200
Message-ID: <1905570.ujI5LhNI6Z@coldstorage>
User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <CAGLBAhcfUv0ptwczgCkgwVxo7d=pK4GLowkwV2viqAbq6vRaDQ@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
<CALqxMTGDET0dEuw9bi=LBXF8jiuLdoPoGYaDCPpXtPvqeDW30A@mail.gmail.com>
<CAGLBAhcfUv0ptwczgCkgwVxo7d=pK4GLowkwV2viqAbq6vRaDQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Mirapoint-Received-SPF: 92.39.203.140 coldstorage.localnet
thomas@thomaszander.se 5 none
X-Junkmail-Status: score=10/50, host=manxnetsf05.manx.net
X-Junkmail-Signature-Raw: score=unknown,
refid=str=0001.0A0B0204.55C72EAD.0137, ss=1, re=0.000, recu=0.000,
reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
so=2014-07-29 09:23:55, dmn=2013-03-21 17:37:32,
mode=multiengine
X-Junkmail-IWF: false
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0),
refid=str=0001.0A0B0204.55C72EAD.0137, ss=1, re=0.000, recu=0.000,
reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,
so=2014-07-29 09:23:55, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 1d0b4c36cb3b39a7afaf456daeb455b9
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: Sun, 09 Aug 2015 10:42:56 -0000
On Saturday 8. August 2015 15.45.28 Dave Scotese via bitcoin-dev wrote:
> Someone mentioned that when the backlog grows faster than it shrinks, that
> is a real problem. I don't think it is. It is a problem for those who
> don't wait for even one confirmation
The mention you refer to was about the fact that the software doesn't cope
well with a continuously growing mempool.
If Bitcoind starts eating more and more memory, I expect lots of people that
run it now to turn it off.
> but backlogs in the past have already
> started training users to wait for at least one confirmation, or go
> off-chain.
I am wondering how you concluded that? The only time we saw full blocks for a
considerable amount of time was when we had a spammer, and the only thing
we taught people was to use higher fees.
Actually, we didn't teach people anything, we told wallet developers to do it.
Most actual users were completely ignorant of the problem.
Full blocks will then stop being a supported usecase when real humans are
trying to buy a beer or a coffee. Waiting for a confirmation won't work either
for the vast majority of the current usages of Bitcoin in the real world.
> I am comfortable leaving those zero-conf people in a little bit
> of trouble. Everyone else can double-spend (perhaps that's not as easy as
> it should be in bitcoin core) and use a higher fee, thus competing for
> block space.
This is false, if you want to double spent you have to do a lot of work and
have non-standard software. For instance sending your newer transaction to a
random node will almost always get it rejected because its a double spent.
Replace by fee (even safe) is not supported in the vast majority of Bitcoin
land.
--
Thomas Zander
|
