From: "Jorge Timón" <jtimon@jtimon•cc>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
Date: Thu, 6 Aug 2015 23:51:00 +0200 [thread overview]
Message-ID: <CABm2gDpnikt4o9EE1Gm2g009gJa1sVtuwDM-iQgwue2ijiNLvQ@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T3KH_pbUc+Yu4wRmWHcF1e6fEtPzLzZddwDrQBMzoZPVg@mail.gmail.com>
Really, thanks again for replying and not getting mad when I get your
thoughts wrong.
I believe that I've learned more about your position on the subject
today than in months of discussion and blogs (that's not a critique to
your blog post, it's just that they didn't answer to some questions
that I personally needed responded).
On Thu, Aug 6, 2015 at 9:42 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:
> On Thu, Aug 6, 2015 at 1:15 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
>>
>> So I reformulate the question:
>>
>> 1) If "not now", when will it be a good time to let the "market
>> minimum fee for miners to mine a transaction" rise above zero?
>
>
> Two answers:
>
> 1. If you are willing to wait an infinite amount of time, I think the
> minimum fee will always be zero or very close to zero, so I think it's a
> silly question.
I'm very happy to have made the stupid question then. It has revealed
another big difference in the fundamental assumptions we're using.
My assumption is that for any reasonable size, free transactions will
eventually disappear (assuming Bitcoin doesn't "fail" for some other
reason).
Maybe I'm being too optimistic about the demand side of the market in
the long term.
In contrast, your assumption seems to be (and please correct me on
anything I get wrong) that...
"The limit will always be big enough so that free transactions are
mined forever. Therefore fees just allow users to prioritize their
urgent transactions and relay policies to protect their nodes against
DoS attacks.
Well, obviously, they also serve to pay for mining in a low-subsidy
future, but even with the presence of free transactions, fees will be
enough to cover mining costs, or a new mechanisms will be developed to
make a low-total-reward blockchain safe or expensive proof of work
will be replaced or complemented with something else that's cheaper.
The main point is that fees are not a mechanism to decide what gets
priced out of the blockchain, because advancements in technology will
always give as enough room for free transactions."
- jtimon putting words in Gavin's mouth, with the only intention to
understand him better.
I'm using "free transactions" even though you said "zero or very close to zero".
To you, "zero or very close to zero" may be the same thing, but to me
zero and very close to zero are like...different galaxies.
To me, entering the "very close to zero galaxy" is a huge step in the
development of the fee market.
I've been always assuming that moving from zero to 1 satoshi was
precisely what "big block advocates" wanted to avoid.
What they meant by "Bitcoin is going to become a high-value only
network" and similar things.
Knowing that for "big block advocates" zero and "very close to zero"
are equally acceptable changes things.
> 2. The "market minimum fee" should be determined by the market. It should
> not be up to us to decide "when is a good time."
I completely agree, but the block size limit is a consensus rule that
doesn't adapt to the market. The market will adapt to whatever limit
is chosen by the consensus rules.
>> 2) Do you have any criterion (automatic or not) that can result in you
>> saying "no, this is too much" for any proposed size?
>
>
> Sure, if keeping up with transaction volume requires a cluster of computers
> or more than "pretty good" broadband bandwidth I think that's too far.
> That's where original 20MB limit comes from, otherwise I'd have proposed a
> much higher limit.
>
>> Would you agree that blocksize increase proposals should have such a
>> criterion/test?
>
>
> Although I've been very clear with my criterion, no, I don't think all
> blocksize increase proposals should have to justify "why this size" or "why
> this rate of increase."
I would really like a more formal criterion, ideally automatic (like
any other test, the parameters can be modified as technology
advances).
But fair enough, even though your criterion is too vague or not
future-proof enough, I guess it is still a criterion.
It seems that this is a matter of disagreements and ideal ways of
doing things and not really a disagreement on fundamental assumptions.
So it seems this question wasn't so interesting after all.
> Part of my frustration with this whole debate is
> we're talking about a sanity-check upper-limit; as long as it doesn't open
> up some terrible new DoS possibility I don't think it really matters much
> what the exact number is.
That's what you think you are discussing, but I (and probably some
other people) think we are discussing something entirely different.
Because we have a fundamentally different assumption on what the block
size limit is about.
I really hope that identifying these "fundamental assumption
discrepancies" (FAD from now own) will help us avoid circular
discussions so that everything is less frustrating and more productive
for everyone.
>> Regardless of the history of the consensus rule (which I couldn't care
>> less about), I believe the only function that the maximum block size
>> rule currently serves is limiting centralization.
>> Since you deny that function, do you think the (artificial) consensus
>> rule is currently serving any other purpose that I'm missing?
>
>
> It prevents trivial denial-of-service attacks (e.g. I promise to send you a
> 1 Terabyte block, then fill up your memory or disk...).
This could be prevented in some other ways. If this is the only
concern, it doesn't need to be a consensus rule.
> And please read what I wrote: I said that the block limit has LITTLE effect
> on MINING centralization. Not "no effect on any type of centralization."
>
> If the limit was removed entirely, it is certainly possible we'd end up with
> very few organizations (and perhaps zero individuals) running full nodes.
Sorry, another try:
You think the maximum block size rule serves to limit centralization
by limiting how hard it is to run a full node.
I agree with that, but I would add something more and you wouldn't:
The maximum block size consensus rule limits how hard it is to be a
competitive miner.
In other words, you think the last statement is false or incorrect.
Meta: I think we should try to collect and list more of this "FADs"
(we have at least 2 of them already). If you think it can be useful,
I'm more than happy to repeat this process in the opposite direction:
you make the questions and I give the answers, you write what you
think I think and I correct you in iterations. Probably we should
finish with you correcting what I think you think first. I am really
excited about understanding your point of view better.
Stupid humor (hopefully not out of context and not offensive): I'm
happy to discover that what I thought it was FUD was just FAD.
More seriously, I'm really happy for your interest in understanding
and being understood.
Let's worry about where do we think differently first and about who is
right on each point later.
In the end, only the conclusions on each point will matter and not who
claimed the final conclusions (in the points where we find them) first
(if we get to final common conclusions on that point at all).
next prev parent reply other threads:[~2015-08-06 21:51 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 14:25 Pieter Wuille
2015-07-30 15:04 ` Greg Sanders
2015-07-30 15:12 ` Jorge Timón
2015-07-30 16:23 ` Jameson Lopp
2015-07-30 16:36 ` Bryan Bishop
2015-07-30 16:43 ` Jameson Lopp
2015-07-30 16:36 ` Venzen Khaosan
2015-07-30 17:51 ` Jorge Timón
2015-07-30 18:00 ` Jorge Timón
2015-07-30 16:56 ` Gary Mulder
2015-07-30 17:13 ` Mark Friedenbach
2015-07-30 16:20 ` Gavin Andresen
2015-07-30 16:41 ` Suhas Daftuar
2015-07-30 16:48 ` Adam Back
2015-07-30 16:49 ` Pieter Wuille
2015-07-31 10:16 ` Mike Hearn
2015-07-31 11:43 ` Venzen Khaosan
2015-07-31 11:51 ` Jorge Timón
2015-07-31 12:15 ` Mike Hearn
2015-07-31 13:07 ` Marcel Jamin
2015-07-31 14:33 ` Jorge Timón
2015-07-31 14:58 ` Mike Hearn
2015-07-31 15:28 ` Venzen Khaosan
2015-07-31 20:09 ` Elliot Olds
2015-08-04 10:35 ` Jorge Timón
2015-08-04 11:04 ` Hector Chu
2015-08-04 11:27 ` Pieter Wuille
2015-08-04 11:34 ` Hector Chu
2015-08-04 12:10 ` Venzen Khaosan
2015-08-04 13:13 ` Jorge Timón
2015-08-04 13:28 ` Hector Chu
2015-08-04 13:42 ` Venzen Khaosan
2015-08-04 17:59 ` Jorge Timón
2015-08-04 13:12 ` Gavin Andresen
2015-08-04 13:54 ` Pieter Wuille
2015-08-04 14:30 ` Venzen Khaosan
2015-08-04 14:43 ` [bitcoin-dev] Fwd: " Venzen Khaosan
2015-08-04 14:45 ` [bitcoin-dev] " Alex Morcos
2015-08-05 8:14 ` Gareth Williams
2015-08-04 11:59 ` Jorge Timón
2015-08-04 12:19 ` Hector Chu
2015-08-04 13:34 ` Venzen Khaosan
2015-08-04 13:37 ` Jorge Timón
2015-08-05 7:29 ` Elliot Olds
2015-08-06 1:26 ` Jorge Timón
2015-08-06 13:40 ` Gavin Andresen
2015-08-06 14:06 ` Pieter Wuille
2015-08-06 14:21 ` Gavin Andresen
2015-08-06 14:53 ` Pieter Wuille
[not found] ` <CABsx9T0B2bZrFHxYR_QNwBmxskQx31zt=QE5BJAYjcOo7wbo3A@mail.gmail.com>
2015-08-06 15:24 ` [bitcoin-dev] Fwd: " Gavin Andresen
2015-08-06 15:26 ` Pieter Wuille
2015-08-06 18:43 ` Michael Naber
2015-08-06 18:52 ` Pieter Wuille
2015-08-07 16:06 ` Thomas Zander
2015-08-07 16:30 ` Pieter Wuille
2015-08-07 17:00 ` Thomas Zander
2015-08-07 17:09 ` Pieter Wuille
2015-08-07 21:35 ` Thomas Zander
2015-08-07 22:53 ` Adam Back
2015-08-08 16:54 ` Dave Scotese
2015-08-07 17:50 ` Gavin Andresen
2015-08-07 18:05 ` Jameson Lopp
2015-08-07 18:10 ` Pieter Wuille
2015-08-07 21:43 ` Thomas Zander
2015-08-07 22:00 ` Thomas Zander
2015-08-06 16:19 ` [bitcoin-dev] " Tom Harding
2015-08-06 21:56 ` Peter Todd
2015-08-06 15:25 ` Jorge Timón
2015-08-06 16:03 ` Gavin Andresen
2015-08-06 16:11 ` Mike Hearn
2015-08-06 17:15 ` Jorge Timón
2015-08-06 19:42 ` Gavin Andresen
2015-08-06 20:01 ` Pieter Wuille
2015-08-06 21:51 ` Jorge Timón [this message]
2015-08-06 23:09 ` Elliot Olds
2015-08-10 19:28 ` Jorge Timón
2015-08-11 5:48 ` Elliot Olds
2015-08-09 18:46 ` [bitcoin-dev] What Lightning Is Tom Harding
2015-08-09 18:54 ` Mark Friedenbach
2015-08-09 20:14 ` Hector Chu
[not found] ` <CAOG=w-s9KsaPwveSpgdvsVTWUDV77YY7Em7NZGyxSQMMCccYSg@mail.gmail.com>
2015-08-09 20:48 ` Hector Chu
2015-08-10 4:48 ` Joseph Poon
2015-08-10 17:03 ` odinn
2015-08-10 17:14 ` Pieter Wuille
2015-08-10 17:45 ` odinn
2015-08-09 21:27 ` Tom Harding
2015-08-09 21:40 ` Chris Pacia
2015-08-09 21:45 ` Hector Chu
2015-08-09 21:57 ` Patrick Strateman
2015-08-09 22:03 ` Hector Chu
2015-08-09 22:36 ` Patrick Strateman
2015-08-10 1:52 ` Tom Harding
2015-08-10 3:31 ` Patrick Strateman
2015-08-09 22:06 ` Patrick Strateman
2015-08-09 22:09 ` Hector Chu
2015-08-09 22:27 ` Patrick Strateman
2015-08-09 22:30 ` Hector Chu
2015-08-09 22:44 ` Gavin Andresen
2015-08-09 22:51 ` Btc Drak
2015-08-10 8:27 ` Thomas Zander
2015-08-10 8:36 ` Patrick Strateman
2015-08-10 4:39 ` Joseph Poon
2015-08-10 21:02 ` Anthony Towns
2015-08-10 21:19 ` Anthony Towns
2015-08-10 21:43 ` Adam Back
2015-08-11 9:01 ` Hector Chu
2015-08-11 17:17 ` Simon Liu
2015-07-31 14:52 ` [bitcoin-dev] Block size following technological growth Bryan Bishop
2015-07-30 17:46 ` Jorge Timón
2015-08-02 22:35 ` Anthony Towns
2015-07-30 20:20 ` Thomas Zander
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=CABm2gDpnikt4o9EE1Gm2g009gJa1sVtuwDM-iQgwue2ijiNLvQ@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gavinandresen@gmail$(echo .)com \
/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