Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-31 Thread Mike Hearn
On Wed, Oct 30, 2013 at 6:13 PM, Gregory Maxwell wrote: > If a node is using priority queued rate limiting for its relaying then > it might "accept" a transaction from you, but have it fall out of its > memory pool (due to higher priority txn arriving, or getting > restarted, etc.) before it ever

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-30 Thread Gregory Maxwell
On Sun, Oct 27, 2013 at 7:32 AM, Mike Hearn 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 then watches

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-30 Thread Mike Hearn
On Wed, Oct 30, 2013 at 10:05 AM, Mark Friedenbach 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. --

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-30 Thread Mark Friedenbach
-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 1:

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-30 Thread Mike Hearn
> 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

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-29 Thread Gavin Andresen
On Tue, Oct 29, 2013 at 10:32 PM, Mike Hearn 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, that's pretty muc

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-29 Thread Mike Hearn
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 secu

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-29 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Peter Todd 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 >> for nons

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-29 Thread Peter Todd
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? T

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-29 Thread Mike Hearn
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 a

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-29 Thread Peter Todd
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 lim

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-29 Thread Warren Togami Jr.
How about rejection codes to notify you that you have been rate limited? Warren On Mon, Oct 28, 2013 at 7:37 PM, Gavin Andresen wrote: > > Thanks for the feedback, everybody, gist updated: > https://gist.github.com/gavinandresen/7079034 > > Categories are: > > 0x01-0x0f Protocol syntax errors

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-28 Thread Gavin Andresen
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

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-28 Thread Gregory Maxwell
On Mon, Oct 28, 2013 at 2:26 AM, Andreas Schildbach 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 requirements. ---

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-28 Thread Andreas Schildbach
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

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-27 Thread Pieter Wuille
Categories that make sense to me: 1) protocol related problems 1.a) failed to deserialize transaction 2) core principle violations 2.a) script evaluation fail (only owner is allowed to spend) 2.b) outputs larger than inputs (no creation of new money) 2.c) outputs not found/already spent (no double

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-27 Thread Luke-Jr
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 applicabl

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-27 Thread kjj
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

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-27 Thread Gavin Andresen
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

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-27 Thread Mike Hearn
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 transactio

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-27 Thread Luke-Jr
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 > networ

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-27 Thread Mike Hearn
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 ac

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-25 Thread kjj
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 pos

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-25 Thread Gavin
On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman 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 n

Re: [Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-25 Thread Jean-Paul Kogelman
Would it make sense to use either fixed length strings or maybe even enums?On Oct 25, 2013, at 05:34 PM, Gavin Andresen 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" denial-of-service mitigati

[Bitcoin-development] Feedback requested: "reject" p2p message

2013-10-25 Thread Gavin Andresen
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" denial-of-service mitigation code was pull-requested). This came up again with my proposed "smartfee" changes, which would drop low-priority or low-fee t