Re: [Bitcoin-development] Newly introduced DoS

2011-09-27 Thread Gavin Andresen
> @@ -1276,13 +1278,13 @@ bool CBlock::AcceptBlock() >     // Get prev block index >     map::iterator mi = > mapBlockIndex.find(hashPrevBlock); >     if (mi == mapBlockIndex.end()) > -        return error("AcceptBlock() : prev block not found"); > +        return DoS(10, error("AcceptBlock() : pre

Re: [Bitcoin-development] Newly introduced DoS

2011-09-27 Thread Gregory Maxwell
On Tue, Sep 27, 2011 at 4:08 PM, Luke-Jr wrote: > Is it certain that it cannot be triggered by a peer having some huge number > more blocks than you? Might be better to have a global flag that indicates when the node thinks its current with the network (this could have other UI impacts, like lett

Re: [Bitcoin-development] Newly introduced DoS

2011-09-27 Thread Luke-Jr
What about this one? @@ -1276,13 +1278,13 @@ bool CBlock::AcceptBlock() // Get prev block index map::iterator mi = mapBlockIndex.find(hashPrevBlock); if (mi == mapBlockIndex.end()) -return error("AcceptBlock() : prev block not found"); +return DoS(10, error("AcceptB

Re: [Bitcoin-development] Newly introduced DoS

2011-09-26 Thread Gavin Andresen
> It's not future. It's presently allowed in blocks. Which means it's perfectly > valid to relay (and also perfectly value to NOT relay or accept). Ergo, > shouldn't be punished. You're absolutely right. And you're right about the 99 confirmations, too-- I was thinking blocks again, not transacti

Re: [Bitcoin-development] Newly introduced DoS

2011-09-26 Thread theymos
On Monday, September 26, 2011 5:53 PM, "Luke-Jr" wrote: > It's not future. It's presently allowed in blocks. Which means it's > perfectly valid to relay (and also perfectly value to NOT relay or > accept). Ergo, shouldn't be punished. Yeah, my node has always relayed these transactions. The limit

Re: [Bitcoin-development] Newly introduced DoS

2011-09-26 Thread Luke-Jr
On Monday, September 26, 2011 5:38:41 PM Gavin Andresen wrote: > > The first one I was referring to is a *transaction* with "non-standard" > > sig op count, which is AFAIK allowed in blocks, just not accepted by the > > mainline rules. > > I sit corrected. The context is: > // Checking ECDSA s

Re: [Bitcoin-development] Newly introduced DoS

2011-09-26 Thread Gavin Andresen
> The first one I was referring to is a *transaction* with "non-standard" sig op > count, which is AFAIK allowed in blocks, just not accepted by the mainline > rules. I sit corrected. The context is: // Checking ECDSA signatures is a CPU bottleneck, so to avoid denial-of-service // attacks

Re: [Bitcoin-development] Newly introduced DoS

2011-09-26 Thread Luke-Jr
On Monday, September 26, 2011 4:47:06 PM Gavin Andresen wrote: > On Mon, Sep 26, 2011 at 3:17 PM, Luke-Jr wrote: > > +return DoS(10, error("AcceptToMemoryPool() : transaction with > > out-of- bounds SigOpCount")); > > +return DoS(10, error("ConnectInputs() : tried t

Re: [Bitcoin-development] Newly introduced DoS

2011-09-26 Thread Gavin Andresen
On Mon, Sep 26, 2011 at 3:17 PM, Luke-Jr wrote: > +        return DoS(10, error("AcceptToMemoryPool() : transaction with out-of- > bounds SigOpCount")); > +                        return DoS(10, error("ConnectInputs() : tried to > spend coinbase at depth %d", pindexBlock->nHeight - pindex->nHeight

[Bitcoin-development] Newly introduced DoS

2011-09-26 Thread Luke-Jr
+return DoS(10, error("AcceptToMemoryPool() : transaction with out-of- bounds SigOpCount")); +return DoS(10, error("ConnectInputs() : tried to spend coinbase at depth %d", pindexBlock->nHeight - pindex->nHeight)); +return DoS(10, error("AcceptBlock() : prev