📅 Original date posted:2015-12-06
📝 Original message:I think something that anyone who isn't validating should be aware of is
that cgminer(which powers the vast majority of the current mining network)
doesn't allow for a pool to revert to mining on the previous block due to
the way chain tracking is implemented.
https://github.com/ckolivas/cgminer/blob/master/cgminer.c#L4727
On Fri, Dec 4, 2015 at 4:43 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Gavin Andresen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> writes:
> > Overall, good idea.
> >
> > Is there a write-up somewhere describing in detail the 'accidental
> selfish
> > mining' problem that this mitigates? I think a link in the BIP to a
> fuller
> > description of the problem and how validation-skipping makes it go away
> > would be helpful.
> >
> > RE: which bit to use: the draft versionbits BIP and BIP101 use bit 30;
> to
> > avoid confusion, I think it would be better to use bit 0.
>
> Yes, BIP9 need to be adjusted (setting bit 30 means BIP9 counts it as a
> vote against all softforks). BIP101 uses bits 0,1,2 AFAICT, so perhaps
> start from the other end and use bit 29? We can bikeshed that later
> though...
>
> > I agree with Jannes Faber, behavior with respect to SPV clients should be
> > to only tell them about fully validated headers.
>
> A delicate balance. If we penalize these blocks too much, it's
> disincentive to set the bit. Fortunately it's easy for SPV clients to
> decide for themselves, I think?
>
> Cheers,
> Rusty.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151205/4ed6a987/attachment.html>;
James Hilliard [ARCHIVE] /
npub10r…kgk2d
2023-06-07 17:45:31
in reply to nevent1q…e9sd
Author Public Key
npub10r9d6edmnrljk59wsf06zqp494l3qtjpa3w245hy6t5euqxlzw2qdkgk2dPublished at
2023-06-07 17:45:31Event JSON
{
"id": "fc77cce07128c0df025cd2004942f529425cb74a4634d347cc4a91fc4fd2e945",
"pubkey": "78cadd65bb98ff2b50ae825fa100352d7f102e41ec5caad2e4d2e99e00df1394",
"created_at": 1686159931,
"kind": 1,
"tags": [
[
"e",
"15a16192f3a989cab67f2ac617a2f0c8ac441d823789f63c6c25a5e7f0b7696c",
"",
"root"
],
[
"e",
"77f9fe845c6da23521abd54f21166b5fd45d806c460f4c56e4ea705bafe0011e",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-12-06\n📝 Original message:I think something that anyone who isn't validating should be aware of is\nthat cgminer(which powers the vast majority of the current mining network)\ndoesn't allow for a pool to revert to mining on the previous block due to\nthe way chain tracking is implemented.\n\nhttps://github.com/ckolivas/cgminer/blob/master/cgminer.c#L4727\n\nOn Fri, Dec 4, 2015 at 4:43 PM, Rusty Russell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Gavin Andresen via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e writes:\n\u003e \u003e Overall, good idea.\n\u003e \u003e\n\u003e \u003e Is there a write-up somewhere describing in detail the 'accidental\n\u003e selfish\n\u003e \u003e mining' problem that this mitigates? I think a link in the BIP to a\n\u003e fuller\n\u003e \u003e description of the problem and how validation-skipping makes it go away\n\u003e \u003e would be helpful.\n\u003e \u003e\n\u003e \u003e RE: which bit to use: the draft versionbits BIP and BIP101 use bit 30;\n\u003e to\n\u003e \u003e avoid confusion, I think it would be better to use bit 0.\n\u003e\n\u003e Yes, BIP9 need to be adjusted (setting bit 30 means BIP9 counts it as a\n\u003e vote against all softforks). BIP101 uses bits 0,1,2 AFAICT, so perhaps\n\u003e start from the other end and use bit 29? We can bikeshed that later\n\u003e though...\n\u003e\n\u003e \u003e I agree with Jannes Faber, behavior with respect to SPV clients should be\n\u003e \u003e to only tell them about fully validated headers.\n\u003e\n\u003e A delicate balance. If we penalize these blocks too much, it's\n\u003e disincentive to set the bit. Fortunately it's easy for SPV clients to\n\u003e decide for themselves, I think?\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151205/4ed6a987/attachment.html\u003e",
"sig": "396df17858c978b829a2fcb95e9b461f9a879ccc60e550cf07bec0cf5f95507e308a2c7ff13bc42574fbe1be05796d48e2cff75570e58d5348875a9d39a6fb71"
}