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] On soft-forks and hard-forks

2013-10-29 Thread Peter Todd
> On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd wrote: > > 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 ju

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