* [Bitcoin-development] Feedback requested: "reject" p2p message @ 2013-10-26 0:34 Gavin Andresen 2013-10-26 1:01 ` Jean-Paul Kogelman 0 siblings, 1 reply; 27+ messages in thread From: Gavin Andresen @ 2013-10-26 0:34 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 845 bytes --] 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 transactions. In short, giving peers feedback about why their blocks or transactions are dropped or why they are being banned should help interoperability between different implementations, and will give SPV (simplified payment verification) clients feedback when their transactions are rejected due to insufficient priority or fees. See the gist for details, I'm looking for feedback and planning on implementing this before circling back to finish the 'smart fee' work: https://gist.github.com/gavinandresen/7079034 -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 1084 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-26 0:34 [Bitcoin-development] Feedback requested: "reject" p2p message Gavin Andresen @ 2013-10-26 1:01 ` Jean-Paul Kogelman 2013-10-26 2:00 ` Gavin 0 siblings, 1 reply; 27+ messages in thread From: Jean-Paul Kogelman @ 2013-10-26 1:01 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 468 bytes --] Would it make sense to use either fixed length strings or maybe even enums? On Oct 25, 2013, at 05:34 PM, Gavin Andresen <gavinandresen@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" 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 transactions. [-- Attachment #2.1: Type: text/html, Size: 573 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-26 1:01 ` Jean-Paul Kogelman @ 2013-10-26 2:00 ` Gavin 2013-10-26 4:32 ` kjj 0 siblings, 1 reply; 27+ messages in thread From: Gavin @ 2013-10-26 2:00 UTC (permalink / raw) To: Jean-Paul Kogelman; +Cc: Bitcoin Dev 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). ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-26 2:00 ` Gavin @ 2013-10-26 4:32 ` kjj 2013-10-27 14:32 ` Mike Hearn 2013-10-27 22:52 ` Gavin Andresen 0 siblings, 2 replies; 27+ messages in thread From: kjj @ 2013-10-26 4:32 UTC (permalink / raw) To: Gavin, Jean-Paul Kogelman; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-26 4:32 ` kjj @ 2013-10-27 14:32 ` Mike Hearn 2013-10-27 14:39 ` Luke-Jr 2013-10-30 17:13 ` Gregory Maxwell 2013-10-27 22:52 ` Gavin Andresen 1 sibling, 2 replies; 27+ messages in thread From: Mike Hearn @ 2013-10-27 14:32 UTC (permalink / raw) To: kjj; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-27 14:32 ` Mike Hearn @ 2013-10-27 14:39 ` Luke-Jr 2013-10-27 14:50 ` Mike Hearn 2013-10-30 17:13 ` Gregory Maxwell 1 sibling, 1 reply; 27+ messages in thread From: Luke-Jr @ 2013-10-27 14:39 UTC (permalink / raw) To: bitcoin-development; +Cc: kjj 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. 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. Sounds like the real bug is "BitcoinJ relies on good/servant behaviour from other nodes". Don't assume your random node isn't hostile. Handling a peer that doesn't relay your transaction for any reason (including if they lie to you about having done so) should be expected behaviour. Luke ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-27 14:39 ` Luke-Jr @ 2013-10-27 14:50 ` Mike Hearn 0 siblings, 0 replies; 27+ messages in thread From: Mike Hearn @ 2013-10-27 14:50 UTC (permalink / raw) To: Luke-Jr; +Cc: Bitcoin Dev, kjj [-- Attachment #1: Type: text/plain, Size: 1402 bytes --] 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 transactions are being rejected due to a change in network rules that won't help either - if the nodes you're connected to are silently eating your transaction, there's no sane UI that can result from that without more explicit error handling. On Sun, Oct 27, 2013 at 3:39 PM, Luke-Jr <luke@dashjr•org> wrote: > 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. 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. > > Sounds like the real bug is "BitcoinJ relies on good/servant behaviour from > other nodes". Don't assume your random node isn't hostile. Handling a peer > that doesn't relay your transaction for any reason (including if they lie > to > you about having done so) should be expected behaviour. > > Luke > [-- Attachment #2: Type: text/html, Size: 1914 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-27 14:32 ` Mike Hearn 2013-10-27 14:39 ` Luke-Jr @ 2013-10-30 17:13 ` Gregory Maxwell 2013-10-31 12:01 ` Mike Hearn 1 sibling, 1 reply; 27+ messages in thread From: Gregory Maxwell @ 2013-10-30 17:13 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, kjj On Sun, Oct 27, 2013 at 7:32 AM, Mike Hearn <mike@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 then watches it propagate across the network. But if that selected peer > refuses the tx for whatever reason, that propagation never comes, and Actually, we'll probably need to explicitly document that a failure to reject is by no means a promise to forward. 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 gets a chance to send it on to any other peers. Finding out that it rejected is still useful information, but even assuming all nodes are honest and well behaved I don't think you could count on its absence to be sure of forwarding. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-30 17:13 ` Gregory Maxwell @ 2013-10-31 12:01 ` Mike Hearn 0 siblings, 0 replies; 27+ messages in thread From: Mike Hearn @ 2013-10-31 12:01 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev, kjj [-- Attachment #1: Type: text/plain, Size: 1323 bytes --] On Wed, Oct 30, 2013 at 6:13 PM, Gregory Maxwell <gmaxwell@gmail•com> 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 gets a chance to send it on to any > other peers. > That's a good point, however, I would hope that this fairly trivial race condition can be resolved. There's no requirement that a transaction be placed into a buffer from which it can be removed before relaying. After relaying - sure. But the gap of a few seconds between that shouldn't cause any issues to eliminate. I believe Gavin's smartfees branch adds mempool persistence to disk, so restarting nodes won't clear the mempool in future. Or at least that's a part of the longer term plan once mempool limiting is done. > Finding out that it rejected is still useful information, but even > assuming all nodes are honest and well behaved I don't think you could > count on its absence to be sure of forwarding. > I think measuring propagation will be a part of bitcoin wallets for the forseeable future, although if all nodes reject that allows for a more responsive and more helpful UI than just waiting for some arbitrary timeout to elapse. [-- Attachment #2: Type: text/html, Size: 1946 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-26 4:32 ` kjj 2013-10-27 14:32 ` Mike Hearn @ 2013-10-27 22:52 ` Gavin Andresen 2013-10-28 2:52 ` kjj ` (2 more replies) 1 sibling, 3 replies; 27+ messages in thread From: Gavin Andresen @ 2013-10-27 22:52 UTC (permalink / raw) To: kjj; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 487 bytes --] 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 quickly. 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.... -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 625 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-27 22:52 ` Gavin Andresen @ 2013-10-28 2:52 ` kjj 2013-10-28 9:26 ` Andreas Schildbach 2013-10-28 2:59 ` Luke-Jr 2013-10-28 3:02 ` Pieter Wuille 2 siblings, 1 reply; 27+ messages in thread From: kjj @ 2013-10-28 2:52 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1670 bytes --] 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 a string or varstring here; we already have a text field. Varint vs. 16 bits is a minor issue, and arguments can be made in both directions. I flipped a coin and got heads, so I'll say varint. Gavin Andresen wrote: > 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 quickly. > > 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.... > > > -- > -- > Gavin Andresen > > > ------------------------------------------------------------------------------ > 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: 2928 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-28 2:52 ` kjj @ 2013-10-28 9:26 ` Andreas Schildbach 2013-10-28 9:32 ` Gregory Maxwell 0 siblings, 1 reply; 27+ messages in thread From: Andreas Schildbach @ 2013-10-28 9:26 UTC (permalink / raw) To: bitcoin-development 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 > 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 a string or varstring > here; we already have a text field. Varint vs. 16 bits is a minor > issue, and arguments can be made in both directions. I flipped a coin > and got heads, so I'll say varint. > > Gavin Andresen wrote: >> 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 quickly. >> >> 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.... >> >> >> -- >> -- >> Gavin Andresen >> >> >> ------------------------------------------------------------------------------ >> 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 > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-28 9:26 ` Andreas Schildbach @ 2013-10-28 9:32 ` Gregory Maxwell 2013-10-29 5:37 ` Gavin Andresen 0 siblings, 1 reply; 27+ messages in thread From: Gregory Maxwell @ 2013-10-28 9:32 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Development On Mon, Oct 28, 2013 at 2:26 AM, Andreas Schildbach <andreas@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 requirements. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 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:52 ` Mike Hearn 0 siblings, 2 replies; 27+ messages in thread From: Gavin Andresen @ 2013-10-29 5:37 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 576 bytes --] 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> 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 [-- Attachment #2: Type: text/html, Size: 2240 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 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 1 sibling, 1 reply; 27+ messages in thread From: Warren Togami Jr. @ 2013-10-29 8:55 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Development, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 1395 bytes --] 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 <gavinandresen@gmail•com>wrote: > > 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=65839951&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: 3729 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-29 8:55 ` Warren Togami Jr. @ 2013-10-29 9:12 ` Peter Todd 0 siblings, 0 replies; 27+ messages in thread From: Peter Todd @ 2013-10-29 9:12 UTC (permalink / raw) To: Warren Togami Jr.; +Cc: Andreas Schildbach, Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 473 bytes --] 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 00000000aefda5391d2a12987ee8dc048c046c8f3e1ad1f1a3a1dbbe4954bfaf [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 685 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-29 5:37 ` Gavin Andresen 2013-10-29 8:55 ` Warren Togami Jr. @ 2013-10-29 9:52 ` Mike Hearn 2013-10-29 10:14 ` Peter Todd 1 sibling, 1 reply; 27+ messages in thread From: Mike Hearn @ 2013-10-29 9:52 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Development, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 2097 bytes --] 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 <gavinandresen@gmail•com>wrote: > > 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=65839951&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: 4540 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-29 9:52 ` Mike Hearn @ 2013-10-29 10:14 ` Peter Todd 2013-10-29 11:38 ` Peter Todd 0 siblings, 1 reply; 27+ messages in thread From: Peter Todd @ 2013-10-29 10:14 UTC (permalink / raw) To: Mike Hearn; +Cc: Andreas Schildbach, Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 477 bytes --] 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 000000000000000908fddb47210344de50e6d3bd842e649c68853eeee0390dcd [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 685 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-29 10:14 ` Peter Todd @ 2013-10-29 11:38 ` Peter Todd 2013-10-29 12:32 ` Mike Hearn 0 siblings, 1 reply; 27+ messages in thread From: Peter Todd @ 2013-10-29 11:38 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Development, Andreas Schildbach -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Peter Todd <pete@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----- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 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 0 siblings, 2 replies; 27+ messages in thread From: Mike Hearn @ 2013-10-29 12:32 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Development, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 1597 bytes --] 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 <pete@petertodd•org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > Peter Todd <pete@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----- > > [-- Attachment #2: Type: text/html, Size: 2139 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] On soft-forks and hard-forks 2013-10-29 12:32 ` Mike Hearn @ 2013-10-29 16:35 ` Peter Todd 2013-10-30 2:01 ` [Bitcoin-development] Feedback requested: "reject" p2p message Gavin Andresen 1 sibling, 0 replies; 27+ messages in thread From: Peter Todd @ 2013-10-29 16:35 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Development, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 4311 bytes --] > On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd <pete@petertodd•org> wrote: > > Peter Todd <pete@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 000000000000000180dabf823b09a30b4f2032b5cab7ba1d0351cab350bee91f [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 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 ` Gavin Andresen 2013-10-30 8:24 ` Mike Hearn 1 sibling, 1 reply; 27+ messages in thread From: Gavin Andresen @ 2013-10-30 2:01 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Development, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 965 bytes --] On Tue, Oct 29, 2013 at 10:32 PM, Mike Hearn <mike@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 [-- Attachment #2: Type: text/html, Size: 1493 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 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 0 siblings, 1 reply; 27+ messages in thread From: Mike Hearn @ 2013-10-30 8:24 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Development, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 998 bytes --] > 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 don't upgrade you rely on the miner majority to get you "back on track". For instance, P2SH was done this way - old nodes that didn't upgrade during that transition believed all spends of P2SH outputs were valid, even those spending someone elses coins. In this case, the code you cite won't do anything because your client will never reject a block during a soft-forking upgrade, even if it does something that's supposed to be invalid or nonsensical. If a new block version changes the serialization format or script language or SIGHASH rules such that old clients reject the block, then they will end up on a hard fork and the alerting code will trigger, which is correct and as it should be. [-- Attachment #2: Type: text/html, Size: 1403 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-30 8:24 ` Mike Hearn @ 2013-10-30 9:05 ` Mark Friedenbach 2013-10-30 10:26 ` Mike Hearn 0 siblings, 1 reply; 27+ messages in thread From: Mark Friedenbach @ 2013-10-30 9:05 UTC (permalink / raw) To: bitcoin-development -----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:24 AM, Mike Hearn wrote: > > 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 don't upgrade you rely on the > miner majority to get you "back on track". For instance, P2SH was > done this way - old nodes that didn't upgrade during that > transition believed all spends of P2SH outputs were valid, even > those spending someone elses coins. > > In this case, the code you cite won't do anything because your > client will never reject a block during a soft-forking upgrade, > even if it does something that's supposed to be invalid or > nonsensical. > > If a new block version changes the serialization format or script > language or SIGHASH rules such that old clients reject the block, > then they will end up on a hard fork and the alerting code will > trigger, which is correct and as it should be. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJScMvBAAoJEAdzVfsmodw4I5sQAL0Wq4e7b6/KX2zl9RmtFl5S qM9ZJkJV8qzirj1hMgVwvnuOj147Vb3EkJujxeMa8ujepXKZ215mMCLnCHPzWPpJ jTtOBn1FCkCUbyt9uSbZ+56NR+ElmSOsDpAJ8IR9VywHriCxm4OIAMCLTR6CKRfr 6NWySvjEMlsSHyr7DFaJTlMqo+KIUWGmP7tdPu1L2AvNE+613dI5q76IjUHYoxhu 2dDtanYUvFCsdLZEnjTr1N45BBf1mTSlPfmA1ZWHgM779h6VIyb0TeO+iCaxpvWp 2RpSDj3+diFdMUK2uu69ZcwkREH0/RoQLOys6U5DfaGkpPtjY0YXB5DwN9quKgzX padWzbQ0flpwWLYOPYrWATz4sWflxZJu6wHAcUkRS5k9crOLVjritXs1205x7YET 0H9jtbqXmBRXidCP2BOZPdq0PGDF8g2VeEHR69JRe3F3dBfSvbgHfKoiF1jpLLqb rttoP+nD4ZRX8FesV2E/DEZgDZJMd8eqDKNDjq7Db4BTDg24Nq2ATNE2fBtenXwI nXVNdmnvjDxjF0weJGlYgaQTfgVwHRxs+j4qgY4VLM0qEYplhHgg+KmOMFUtxAF/ sZv6w56XtCZS3LdNONAJSZzXIcqgmcodiWKVxkTL29dsWKikcBL5cG9ipdfmjQKT eccFOHArsbW3eSfKP/Mb =FSQI -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-30 9:05 ` Mark Friedenbach @ 2013-10-30 10:26 ` Mike Hearn 0 siblings, 0 replies; 27+ messages in thread From: Mike Hearn @ 2013-10-30 10:26 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 251 bytes --] On Wed, Oct 30, 2013 at 10:05 AM, Mark Friedenbach <mark@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. [-- Attachment #2: Type: text/html, Size: 571 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-27 22:52 ` Gavin Andresen 2013-10-28 2:52 ` kjj @ 2013-10-28 2:59 ` Luke-Jr 2013-10-28 3:02 ` Pieter Wuille 2 siblings, 0 replies; 27+ messages in thread From: Luke-Jr @ 2013-10-28 2:59 UTC (permalink / raw) To: bitcoin-development 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. https://en.bitcoin.it/wiki/BIP_0022#Appendix:_Example_Rejection_Reasons Luke ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Bitcoin-development] Feedback requested: "reject" p2p message 2013-10-27 22:52 ` Gavin Andresen 2013-10-28 2:52 ` kjj 2013-10-28 2:59 ` Luke-Jr @ 2013-10-28 3:02 ` Pieter Wuille 2 siblings, 0 replies; 27+ messages in thread From: Pieter Wuille @ 2013-10-28 3:02 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev, kjj [-- Attachment #1: Type: text/plain, Size: 1588 bytes --] 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 spending) 3) policy rules 3.a) not standard 3.b) ... -- Pieter On Oct 27, 2013 11:54 PM, "Gavin Andresen" <gavinandresen@gmail•com> wrote: > 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 quickly. > > 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.... > > > -- > -- > Gavin Andresen > > > ------------------------------------------------------------------------------ > 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: 2330 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2013-10-31 12:01 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-10-26 0:34 [Bitcoin-development] Feedback requested: "reject" p2p message 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox