From: mbtc-dev@xe0•me
To: Luke Dashjr <luke@dashjr•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
Date: Mon, 06 Feb 2017 08:24:10 -0800 [thread overview]
Message-ID: <af8301fc246c8c3fae857167968d94d4@xe0.me> (raw)
In-Reply-To: <201701280403.05558.luke@dashjr.org>
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
next prev parent reply other threads:[~2017-02-06 16:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-27 1:06 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 [this message]
2017-02-07 20:32 ` Eric Voskuil
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=af8301fc246c8c3fae857167968d94d4@xe0.me \
--to=mbtc-dev@xe0$(echo .)me \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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