From: Alex Mizrahi <alex.mizrahi@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
Date: Fri, 8 May 2015 18:57:27 +0300 [thread overview]
Message-ID: <CAE28kUSkQ6YWzkcqU9RqRkZzHUR_8wYj1pTxGF8Z4gp5SztdAA@mail.gmail.com> (raw)
In-Reply-To: <16096345.A1MpJQQkRW@crushinator>
[-- Attachment #1: Type: text/plain, Size: 992 bytes --]
Adaptive schedules, i.e. those where block size limit depends not only on
block height, but on other parameters as well, are surely attractive in the
sense that the system can adapt to the actual use, but they also open a
possibility of a manipulation.
E.g. one of mining companies might try to bankrupt other companies by
making mining non-profitable. To do that they will accept transactions with
ridiculously low fees (e.g. 1 satoshi per transaction). Of course, they
will suffer losees themselves, but the they might be able to survive that
if they have access to financial resources. (E.g. companies backed by banks
and such will have an advantage).
Once competitors close down their mining operations, they can drive fees
upwards.
So if you don't want to open room for manipulation (which is very hard to
analyze), it is better to have a block size hard limit which depends only
on block height.
On top of that there might be a soft limit which is enforced by the
majority of miners.
[-- Attachment #2: Type: text/html, Size: 1237 bytes --]
next prev parent reply other threads:[~2015-05-08 15:57 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 7:20 Matt Whitlock
2015-05-08 10:15 ` Mike Hearn
2015-05-08 10:30 ` Clément Elbaz
2015-05-08 12:32 ` Joel Joonatan Kaartinen
2015-05-08 12:48 ` Matt Whitlock
2015-05-08 13:24 ` Matt Whitlock
2015-05-08 12:48 ` Gavin Andresen
2015-05-08 16:51 ` Peter Todd
2015-05-08 22:36 ` Joel Joonatan Kaartinen
2015-05-09 18:30 ` Peter Todd
2015-05-08 15:57 ` Alex Mizrahi [this message]
2015-05-08 16:55 ` Bryan Bishop
2015-05-08 20:33 ` Mark Friedenbach
2015-05-08 22:43 ` Aaron Voisine
2015-05-08 22:45 ` Mark Friedenbach
2015-05-08 23:15 ` Aaron Voisine
2015-05-08 23:58 ` Mark Friedenbach
2015-05-09 3:36 ` Gregory Maxwell
2015-05-09 11:58 ` Gavin Andresen
2015-05-09 13:49 ` Tier Nolan
2015-05-10 17:36 ` Owen Gunden
2015-05-10 18:10 ` Mark Friedenbach
2015-05-10 21:21 ` Gavin Andresen
2015-05-10 21:33 ` Gregory Maxwell
2015-05-10 21:56 ` Rob Golding
2015-05-13 10:43 ` Tier Nolan
2015-05-16 0:22 ` Rusty Russell
2015-05-16 11:09 ` Tier Nolan
2015-05-18 1:42 ` Rusty Russell
2015-05-19 8:59 ` Tier Nolan
2015-05-10 21:48 ` Thomas Voegtlin
2015-05-10 22:31 ` Mark Friedenbach
2015-05-10 23:11 ` Thomas Voegtlin
2015-05-28 15:53 ` Gavin Andresen
2015-05-28 17:05 ` Mike Hearn
2015-05-28 17:19 ` Gavin Andresen
2015-05-28 17:34 ` Mike Hearn
2015-05-28 18:23 ` Gavin Andresen
2015-05-29 11:26 ` Mike Hearn
2015-05-29 11:42 ` Tier Nolan
2015-05-29 11:57 ` Mike Hearn
2015-05-29 12:39 ` Gavin Andresen
2015-05-29 14:00 ` insecurity
2015-05-29 14:15 ` Braun Brelin
2015-05-29 14:09 ` Tier Nolan
2015-05-29 14:20 ` Gavin Andresen
2015-05-29 14:22 ` Mike Hearn
2015-05-29 14:21 ` Mike Hearn
2015-05-29 14:22 ` Tier Nolan
2015-05-29 16:39 ` [Bitcoin-development] Proposed alternatives to the 20MB stepfunction Raystonn .
2015-05-29 18:28 ` Tier Nolan
2015-05-29 17:53 ` [Bitcoin-development] Proposed alternatives to the 20MB step function Admin Istrator
2015-05-30 9:03 ` Aaron Voisine
2015-06-01 11:30 ` Ricardo Filipe
2015-06-01 11:46 ` Marcel Jamin
2015-05-29 18:47 ` Bryan Cheng
2015-05-30 1:36 ` Cameron Garnham
2015-05-28 17:39 ` [Bitcoin-development] Proposed alternatives to the 20MB stepfunction Raystonn .
2015-05-28 17:59 ` Pieter Wuille
2015-05-28 18:21 ` Gavin Andresen
2015-05-28 17:50 ` [Bitcoin-development] Proposed alternatives to the 20MB step function Peter Todd
2015-05-28 17:14 ` Thomas Voegtlin
2015-05-28 17:34 ` Pieter Wuille
2015-05-29 17:45 ` Aaron Voisine
2015-05-08 14:57 Steven Pine
2015-05-09 0:13 Raystonn
[not found] <CAAjy6kDdB8uODpPcmS8h4eap8fke7Y2y773NHJZja8tB5mPk4Q@mail.gmail.com>
2015-05-28 16:30 ` Steven Pine
[not found] ` <CABsx9T03aNRC5DRbR06nNtsiBdJAcQsGAHvbCOe3pnuRpdvq5w@mail.gmail.com>
2015-05-28 18:25 ` Steven Pine
2015-05-28 18:31 ` Gavin Andresen
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=CAE28kUSkQ6YWzkcqU9RqRkZzHUR_8wYj1pTxGF8Z4gp5SztdAA@mail.gmail.com \
--to=alex.mizrahi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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