Re: [bitcoin-dev] Blockchain verification flag (BIP draft)
On Sun, Dec 6, 2015 at 2:47 AM, James Hilliard via bitcoin-dev wrote: > 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. An interesting potential use for the flag suggested in this draft would be allowing non-monotone mining for non-verified blocks. I could add a recommendation for that as well. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Blockchain verification flag (BIP draft)
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@lists.linuxfoundation.org> wrote: > Gavin Andresen via bitcoin-dev > 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@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] Blockchain verification flag (BIP draft)
On Fri, Dec 4, 2015 at 10:43 PM, Rusty Russell wrote: >> 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? I think this is orthogonal: You should only tell SPV clients* about blocks you've fully validated yourself. The bit in the header doesn't matter with respect to that. (Effectively, the wallet risk model gets as input the fact that they got given the block in the first place as well as the flag where the miner said they were validating things or not.) Whatever the ideal behavior is for network nodes towards lite clients; it's insanely cheap to just spin up a lot of 'nodes' that have arbitrary behavior; so it shouldn't be relied on too much; but absolutely they should be filtering to things they've verified themselves... unlike the mining case, there is no reason not to. [Specific attacks to consider: You get a broken miner to include both your payment, and some invalid transaction. Other miners extend it without verifying. To avoid the fact that nodes sensibly filter invalid blocks from their lite clients, you simply just run a lot of 'nodes' so that virtually every lite client has a connection to you] (More specifically, peers should be able to specify that they want to know about pre-validated blocks and you should be able to fetch blocks from them which haven't been validated... but no one should get fed unverified blocks by surprise.) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Blockchain verification flag (BIP draft)
Gavin Andresen via bitcoin-dev 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
