From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Prayank <prayank@tutanota•de>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: "billy.tetrud@gmail•com" <billy.tetrud@gmail•com>
Subject: Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
Date: Tue, 07 Sep 2021 23:38:42 +0000 [thread overview]
Message-ID: <ceFmn7ZHyPHN70rDuE66lnPEwjgjQ7LtZLwyFgIVUpPvPDvSZSsLHUf_yiBvXTpjdEju4UxAOnDgilZaQAMvQzYcUbOkZsYvOIpuBG7japo=@protonmail.com> (raw)
In-Reply-To: <MiuahdA--3-2@tutanota.de>
Good morning all,
A thing I just realized about Braidpool is that the payout server is still a single central point-of-failure.
Although the paper claims to use Tor hidden service to protect against DDoS attacks, its centrality still cannot protect against sheer accident.
What happens if some clumsy human (all humans are clumsy, right?) fumbles the cables in the datacenter the hub is hosted in?
What happens if the country the datacenter is in is plunged into war or anarchy, because you humans love war and chaos so much?
What happens if Zeus has a random affair (like all those other times), Hera gets angry, and they get into a domestic, and then a random thrown lightning bolt hits the datacenter the hub is in?
The paper relies on economic arguments ("such an action will end the pool and the stream of future profits for the hub"), but economic arguments tend to be a lot less powerful in a monopoly, and the hub effectively has a monopoly on all Braidpool miners.
Hashers might be willing to tolerate minor peccadilloes of the hub, simply to let the pool continue (their other choices would be even worse).
So it seems to me that it would still be nicer, if it were at all possible, to use multiple hubs.
I am uncertain how easily this can be done.
Perhaps a Lightning model can be considered.
Multiple hubs may exist which offer liquidity to the Braidpool network, hashers measure uptime and timeliness of payouts, and the winning hasher elects one of the hubs.
The hub gets paid on the coinbase, and should send payouts, minus fees, on the LN to the miners.
However, this probably complicates the design too much, and it may be more beneficial to get *something* working now.
Let not the perfect be the enemy of the good.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-09-07 23:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-06 10:15 Prayank
2021-09-07 23:38 ` ZmnSCPxj [this message]
2021-09-08 10:03 ` pool2win
2021-09-10 9:30 ` Filippo Merli
2021-09-11 1:09 ` ZmnSCPxj
2021-09-11 7:54 ` Filippo Merli
2021-09-13 8:03 ` pool2win
-- strict thread matches above, loose matches on Subject: below --
2021-08-29 5:57 pool2win
2021-09-02 6:46 ` Billy Tetrud
2021-09-06 6:23 ` David A. Harding
2021-09-06 7:29 ` Eric Voskuil
2021-09-06 7:54 ` David A. Harding
2021-09-06 8:26 ` Eric Voskuil
2021-09-06 9:03 ` pool2win
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='ceFmn7ZHyPHN70rDuE66lnPEwjgjQ7LtZLwyFgIVUpPvPDvSZSsLHUf_yiBvXTpjdEju4UxAOnDgilZaQAMvQzYcUbOkZsYvOIpuBG7japo=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=prayank@tutanota$(echo .)de \
/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