@holiman @AlexeyAkhunov Here are test vectors for Keccak-f800 from Keccak Code Package: https://github.com/XKCP/XKCP/blob/master/tests/TestVectors/KeccakF-800-IntermediateValues.txt
I am sure it depends on client's implementation. EthereumJ has a gas price threshold for Tx mem pool, Txes with gas prices lower than that threshold just skipped. And there is nothing that would be done with the peer in that case. I think it worth to reduce peer's reputation if it sends tons of spam messages.
@djrtwo I just checked in geth. There is no penalisation. In this "case" clause at the link, you can see that the only place "p" (peer) is still associated with the transaction is the call to p.MarkTransaction(). And inside that MarkTransaction, it only adds tx ID to the set of max 32k transaction that the peer "knows about", so that we do not send them back to the same peer: https://github.com/ethereum/go-ethereum/blob/4b6824e07b1b7c5a2907143b4d122283eadb2474/eth/handler.go#L666
same for parity. I think. In the code under the link, you can see that peer_id is not passed into "import_external_transactions" (this is where txs get to the pool). In the "notify.transaction_received()" no penalisation happens either. https://github.com/paritytech/parity-ethereum/blob/cc963d42a06bcae2480cec657fa4b55a829fdaa6/ethcore/src/client/client.rs#L2099
just to share it around with other PegaSysers and make sure we have all the relevant information for the call
ah
it's this I guess...
If someone whats to review some "crypto" code I sending changes related to ProgPOW here: https://github.com/chfast/ethash/pulls
zoom link to follow
@/all Core devs meeting in a little less than 12 hours
Agenda for meeting: ethereum/pm#58
Videoconference Link: https://zoom.us/j/717504189
We will be having someone who has ran new benchmarks for EIP 1108: Reduce alt_bn128 precompile gas costs.
We will also be having the team behind ProgPoW on the call so we can all sync up with what various people have been doing to test, benchmark, and otherwise explore it.
Please look over EIP 1108 and think of any questions you have for the ProgPoW team.
Trying to get this merged: ethereum/EIPs#1375 . Clarifications regarding Skinny Create2 cc @vbuterin
0xff is a single byte, why would it have endianness?
Preliminary call notes are up, please PR additions and corrections, thanks! https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2047.md
I use https://ropsten-stats.parity.io/ for basic stats on Ropsten.
OK, you've settled on 4200000.
https://ropsten-stats.parity.io/ is helpful, it says the average block time is 12.89 sec. I used 14 sec in my math. If it is indeed 12.89 sec (not sure over what time horizon this is calculated), then it will be closer to ten days from now, not 11.
I said 14 sec based on https://ropsten.etherscan.io/chart/blocktime but there’s been a lot of variance lately
oh geez - that data is from 2017!
So yea if the block time is indeed ~12.9 secs, my math shows block 4.2M happening in 10.16 days
4242424 would actually come 6 to 7.5 days later than 4200000, so maybe 4200000 is better.
So I didn't mean to ask about endianness, but the PR in general, since you're the author of the eip
So, verifying that X behaves the same before destruction and after re-creation requires verifying the same condition for every external contract that X might reference. (This is essentially the same problem as when verifying behaviour of any non-"pure" code.)
(FTR, I'm not trying to contradict that this flexibility is useful. It does seem so, and indeed especially in state channels.)
