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
129
130
131
132
133
134
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WYB70-0000oW-TW
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Apr 2014 09:17:34 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.49 as permitted sender)
client-ip=209.85.219.49; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f49.google.com;
Received: from mail-oa0-f49.google.com ([209.85.219.49])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WYB70-0004GN-31
for bitcoin-development@lists.sourceforge.net;
Thu, 10 Apr 2014 09:17:34 +0000
Received: by mail-oa0-f49.google.com with SMTP id o6so4133091oag.36
for <bitcoin-development@lists.sourceforge.net>;
Thu, 10 Apr 2014 02:17:28 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.132.75 with SMTP id os11mr51525oeb.70.1397121448793; Thu,
10 Apr 2014 02:17:28 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Thu, 10 Apr 2014 02:17:28 -0700 (PDT)
In-Reply-To: <77889B25-03D6-4401-A5FE-432976951F55@bitsofproof.com>
References: <CA+s+GJCn9U2kmyMH6w3o+m99NCfO0ws=SccvGBYJv07WVuF=eA@mail.gmail.com>
<CAADm4BCEFCiOpNzUThPPHUamP2256izU8pwD3nerLCxks0wENA@mail.gmail.com>
<CAAS2fgTx40XSLhiygnJMrSbOC=iJ2YMVLNK7-AMt3ifvAHDZUA@mail.gmail.com>
<E9BAD633-3B6A-4A2C-AA06-DB591973DF66@bitsofproof.com>
<53456B99.9010207@monetize.io>
<B2FEC170-7214-4E46-8830-153995870B62@bitsofproof.com>
<00b77560-d7ed-4ed4-a4e5-eb1f00467a06@email.android.com>
<0509477C-89F9-47C7-8820-29ACAD4A4A8E@bitsofproof.com>
<CANEZrP2Q=TG+jejEVFFh5FhjzDDkySHNSTfwtKueLcHu=pB6Kw@mail.gmail.com>
<CA+s+GJBRvDFgktTgW2sCvAVahrjxcGqfgHw0BVNPvwUupotVrg@mail.gmail.com>
<534592E2.7040800@gmail.com>
<CAAS2fgS3q6N9go-NSKdjLwgU_5bFwa8YE88DcjNYHQTwzPCn3Q@mail.gmail.com>
<5345986C.3040901@gmail.com>
<CAAS2fgQyXHNnBDKoUMd_=-=1irGJ6cFKwi59enLJvFJiWBv50A@mail.gmail.com>
<CAJna-Hj1U5cQ22bSXoNB-4ck_urCuS9xCk+iEHsbh+yv17MP7A@mail.gmail.com>
<CANEZrP2w2b28qnYd7q=fo=VL0FzVE1R15s5Entuy+fK9x+V8Kg@mail.gmail.com>
<CA+s+GJDcGxa_ARPFAbsd54cFhgBn8WcqNrRs00TZJBrNmvq5jQ@mail.gmail.com>
<77889B25-03D6-4401-A5FE-432976951F55@bitsofproof.com>
Date: Thu, 10 Apr 2014 11:17:28 +0200
X-Google-Sender-Auth: Rq06-ZHHi90a7Sjnn_tewovZ4ZE
Message-ID: <CANEZrP1ELraedzEpME6E8s7kXy57RKtr6667_Ke7cvhvcc9W0Q@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Tamas Blummer <tamas@bitsofproof.com>
Content-Type: multipart/alternative; boundary=047d7b471e70a9dea704f6acafe4
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: 1WYB70-0004GN-31
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV
wallets
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: Thu, 10 Apr 2014 09:17:35 -0000
--047d7b471e70a9dea704f6acafe4
Content-Type: text/plain; charset=UTF-8
>
> I find it is odd that we who hold the key to instant machine to machine
> micro payments do not use it to incentivise committing resources to the
> network.
>
It's not a new idea, obviously, but there are some practical consequences:
1) To pay a node for serving, you have to have bitcoins. To get bitcoins,
you need to sync with the network via a node. Catch 22.
2) If some nodes choose to charge and others choose to not charge, a smart
wallet will always use the free nodes. In the absence of any global load
balancing algorithms, this would lead to the free nodes getting overloaded
and collapsing whilst the for-pay nodes remain silent.
3) The only payment channel implementations today are bitcoinj's (Java) and
one written by Jeff in Javascript. There are no C++ implementations. And as
Matt and I can attest to, doing a real, solid, fully debugged
implementation that's integrated into a real app is .... a lot of work.
I still think the lowest hanging fruit is basic, boring optimisations
rather than architectural rethinks.
--047d7b471e70a9dea704f6acafe4
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"><div style=3D"word-wrap:break-word"><div>I find =
it is odd that we who hold the key to instant machine to machine micro paym=
ents do not use it to incentivise committing resources to the network.</div=
>
</div></blockquote><div><br></div><div>It's not a new idea, obviously, =
but there are some practical consequences:</div><div><br></div><div>1) To p=
ay a node for serving, you have to have bitcoins. To get bitcoins, you need=
to sync with the network via a node. Catch 22.</div>
<div><br></div><div>2) If some nodes choose to charge and others choose to =
not charge, a smart wallet will always use the free nodes. In the absence o=
f any global load balancing algorithms, this would lead to the free nodes g=
etting overloaded and collapsing whilst the for-pay nodes remain silent.</d=
iv>
<div><br></div><div>3) The only payment channel implementations today are b=
itcoinj's (Java) and one written by Jeff in Javascript. There are no C+=
+ implementations. And as Matt and I can attest to, doing a real, solid, fu=
lly debugged implementation that's integrated into a real app is .... a=
lot of work.</div>
<div><br></div><div>I still think the lowest hanging fruit is basic, boring=
optimisations rather than architectural rethinks.</div></div></div></div>
--047d7b471e70a9dea704f6acafe4--
|
