Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vb5yY-0005nx-CG for bitcoin-development@lists.sourceforge.net; Tue, 29 Oct 2013 09:52:38 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.169 as permitted sender) client-ip=209.85.214.169; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f169.google.com; Received: from mail-ob0-f169.google.com ([209.85.214.169]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Vb5yW-0003dI-Js for bitcoin-development@lists.sourceforge.net; Tue, 29 Oct 2013 09:52:38 +0000 Received: by mail-ob0-f169.google.com with SMTP id uz6so5007535obc.0 for ; Tue, 29 Oct 2013 02:52:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.36.133 with SMTP id q5mr1527602oej.63.1383040351168; Tue, 29 Oct 2013 02:52:31 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.156.42 with HTTP; Tue, 29 Oct 2013 02:52:31 -0700 (PDT) In-Reply-To: References: <274a1888-276c-4aa6-a818-68f548fbe0fa@me.com> <9DCDB8F6-E3B2-426B-A41E-087E66B3821A@gmail.com> <526B45DB.2030200@jerviss.org> <526DD18A.7060201@jerviss.org> Date: Tue, 29 Oct 2013 10:52:31 +0100 X-Google-Sender-Auth: YBYhROAlUablJs_McsGMlV5vpyk Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: multipart/alternative; boundary=089e01293f10d76ff604e9de2c08 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: doubleclick.net] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Vb5yW-0003dI-Js Cc: Bitcoin Development , Andreas Schildbach Subject: Re: [Bitcoin-development] Feedback requested: "reject" p2p message X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 09:52:38 -0000 --089e01293f10d76ff604e9de2c08 Content-Type: text/plain; charset=UTF-8 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 wrote: > > Thanks for the feedback, everybody, gist updated: > https://gist.github.com/gavinandresen/7079034 > > Categories are: > > 0x01-0x0f Protocol syntax errors0x10-0x1f Protocol semantic errors0x40-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 > > --089e01293f10d76ff604e9de2c08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For tx reject, should there be a code for "unknown ve= rsion"? That is, tx.nVersion > bestKnownVersion =3D=3D reject? In t= hat case 0x40 would become "non-standard transaction type". I thi= nk "unknown transaction type" is a bit vague. Or do we want new t= x messages to always be backwards compatible?

0x42 and 0x43 seems a bit similar to me. The sender knows wh= at fee was paid (presumably). If free transactions and fee-paying transacti= ons end up having a unified ranking applied, then distinguishing between th= em 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 nVersi= on field to people just using it for nonsense, so does it make sense to rej= ect 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 t= he feedback, everybody, gist updated:

Categories are:

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


RE: w= hy not a varint: =C2=A0because we're never ever going to run out of rej= ect codes. =C2=A0Eight 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 squar= e 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<= br> Android apps secure.
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D65839951&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e01293f10d76ff604e9de2c08--