public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Marcel Jamin <marcel@jamin.net>
To: Adam Back <adam@cypherspace.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Yet another blocklimit proposal / compromise
Date: Fri, 11 Sep 2015 19:54:17 +0200	[thread overview]
Message-ID: <CAAUq484fRauFkiaTRc5GE7ZNVEqX_b7-JaSx5_tJeOp=Cjb=jQ@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTF5BxdeWm1PBBNwWm41o8Y3bMvgSyDm2_CE73ibXnnwiw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3167 bytes --]

> Therefore it is important that it be reasonably convenient to run full
nodes for decentralisation security.

Yes, and I'm suggesting to define what "reasonably convenient" is in 2016.
Most likely node operators have more than a little headroom for larger
blocks. If you just use more of the processing power / storage / bandwidth
you very likely already paid for then there is no increase in costs.

> I think you maybe misunderstanding what the Chinese miners said also, about
8MB, that was a cap on the maximum they felt they could handle with current
network infrastructure.

And what they felt "remained fair to all to all miners and node operators
worldwide." Increasing network connection requirements might even decrease
mining centralization right now.



2015-09-11 18:47 GMT+02:00 Adam Back <adam@cypherspace.org>:

> Bitcoin security depends on the enforcement of consensus rules which
> is done by economically dependent full nodes.  This is distinct from
> miners fullnodes, and balances miners interests, otherwise SPV nodes
> and decentralisation of policy would tend degrade, I think.  Therefore
> it is important that it be reasonably convenient to run full nodes for
> decentralisation security.
>
> Also you may want to read this summary of Bitcoin decentralisation by Mark:
>
>
> https://www.reddit.com/r/Bitcoin/comments/3h7eei/greg_luke_adam_if_xt_takes_over_and_wins_the/cu53eq3
>
> I think you maybe misunderstanding what the Chinese miners said also,
> about 8MB, that was a cap on the maximum they felt they could handle
> with current network infrastructure.
>
> I had proposed 2-4-8MB growing over a 4 year time frame with 2MB once
> the hard-fork is upgraded by everyone in the network.  (I dont
> consider miner triggers, as with soft-fork upgrades, to be an
> appropriate roll out mechanism because it is more important that
> economically dependent full nodes upgrade, though it can be useful to
> know that miners also have upgraded to a reasonable extent to avoid a
> temporary hashrate drop off affecting security).
>
> Adam
>
> On 9 September 2015 at 15:00, Marcel Jamin via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I think the overlap of people who want to run a serious mining operation
> and
> > people who are unable to afford a slightly above average internet
> connection
> > is infinitesimally small.
> >
> > 2015-09-09 20:51 GMT+02:00 Jorge Timón <jtimon@jtimon.cc>:
> >>
> >>
> >> On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev"
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> >
> >> > I propose to:
> >> >
> >> > a) assess what blocklimit is currently technically possible without
> >> > driving up costs of running a node up too much. Most systems currently
> >> > running a fullnode probably have some capacity left.
> >>
> >> What about the risk of further increasing mining centralization?
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

[-- Attachment #2: Type: text/html, Size: 4805 bytes --]

  reply	other threads:[~2015-09-11 17:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-09  7:55 [bitcoin-dev] Yet another blocklimit proposal / compromise Marcel Jamin
2015-09-09 18:51 ` Jorge Timón
2015-09-09 19:00   ` Marcel Jamin
2015-09-11 16:22     ` Jorge Timón
2015-09-11 16:47     ` Adam Back
2015-09-11 17:54       ` Marcel Jamin [this message]
2015-09-11 18:17         ` Jorge Timón

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='CAAUq484fRauFkiaTRc5GE7ZNVEqX_b7-JaSx5_tJeOp=Cjb=jQ@mail.gmail.com' \
    --to=marcel@jamin.net \
    --cc=adam@cypherspace.org \
    --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