Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
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
Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
>From my understanding of the posted proposal, a share to get rewarded must "prove" to be created before the rewarded share. (between L and R) If GOOD3 refers to BAD2 the only thing that I can prove is that BAD2 has been mined before GOOD2. So if BAD3 is a valid block (I call it R like in the pdf) the only thing that I can certainly know is that between L and R there is BAD1 and BAD2 and they should be the ones that get the rewards. Btw rereading the proposal I'm not sure about how the rewards are calculated, what let me think that is the way that I illustrate above is the figure 2: c3 is referring to a3 but is not included in the first reward. To clarify I'm talking about two things in my previous email, the first one is: what if a bad miner does not refer to good miners' shares? The second thing is: what if a bad miner publishes two (or more) conflicting versions of the DAG? On Sat, Sep 11, 2021 at 3:09 AM ZmnSCPxj wrote: > Good morning Filippo, > > > Hi! > > > > From the proposal it is not clear why a miner must reference other > miners' shares in his shares. > > What I mean is that there is a huge incentive for a rogue miner to not > reference any share from > > other miner so he won't share the reward with anyone, but it will be > paid for the share that he > > create because good miners will reference his shares. > > The pool will probably become unprofitable for good miners. > > > > Another thing that I do not understand is how to resolve conflicts. For > example, using figure 1 at > > page 1, a node could be receive this 2 valid states: > > > > 1. L -> a1 -> a2 -> a3 -> R > > 2. L -> a1* -> a2* -> R > > > > To resolve the above fork the only two method that comes to my mind are: > > > > 1. use the one that has more work > > 2. use the longest one > > Btw both methods present an issue IMHO. > > > > If the longest chain is used: > > When a block (L) is find, a miner (a) could easily create a lot of share > with low difficulty > > (L -> a1* -> a2* -> ... -> an*), then start to mine shares with his real > hashrate (L -> a1 -> a2) > > and publish them so they get referenced. If someone else finds a block > he gets the reward cause he > > has been referenced. If he finds the block he just attaches the funded > block to the longest chain > > (that reference no one) and publishes it without sharing the reward > > (L -> a1* -> a2* -> ... -> an* -> R). > > > > If is used the one with more work: > > A miner that has published the shares (L -> a1 -> a2 -> a3) when find a > block R that alone has more > > work than a1 + a2 + a3 it just publish (L -> R) and he do not share the > reward with anyone. > > > My understanding from the "Braid" in braidpool is that every share can > reference more than one previous share. > > In your proposed attack, a single hasher refers only to shares that the > hasher itself makes. > > However, a good hasher will refer not only to its own shares, but also to > shares of the "bad" hasher. > > And all honest hashers will be based, not on a single chain, but on the > share that refers to the most total work. > > So consider these shares from a bad hasher: > > BAD1 <- BAD2 <- BAD3 > > A good hasher will refer to those, and also to its own shares: > > BAD1 <- BAD2 <- BAD3 >^ ^ ^ >| | | >| | +--+ >| +-+| >| || >+--- GOOD1 <- GOOD2 <- GOOD3 > > `GOOD3` refers to 5 other shares, whereas `BAD3` refers to only 2 shares, > so `GOOD3` will be considered weightier, thus removing this avenue of > attack and resolving the issue. > Even if measured in terms of total work, `GOOD3` also contains the work > that `BAD3` does, so it would still win. > > Regards, > ZmnSCPxj > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
Good morning Filippo, > Hi! > > From the proposal it is not clear why a miner must reference other miners' > shares in his shares. > What I mean is that there is a huge incentive for a rogue miner to not > reference any share from > other miner so he won't share the reward with anyone, but it will be paid for > the share that he > create because good miners will reference his shares. > The pool will probably become unprofitable for good miners. > > Another thing that I do not understand is how to resolve conflicts. For > example, using figure 1 at > page 1, a node could be receive this 2 valid states: > > 1. L -> a1 -> a2 -> a3 -> R > 2. L -> a1* -> a2* -> R > > To resolve the above fork the only two method that comes to my mind are: > > 1. use the one that has more work > 2. use the longest one > Btw both methods present an issue IMHO. > > If the longest chain is used: > When a block (L) is find, a miner (a) could easily create a lot of share with > low difficulty > (L -> a1* -> a2* -> ... -> an*), then start to mine shares with his real > hashrate (L -> a1 -> a2) > and publish them so they get referenced. If someone else finds a block he > gets the reward cause he > has been referenced. If he finds the block he just attaches the funded block > to the longest chain > (that reference no one) and publishes it without sharing the reward > (L -> a1* -> a2* -> ... -> an* -> R). > > If is used the one with more work: > A miner that has published the shares (L -> a1 -> a2 -> a3) when find a block > R that alone has more > work than a1 + a2 + a3 it just publish (L -> R) and he do not share the > reward with anyone. My understanding from the "Braid" in braidpool is that every share can reference more than one previous share. In your proposed attack, a single hasher refers only to shares that the hasher itself makes. However, a good hasher will refer not only to its own shares, but also to shares of the "bad" hasher. And all honest hashers will be based, not on a single chain, but on the share that refers to the most total work. So consider these shares from a bad hasher: BAD1 <- BAD2 <- BAD3 A good hasher will refer to those, and also to its own shares: BAD1 <- BAD2 <- BAD3 ^ ^ ^ | | | | | +--+ | +-+| | || +--- GOOD1 <- GOOD2 <- GOOD3 `GOOD3` refers to 5 other shares, whereas `BAD3` refers to only 2 shares, so `GOOD3` will be considered weightier, thus removing this avenue of attack and resolving the issue. Even if measured in terms of total work, `GOOD3` also contains the work that `BAD3` does, so it would still win. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
Hi!
>From the proposal it is not clear why a miner must reference other miners'
shares in his shares.
What I mean is that there is a huge incentive for a rogue miner to not
reference any share from
other miner so he won't share the reward with anyone, but it will be paid
for the share that he
create because good miners will reference his shares.
The pool will probably become unprofitable for good miners.
Another thing that I do not understand is how to resolve conflicts. For
example, using figure 1 at
page 1, a node could be receive this 2 valid states:
1. L -> a1 -> a2 -> a3 -> R
2. L -> a1* -> a2* -> R
To resolve the above fork the only two method that comes to my mind are:
1. use the one that has more work
2. use the longest one
Btw both methods present an issue IMHO.
If the longest chain is used:
When a block (L) is find, a miner (a) could easily create a lot of share
with low difficulty
(L -> a1* -> a2* -> ... -> an*), then start to mine shares with his real
hashrate (L -> a1 -> a2)
and publish them so they get referenced. If someone else finds a block he
gets the reward cause he
has been referenced. If he finds the block he just attaches the funded
block to the longest chain
(that reference no one) and publishes it without sharing the reward
(L -> a1* -> a2* -> ... -> an* -> R).
If is used the one with more work:
A miner that has published the shares (L -> a1 -> a2 -> a3) when find a
block R that alone has more
work than a1 + a2 + a3 it just publish (L -> R) and he do not share the
reward with anyone.
On Wed, Sep 8, 2021 at 1:15 PM pool2win via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 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@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@lists.linuxfoundation.org
>
Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
> 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 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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
> How would you compare this to Stratum v2? Stratum v2 will help miners with encryption, broadcasting new blocks, signalling bits, choose transactions set, however the mining pools can still reject negotiations and censor payments. Maybe Stratum v2 can be used in combination with other things like discreet log contracts: https://mailmanlists.org/pipermail/dlc-dev/2021-May/73.html I think Braidpool does this in a better way. -- Prayank A3B1 E430 2298 178F ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
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 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
Switching pools has always been possible. But the largest pool is the most profitable, and centralized pools are easily controlled. Decoupling selection without decoupling payout is an engineering change without a pooling pressure change. e > On Sep 6, 2021, at 10:01, David A. Harding 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
It doesn’t centralize payment, which ultimately controls transaction selection (censorship). e > On Sep 6, 2021, at 08:25, David A. Harding via bitcoin-dev > wrote: > > On Wed, Sep 01, 2021 at 11:46:55PM -0700, Billy Tetrud via bitcoin-dev wrote: >> How would you compare this to Stratum v2? > > Specifically, I'd be interested in learning what advantages this has > over a centralized mining pool using BetterHash or StratumV2 with > payouts made via LN (perhaps immediately after each submitted share is > validated). > > -Dave > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
On Wed, Sep 01, 2021 at 11:46:55PM -0700, Billy Tetrud via bitcoin-dev wrote: > How would you compare this to Stratum v2? Specifically, I'd be interested in learning what advantages this has over a centralized mining pool using BetterHash or StratumV2 with payouts made via LN (perhaps immediately after each submitted share is validated). -Dave signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
How would you compare this to Stratum v2? On Sun, Aug 29, 2021 at 1:02 AM pool2win via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
