Re: [Bitcoin-development] Feedback requested: reject p2p message
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 limiting rejection code is things like getblock and other requests. -- 'peter'[:-1]@petertodd.org aefda5391d2a12987ee8dc048c046c8f3e1ad1f1a3a1dbbe4954bfaf signature.asc Description: Digital signature -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
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 0x43 seems a bit similar to me. The sender knows what fee was paid (presumably). If free transactions and fee-paying transactions end up having a unified ranking applied, then distinguishing between them in the reject message won't make much sense. 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? On Tue, Oct 29, 2013 at 6:37 AM, Gavin Andresen gavinandre...@gmail.comwrote: Thanks for the feedback, everybody, gist updated: https://gist.github.com/gavinandresen/7079034 Categories are: 0x01-0x0f Protocol syntax errors0x10-0x1f Protocol semantic errors0x40-0x4fServer policy rule https://gist.github.com/gavinandresen/7079034#rejection-codes-common-to-all-message-types RE: why not a varint: because we're never ever going to run out of reject codes. Eight are defined right now, if we ever defined eight more I'd be surprised. RE: why not use HTTP codes directly: because we'd be fitting round pegs into square holes. -- -- Gavin Andresen -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
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 would prevent us from using nVersion as a soft-forking mechanism. -- 'peter'[:-1]@petertodd.org 000908fddb47210344de50e6d3bd842e649c688530390dcd signature.asc Description: Digital signature -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
-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 for nonsense, so does it make sense to reject blocks that claim to be v2 or v3? That would prevent us from using nVersion as a soft-forking mechanism. Actually, that statement didn't go far enough: rejecting blocks with nVersions that you don't expect is a hard fork. -BEGIN PGP SIGNATURE- Version: APG v1.0.9 iQFQBAEBCAA6BQJSb544MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfuGCADHB+5WZ3oSRCCYgId+ 5c4rxZHjjmXXIVOlXySjoRQ20JUnGbkUqN057VlutYbWaGV7OqR0oQyzh0LGpMdL BU9hg8XoHbyIvA0WhCfEJvFzkwseN8Ac77UxtV3leBpBkSzjqlMS9QBGU6L5rw2U uo8Sd7bQaqkadOPode3MMWDtmmqAZaj2dN02w/8C1rRna3SrbYRVYbaVAuN9yREO 99DOGEM2V7ni+eo4sQoxP2jf8vmNzy1EuQH8v1OloPgcpxl/GkLVXzQh4ZfO1ApE UVKBo93oT34Tce9LwZy+k8XpeCvBRJ/+QwsbAAgdVYKr8KmRcAW4oR2KN7Y0jjq4 44xU =OaON -END PGP SIGNATURE- -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
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 security model is problematic. On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd p...@petertodd.org wrote: -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 for nonsense, so does it make sense to reject blocks that claim to be v2 or v3? That would prevent us from using nVersion as a soft-forking mechanism. Actually, that statement didn't go far enough: rejecting blocks with nVersions that you don't expect is a hard fork. -BEGIN PGP SIGNATURE- Version: APG v1.0.9 iQFQBAEBCAA6BQJSb544MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhfuGCADHB+5WZ3oSRCCYgId+ 5c4rxZHjjmXXIVOlXySjoRQ20JUnGbkUqN057VlutYbWaGV7OqR0oQyzh0LGpMdL BU9hg8XoHbyIvA0WhCfEJvFzkwseN8Ac77UxtV3leBpBkSzjqlMS9QBGU6L5rw2U uo8Sd7bQaqkadOPode3MMWDtmmqAZaj2dN02w/8C1rRna3SrbYRVYbaVAuN9yREO 99DOGEM2V7ni+eo4sQoxP2jf8vmNzy1EuQH8v1OloPgcpxl/GkLVXzQh4ZfO1ApE UVKBo93oT34Tce9LwZy+k8XpeCvBRJ/+QwsbAAgdVYKr8KmRcAW4oR2KN7Y0jjq4 44xU =OaON -END PGP SIGNATURE- -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On soft-forks and hard-forks
On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd p...@petertodd.org wrote: 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 for nonsense, so does it make sense to reject blocks that claim to be v2 or v3? That would prevent us from using nVersion as a soft-forking mechanism. Actually, that statement didn't go far enough: rejecting blocks with nVersions that you don't expect is a hard fork. 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 security model is problematic. That's a nice sentiment, but there's a lot more nuance to it than soft-forks are bad We're talking about rejection here: you don't want to end up on an isolated chain fork wondering if maybe miners have been unlucky. You want to know that a longer chain exists so as to have solid evidence that you're local configuration isn't what miners are mining. Thus not only should you accept blocks with versions you don't know about, you should relay those blocks as well so that other out-of-date nodes have the highest possible chance of finding out about them. Creating a block is expensive, so with some minor safeguards - a high minimum difficulty, and maximum size - relaying blocks you consider invalid is perfectly safe and doesn't enable DoS attacks. Relaying block headers has similar logic, and even less DoS attack worry. (don't apply bloom filters to invalid blocks though!) I had this discussion with Warren the other day actually: Litecoin is considering banning old node versions and rejecting their attempts to connect. I pointed out how you wanted to be damn sure there was no-one mining with them, least you wind up creating a slowly growing fork mined by nodes unaware of the main chain. Soft-forks and SPV nodes is another topic. SPV nodes don't do any meaningful validation - they usually don't even have the transaction inputs spent by a transaction to determine if a scriptSig is valid. Their security is already dependent on miners, so allowing those miners to upgrade does no harm. In addition there are even cases where what would be a hard-fork for a full node, is a soft-fork for a SPV node. On the other hand if your SPV node is more sophisticated, then by all means use a nVersion change to trigger an alert to the user. If you're implementation relays blockchain data, continue doing so to ensure other nodes find out about the new version as soon as possible. (all SPV nodes should relay block headers if possible) Note how the nVersion field is useful for voting: the chain height in coinbase soft-fork was accomplished this way, changing nVersion from 1 to 2 with full enforcement of the rule triggered by a 95% supermajority. Bitcoin is a decentralized system, so any changes need to be done by voting to show that a clear consensus of hashing power will enforce and validate the new rules. (time and height deadlines can be disasters if the upgrade is ever ignored or delayed) Interestingly this suggests that what we actually want is two nVersions per upgrade: the first to signal that nodes wish to upgrade, and are showing their intent to use the new rules. The second to signal that the upgrade has actually happened and the old rules are now ignored. Client software can use this two stage approach to know when rules may have changed, and the user probably should consider upgrading. As applied to the chain height upgrade we would have gone from version 2 during the voting, to version 3 for any block produced while the rules were in effect. Put another way, the last in nVersion is simply to signify that the new blockchain rules are now active, as opposed to being proposed. -- 'peter'[:-1]@petertodd.org 000180dabf823b09a30b4f2032b5cab7ba1d0351cab350bee91f signature.asc Description: Digital signature -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
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, that's pretty much the whole purpose of Bitcoin's design. Undermining that security model is problematic. But if you are getting soft-forked recent versions of the reference implementation WILL alert you; see this code in main.cpp: if (nUpgraded 100/2) strMiscWarning = _(Warning: This version is obsolete, upgrade required!); That is, if more than half of the last 100 blocks are up-version, warn. block.version is part of the block header, so SPV clients can (and probably should) do the same. There are also warnings if you are forked, and, most recently, warnings if there is a high-work alternative fork. -- -- Gavin Andresen -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
