path: root/1b/8bb4faba584a83af07ea61e41ffd961865f109

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BC6A049B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 12:03:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com
	[209.85.220.49])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE09B12F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 12:03:49 +0000 (UTC)
Received: by pacan13 with SMTP id an13so4903950pac.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 05:03:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to;
	bh=XcLKEGzp4Rfnq9MoojNJlX32UcizdnSqkcxhCkmjnc0=;
	b=nMctb/E4QCNpGjbttXvHuj1I7dLAfZ9is9wLMtQx9bQI80R6Ak2dyUUJf/oo6cd/zK
	aiJI/RFQrKUcpDss3cUjLt3N6wOHPhFE5rqwmvGDt/9/gDD8n9HjpZIWj32YQemi+CVW
	G1FEo4BD5sksRJ5EbR7J0t4Wy3Sa8bq8QRdr1k7eY3Brg8dJQx00fA+AXZ9Ff7zB8bX+
	6J5ZhEVXlCT+S2MQyjpUBIM2Vqax5qwjmr4tVsb4BjPXd5jL9uIpQ1y76ZY40+D4J4Ff
	YsJuT29AN5RdlZcwJGv6YX2KYBgMZdj7KNdm981lM7KqGrOaGFCutKiDXYoHtmb8MCf9
	AHlg==
X-Received: by 10.66.161.232 with SMTP id xv8mr92980372pab.137.1438171429601; 
	Wed, 29 Jul 2015 05:03:49 -0700 (PDT)
Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
	xp10sm40720785pac.34.2015.07.29.05.03.47
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 29 Jul 2015 05:03:48 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_7EFA5E39-B4BA-4A27-A140-41790D94A0A0";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
Date: Wed, 29 Jul 2015 05:03:45 -0700
Message-Id: <59FC8BA8-C61F-4340-887F-CE2DD57ADD49@gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
	<CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com>
	<D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
	<CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
To: Mike Hearn <hearn@vinumeris.com>
X-Mailer: Apple Mail (2.2098)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	MIME_QP_LONG_LINE, 
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
	temporary
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2015 12:03:51 -0000


--Apple-Mail=_7EFA5E39-B4BA-4A27-A140-41790D94A0A0
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C58B19EA-3EC9-4A5C-BD9B-7D2F67AABE54"


--Apple-Mail=_C58B19EA-3EC9-4A5C-BD9B-7D2F67AABE54
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jul 29, 2015, at 4:15 AM, Mike Hearn <hearn@vinumeris.com> wrote:
>=20
> Irrelevant what term was used - and as brilliant as Satoshi might have =
been at some things, he obviously got this one wrong.
>=20
> I don't think it's obvious. You may disagree, but don't pretend any of =
this stuff is obvious.
>=20
> Consider this:  the highest Bitcoin tx fees can possibly go is perhaps =
a little higher than what our competition charges. Too much higher than =
that, and people will just say, you know what .... I'll make a bank =
transfer. It's cheaper and not much slower, sometimes no slower at all.
>=20
> And now consider that in many parts of the world bank transfers are =
free.
>=20
> They aren't actually free, of course, but they appear to be free =
because the infrastructure for doing them is cross subsidised by the =
fees on other products and services, or hidden in the prices of goods =
sold.
>=20
> So that's a market reality Bitcoin has to handle. It's already more =
expensive than the competition sometimes, but luckily not much more, and =
anyway Bitcoin has some features those other systems lack (and vice =
versa). So it can still be competitive.
>=20
> But your extremely vague notion of a "fee market" neglects to consider =
that it already exists, and it's not a market of "Bitcoin users buying =
space in Bitcoin blocks". It's "users paying to move money".
>=20
> You can argue with this sort of economic logic if you like, but don't =
claim this stuff is obvious.

100% granted - it was not obvious=E2=80=A6and we speak today with the =
benefit of hindsight.

I=E2=80=99ll clarify my argument, for the sake of anyone who thinks =
I=E2=80=99m looking to play word games rather than trying to figure out =
a good way forward.

Point is=E2=80=A6processing blocks requires computational resources that =
someone needs to put up. Unless the people who are putting up these =
resources are properly incentivized to continue doing it, the network =
will fail.

Unfortunately, it was unforeseen that most nodes on the network would =
turn out to not be miners=E2=80=A6and that most miners wouldn=E2=80=99t =
even run full nodes. Yes, I speak with the benefit of hindsight, had I =
been discussing this in 2008 I very well could have made the same =
mistake or worse. But it isn=E2=80=99t 2008, it=E2=80=99s 2015=E2=80=A6and=
 we=E2=80=99ve learned a thing or two since.

Given that things are what they are, it is clear that larger blocks =
externalize costs onto the rest of the network.

Waiting until we can no longer count on the altruistic goodwill of =
volunteers because they suddenly decide that they have better uses for =
their computers is probably not such a wonderful idea. But even worse is =
further burdening the network with externalized costs before we=E2=80=99ve=
 solved these important issues=E2=80=A6especially given the evidence =
that larger blocks tend to lead to network forks. No, I=E2=80=99m not =
talking about regular run-of-the-mill reorgs=E2=80=A6I=E2=80=99m talking =
consensus forks - a network partition that cannot be reconciled without =
manual intervention, so please don=E2=80=99t distract the issue. Yes, =
each incident occurred for a very different reason=E2=80=A6but you=E2=80=99=
d have to be blind to miss the correlation between bigger blocks and the =
propensity for forks.

What Satoshi might have thought in 2008-2009 is fascinating from a =
historical perspective, but his early pioneering insights don=E2=80=99t =
appear to be of much help in addressing these particular issues.

> Nobody threatened to start mining huge blocks given how relatively =
inexpensive it was to mine back then?
>=20
> Not that I recall. It wasn't a response to any actual event, I think, =
but rather a growing realisation that the code was full of DoS attacks.
>=20
>=20
> Guess what? SPV wallets are still not particularly widespread=E2=80=A6an=
d those that are out there are notoriously terrible at detecting network =
forks and making sure they are on the right one.
>=20
> The most popular mobile wallet (measured by installs) on Android is =
SPV. It has between 500,000 and 1 million installs, whilst Coinbase has =
not yet crossed the 500,000 mark. One of the most popular wallets on iOS =
is SPV. If we had SPV wallets with better user interfaces on desktops, =
they'd be more popular there too (perhaps MultiBit HD can recapture some =
lost ground).
>=20
> So I would argue that they are in fact very widespread.
>=20
> Likewise, they are not "notoriously terrible" at detecting chain =
forks. That's a spurious idea that you and Patrick have been pushing =
lately, but they detect them and follow reorgs across them according to =
the SPV algorithm, which is based on most work done. This is exactly =
what they are designed to do.
>=20
> Contrast this with other lightweight wallets which either don't =
examine the block chain or implement the algorithm incorrectly, and I =
fail to see how this can be described as "notoriously terrible".
>=20
>=20
> I understand that initially it was desirable that transactions be =
free=E2=80=A6but surely even Satoshi understood this couldn=E2=80=99t be =
perpetually self-sustaining=E2=80=A6and that the ability to bid for =
inclusion in blocks would eventually become a crucial component of the =
network. Or were fees just added for decoration?
>=20
> Fees were added as a way to get money to miners in a fair and =
decentralised way.
>=20
> Attaching fees directly to all transactions is certainly one way to =
use that, but it's not the only way. As noted above, our competitors =
prefer a combination of price-hiding and cross subsidisation. Both of =
these can be implemented with tx fees, but not necessarily by trying to =
artificially limit supply, which is economically nonsensical.
>=20
>=20
> We=E2=80=99re already more than six years into this. When were these =
mechanisms going to be developed and tested? After 10 years? 20? Perhaps =
after 1024 =
years?(https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki =
<https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki>)
>=20
> Maybe when there is a need? I already discussed this topic of need =
here:
>=20
> https://medium.com/@octskyward/hashing-7d04a887acc8 =
<https://medium.com/@octskyward/hashing-7d04a887acc8>
>=20
> Right. Turns out the ledger structure is terrible for constructing the =
kinds of proofs that are most important to validators - i.e. whether an =
output exists, what its script and amounts are, whether it=E2=80=99s =
been spent, etc=E2=80=A6
>=20
> Validators don't require proofs. That's why they are validators.
>=20
> I think you're trying to say the block chain doesn't provide the kinds =
of proofs that are most important to lightweight wallets. But I would =
disagree. Even with UTXO commitments, there can still be double spends =
out there in the networks memory pools you are unaware of. Merely being =
presented with a correctly signed transaction doesn't tell you a whole =
lot ..... if you wait for a block, you get the same level of proof =
regardless of whether there are UTXO commitments or not. If you don't =
then you still have to have some trust in your peers that you are seeing =
an accurate and full view of network traffic.
>=20
> So whilst there are ways to make the protocol incrementally better, =
when you work through the use cases for these sorts of data structures =
and ask "how will this impact the user experience", the primary =
candidates so far don't seem to make much difference.
>=20
> Remote attestation from secure hardware would make a big difference =
though. Then you could get rid of the waiting times entirely because you =
know the sending wallet won't double spend.
>=20
>=20
> Yes, let=E2=80=99s wait until things are about to break before even =
beginning to address the issue=E2=80=A6because we can =E2=80=9Ceasily =
create=E2=80=9D anything we haven=E2=80=99t invented yet at the last =
minute.
>=20
> bitcoinj already has a micropayment channel implementation in it. =
There's a bit of work required to glue everything together, but it's not =
a massive project to start using this to pay nodes for their services.
>=20
> But it's not needed right now:  serving these clients is so darn =
cheap. And there is plenty of room for optimising things still further!
>=20
>=20
> I=E2=80=99m one of the very few developers in this space that has =
actually tried *hard* to make your BIP37 work. Amongst the desktop =
wallets listed on bitcoin.org <http://bitcoin.org/>, there are only two =
that have always supported SPV (or at least I think MultiBit has always =
supported it, perhaps I=E2=80=99m wrong). One is MultiBit, the other one =
is mine. I give you credit for your work=E2=80=A6perhaps you could be =
generous enough to extend me some credit too?
>=20
> MultiBit has always supported it. I apologise for implying you have =
not built a wallet. I think yours is mSIGNA, right? Did it used to be =
called something else? I recognise the website design but must admit, I =
have not heard of mSIGNA before.
>=20
> Regardless, as a fellow implementor, I would appreciate it more if you =
designed and implemented upgrades, rather than just trashing the work =
done so far as "notoriously terrible", Satoshi as "not a systems =
architect" and so on.
>=20


--Apple-Mail=_C58B19EA-3EC9-4A5C-BD9B-7D2F67AABE54
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jul 29, 2015, at 4:15 AM, Mike Hearn &lt;<a =
href=3D"mailto:hearn@vinumeris.com" class=3D"">hearn@vinumeris.com</a>&gt;=
 wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D"">Irrelevant =
what term was used - and as brilliant as Satoshi might have been at some =
things, he obviously got this one wrong.</div></div></blockquote><div =
class=3D""><br class=3D""></div><div class=3D"">I don't think it's =
obvious. You may disagree, but don't pretend any of this stuff is =
obvious.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Consider this: &nbsp;the highest Bitcoin tx fees can possibly =
go is perhaps a little higher than what our competition charges. Too =
much higher than that, and people will just say, you know what .... I'll =
make a bank transfer. It's cheaper and not much slower, sometimes no =
slower at all.</div><div class=3D"">&nbsp;</div><div class=3D"">And now =
consider that in many parts of the world bank transfers are =
free.</div><div class=3D""><br class=3D""></div><div class=3D"">They =
aren't actually free, of course, but they <i class=3D"">appear</i>&nbsp;to=
 be free because the infrastructure for doing them is cross subsidised =
by the fees on other products and services, or hidden in the prices of =
goods sold.</div><div class=3D""><br class=3D""></div><div class=3D"">So =
that's a market reality Bitcoin has to handle. It's already more =
expensive than the competition sometimes, but luckily not much more, and =
anyway Bitcoin has some features those other systems lack (and vice =
versa). So it can still be competitive.&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">But your extremely vague notion of a =
"fee market" neglects to consider that it already exists, and it's not a =
market of "Bitcoin users buying space in Bitcoin blocks". It's "users =
paying to move money".</div><div class=3D""><br class=3D""></div><div =
class=3D"">You can argue with this sort of economic logic if you like, =
but don't claim this stuff is =
obvious.</div></div></div></div></div></blockquote><div><br =
class=3D""></div>100% granted - it was not obvious=E2=80=A6and we speak =
today with the benefit of hindsight.</div><div><br =
class=3D""></div><div>I=E2=80=99ll clarify my argument, for the sake of =
anyone who thinks I=E2=80=99m looking to play word games rather than =
trying to figure out a good way forward.</div><div><br =
class=3D""></div><div>Point is=E2=80=A6processing blocks requires =
computational resources that someone needs to put up. Unless the people =
who are putting up these resources are properly incentivized to continue =
doing it, the network will fail.&nbsp;</div><div><br =
class=3D""></div><div>Unfortunately, it was unforeseen that most nodes =
on the network would turn out to not be miners=E2=80=A6and that most =
miners wouldn=E2=80=99t even run full nodes. Yes, I speak with the =
benefit of hindsight, had I been discussing this in 2008 I very well =
could have made the same mistake or worse. But it isn=E2=80=99t 2008, =
it=E2=80=99s 2015=E2=80=A6and we=E2=80=99ve learned a thing or two =
since.</div><div><br class=3D""></div><div>Given that things are what =
they are, it is clear that larger blocks externalize costs onto the rest =
of the network.</div><div><br class=3D""></div><div>Waiting until we can =
no longer count on the altruistic goodwill of volunteers because they =
suddenly decide that they have better uses for their computers is =
probably not such a wonderful idea. But even worse is further burdening =
the network with externalized costs before we=E2=80=99ve solved these =
important issues=E2=80=A6especially given the evidence that larger =
blocks tend to lead to network forks. No, I=E2=80=99m not talking about =
regular run-of-the-mill reorgs=E2=80=A6I=E2=80=99m talking consensus =
forks - a network partition that cannot be reconciled without manual =
intervention, so please don=E2=80=99t distract the issue. Yes, each =
incident occurred for a very different reason=E2=80=A6but you=E2=80=99d =
have to be blind to miss the correlation between bigger blocks and the =
propensity for forks.<br class=3D""><div><br class=3D""></div><div>What =
Satoshi might have thought in 2008-2009 is fascinating from a historical =
perspective, but his early pioneering insights don=E2=80=99t appear to =
be of much help in addressing these particular issues.</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D""><span =
class=3D""><div class=3D"">Nobody threatened to start mining huge blocks =
given how relatively inexpensive it was to mine back then?<br =
class=3D""></div></span></div></div></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">Not that I recall. It wasn't a response =
to any actual event, I think, but rather a growing realisation that the =
code was full of DoS attacks.</div><div class=3D""><br =
class=3D""></div><div class=3D"">&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""><div class=3D"">Guess what? SPV wallets are =
still not particularly widespread=E2=80=A6and those that are out there =
are notoriously terrible at detecting network forks and making sure they =
are on the right one.</div></div></div></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">The most popular mobile wallet =
(measured by installs) on Android is SPV. It has between 500,000 and 1 =
million installs, whilst Coinbase has not yet crossed the 500,000 mark. =
One of the most popular wallets on iOS is SPV. If we had SPV wallets =
with better user interfaces on desktops, they'd be more popular there =
too (perhaps MultiBit HD can recapture some lost ground).</div><div =
class=3D""><br class=3D""></div><div class=3D"">So I would argue that =
they are in fact very widespread.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Likewise, they are not "notoriously =
terrible" at detecting chain forks. That's a spurious idea that you and =
Patrick have been pushing lately, but they detect them and follow reorgs =
across them according to the SPV algorithm, which is based on most work =
done. This is exactly what they are designed to do.&nbsp;</div><div =
class=3D""><br class=3D""></div><div class=3D"">Contrast this with other =
lightweight wallets which either don't examine the block chain or =
implement the algorithm incorrectly, and I fail to see how this can be =
described as "notoriously terrible".</div><div class=3D""><br =
class=3D""></div><div class=3D"">&nbsp;<br class=3D""></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""><div class=3D"">I understand that initially =
it was desirable that transactions be free=E2=80=A6but surely even =
Satoshi understood this couldn=E2=80=99t be perpetually =
self-sustaining=E2=80=A6and that the ability to bid for inclusion in =
blocks would eventually become a crucial component of the network. Or =
were fees just added for decoration?<br =
class=3D""></div></div></div></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">Fees were added as a way to get money =
to miners in a fair and decentralised way.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Attaching fees directly to all =
transactions is certainly one way to use that, but it's not the only =
way. As noted above, our competitors prefer a combination of =
price-hiding and cross subsidisation. Both of these can be implemented =
with tx fees, but not necessarily by trying to artificially limit =
supply, which is economically nonsensical.</div><div class=3D""><br =
class=3D""></div><div class=3D"">&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""><div class=3D""></div><div class=3D"">We=E2=80=99=
re already more than six years into this. When were these mechanisms =
going to be developed and tested? After 10 years? 20? Perhaps after 1024 =
years?(<a =
href=3D"https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki" =
target=3D"_blank" =
class=3D"">https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki<=
/a>)<br class=3D""></div></div></div></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">Maybe when there is a need? I already =
discussed this topic of need here:</div><div class=3D""><br =
class=3D""></div><div class=3D""><a =
href=3D"https://medium.com/@octskyward/hashing-7d04a887acc8" =
class=3D"">https://medium.com/@octskyward/hashing-7d04a887acc8</a><br =
class=3D""></div><div class=3D""><br class=3D""></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""><span class=3D""><div class=3D"">Right. Turns =
out the ledger structure is terrible for constructing the kinds of =
proofs that are most important to validators - i.e. whether an output =
exists, what its script and amounts are, whether it=E2=80=99s been =
spent, etc=E2=80=A6<br =
class=3D""></div></span></div></div></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">Validators don't require proofs. That's =
why they are validators.</div><div class=3D""><br class=3D""></div><div =
class=3D"">I think you're trying to say the block chain doesn't provide =
the kinds of proofs that are most important to lightweight wallets. But =
I would disagree. Even with UTXO commitments, there can still be double =
spends out there in the networks memory pools you are unaware of. Merely =
being presented with a correctly signed transaction doesn't tell you a =
whole lot ..... if you wait for a block, you get the same level of proof =
regardless of whether there are UTXO commitments or not. If you don't =
then you still have to have some trust in your peers that you are seeing =
an accurate and full view of network traffic.</div><div class=3D""><br =
class=3D""></div><div class=3D"">So whilst there are ways to make the =
protocol incrementally better, when you work through the use cases for =
these sorts of data structures and ask "how will this impact the user =
experience", the primary candidates so far don't seem to make much =
difference.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Remote attestation from secure hardware would make a big =
difference though. Then you could get rid of the waiting times entirely =
because you know the sending wallet won't double spend.</div><div =
class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D""><span =
class=3D""><div class=3D""></div></span><div class=3D"">Yes, let=E2=80=99s=
 wait until things are about to break before even beginning to address =
the issue=E2=80=A6because we can =E2=80=9Ceasily create=E2=80=9D =
anything we haven=E2=80=99t invented yet at the last minute.<br =
class=3D""></div></div></div></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">bitcoinj already has a micropayment =
channel implementation in it. There's a bit of work required to glue =
everything together, but it's not a massive project to start using this =
to pay nodes for their services.</div><div class=3D""><br =
class=3D""></div><div class=3D"">But it's not needed right now: =
&nbsp;serving these clients is so darn cheap. And there is plenty of =
room for optimising things still further!</div><div class=3D""><br =
class=3D""></div><div class=3D"">&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""><div class=3D""></div></div><div =
class=3D"">I=E2=80=99m one of the very few developers in this space that =
has actually tried *hard* to make your BIP37 work. Amongst the desktop =
wallets listed on <a href=3D"http://bitcoin.org/" target=3D"_blank" =
class=3D"">bitcoin.org</a>, there are only two that have always =
supported SPV (or at least I think MultiBit has always supported it, =
perhaps I=E2=80=99m wrong). One is MultiBit, the other one is mine. I =
give you credit for your work=E2=80=A6perhaps you could be generous =
enough to extend me some credit too?</div></div></blockquote></div><br =
class=3D""></div><div class=3D"gmail_extra">MultiBit has always =
supported it. I apologise for implying you have not built a wallet. I =
think yours is mSIGNA, right? Did it used to be called something else? I =
recognise the website design but must admit, I have not heard of mSIGNA =
before.</div><div class=3D"gmail_extra"><br class=3D""></div><div =
class=3D"gmail_extra">Regardless, as a fellow implementor, I would =
appreciate it more if you designed and implemented upgrades, rather than =
just trashing the work done so far as "notoriously terrible", Satoshi as =
"not a systems architect" and so on.</div><div class=3D"gmail_extra"><br =
class=3D""></div></div>
</div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_C58B19EA-3EC9-4A5C-BD9B-7D2F67AABE54--

--Apple-Mail=_7EFA5E39-B4BA-4A27-A140-41790D94A0A0
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 - https://gpgtools.org

iQIcBAEBCgAGBQJVuMEhAAoJEJNAI64YFENUGdMQAJYQ1fISOkSIdZ4FmliDTRkt
gmNmwMn4mWdHCA8SZFOSqIlvGUsCJVh+S7GusHFp6UUi/WRNw4XYLdf/0oX6kGgr
W/9dzW16w86isMbWRJqNwv8gzIOjK0IDFLc0XYfAH4QOMCSpWnX6XTTr6AOjZboX
KgYHpRkJQcm2a2GCCdfjbo12NGUYz1UN+wu4R5WRj2IieQtepv6k5RJ6B6IdNtAL
zy4Q3niTE7dkMT0uH5UmgT58S5rZeOjPKMdM/BH0+cpX6Nri75kYcGXy8EhAwJhf
BLz2nn4jsFsTbf/dNE7Z9RX9JyeiGs4G231op354LkjMXsmomRdqN8TD9Ih0Ynn7
LghnKoc3rjqobzRbhH9TntTlAbpQlKo6KZHzPSCPuG16d+93UZPUNA7KcnJgyoNt
TGfEXI7fjBABj869OCXomYnIBvWi+mtPUJdUfbLxAyZCXoizOtRL9FMFyQxnAp0i
UqRsDCbgHw7I6o4MbV1tnRWcdz6ApdkBp3z+RIvKQ9t+WtT2DhnJOsSv1NL+LRzJ
AYiN/YEPNR5sDw8bWrh+QkuPvuh2+YuZCIz4u29NbNF/Ela/Wya88uhM2BmJIKpJ
W69GJgIo7/MgVtCDTkC6TUGyYD34U0gxc9kWKd79blqBukMjh5yMeJtugCCeApbq
8njKBaCdo8BYmxkYCqLj
=Ubx5
-----END PGP SIGNATURE-----

--Apple-Mail=_7EFA5E39-B4BA-4A27-A140-41790D94A0A0--