pool2win [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-08-29 to 2021-09-13
💬 Posted a total of 4 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 22:58:33

- reply

📅 Original date posted:2021-09-13
📝 Original message:Hi Filippo,
If a malicious miner, M broadcasts {m1, m2 ... mn} at a regular interval, *and* also broadcasts {m1*, mn*} where mn* is bitcoin block then M will cheat all other miners of their reward. You correctly identified this attack. The problem stems from the fact that I wanted to use the bitcoin block as the sentinel to mark the shares from the DAG that need to be rewarded. There's a few approaches we can take here, but I think the best one is that the hub broadcasts a "sentinel" to mark out the point in logical time up to which shares will be rewarded.
m1* <-------------------- mn*<--------+
|
m1 <----m2 <---m3 <-------------------+
^ ^ ^ |
| | | |
| | +-----------+ |
| | | |
| +--------+ | SENTINEL
+-----+ | | |
| | | |
a1 <------ a2 <-----a3 <------+
In the above diagram, when hub receives mn*, the bitcoin block to be rewarded, the hub has also received {m1...m3, a1...a3} and therefore rewards all those shares and broadcasts this logical time to the p2p by sending a sentinel announcement.
This solution will also scale to the multiple hubs construction, as each hub will define their own sentinel and the miners working with each hub can independently verify their shares are being correctly rewarded. The solution also handles the case where M is not referencing any other shares.
The above alternative, might also answer your question about why we need to build a DAG. With a DAG we can capture logical time. Without a DAG, the above solution will require the hub to announce the hash of shares from each miner that have been rewarded.
I really appreciate you taking the time to go through the proposal and pointing out the attack. I hope the above solution addresses your concerns.
Thanks and best regards
pool2win

2023-06-07 22:58:30

- reply

📅 Original date posted:2021-09-08
📝 Original message:> A thing I just realized about Braidpool is that the payout server is still a single central point-of-failure.
> However, this probably complicates the design too much, and it may be more beneficial to get *something* working now.
You have hit the nail on the head here and Chris Belcher's original proposal for using payment channels does provide a construction for multiple hubs [1]. In the Braidpool proposal however, the focus is on a single hub to describe the plan for an MVP.
Decentralising hubs is the end goal here, and either Belcher's multiple hubs construction or a leadership election based construction along the lines you propose might be a good way forward. Belcher's idea has the added advantage that the required liquidity at each hub is reduced as more hubs join, with the cost that in case of a hubs defecting, it takes longer for miners to do cascading close on channels to all hubs. TBH, it might be a cost worth paying in the absence of better ideas. But as braidpool is built, more ideas will be appear as well.
[1] Payment Channel Payouts: An Idea for Improving P2Pool Scalability: https://bitcointalk.org/index.php?topic=2135429.0
---------- Original Message ----------
On Tue, September 7, 2021 at 11:39 PM, ZmnSCPxj via bitcoin-dev<bitcoin-dev at lists.linuxfoundation.org> wrote:
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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:58:29

- reply

📅 Original date posted:2021-09-06
📝 Original message:I see Braidpool as an improvement to P2Pool - i.e. make a peer to peer pool work at scale.
This is in contrast to Stratum v2, which brings some very good and much needed engineering improvements to centralised pools.
Specifically about transaction selection in Stratum V2, as far as I understand, the pool still controls both accepting the proposed block and also as Eric says, they still could refuse payouts. Here's a quote from the Stratum V2 docs[1]:
"The name Job ‘Negotiation’ Protocol is telling, as job selection is indeed a negotiation process between a miner and a pool. The miner proposes a block template, and it is up to a pool to accept or reject it."
As David says, a miner is free to hop pools, but generally pool hopping can be detrimental to a pool [2].
Further still, the immediate payouts to miners will work if they opt for PPS. But most centralised pools still use PPLNS(*) or equivalent.
I'd like to highlight an additional problem with centralised pools using PPLNS. These pools are opaque, at least to smaller miners, who can't view the shares received by the pool. Miners are forced to simply trust centralised pools to be honest and compute rewards fairly. A bug in their share tracking or reward calculation protocol could go unnoticed for a long time.
With Braidpool you get:
1. Transparent view of the shares received by the pool - thus have the ability to verify reward calculation, even with a PPLNS like scheme. This is the same advantage as P2Pool.
2. Payouts over one-way channel, so we don't consume block space for miner rewards payouts. This is different from P2Pool.
3. Using the transparent view of shares, we can build delivery of such shares to market makers providing futures contracts for hashrate. This is nigh impossible with opaque centralised pools.
4. We prepare for any attacks on centralised mining pools in the future - which we want to keep as the central aim of Braidpool. All the other advantages attract miners to Braidpool now, while preparing our defense against future attacks.
[1] Stratum V2: https://braiins.com/stratum-v2
[2] Analysis of Bitcoin Pooled Mining Reward Systems: https://arxiv.org/abs/1112.4980
(*) Starting a new PPS based pool requires a lot of funds. The probability of bankruptcy for pools providing PPS is pretty high.
---------- Original Message ----------
On Mon, September 6, 2021 at 8:01 AM, David A. Harding via bitcoin-dev<bitcoin-dev at lists.linuxfoundation.org> wrote:
On Mon, Sep 06, 2021 at 09:29:01AM +0200, Eric Voskuil wrote:
> It doesn’t centralize payment, which ultimately controls transaction selection (censorship).
Yeah, but if you get paid after each share via LN and you can switch
pools instantly, then the worst case with centralized pools is that
you don't get paid for one share. If the hasher sets their share
difficulty low enough, that shouldn't be a big deal.
I'm interested in whether braidpool offers any significant benefits over
an idealized version of centralized mining with independent transaction
selection.
-Dave
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:58:21

- reply

📅 Original date posted:2021-08-29
📝 Original message:We have been working on a peer to peer mining pool that overcomes the
problems faced by P2Pool and enables building a futures market for
hashrate.
The proposal can be found here:
https://github.com/pool2win/braidpool/raw/main/proposal/proposal.pdf
The key features of the pool are:
1. Lower variance for smaller miners, even when large miners join
the pool.
2. Miners build their own blocks, just like in P2Pool.
3. Payouts require a constant size blockspace, independent of the
number of miners in the pool.
4. Provide building blocks for enabling a futures market of hash
rates.
Braidpool: Decentralised Mining Pool for Bitcoin
Abstract. Bitcoin P2Pool's usage has steadily declined over the years,
negatively impacting bitcoin's decentralisation. The variance in
earnings for miners increases with total hashrate participating in
P2Pool, and payouts require a linearly increasing block space with the
number of miners participating in the pool. We present a solution that
uses a DAG of shares replicated at all miners. The DAG is then used to
compute rewards for miners. Rewards are paid out using one-way payment
channels by an anonymous hub communicating with the miners using Tor's
hidden services. Using the payment channels construction, neither the
hub nor the miners can cheat.
Full proposal at
https://github.com/pool2win/braidpool/raw/main/proposal/proposal.pdf
Details on trading hashrate are here:
https://pool2win.github.io/braidpool/2021/08/18/deliver-hashrate-to-market-makers.html
@pool2win