public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
	Andrew Johnson <andrew.johnson83@gmail.com>
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
Date: Sat, 28 Jan 2017 04:03:03 +0000	[thread overview]
Message-ID: <201701280403.05558.luke@dashjr.org> (raw)
In-Reply-To: <CAAy62_KUSNTjivwJT87K9f1c=k-6gdaLXEBJjcy2KK+uLSTWDA@mail.gmail.com>

On Friday, January 27, 2017 11:53:02 PM Andrew Johnson via bitcoin-dev wrote:
> I don't think that the 17% yearly increase is too far off base considering
> current global trends(although I still don't particularly like the idea of
> centrally planning the limit, especially not that far into the future), but
> the 66% decrease first seems completely out of touch with reality.

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.

> I'd also like to point out to Luke that Satoshi envisioned most full nodes
> running in data centers in the white paper, not every single user needs to
> run a full node to use bitcoin.

Satoshi envisioned a system where full nodes could publish proofs of invalid 
blocks that would be automatically verified by SPV nodes and used to ensure 
even they maintained the equivalent of full node security so long as they were 
not isolated. But as a matter of fact, this vision has proven impossible, and 
there is to date no viable theory on how it might be fixed. As a result, the 
only way for nodes to have full-node-security is to actually be a true full 
node, and therefore the plan of only having full nodes in datacenters is 
simply not realistic without transforming Bitcoin into a centralised system.

> That a lot of people want to continue to move in that direction shouldn't
> be a surprise.

I think it's likely safe to say that if this were a possibility, everyone 
would want to continue to move in that direction. But as the facts stand, it 
simply isn't possible.

Luke


  reply	other threads:[~2017-01-28  4:04 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 [this message]
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
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=201701280403.05558.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=andrew.johnson83@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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