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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WFsP2-0003G9-WD for bitcoin-development@lists.sourceforge.net;
Tue, 18 Feb 2014 21:40:33 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org
designates 80.91.229.3 as permitted sender)
client-ip=80.91.229.3;
envelope-from=gcbd-bitcoin-development@m.gmane.org;
helo=plane.gmane.org;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WFsP0-0004Uu-Lo
for bitcoin-development@lists.sourceforge.net;
Tue, 18 Feb 2014 21:40:32 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1WFsOt-0006Ni-5k for bitcoin-development@lists.sourceforge.net;
Tue, 18 Feb 2014 22:40:23 +0100
Received: from f052085125.adsl.alicedsl.de ([78.52.85.125])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Tue, 18 Feb 2014 22:40:23 +0100
Received: from andreas by f052085125.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Tue, 18 Feb 2014 22:40:23 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Tue, 18 Feb 2014 22:40:13 +0100
Message-ID: <le0jvf$i7d$1@ger.gmane.org>
References: <le05ca$qn5$1@ger.gmane.org> <5303B110.70603@bitpay.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: f052085125.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
In-Reply-To: <5303B110.70603@bitpay.com>
X-Spam-Score: -1.0 (-)
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.91.229.3 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.1 DKIM_ADSP_ALL No valid author signature,
domain signs all mail
-0.0 SPF_PASS SPF: sender matches SPF record
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WFsP0-0004Uu-Lo
Subject: Re: [Bitcoin-development] BIP70 proposed changes
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: Tue, 18 Feb 2014 21:40:33 -0000
On 02/18/2014 08:14 PM, Ryan X. Charles wrote:
> The most important missing piece of the payment protocol is that is has
> no concept of the status of a payment after it has been made. What if
> the payment is too little? Too much? What if it is never confirmed? What
> if it is confirmed, but very late? These are regular occurrences at
> BitPay (although hopefully they will be a lot fewer after the payment
> protocol is widely adopted).
I would like to understand why this happens at BitPay? If this is
because people use cut and paste to copy the address and then type the
amount by hand... well this kind of usage will go away.
A program (like an app) should be capable of paying the exact amount. If
not, that's a bug of the app not the protocol.
> On an unrelated note, X.509 is a terrible standard that should be
> abandoned as quickly as possible.
+1
> BitPay is working on a new standard
> based on bitcoin-like addresses for authentication. It would be great if
> we could work with the community to establish a complete, decentralized
> authentication protocol.
Sounds interesting, let us know as soon as you have anything.
>> - certificate chain in pki_data: I think it should be required that is
>> most contain the first certificate PLUS all intermediate certificates
>> (if any), but NOT the root certificate. Reason: We want to be able to
>> verify offline.
>
> So long as the root certificate remains an optional addition, this seems
> like a good idea.
In which case does it make sense to duplicate the root cert? I'm asking
because it should already be present in the trusted root store, right?
Maybe can you tell about which measures you needed to take to get X.509
working? To me it felt there very several problems.
> My experience with tls in node is that it is required
TLS? We're not using that for pki_data -- its just a byte array.
>> - definition of timezone: Its not clear if times (e.g. expires) are in
>> UTC or local. I suggest to require UTC. If if we can't agree on this,
>> there should be a sentence about timezones in the spec.
>
> The world needs to abandon timezones altogether for everything and only
> use UTC. So, agreed. Require UTC.
--> https://github.com/bitcoin/bips/pull/20
|
