From: Jonathan Toomim <j@toom•im>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness features wish list
Date: Mon, 14 Dec 2015 20:50:51 +0800 [thread overview]
Message-ID: <478742B9-8CEA-467D-957D-3FAAB8AF5337@toom.im> (raw)
In-Reply-To: <CALqxMTFY4oAAO4mXVJigEunjPw+q6y3x=zATLEw9ErDcS1RDuw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1752 bytes --]
Off-topic: If you want to decentralize hashing, the best solution is probably to redesign p2pool to use DAGs. p2pool would be great except for the fact that the 30 sec share times are (a) long enough to cause significant reward variance for miners, but (b) short enough to cause hashrate loss from frequent switching on hardware that wasn't designed for it (e.g. Antminers, KNC) and (c) uneven rewards to different miners due to share orphan rates. DAGs can fix all of those issues. I had a talk with some medium-sized Chinese miners on Thursday in which I told them about p2pool, and I got the impression that they would prefer it over their existing pools due to the 0% fees and trustless design if the performance issues were fixed. If anybody is interested in helping with this work, ping me or Bob McElrath backchannel to be included in our conversation.
On Dec 14, 2015, at 8:32 PM, Adam Back <adam@cypherspace•org> wrote:
> The other thing which is not protocol related, is that companies can
> help themselves and help Bitcoin developers help them, by working to
> improve decentralisation with better configurations, more use of
> self-hosted and secured full nodes, and decentralisation of policy
> control over hashrate. That might even include buying a nominal (to a
> reasonably funded startup) amount of mining equipment. Or for power
> users to do more of that. Some developers are doing mining.
> Blockstream and some employees have a little bit of hashrate. If we
> could define some metrics and best practices and measure the
> improvements, that would maybe reduce miners concerns about
> centralisation risk and allow a bigger block faster, alongside the
> IBLT & weak block network protocol improvements.
[-- Attachment #1.2: Type: text/html, Size: 10414 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]
next prev parent reply other threads:[~2015-12-14 12:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 12:32 Adam Back
2015-12-14 12:50 ` Jonathan Toomim [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-12-10 6:47 jl2012
2015-12-10 8:26 ` Gregory Maxwell
2015-12-10 8:28 ` Bryan Bishop
2015-12-10 9:51 ` Gregory Maxwell
2015-12-13 15:25 ` jl2012
2015-12-13 18:07 ` Pieter Wuille
2015-12-13 18:41 ` jl2012
2015-12-10 12:54 ` Tamas Blummer
2015-12-12 0:43 ` Jannes Faber
2015-12-13 20:34 ` Rusty Russell
2015-12-14 11:44 ` Jonathan Toomim
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=478742B9-8CEA-467D-957D-3FAAB8AF5337@toom.im \
--to=j@toom$(echo .)im \
--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