From: Mike Hearn <mike@plan99•net>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>,
Andreas Schildbach <andreas@schildbach•de>
Subject: Re: [Bitcoin-development] Feedback requested: "reject" p2p message
Date: Tue, 29 Oct 2013 10:52:31 +0100 [thread overview]
Message-ID: <CANEZrP1teOnb=Gt_Nybh0jfQopK06Ps34Hy73OxOpHwuz-iZig@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T3p6KFc8FiOgBwLtQsmkETE_iUbMhO47pS7J3hi3a9_4w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]
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 errors0x10-0x1f Protocol semantic errors0x40-0x4fServer
> policy rule
> <https://gist.github.com/gavinandresen/7079034#rejection-codes-common-to-all-message-types>
>
> 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
>
>
[-- Attachment #2: Type: text/html, Size: 4540 bytes --]
next prev parent reply other threads:[~2013-10-29 9:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-26 0:34 Gavin Andresen
2013-10-26 1:01 ` Jean-Paul Kogelman
2013-10-26 2:00 ` Gavin
2013-10-26 4:32 ` kjj
2013-10-27 14:32 ` Mike Hearn
2013-10-27 14:39 ` Luke-Jr
2013-10-27 14:50 ` Mike Hearn
2013-10-30 17:13 ` Gregory Maxwell
2013-10-31 12:01 ` Mike Hearn
2013-10-27 22:52 ` Gavin Andresen
2013-10-28 2:52 ` kjj
2013-10-28 9:26 ` Andreas Schildbach
2013-10-28 9:32 ` Gregory Maxwell
2013-10-29 5:37 ` Gavin Andresen
2013-10-29 8:55 ` Warren Togami Jr.
2013-10-29 9:12 ` Peter Todd
2013-10-29 9:52 ` Mike Hearn [this message]
2013-10-29 10:14 ` Peter Todd
2013-10-29 11:38 ` Peter Todd
2013-10-29 12:32 ` Mike Hearn
2013-10-29 16:35 ` [Bitcoin-development] On soft-forks and hard-forks Peter Todd
2013-10-30 2:01 ` [Bitcoin-development] Feedback requested: "reject" p2p message Gavin Andresen
2013-10-30 8:24 ` Mike Hearn
2013-10-30 9:05 ` Mark Friedenbach
2013-10-30 10:26 ` Mike Hearn
2013-10-28 2:59 ` Luke-Jr
2013-10-28 3:02 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP1teOnb=Gt_Nybh0jfQopK06Ps34Hy73OxOpHwuz-iZig@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox