From: John Dillon <john.dillon892@googlemail•com>
To: "Goss, Brian C., M.D." <Goss.Brian@mayo•edu>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] 1. Re: On the optimal block size and why transaction fees are 8
Date: Wed, 13 Nov 2013 20:27:52 +0000 [thread overview]
Message-ID: <CAPaL=UWEwWOtLtj684jNAhpDV3C8rWZ+dUVC6FWMmWpARRzUOg@mail.gmail.com> (raw)
In-Reply-To: <FFE335820B1BFF4F8E8619F446F2D87F4C20067D@MSGPEXCEI32B.mfad.mfroot.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Nov 8, 2013 at 4:21 PM, Goss, Brian C., M.D.
<Goss.Brian@mayo•edu> wrote:
> Peter,
>
> What is the propagation time within a pool? If my pool is made up of a ton
> of fancy ASICs connected by 300 baud modems, how does that affect your
> analysis (ie, Q for a mining pool is effectively a function of time as
> well)?
The propagation time you're thinking of is from the pool to the miner, and even
now that is significant for pools that do not pay for stale shares. I remember
an Australian pool mentioning that problem on their website as a reason for the
pools existence.
I would expect selfish mining, as well as orphans becoming more important in
general, to centralize the physical location of hashing power too. If the 100ms
delay to your pool impacts profits you'll have an incentive to locate your
mining equipment physically closer to the pool. The next step is pools wanting
to physically locate themselves closer to other pools.
It would not be good if all Bitcoin mining was done in Iceland...
> Brian
> P.S. I hope these are not ignorant questions; if they are, please feel free
> to disregard!
Not ignorant at all IMO.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSg+CpAAoJEEWCsU4mNhiPufwIAKNpBBvlRvSQZOzMJvghG7fX
lCNliohDKw9kdKJJjN1T73Ssl06wGbBe881k4c4r7fHeNDRQZbrFsj+uBsFyUhmy
CF70KiOKuowDlWwyWMxZbbyinK0mEKC7J/hJVOt15FHubLnq71Utb+I2L7seyHlo
2E2byG4UnofoD5L+hGzfD6FJ/zYEHtTKgFw7Y1+ZSmAxlIcdrcpH7tPmUzFD7JPi
RnaK1BH7hpM6FyZQUhSC/tW7mYswNEasvouBE4V1vSySZb6S43kiED2Q4uH3W0+A
UtbyRQ7yT3BOLGB2OO/L92tg6S7WRyMtvQoevJkEIAnUywD3YWaZnBbf0IM4LWg=
=6750
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2013-11-13 20:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-08 16:21 Goss, Brian C., M.D.
2013-11-13 20:27 ` John Dillon [this message]
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='CAPaL=UWEwWOtLtj684jNAhpDV3C8rWZ+dUVC6FWMmWpARRzUOg@mail.gmail.com' \
--to=john.dillon892@googlemail$(echo .)com \
--cc=Goss.Brian@mayo$(echo .)edu \
--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