From: Mike Hearn <mike@plan99•net>
To: kjj <bitcoin-devel@jerviss•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Feedback requested: "reject" p2p message
Date: Sun, 27 Oct 2013 15:32:57 +0100 [thread overview]
Message-ID: <CANEZrP2dQT6Evgm0UwvSKdgVsSnb_VF6fovVo0n0eKDM5ARZpw@mail.gmail.com> (raw)
In-Reply-To: <526B45DB.2030200@jerviss.org>
[-- Attachment #1: Type: text/plain, Size: 3082 bytes --]
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 <bitcoin-devel@jerviss•org> 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
>
[-- Attachment #2: Type: text/html, Size: 4344 bytes --]
next prev parent reply other threads:[~2013-10-27 14:33 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 [this message]
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
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=CANEZrP2dQT6Evgm0UwvSKdgVsSnb_VF6fovVo0n0eKDM5ARZpw@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-devel@jerviss$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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