Eh?
I'm suggesting a change to bitcoind that would speed things up.
My comment included the fact that most bitcoind's have most of the transactions that they receive each time they receive a new block.
The problem is that when a node receives a new block, it gets a copy of every transaction in the block and verifies every transaction in the block.
It, however, already has most if not all but one of the transactions in the block, and I'm not sure why the transactions in the memory pool are not verified enough to match the verification applied to the txns in the block.
The network latency of sending around a block is the exact reason I've suggested this before and again here.
none of that changes the fact that it's going to be at an inherent disadvantage vs most pools, that'll have 100's of open connections.
http://blockchain.info/inv/00000000000004522cf2395cfdb85d268a393b781cba2217ce25a29e2f3921c909/14/12 18:35:47 ThreadRPCServer method=submitblock
09/14/12 18:35:48 SetBestChain: new best=00000000000004522cf2 height=198785 work=479119430009406564588 date=09/14/12 18:35:28
09/14/12 18:35:48 ProcessBlock: ACCEPTED
my US IP then received and processed it at 18:35:48, my kimsufi received it at 18:35:49, but didnt finish processing it until 18:35:53
my p2pool server reports
http://nogleg.com:9332/static/share.html#00000000000004522cf2395cfdb85d268a393b781cba2217ce25a29e2f3921c9this was solved by someone in russia. it was relayed to me by a node in slovenia. i have 60ms ping time to this russian domain, 40ms to slovenia.
hence 'addnode'
(ed: i never messed with addnodes myself until i started using p2pool, pretty easy to recognize that things would propagate slower when most ppl are running bitcoind with probably 8 connections, seems to me like faster processing time would benefit the person with 500 open connections even moreso.. btcguild has weird propagation, seems slow to me. i dont think that would have had a chance vs a slush, deepbit, emc, etc block)
