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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1V1Zxd-0005wk-Rq
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 10:36:53 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.53 as permitted sender)
client-ip=209.85.219.53; envelope-from=pieter.wuille@gmail.com;
helo=mail-oa0-f53.google.com;
Received: from mail-oa0-f53.google.com ([209.85.219.53])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V1Zxc-000132-4t
for bitcoin-development@lists.sourceforge.net;
Tue, 23 Jul 2013 10:36:53 +0000
Received: by mail-oa0-f53.google.com with SMTP id k14so10695213oag.40
for <bitcoin-development@lists.sourceforge.net>;
Tue, 23 Jul 2013 03:36:46 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.56.20 with SMTP id w20mr21186507igp.40.1374575806785;
Tue, 23 Jul 2013 03:36:46 -0700 (PDT)
Received: by 10.50.20.225 with HTTP; Tue, 23 Jul 2013 03:36:46 -0700 (PDT)
In-Reply-To: <ksllu7$9i$1@ger.gmane.org>
References: <CAJHLa0Ou1xF=LeLVu_wH1-XgJ1PavDV7_NHoDevo3R9+4z-ZfQ@mail.gmail.com>
<201307231030.14139.andyparkins@gmail.com>
<20130723094703.GA25900@savin> <ksllu7$9i$1@ger.gmane.org>
Date: Tue, 23 Jul 2013 12:36:46 +0200
Message-ID: <CAPg+sBj8Nt5eQmnyiD6vaFP1970hj5Z5JxEocw3BHEwO_Lbhkg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1V1Zxc-000132-4t
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] HTTP REST API for bitcoind
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, 23 Jul 2013 10:36:54 -0000
On Tue, Jul 23, 2013 at 12:29 PM, Andreas Schildbach
<andreas@schildbach.de> wrote:
> Yes, I understand that. For this reason, I would vote for adding the
> usual HTTP authentication/SSL stuff to the REST API. That way, SPV users
> can decide to run their own instance of the API (providing the needed
> resources themselves).
>
> Or, a trusted party can set up a server. For example, I would be willing
> to set it up for users of Bitcoin Wallet. I don't expect shitloads of
> paper wallets sweeps for the forseeable future.
I don't object to using a trusted server for this if people want that,
but I don't think the reference client should encourage this.
Apart from that, exposing this HTTP-based interface publicly has its
own problems, like security risks and potential DoS risks. If
anything, we should be reducing the attack surface rather than
increase it. IMHO, the only thing that should be exposed in the P2P
protocol, which is inevitable, and already has some DoS protections.
I like this HTTP interface, but it should really only be used for
trusted local applications and debugging.
--
Pieter
|
