public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ivan Brightly <ibrightly@gmail•com>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Răspuns: Personal opinion on the fee market from a worried local trader
Date: Thu, 30 Jul 2015 08:45:16 -0400	[thread overview]
Message-ID: <CAAre=yTfiQhprMx2zmhZHVPuNmazxBLNX5CkVjZzpC-41tgvow@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTHEknuwPW-uG3W9Fv1sQC54ud3zk4aLQaFGTTjAt7ghfA@mail.gmail.com>

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

One thing that the below assumption doesn't appear to take into account is
user demand for quick confirmations. I haven't fully thought out the game
theory on this but here goes:

Example: if 75% of hashing power accepts 'medium' fee transactions while
25% is willing to accept low (or any) fee transactions, then a user paying
a lower fee wishing to get their transaction included in the next block
runs a ~75% chance that their transaction won't be included.

Users desiring the most reliably fast confirmations are better off by
paying the minimum fee that a majority of miners will accept. Miners
breaking ranks and accepting lower fees only affects users who aren't
sufficiently interested in quicker confirmations. As long as a majority of
miners 'collude', they will likely be able to keep the average fees higher
than miners with the lower costs of operations might be willing to accept.

On Thu, Jul 30, 2015 at 12:00 AM, Adam Back via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On 29 July 2015 at 20:41, Ryan Butler via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > Does an unlimited blocksize imply the lack of a fee market?  Isn't every
> > miner able to set their minimum accepted fee or transaction acceptance
> > algorithm?
>
> The assumption is that wont work because any miner can break ranks and
> do so profitably, so to expect otherwise is to expect oligopoly
> behaviour which is the sort of antithesis of a decentralised mining
> system.  It's in fact a similar argument as to why decentralisation of
> mining provides policy neutrality: some miner somewhere with some
> hashrate will process your transaction even if some other miners are
> by policy deciding not to mine it.  It is also similar reason why free
> transactions are processed today - policies vary and this is good for
> ensuring many types of transaction get processed.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

  parent reply	other threads:[~2015-07-30 12:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CADZB0_ZgDMhVgCUh2PTAPDL7k_W8QGt_HLYdkwv_qQ5xEMn8HA@mail.gmail.com>
2015-07-29 14:09 ` Vali Zero
2015-07-29 17:47   ` Raystonn .
2015-07-29 22:54     ` s7r
2015-07-30  3:41       ` Ryan Butler
2015-07-30  4:00         ` Adam Back
2015-07-30  4:05           ` Adam Back
2015-07-30  4:48           ` Ryan Butler
2015-07-30 13:14             ` Tom Harding
2015-07-30 14:25               ` Dave Hudson
2015-07-30 14:57                 ` Tom Harding
2015-07-30 18:14               ` Jorge Timón
2015-07-30 18:16                 ` Jorge Timón
2015-07-30 20:53                 ` Tom Harding
2015-07-31  1:21                   ` Jorge Timón
2015-07-31  1:29                     ` Jorge Timón
2015-07-31  9:56                     ` Thomas Zander
2015-07-31 12:32                       ` Oleg Andreev
2015-07-31 15:24                         ` Jorge Timón
2015-07-30 12:45           ` Ivan Brightly [this message]
2015-07-30  4:07         ` Jean-Paul Kogelman
2015-07-30  9:52       ` odinn

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='CAAre=yTfiQhprMx2zmhZHVPuNmazxBLNX5CkVjZzpC-41tgvow@mail.gmail.com' \
    --to=ibrightly@gmail$(echo .)com \
    --cc=adam@cypherspace$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.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