path: root/b7/94d2a6a1e49891c7d6dd469018c59809d84478

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D050B258
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  7 Feb 2017 20:32:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com
	[209.85.192.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A1AD2213
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  7 Feb 2017 20:32:49 +0000 (UTC)
Received: by mail-pf0-f171.google.com with SMTP id e4so35585882pfg.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 07 Feb 2017 12:32:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=XlEfrxcgivYiLHqe6feAiCJhKqmbL3cXGwp7YAsMaBg=;
	b=yf5keFytNAt6uafn+esAt4F8UoXr4XYi/UwXWB13o1Pq2trJjrGo7Jre4f3eCCQmml
	7Y1vDtB26nt8mlkAdN/ZcWR2fKOPlzrUA64dplKVhkg1OstuAfR/jq3iJ7ZHVvAfiBZT
	Z/CbEvMJca67ZVkggUiZhelBZk+XFhixnmti/sJganQu1RenbnZIeXcgwhF0zFXrPxDA
	UvmcMiI2XSxEUTRWbulDDLNaNllbOjN5juDQFUzLQAdaLziNlMT9xi5SD0FRTBTfSm9s
	i0kL+IqQALfZWsY43GXprtvudMsgZEUXpfn+KiVNhRa3OapVmg1fDusqa1ww5moHJ24c
	Y5iA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=XlEfrxcgivYiLHqe6feAiCJhKqmbL3cXGwp7YAsMaBg=;
	b=FW6SSOvcBCgtOOzNGJzlrya/vt8D0o5LQbiQf6eXmMPg+LlDN7CXqyLFMiq/NM/WA/
	iE5Jwa0O4By8+tT6Sgij94LMsNUaIpTCVf4NICMQgKipZhqK+XyFG9HxTf4tsBDm0BBk
	OvRt1rrnTpzj4E4iXPNPX/GK+lNPohomlnhrzvxK5zw1Jok7Qf4vMWMH6UaChxSD0eGq
	64gjanWBikJkvN4sLrBQOVIPFt7gTnGGle3A9puT0s6neTWAjcrAVmYPkovieToxmnaS
	i9RT5gLSoBrs9wtSH0jBWM9pqQC3Q8SH8iY3ho6iA3Xgy7ajjJ90fPj0rQvjW9/JRaqP
	eKvw==
X-Gm-Message-State: AIkVDXKC2zQUh7zrBAPWiEOxg7XIBZflZXz66OMdj6h3SLxh3yB6DrlL2xB6oP3UXCCXDQ==
X-Received: by 10.98.159.80 with SMTP id g77mr21793072pfe.34.1486499568996;
	Tue, 07 Feb 2017 12:32:48 -0800 (PST)
Received: from [10.35.87.65] (mobile-166-176-187-182.mycingular.net.
	[166.176.187.182]) by smtp.gmail.com with ESMTPSA id
	e189sm13648126pfg.64.2017.02.07.12.32.47
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 07 Feb 2017 12:32:48 -0800 (PST)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (14D27)
In-Reply-To: <af8301fc246c8c3fae857167968d94d4@xe0.me>
Date: Tue, 7 Feb 2017 12:32:46 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <52CB8F39-6810-4235-836D-4E9ED0F58DD0@voskuil.org>
References: <201701270107.01092.luke@dashjr.org> <20170127212810.GA5856@nex>
	<CAAy62_KUSNTjivwJT87K9f1c=k-6gdaLXEBJjcy2KK+uLSTWDA@mail.gmail.com>
	<201701280403.05558.luke@dashjr.org>
	<af8301fc246c8c3fae857167968d94d4@xe0.me>
To: mbtc-dev@xe0.me,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, MIME_QP_LONG_LINE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 08 Feb 2017 01:42:41 +0000
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Tue, 07 Feb 2017 20:32:50 -0000

The semantics of a necessarily secure and private client-server protocol dif=
fer from that of a necessarily distributed and public P2P protocol. I realiz=
e you refer to the C/S as a distinct API, but this point is worthy of clarif=
ication and emphasis.

The introduction of client-server sub-protocols into the Bitcoin P2P protoco=
l has resulted in large scale privacy loss, weakened end-user security and r=
educed access to the public network. Plans to mitigate these issues stand to=
 make matters worse by restricting access to the public network through the i=
ntroduction of strong identity to the P2P protocol.

It is not the case that C/S APIs against private full nodes do not exist. El=
ectrum (stratum) and Libbitcoin (zeromq) are notable examples. The managemen=
t difficulties are not small, but there are also fundamental issues that mus=
t first be addressed.

In your example you imagine pluggsble SSD space, but Satoshi derivatives hav=
e scale deficiencies unrelated to storage. If we are going to get to reliabl=
e, cheap, performant personal full nodes (which I agree is essential to Bitc=
oin survival) we need nodes that scale (i.e. to the available hardware). We a=
lso require a robust, reliable and performant node/server development stack,=
 not just the impossible choice between a fragile monolith and centralizing w=
eb APIs/wallets.

All centralized interfaces to Bitcoin (wallets, web APIs, payment services) s=
hrink the economic consensus and thereby weaken its defense of sound and fun=
gible money. The only solution is personally-controlled full nodes, as you s=
ay. The incentives for running a full node are sufficient if the cost of doi=
ng so is low. Getting there requires a node/server architecture intended for=
 this outcome. Then maybe appliances are feasible.

e


> On Feb 6, 2017, at 8:24 AM, netkn0t (marcus) via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
>=20
>> On 27.01.2017 20:03, Luke Dashjr via bitcoin-dev wrote:
>> Assume as a premise (despite your apparent disagreement below) that for
>> Bitcoin to function, a supermajority of economic activity needs to be ver=
ified
>> using full nodes operated by the recipient. Evidence suggests that at thi=
s
>> current time, at best 10% of economic activity is in fact using a full no=
de to
>> verify the transaction. On this basis, it seems pretty clear that serious=

>> action must be taken to change the status quo, and so for efforts to do s=
o
>> without dropping the block size have proven ineffective.
> Lets think like people in sales and marketing for a moment.
>=20
> There's an implicit assumption here that ANY protocol or consensus-rule ba=
sed solution exists that would reverse the trend of diminishing full node ve=
rified economic activity. Since there's no economic advantage to running a f=
ull node, there's no inherent motivation for implementation (or outright pur=
chase) of full nodes by the very large percentage of people who fall in the n=
on-technical "I just want it to work, and I don't want my money stolen" cate=
gory. Yes, anyone on this list understands that "don't want my money stolen"=
 is inherently connected to running your own node and using it for transacti=
ons, but the average user does not, and even if they did, they don't have th=
e resources (time and/or money) to do anything about it. Running your own fu=
ll node increases the protection agains double spend attacks and other proto=
col bases shenanigans, but now you've taken on another set of security expos=
ures related to the physical box that is running the node. Anti-virus, off a=
nd on-site backups, multiple boxes/devices for multi-sig, backup of key seed=
s.
>=20
> Reducing (or even maintaining) the block size doesn't somehow increase the=
 number of people who are capable of running full nodes, and it doesn't add a=
ny incentive for people already in that "capable" set to suddenly take up th=
e task of running and transacting via a full node. I'd argue that the size o=
f the block-chain and the time to download it are the least concerning aspec=
ts to anyone faced with running their own node and actually storing some of t=
heir wealth on it and using it for transactions.
>=20
> You're looking for a (maybe dangerous/maybe impossible) balance between ch=
oking off casual (not full node) usage of bitcoin and yet trying to make it m=
ore popular among the people (and organizations) who have the capability and=
 resources to run and transact on full nodes.
>=20
> We should sit with this for a moment.
>=20
> On one hand, Bitcoin may ultimately end up as digital currency "only for g=
eeks and B2B transactions." I'd speculate we'd loose a big subset of the gee=
ks that way too, unless they happen to do a lot of transactions with medium t=
o large size businesses. (Small businesses won't be able to afford the expen=
se of or the time to maintain the node.) There's some level of risk that thi=
s pushes bitcoin into oblivion. And is it really a decentralized P2P currenc=
y if it's only used by medium and large businesses and a small set of techni=
cally capable individuals that transact with those entities directly in BTC?=
 And is it really a decentralized currency in this scenario if its used main=
ly by medium and large businesses, banks, and exchanges? (I've purposely exc=
luded small businesses because while they like the benefits of flexible paym=
ent systems, more don't have the time or skill (or resources to hire the ski=
ll) needed to do a full node implementation.)
>=20
> I feel inherent cognitive dissonance between "keep it decentralized" and "=
not useful to small business and individuals." One can make the argument tha=
t L2 solutions will be available for the small businesses and individuals bu=
t that doesn't solve the stated intent of reversing the trend of transaction=
s not originating from or being received by full nodes. I guess you're sayin=
g bitcoin will be stronger, more resistant to outside power agency and censo=
rship if its only used by exchanges, banks, large businesses, and die-hard t=
echnically inclined people.
>=20
>=20
> On the other hand, maybe there's a scenario where an average person walks i=
nto a big box electronics store in any developed country and buys a "persona=
l digital bank" appliance. I frame it this way because the majority of the w=
orlds population is never going to run a full node on their desktop or lapto=
p. There's no viable scenario where that happens. Laptops and desktops are a=
lready diminishing in market share due to the introduction of tablets and sm=
artphones. General purpose OS's are also inherently un-secure, so  going dow=
n this route means we are immediately in the realm of lots of theft. Prevent=
ing theft (or loss due to errors) requires additional digital key devices, o=
r additional devices for multi-sig transactions just for basic financial saf=
ety, not to mention a functioning backup plan, including off-site backups. R=
ansomeware/phishing protection? Checking email and surfing the web on the co=
mputer that holds your standard (non-multi-sig) wallet? Forgetaboutit. It'll=
 never reach critical mass. It's not a viable proposal. Not to mention, you c=
an't physically carry your laptop with you when you go to the shopping mall.=
 In order for this appliance model to function, smartphone based implementat=
ions will need to interact with your personal or family server/appliance, an=
d you'll need to be able to do multi-sig with a smartphone and another physi=
cal token you carry with you. Imagine a 2 of 5 multi-sig wallet where your p=
hone and an NFC or LE bluetooth device are sufficient to create a transactio=
n on your home node while shopping. Or your phone has a single sig wallet an=
d you top it up from your appliance and it never has a high balance. In any c=
ase, I've made the argument before that the definition of "bitcoin protocol"=
 should, in addition to the consensus protocol, probably include a secure AP=
I protocol between wallet client and full node, and it still seems to be an i=
mportant missing piece. I want to be able to travel and spend BTC and I DON'=
T want to do general purpose computing like email and web surfing on the sam=
e computer where I have a big chunk of life savings stored! I think defining=
 this API will actually really support the use of user controlled full nodes=
 for transactions! Imagine Trezor owners using their own node for transactio=
ns! Bitpay is the only player I know of that provides enough of a software s=
tack to set this up for yourself.
>=20
> I think reversing the non-full node transaction trend will have to be base=
d the appliance usage model. You buy a new 200-500Gb nvme SSD every year and=
 put it in one of the free slots. You upgrade when all slots are full. This i=
s one scenario that could put us on a trend of increasing transactions origi=
nating and being received by personal full nodes, i.e. reversing centralizat=
ion trends.
>=20
>=20
> If there is any solution to this problem, it will need to recognize the fa=
ct that the supermajority of people on the planet are not technically savvy n=
or are they inclined to take the time to learn how to protect themselves wit=
h basic computer security much less how to use a full node for bitcoin trans=
actions. The solution, if it exists, will need to be handed to them, and the=
y'll need a reason to buy it. Any solution will also need to recognize the f=
act that it will cost resources (time and money) to run a full node. Lots of=
 people spend a huge portion of their income just to get a smartphone becaus=
e it's a useful communication device that does lots of other useful things. T=
here's not nearly the same level of need to spend on a full node for bitcoin=
 security.
>=20
> Any solution to this problem should also recognize the fact that there's a=
 significant amount of work to do to have a functioning personal implementat=
ion of a node and to use it for transactions. Even in my imagined future of p=
olished and easy to use appliances, if you have enough capital in BTC that y=
ou need it and you can afford to buy it, you're now only starting to deal wi=
th implementation issues. You've now become your own bank. Now you have to s=
ecure that appliance physically, secure and back up the key seed material, s=
ecure the devices used to access it, connect an app on your smartphone to th=
e appliance so you can create transactions while out of your home, connect y=
our home computer(s) to the appliance, do key exchange with the app/PC and t=
he appliance or implement some sort of PKI on all devices. You've just taken=
 on the responsibility of a bank and a sysadmin! The higher the balance, the=
 more of a target you are, and the more time/money you have to spend mitigat=
ing risk. This is a huge centralizing force that no one really seems to talk=
 about. If you're the average person, you want to find a trustworthy company=
 or trusted friend/family to take care of that stuff for you. If you're a te=
chnically inclined person AND maybe there's a way to reap some of the mining=
 reward on a small scale, you're slightly more interested.
>=20
> As a sysadmin for many years, I've seen first hand that most people want t=
ools that just work, whether its software to make spreadsheets, operating sy=
stems, phones, or thermostats. My point here is that the number of people in=
 the world who have the technical chops to run a node is ALWAYS going to be v=
astly lower than the number of people who will be using bitcoin (or cryptocu=
rrency).
>=20
> Of course we can make the argument that the definition of "bitcoin" is by d=
esign something to be used exclusively by institutions and geeks, and that t=
his definition falls out of the necessity to ensure that it remains decentra=
lized and censorship resistant. However, I'm not sure that logic holds or th=
at it doesn't introduce risk that that sort of definition drives bitcoin tow=
ard diminished relevance.
>=20
> At the end of all this though experiment, I'm still convinced that if the t=
ools are built to enable flexible usage of full nodes (i.e. my phone, tablet=
 or desktop app interfaces with the full node) then there's a large potentia=
l for increased usage of full nodes.
>=20
> Thanks,
> G
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev