But if you are getting soft-forked recent versions of the reference
implementation WILL alert you; see this code in main.cpp:
Perhaps I'm confused about how we're using the term soft fork. My
understanding is that this is where a new upgrade is designed to look valid
to old nodes, and if you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If I understand the code correctly, it's not about rejecting blocks.
It's about noticing that 50% of recent blocks are declaring a version
number that is meaningless to you. Chances are, there's been a soft
fork and you should upgrade.
On 10/30/13
On Wed, Oct 30, 2013 at 10:05 AM, Mark Friedenbach m...@monetize.io wrote:
If I understand the code correctly, it's not about rejecting blocks.
I was referring to the fork alerts that Matt did. They also alert you if
there's a missed upgrade.
On Sun, Oct 27, 2013 at 7:32 AM, Mike Hearn m...@plan99.net wrote:
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
On Mon, Oct 28, 2013 at 10:55:59PM -1000, Warren Togami Jr. wrote:
How about rejection codes to notify you that you have been rate limited?
ACK
However note that for the rejection messages defined these are actually
covered by the too-low-fees rejection codes. What would would want a
rate
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
On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:
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?
That
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Peter Todd p...@petertodd.org wrote:
On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:
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
Yes, exactly. That's the point. As you well know I think the whole
soft-fork mechanism is wrong and should not be used. If the rules change,
your node is *supposed* to end up on a chain fork and trigger an alert to
you, that's pretty much the whole purpose of Bitcoin's design. Undermining
that
On Tue, Oct 29, 2013 at 10:32 PM, Mike Hearn m...@plan99.net wrote:
Yes, exactly. That's the point. As you well know I think the whole
soft-fork mechanism is wrong and should not be used. If the rules change,
your node is *supposed* to end up on a chain fork and trigger an alert to
you,
HTTP also defines success codes (2xx). Are we also talking about ACK
messages now, rather than just REJECT messages?
On 10/28/2013 03:52 AM, kjj wrote:
Any reason not to use actual HTTP codes? I'm not aware of any major
deficiency in them. Most of them won't apply to us, which is fine, they
On Mon, Oct 28, 2013 at 2:26 AM, Andreas Schildbach
andr...@schildbach.de wrote:
HTTP also defines success codes (2xx). Are we also talking about ACK
messages now, rather than just REJECT messages?
I do not believe we should do that: It would be a non-trivial
increase the protocol bandwidth
Thanks for the feedback, everybody, gist updated:
https://gist.github.com/gavinandresen/7079034
Categories are:
0x01-0x0fProtocol syntax errors0x10-0x1fProtocol semantic errors0x40-0x4fServer
policy rule
https://gist.github.com/gavinandresen/7079034#rejection-codes-common-to-all-message-types
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
On Sunday, October 27, 2013 2:32:57 PM Mike Hearn wrote:
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.
These nodes are much more likely to just be broken than malicious, but
without any way to diagnose why they are dropping a transaction it's hard
to find out what's really going on.
Anyway, yes, I need to spend time adding timeouts and all kinds of other
things, although of course if the
RE: use HTTP-like status codes:
Okey dokey, I'll add a one-byte machine-readable HTTP-like status code.
Unless y'all want a 32-bit status code. Or maybe a varint. Or a
three-character numeric string. I really and truly don't care, but I am
writing this code right now so whatever you want, decide
Any reason not to use actual HTTP codes? I'm not aware of any major
deficiency in them. Most of them won't apply to us, which is fine, they
don't seem to apply to HTTP either. We can extend the scheme on our own
if we find a good reason to.
That implies 16 bits, or a varint. I would avoid
On Sunday, October 27, 2013 10:52:25 PM Gavin Andresen wrote:
If anybody has strong feelings about what the reject categories should be,
then please take the time to write a specific list, I can't read your
mind
It might make sense to use the rejection reasons from BIP 22 where applicable.
Would it make sense to use either fixed length strings or maybe even enums?On Oct 25, 2013, at 05:34 PM, Gavin Andresen gavinandre...@gmail.com wrote:Mike Hearn has been lobbying for an "error" message in the Bitcoin p2p protocol for years (at least since the "ban peers if they send us garbage"
On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman jeanpaulkogel...@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
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
22 matches
Mail list logo
