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
98
99
100
101
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YwxJJ-00045B-7t
for bitcoin-development@lists.sourceforge.net;
Mon, 25 May 2015 18:41:13 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.174 as permitted sender)
client-ip=209.85.212.174; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f174.google.com;
Received: from mail-wi0-f174.google.com ([209.85.212.174])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YwxJI-0004g0-C0
for bitcoin-development@lists.sourceforge.net;
Mon, 25 May 2015 18:41:13 +0000
Received: by wicmx19 with SMTP id mx19so46404267wic.0
for <bitcoin-development@lists.sourceforge.net>;
Mon, 25 May 2015 11:41:06 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.9.161 with SMTP id a1mr42372304wjb.39.1432579266390;
Mon, 25 May 2015 11:41:06 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.143.9 with HTTP; Mon, 25 May 2015 11:41:06 -0700 (PDT)
In-Reply-To: <2114827.D6GUhXtGkV@crushinator>
References: <CANe1mWzBy8-C+CWfwaOLxJ2wokjy8ytQUh2TkRY_Ummn1BpPzw@mail.gmail.com>
<2114827.D6GUhXtGkV@crushinator>
Date: Mon, 25 May 2015 20:41:06 +0200
X-Google-Sender-Auth: CrE-47OqobNqiENmq4ODYTFEUuc
Message-ID: <CANEZrP2KnL9NO-DgUuaT5-VHE0oT5MTsok2YuAO1nJiznLfpMA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: multipart/alternative; boundary=047d7b5d34fa4930960516ec5aa2
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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
X-Headers-End: 1YwxJI-0004g0-C0
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] A suggestion for reducing the size of the
UTXO database
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: Mon, 25 May 2015 18:41:13 -0000
--047d7b5d34fa4930960516ec5aa2
Content-Type: text/plain; charset=UTF-8
>
> some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you
> can only spend confirmed UTXOs. I can't tell you how aggravating it is to
> have to tell a friend, "Oh, oops, I can't pay you yet. I have to wait for
> the last transaction I did to confirm first." All the more aggravating
> because I know, if I have multiple UTXOs in my wallet, I can make multiple
> spends within the same block.
>
Andreas' wallet hasn't done that for years. Are you repeating this from
some very old memory or do you actually see this issue in reality?
The only time you're forced to wait for confirmations is when you have an
unconfirmed inbound transaction, and thus the sender is unknown.
--047d7b5d34fa4930960516ec5aa2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">some wallets (e.g., Andreas Schildbach's wal=
let) don't even allow it - you can only spend confirmed UTXOs. I can=
9;t tell you how aggravating it is to have to tell a friend, "Oh, oops=
, I can't pay you yet. I have to wait for the last transaction I did to=
confirm first." All the more aggravating because I know, if I have mu=
ltiple UTXOs in my wallet, I can make multiple spends within the same block=
.<br></blockquote><div><br></div><div>Andreas' wallet hasn't done t=
hat for years. Are you repeating this from some very old memory or do you a=
ctually see this issue in reality?</div><div><br></div><div>The only time y=
ou're forced to wait for confirmations is when you have an unconfirmed =
inbound transaction, and thus the sender is unknown.</div></div></div></div=
>
--047d7b5d34fa4930960516ec5aa2--
|
