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
>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
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
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
> 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
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
> 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
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
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
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?
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
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
>
13 matches
Mail list logo
