For tx reject, should there be a code for "unknown version"? That is, tx.nVersion > bestKnownVersion == reject? In that case 0x40 would become "non-standard transaction type". I think "unknown transaction type" is a bit vague. Or do we want new tx messages to always be backwards compatible?

0x42 and 0x43 seems a bit similar to me. The sender knows what fee was paid (presumably). If free transactions and fee-paying transactions end up having a unified ranking applied, then distinguishing between them in the reject message won't make much sense.

For block 0x11 again shall there be a separate code for "block is from the future"? We don't want to lose the nVersion field to people just using it for nonsense, so does it make sense to reject blocks that claim to be v2 or v3?




On Tue, Oct 29, 2013 at 6:37 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:

Thanks for the feedback, everybody, gist updated:
  https://gist.github.com/gavinandresen/7079034

Categories are:

0x01-0x0f Protocol syntax errors
0x10-0x1f Protocol semantic errors
0x40-0x4fServer policy rule


RE: why not a varint:  because we're never ever going to run out of reject codes.  Eight are defined right now, if we ever defined eight more I'd be surprised.

RE: why not use HTTP codes directly: because we'd be fitting round pegs into square holes.

--
--
Gavin Andresen

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development