Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VaROq-0000XK-Rg for bitcoin-development@lists.sourceforge.net; Sun, 27 Oct 2013 14:33:04 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.51 as permitted sender) client-ip=209.85.219.51; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f51.google.com; Received: from mail-oa0-f51.google.com ([209.85.219.51]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VaROp-0005V9-2B for bitcoin-development@lists.sourceforge.net; Sun, 27 Oct 2013 14:33:04 +0000 Received: by mail-oa0-f51.google.com with SMTP id h1so2621288oag.38 for ; Sun, 27 Oct 2013 07:32:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.52.101 with SMTP id s5mr211801oeo.56.1382884377655; Sun, 27 Oct 2013 07:32:57 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.156.42 with HTTP; Sun, 27 Oct 2013 07:32:57 -0700 (PDT) In-Reply-To: <526B45DB.2030200@jerviss.org> References: <274a1888-276c-4aa6-a818-68f548fbe0fa@me.com> <9DCDB8F6-E3B2-426B-A41E-087E66B3821A@gmail.com> <526B45DB.2030200@jerviss.org> Date: Sun, 27 Oct 2013 15:32:57 +0100 X-Google-Sender-Auth: qLegQTQOF6ZH510viJwHBcOVWIU Message-ID: From: Mike Hearn To: kjj Content-Type: multipart/alternative; boundary=001a11330d5418805f04e9b9dcbe 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: 1VaROp-0005V9-2B Cc: Bitcoin Dev 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: Sun, 27 Oct 2013 14:33:05 -0000 --001a11330d5418805f04e9b9dcbe Content-Type: text/plain; charset=UTF-8 Yeah, something like HTTP would work well. I'm really looking forward to this. Currently bitcoinj gets a small but steady stream of bug reports of the form "my transaction did not propagate". It's flaky because the library picks one peer to send the transaction to, and then watches it propagate across the network. But if that selected peer refuses the tx for whatever reason, that propagation never comes, and there's currently no timeout to make it retry with a different node. The transactions as created usually look fine, so it's not clear to me why some nodes would accept it others wouldn't given the absence of double spends, and there's no way to debug and find out :( On Sat, Oct 26, 2013 at 6:32 AM, kjj wrote: > The HTTP status code system seems to work well enough, and seems to give > the best of both worlds. A 3 digit numeric code that is > machine-readable, and a freeform text note for humans. > > The clever part about that system was in realizing that the numeric > codes didn't need to account for every possible error. They just need to > give the other node the most useful information, like "try that again > later, I'm having a temporary problem" vs. "That is just plain wrong and > it will still be wrong next time too, so don't bother to retry". > > We can leave it to the humans to puzzle out the meaning of "403: values > of txid gives rise to dom!" > > Gavin wrote: > > > > On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman < > jeanpaulkogelman@me.com> wrote: > > > >> Would it make sense to use either fixed length strings or maybe even > enums? > > No. Enums or fixed length strings just make it harder to extend, for no > benefit (bandwidth of 'reject' messages doesn't matter, they will be rare > and are not relayed). > > > > > > > ------------------------------------------------------------------------------ > > October Webinars: Code for Performance > > Free Intel webinars can help you accelerate application performance. > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > > the latest Intel processors and coprocessors. See abstracts and register > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a11330d5418805f04e9b9dcbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, something like HTTP would work well.

<= div>I'm really looking forward to this. Currently bitcoinj gets a small= but steady stream of bug reports of the form "my transaction did not = propagate". It's flaky because the library picks one peer to send = the transaction to, and then watches it propagate across the network. But i= f that selected peer refuses the tx for whatever reason, that propagation n= ever comes, and there's currently no timeout to make it retry with a di= fferent node. The transactions as created usually look fine, so it's no= t clear to me why some nodes would accept it others wouldn't given the = absence of double spends, and there's no way to debug and find out :(




On Sat, Oct 26, 2013 at 6:32 AM, kjj <bitco= in-devel@jerviss.org> wrote:
The HTTP status code system seems to work we= ll enough, and seems to give
the best of both worlds. =C2=A0A 3 digit numeric code that is
machine-readable, and a freeform text note for humans.

The clever part about that system was in realizing that the numeric
codes didn't need to account for every possible error. They just need t= o
give the other node the most useful information, like "try that again<= br> later, I'm having a temporary problem" vs. "That is just plai= n wrong and
it will still be wrong next time too, so don't bother to retry".
We can leave it to the humans to puzzle out the meaning of "403: value= s
of txid gives rise to dom!"

Gavin wrote:
>
> On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman <jeanpaulkogelman@me.com> wrote:
>
>> Would it make sense to use either fixed length strings or maybe ev= en enums?
> No. Enums or fixed length strings just make it harder to extend, for n= o benefit (bandwidth of 'reject' messages doesn't matter, they = will be rare and are not relayed).
>
>
> ----------------------------------------------------------------------= --------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the mo= st from
> the latest Intel processors and coprocessors. See abstracts and regist= er >
> http://pubads.g.doubleclick.net= /gampad/clk?id=3D60135991&iu=3D/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-d= evelopment@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitco= in-development


---------------------------------------------------------------------------= ---
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most fr= om
the latest Intel processors and coprocessors. See abstracts and register &g= t;
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D60135991&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a11330d5418805f04e9b9dcbe--