{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-10-27\n📝 Original message:Yeah, something like HTTP would work well.\n\nI'm really looking forward to this. Currently bitcoinj gets a small but\nsteady stream of bug reports of the form \"my transaction did not\npropagate\". It's flaky because the library picks one peer to send the\ntransaction to, and then watches it propagate across the network. But if\nthat selected peer refuses the tx for whatever reason, that propagation\nnever comes, and there's currently no timeout to make it retry with a\ndifferent node. The transactions as created usually look fine, so it's not\nclear to me why some nodes would accept it others wouldn't given the\nabsence of double spends, and there's no way to debug and find out :(\n\n\n\n\nOn Sat, Oct 26, 2013 at 6:32 AM, kjj \u003cbitcoin-devel at jerviss.org\u003e wrote:\n\n\u003e The HTTP status code system seems to work well enough, and seems to give\n\u003e the best of both worlds.  A 3 digit numeric code that is\n\u003e machine-readable, and a freeform text note for humans.\n\u003e\n\u003e The clever part about that system was in realizing that the numeric\n\u003e codes didn't need to account for every possible error. They just need to\n\u003e give the other node the most useful information, like \"try that again\n\u003e later, I'm having a temporary problem\" vs. \"That is just plain wrong and\n\u003e it will still be wrong next time too, so don't bother to retry\".\n\u003e\n\u003e We can leave it to the humans to puzzle out the meaning of \"403: values\n\u003e of txid gives rise to dom!\"\n\u003e\n\u003e Gavin wrote:\n\u003e \u003e\n\u003e \u003e On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman \u003c\n\u003e jeanpaulkogelman at me.com\u003e wrote:\n\u003e \u003e\n\u003e \u003e\u003e Would it make sense to use either fixed length strings or maybe even\n\u003e enums?\n\u003e \u003e No. Enums or fixed length strings just make it harder to extend, for no\n\u003e benefit (bandwidth of 'reject' messages doesn't matter, they will be rare\n\u003e and are not relayed).\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e October Webinars: Code for Performance\n\u003e \u003e Free Intel webinars can help you accelerate application performance.\n\u003e \u003e Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most\n\u003e from\n\u003e \u003e the latest Intel processors and coprocessors. See abstracts and register\n\u003e \u003e\n\u003e \u003e\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=60135991\u0026iu=/4140/ostg.clktrk\n\u003e \u003e _______________________________________________\n\u003e \u003e Bitcoin-development mailing list\n\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e October Webinars: Code for Performance\n\u003e Free Intel webinars can help you accelerate application performance.\n\u003e Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most\n\u003e from\n\u003e the latest Intel processors and coprocessors. See abstracts and register \u003e\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=60135991\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131027/d02f8dde/attachment.html\u003e"}