From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D050B258 for ; 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 ; Tue, 7 Feb 2017 20:32:49 +0000 (UTC) Received: by mail-pf0-f171.google.com with SMTP id e4so35585882pfg.1 for ; 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 X-Mailer: iPhone Mail (14D27) In-Reply-To: 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> <201701280403.05558.luke@dashjr.org> To: mbtc-dev@xe0.me, Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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