public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Benjamin <benjamin.l.cordes@gmail.com>
To: Peter Todd <pete@petertodd.org>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
Date: Sat, 27 Jun 2015 19:26:00 +0200	[thread overview]
Message-ID: <CAOoPuRZrV_8XJbCbHMEWAfoKYc+OSQQMuhgESgG2JD2nEHoyvQ@mail.gmail.com> (raw)
In-Reply-To: <20150627172011.GB18729@muck>

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

"Thus we have a fixed capacity system where access is mediated by supply
and demand transaction fees."

There is no supply and demand. That would mean users would be able to adapt
fees and get different quality of service depending on current capacity.
For example if peak load is 10x average load, then at those times fees
would be higher and users would delay transactions to smooth out demand.

On Sat, Jun 27, 2015 at 7:20 PM, Peter Todd <pete@petertodd.org> wrote:

> On Sat, Jun 27, 2015 at 12:19:04PM -0400, Michael Naber wrote:
> > That test seems like a reasonable suggestion; 840GB is not prohibitive
> > given today's computing costs. What other than the successful result of
> > that test would you want to see before agreeing to increase the block
> size
> > to 8MB?
>
> The two main things you need to show is:
>
> 1) Small, anonymous, miners remain approximately as profitable as large
> miners, regardless of whether they are in the world, and even when
> miners are under attack. Remember I'm talking about mining here, not
> just hashing - the process of selling your hashpower to someone else who
> is actually doing the mining.
>
> As for "approximately as profitable", based on a 10% profit margin, a 5%
> profitability difference between a negligable ~0% hashing power miner
> and a 50% hashing power miner is a good standard here.
>
> The hard part here is basically keeping orphan rates low, as the %5
> profitability different on %10 profit margin implies an orphan rate of
> about 0.5% - roughly what we have right now if not actually a bit lower.
> That also implies blocks propagate across the network in just a few
> seconds in the worst case, where blocks are being generated with
> transactions in them that are not already in mempools - circumventing
> propagation optimization techniques. As we're talking about small
> miners, we can't assume the miners are directly conneted to each other.
> (which itself is dangerous from an attack point of view - if they're
> directly connected they can be DoS attacked)
>
> 2) Medium to long term plan to pay for hashing power. Without scarcity
> of blockchain space there is no reason to think that transaction fees
> won't fall to the marginal cost of including a transaction, which
> doesn't leave anything to pay for proof-of-work security. A proposal
> meeting this criteria will have to be clever if you don't keep the
> blocksize sufficiently limited that transaction fees are non-negligable.
> One possible approach - if probably politically non-viable - would be to
> change the inflation schedule so that the currency is inflated
> indefinitely.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

  reply	other threads:[~2015-06-27 17:26 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-27 14:39 [bitcoin-dev] A Proposed Compromise to the Block Size Limit Michael Naber
2015-06-27 15:21 ` Peter Todd
2015-06-27 15:29   ` Randi Joseph
2015-06-27 15:32     ` Peter Todd
2015-06-27 16:19   ` Michael Naber
2015-06-27 17:20     ` Peter Todd
2015-06-27 17:26       ` Benjamin [this message]
2015-06-27 17:37         ` Peter Todd
2015-06-27 17:46           ` Benjamin
2015-06-27 17:54             ` Peter Todd
2015-06-27 17:58               ` Venzen Khaosan
2015-06-27 19:34               ` Benjamin
2015-06-27 15:33 ` Adam Back
2015-06-27 16:09   ` Michael Naber
2015-06-27 16:28     ` Mark Friedenbach
2015-06-27 16:37     ` Peter Todd
2015-06-27 17:25       ` Michael Naber
2015-06-27 17:34         ` Peter Todd
2015-06-27 18:02           ` Jameson Lopp
2015-06-27 18:47             ` Peter Todd
2015-06-28  5:34 Raystonn
2015-06-28 10:07 ` Adam Back
2015-06-28 10:29   ` Benjamin
2015-06-28 12:37     ` Adam Back
2015-06-28 16:32       ` Raystonn .
2015-06-28 17:12         ` Mark Friedenbach
2015-06-28 17:18           ` Benjamin
2015-06-28 17:29           ` Gavin Andresen
2015-06-28 17:45             ` Mark Friedenbach
2015-06-28 17:51             ` Adam Back
2015-06-28 18:58               ` Adam Back
2015-06-28 21:05                 ` Gavin Andresen
2015-06-28 21:23                   ` Michael Naber
2015-06-28 22:07                   ` Adam Back
2015-06-29  0:59                     ` Eric Lombrozo
2015-06-29  1:13                     ` Eric Lombrozo
2015-06-29  1:45                     ` Andy Schroder
2015-06-30  0:42                     ` Tom Harding
2015-07-10  2:55                 ` Tom Harding
2015-06-28 17:53             ` Jorge Timón
2015-06-28 19:22             ` Andrew Lapp
2015-06-28 19:40               ` Benjamin
2015-06-28 12:32   ` Milly Bitcoin

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=CAOoPuRZrV_8XJbCbHMEWAfoKYc+OSQQMuhgESgG2JD2nEHoyvQ@mail.gmail.com \
    --to=benjamin.l.cordes@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pete@petertodd.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