Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WYBRi-0000Vi-Lh for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 09:38:58 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WYBRf-0004tw-40 for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 09:38:58 +0000 Received: from [37.143.74.116] (helo=[192.168.2.2]); authenticated by wp059.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WYBRY-0007Ys-BB; Thu, 10 Apr 2014 11:38:48 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_7BC393DF-1A6A-4B64-815D-F244B67EA043"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Tamas Blummer In-Reply-To: Date: Thu, 10 Apr 2014 11:39:07 +0200 Message-Id: <5EA7E1CA-2673-49D4-A1C4-015117E5133D@bitsofproof.com> References: <53456B99.9010207@monetize.io> <00b77560-d7ed-4ed4-a4e5-eb1f00467a06@email.android.com> <0509477C-89F9-47C7-8820-29ACAD4A4A8E@bitsofproof.com> <534592E2.7040800@gmail.com> <5345986C.3040901@gmail.com> <77889B25-03D6-4401-A5FE-432976951F55@bitsofproof.com> To: Mike Hearn X-Mailer: Apple Mail (2.1874) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1397122735; 8fc6162f; X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WYBRf-0004tw-40 Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 09:38:58 -0000 --Apple-Mail=_7BC393DF-1A6A-4B64-815D-F244B67EA043 Content-Type: multipart/alternative; boundary="Apple-Mail=_5E30614C-4BF4-4DF5-AE98-5EB58A193856" --Apple-Mail=_5E30614C-4BF4-4DF5-AE98-5EB58A193856 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I know the idea is not new. Just bringing it up to emphasize that if we = don=92t use it how could we expect other networks using it. Machine to machine micro payments could become the killer application = for Bitcoin. 1) There is no catch 22 as there are plenty of ways getting bitcoin = without bootstrapping a full node. 2) let markets work out and not speculate what would happen. 3) Serving archive bolcks does not have to be part of core but could be = a distinct service written in a language of your choice using new = protocol. As mentioned earlier I am for a stripped down core that does nothing = else than consensus and stores nothing else needed for that task and = offering SPV api to the wallets. Tamas Blummer http://bitsofproof.com On 10.04.2014, at 11:17, Mike Hearn wrote: > 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. >=20 > It's not a new idea, obviously, but there are some practical = consequences: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > I still think the lowest hanging fruit is basic, boring optimisations = rather than architectural rethinks. --Apple-Mail=_5E30614C-4BF4-4DF5-AE98-5EB58A193856 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I = know the idea is not new. Just bringing it up to emphasize that if we = don=92t use it how could we expect other networks using = it.
Machine to machine micro payments could become the killer = application for Bitcoin.

1) There is no catch = 22 as there are plenty of ways getting bitcoin without bootstrapping a = full node.

2) let markets work out and not = speculate what would happen.

3) Serving archive = bolcks does not have to be part of core but could be a distinct service = written in a language of your choice using new = protocol.

As mentioned earlier I am for a = stripped down core that does nothing else than consensus and stores = nothing else needed for that task and offering SPV api to the = wallets.


On 10.04.2014, at 11:17, Mike Hearn <mike@plan99.net> wrote:

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.

= --Apple-Mail=_5E30614C-4BF4-4DF5-AE98-5EB58A193856-- --Apple-Mail=_7BC393DF-1A6A-4B64-815D-F244B67EA043 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTRma7AAoJEPZykcUXcTkc0qgH/jSVwRZChJHMsQtyokr1RWF5 gLJ4PcEfkzSHuq+w8Yqe03bSrg2n//YWafuNFJpt9+hzo+XvPljJBydkU5PmBSUt lEfA9A1x6cOEX/xtau1t1uixqMVSiYeTg8F0kCSQSvPNlRspKn+RKSNQnKHDeAJw YUtUf42v+Nv+g0/qc+wj5nTK1N61aFvR6LfzCg3pDSqOJWgrrupAzSCqJzbJWHNw KCXvdQ9H2turzBdiTJBDFh6QHzoAxLlmxRuIjkTZzNNdrVPRgiOVv4PYlK8yEZXw NQrj4ooZiPwpYErEQl6mo2DXF4Bke2ejJZEuvIVIzXww6ZMVsFBP1Xeif/X/cxY= =Gox2 -----END PGP SIGNATURE----- --Apple-Mail=_7BC393DF-1A6A-4B64-815D-F244B67EA043--