public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: mbtc-dev@xe0.me,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
Date: Tue, 7 Feb 2017 12:32:46 -0800	[thread overview]
Message-ID: <52CB8F39-6810-4235-836D-4E9ED0F58DD0@voskuil.org> (raw)
In-Reply-To: <af8301fc246c8c3fae857167968d94d4@xe0.me>

The semantics of a necessarily secure and private client-server protocol differ from that of a necessarily distributed and public P2P protocol. I realize you refer to the C/S as a distinct API, but this point is worthy of clarification and emphasis.

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

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

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

All centralized interfaces to Bitcoin (wallets, web APIs, payment services) shrink the economic consensus and thereby weaken its defense of sound and fungible money. The only solution is personally-controlled full nodes, as you say. The incentives for running a full node are sufficient if the cost of doing 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:
> 
>> 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 verified
>> using full nodes operated by the recipient. Evidence suggests that at this
>> current time, at best 10% of economic activity is in fact using a full node 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 so
>> without dropping the block size have proven ineffective.
> Lets think like people in sales and marketing for a moment.
> 
> There's an implicit assumption here that ANY protocol or consensus-rule based solution exists that would reverse the trend of diminishing full node verified economic activity. Since there's no economic advantage to running a full node, there's no inherent motivation for implementation (or outright purchase) of full nodes by the very large percentage of people who fall in the non-technical "I just want it to work, and I don't want my money stolen" category. 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 transactions, but the average user does not, and even if they did, they don't have the resources (time and/or money) to do anything about it. Running your own full node increases the protection agains double spend attacks and other protocol bases shenanigans, but now you've taken on another set of security exposures related to the physical box that is running the node. Anti-virus, off and on-site backups, multiple boxes/devices for multi-sig, backup of key seeds.
> 
> 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 any incentive for people already in that "capable" set to suddenly take up the task of running and transacting via a full node. I'd argue that the size of the block-chain and the time to download it are the least concerning aspects to anyone faced with running their own node and actually storing some of their wealth on it and using it for transactions.
> 
> You're looking for a (maybe dangerous/maybe impossible) balance between choking off casual (not full node) usage of bitcoin and yet trying to make it more popular among the people (and organizations) who have the capability and resources to run and transact on full nodes.
> 
> We should sit with this for a moment.
> 
> On one hand, Bitcoin may ultimately end up as digital currency "only for geeks and B2B transactions." I'd speculate we'd loose a big subset of the geeks that way too, unless they happen to do a lot of transactions with medium to large size businesses. (Small businesses won't be able to afford the expense of or the time to maintain the node.) There's some level of risk that this pushes bitcoin into oblivion. And is it really a decentralized P2P currency if it's only used by medium and large businesses and a small set of technically capable individuals that transact with those entities directly in BTC? And is it really a decentralized currency in this scenario if its used mainly by medium and large businesses, banks, and exchanges? (I've purposely excluded small businesses because while they like the benefits of flexible payment systems, more don't have the time or skill (or resources to hire the skill) needed to do a full node implementation.)
> 
> I feel inherent cognitive dissonance between "keep it decentralized" and "not useful to small business and individuals." One can make the argument that L2 solutions will be available for the small businesses and individuals but that doesn't solve the stated intent of reversing the trend of transactions not originating from or being received by full nodes. I guess you're saying bitcoin will be stronger, more resistant to outside power agency and censorship if its only used by exchanges, banks, large businesses, and die-hard technically inclined people.
> 
> 
> On the other hand, maybe there's a scenario where an average person walks into a big box electronics store in any developed country and buys a "personal digital bank" appliance. I frame it this way because the majority of the worlds population is never going to run a full node on their desktop or laptop. There's no viable scenario where that happens. Laptops and desktops are already diminishing in market share due to the introduction of tablets and smartphones. General purpose OS's are also inherently un-secure, so  going down this route means we are immediately in the realm of lots of theft. Preventing theft (or loss due to errors) requires additional digital key devices, or additional devices for multi-sig transactions just for basic financial safety, not to mention a functioning backup plan, including off-site backups. Ransomeware/phishing protection? Checking email and surfing the web on the computer 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 can't physically carry your laptop with you when you go to the shopping mall. In order for this appliance model to function, smartphone based implementations will need to interact with your personal or family server/appliance, and you'll need to be able to do multi-sig with a smartphone and another physical token you carry with you. Imagine a 2 of 5 multi-sig wallet where your phone and an NFC or LE bluetooth device are sufficient to create a transaction on your home node while shopping. Or your phone has a single sig wallet and you top it up from your appliance and it never has a high balance. In any case, I've made the argument before that the definition of "bitcoin protocol" should, in addition to the consensus protocol, probably include a secure API protocol between wallet client and full node, and it still seems to be an important 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 same 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 transactions! Bitpay is the only player I know of that provides enough of a software stack to set this up for yourself.
> 
> I think reversing the non-full node transaction trend will have to be based 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 is one scenario that could put us on a trend of increasing transactions originating and being received by personal full nodes, i.e. reversing centralization trends.
> 
> 
> If there is any solution to this problem, it will need to recognize the fact that the supermajority of people on the planet are not technically savvy nor are they inclined to take the time to learn how to protect themselves with basic computer security much less how to use a full node for bitcoin transactions. The solution, if it exists, will need to be handed to them, and they'll need a reason to buy it. Any solution will also need to recognize the fact 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 because it's a useful communication device that does lots of other useful things. There's not nearly the same level of need to spend on a full node for bitcoin security.
> 
> 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 implementation of a node and to use it for transactions. Even in my imagined future of polished and easy to use appliances, if you have enough capital in BTC that you need it and you can afford to buy it, you're now only starting to deal with implementation issues. You've now become your own bank. Now you have to secure that appliance physically, secure and back up the key seed material, secure the devices used to access it, connect an app on your smartphone to the appliance so you can create transactions while out of your home, connect your home computer(s) to the appliance, do key exchange with the app/PC and the 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 mitigating 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 technically inclined person AND maybe there's a way to reap some of the mining reward on a small scale, you're slightly more interested.
> 
> As a sysadmin for many years, I've seen first hand that most people want tools that just work, whether its software to make spreadsheets, operating systems, 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 vastly lower than the number of people who will be using bitcoin (or cryptocurrency).
> 
> Of course we can make the argument that the definition of "bitcoin" is by design something to be used exclusively by institutions and geeks, and that this definition falls out of the necessity to ensure that it remains decentralized and censorship resistant. However, I'm not sure that logic holds or that it doesn't introduce risk that that sort of definition drives bitcoin toward diminished relevance.
> 
> At the end of all this though experiment, I'm still convinced that if the tools 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 potential for increased usage of full nodes.
> 
> Thanks,
> G
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


  reply	other threads:[~2017-02-07 20:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-27  1:06 [bitcoin-dev] Three hardfork-related BIPs Luke Dashjr
     [not found] ` <CAAy62_L-mLhokVy4_WeLBVnxM0Y76dtFBaaDrRvQozxw=J1Ctw@mail.gmail.com>
     [not found]   ` <CAAy62_+1OjF3V5g4wpOyW0KtNGodddJu_cxOfG-f+8LB7D=rPA@mail.gmail.com>
2017-01-27  3:04     ` Andrew Johnson
2017-01-27  4:14       ` Luke Dashjr
     [not found]         ` <CAAy62_LHtrx7k73kznMpPvheA--0T9YiHkjHArf2KK0Qt+ViUg@mail.gmail.com>
2017-01-27  6:13           ` Andrew Johnson
     [not found]             ` <CAMZUoKnxqxvPQehdWo1ZaHB-1-od4cHvJRDTmF5x7ty1CdLbUQ@mail.gmail.com>
     [not found]               ` <CAMZUoK=eb3jgA7Rwt38tvZt0tYk7gRVPc_2=HUWg1L_vaD93uw@mail.gmail.com>
2017-01-27 20:34                 ` Russell O'Connor
2017-01-27 20:47                   ` Greg Sanders
2017-01-27 21:28                     ` Christian Decker
2017-01-27 23:53                       ` Andrew Johnson
2017-01-28  4:03                         ` Luke Dashjr
2017-01-28 10:36                           ` Natanael
2017-01-28 18:29                             ` Peter Todd
2017-01-29 19:15                               ` Tom Harding
2017-01-29 19:37                                 ` Eric Voskuil
2017-02-11 15:26                                   ` Staf Verhaegen
2017-01-29 19:39                                 ` David Vorick
2017-01-28 19:43                             ` Luke Dashjr
2017-01-28 21:54                               ` Peter Todd
2017-02-06 16:24                           ` mbtc-dev
2017-02-07 20:32                             ` Eric Voskuil [this message]
2017-01-28 18:22                         ` Peter Todd
2017-01-27  4:21 ` Johnson Lau
2017-01-27 18:54 ` t. khan
2017-01-27 12:12 Daniele Pinna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52CB8F39-6810-4235-836D-4E9ED0F58DD0@voskuil.org \
    --to=eric@voskuil.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=mbtc-dev@xe0.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox