Jonathan Toomim [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-14 📝 Original message:Off-topic: If you want to ...
📅 Original date posted:2015-12-14
📝 Original message: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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151214/8a06afe6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151214/8a06afe6/attachment-0001.sig>
📝 Original message: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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151214/8a06afe6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151214/8a06afe6/attachment-0001.sig>