From: "t. khan" <teekhan42@gmail•com>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] BIP - 'Block75' - New algorithm
Date: Tue, 3 Jan 2017 09:28:27 -0500 [thread overview]
Message-ID: <CAGCNRJpKCtyjS9bm15UFh_p=N4o1A=2tzNvnWVZKbq8Tn4x7Lw@mail.gmail.com> (raw)
In-Reply-To: <201701022119.11115.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 3261 bytes --]
On Mon, Jan 2, 2017 at 4:19 PM, Luke Dashjr <luke@dashjr•org
<javascript:_e(%7B%7D,'cvml','luke@dashjr•org');>> wrote:
> > Using the growth rate over the last year as a model (
> > https://blockchain.info/charts/avg-block-size?daysAverageString=14 ),
> > Block75 would also have frequently decreased the limit. Though, yes, more
> > transactions would equal larger blocks over time, but that's the entire
> > point of this.
>
> Then it doesn't solve the actual problems of either miner spam or growth in
> resource requirements, which are the entire purpose of the block size
> limit.
>
Do you have any direct evidence of "miner spam"? If so, please link to a
transaction. Also, what could a miner possibly gain from this?
For resource requirements (bandwidth/disk space), please run the numbers on
the Block75 algorithm and compare with growth rates of both.
> What is your definition of "spam"?
>
> Anything that consumes more data than necessary to properly convey the
> intended transfer of value (bitcoins) from one entity to another, including
> all data that is not intended for such a purpose.
>
By this definition, any transaction which transfers ownership of an asset
(stock certificate, deeds to property, copyrights, etc.) is spam. But these
are legitimate, fee paying transactions. They are not spam. Yes, they're
only moving 0.0001 btc. Some will eventually move to Lightning (or
something like it), but many will not as they are unsuitable for off-chain.
> > I doubt you'll get consensus for such a fundamentally broken proposal.
> > > I certainly don't foresee any circumstance where I could reasonably
> > > support it... The block size limit exists to restrict miners; it makes
> no
> > > sense to put it in their control.
> >
> > Specifically, what is broken about it?
>
> Putting group X in control of a limit that exists for the sole purpose of
> restricting group X.
>
No, it actually gives them less power than they have now. Consider the
two-week recalculation: the result of any attempt to manipulate the block
size (up or down) will only last for two weeks. There's no way for a miner
to profit from this (in fact, they'd lose money this way). The best outcome
they could hope for is a very small increase or decrease for two weeks. So
why would anyone do this?
As soon as such a manipulation ended, Block75 would correct the max block
size back to an appropriate level (defined as: average block 75% full).
> There would still be a block size limit, it would just change slightly
> > every two weeks. I agree that miners shouldn't have control of this, and
> > Block75 doesn't give them any (at least none they can make a profit on).
>
> It gives miners complete control over the limit. They can make blocks of
> any
> size (within the current limit), thus triggering the conditions by which
> your
> proposal would raise the limit further.
We covered this ad nauseum in the other Block75 thread, but basically no
one has been able to come up with a realistic scenario wherein miners would
be motivated to do this *and* there aren't any pools large enough now (nor
have there ever been) to have anything more than a minor and temporary
effect.
If such a scenario actually does exist, please describe it in detail.
- t.k.
[-- Attachment #2: Type: text/html, Size: 4730 bytes --]
next prev parent reply other threads:[~2017-01-03 14:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-02 18:04 t. khan
2017-01-02 19:01 ` Tom Zander
2017-01-02 19:32 ` t. khan
2017-01-02 20:35 ` Tom Zander
2017-01-02 21:05 ` t. khan
2017-01-02 22:33 ` Tom Zander
2017-01-02 21:19 ` Luke Dashjr
2017-01-02 22:01 ` Tom Zander
2017-01-03 14:28 ` t. khan [this message]
2017-02-13 11:21 ` Hampus Sjöberg
2017-01-02 20:04 ` Luke Dashjr
2017-01-02 20:41 ` t. khan
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='CAGCNRJpKCtyjS9bm15UFh_p=N4o1A=2tzNvnWVZKbq8Tn4x7Lw@mail.gmail.com' \
--to=teekhan42@gmail$(echo .)com \
--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