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 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] Note on Sequence Lock Upgrades Defect
Hi Jeremy, I think it would be nice to have and suggested something similar (enforce minimality) in the context of Miniscript a few months ago [0]. However your code: const bool seq_is_reserved = (txin.nSequence < CTxIn::SEQUENCE_FINAL-2) && ( // when sequence is set to disabled, it is reserved for future use ((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0) || // when sequence has bits set outside of the type flag and locktime mask, // it is reserved for future use. ((~(CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG | CTxIn::SEQUENCE_LOCKTIME_MASK) & txin.nSequence) != 0) ); Would effectively prevent Lightning Network commitment transactions from relaying. The protocol uses a hack encoding the commitment transaction numbering in the part of nSequence (and nLockTime) without consensus meaning. This both sets the LOCKTIME_DISABLE_FLAG and uses bits outside of the mask. [0] https://github.com/rust-bitcoin/rust-miniscript/pull/246#issue-671512626 [1] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#commitment-transaction ‐‐‐ Original Message ‐‐‐ Le lundi 6 septembre 2021 à 5:17 AM, Jeremy via bitcoin-dev a écrit : > BIP 68 says >= 2:This specification defines the meaning of sequence numbers > for transactions with an nVersion greater than or equal to 2 for which the > rest of this specification relies on. > BIP-112 says not < 2 > // Fail if the transaction's version number is not set high > // enough to trigger BIP 68 rules. > if (static_cast(txTo->nVersion) < 2) return false; > > A further proof that this needs fix: the flawed upgradable semantic exists in > script as well as in the transaction nSeqeunce. we can't really control the > transaction version an output will be spent with in the future, so it would > be weird/bad to change the semantic in transaction version 3. > > -- > [@JeremyRubin](https://twitter.com/JeremyRubin)https://twitter.com/JeremyRubin > > On Sun, Sep 5, 2021 at 7:36 PM David A. Harding wrote: > >> On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev wrote: >>> Hi Bitcoin Devs, >>> >>> I recently noticed a flaw in the Sequence lock implementation with respect >>> to upgradability. It might be the case that this is protected against by >>> some transaction level policy (didn't see any in policy.cpp, but if not, >>> I've put up a blogpost explaining the defect and patching it >>> https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/ >> >> Isn't this why BIP68 requires using tx.version=2? Wouldn't we just >> deploy any new nSequence rules with tx.version>2? >> >> -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
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
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
> 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
