Re: [Bitcoin-development] Payment protocol for onion URLs.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Oct 26, 2013 at 3:31 AM, Gregory Maxwell wrote: > One limitation of the payment protocol as speced is that there is no > way for a hidden service site to make use of its full authentication > capability because they are unable to get SSL certificates issued to > them. > > Thoughts? I think this is a great idea and wish to see it done. Here is 1BTC for you, redeemable when you finish this task. I trust either Jeff Garzik or Peter Todd to evaluate your finished product, or possibly someone elses: 37NDa6iFLEozbvw8vj38ri5D6SLw5xQujS 22e067d3317e6300a9edda84fd0e24d8bfb86cf91540c3fe7acff45e4dc64dd3:0 redeemScript : "5241045f4bba15dbfe94a45f362aa13bbaef8bbf21ff84fec1be5b27fa628f4b3acca1a2e5711503c8b8fe2e228229b8b8814f9e33e0f7a314a089d7140269ffd51fe44104d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e71417834104f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce453ae" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJSbfy2AAoJEEWCsU4mNhiPrMMH/jd+AgVYUKd1vmP1BfaZum1s X186JulwF659YHOx94dLs+NOjvjMfY6cPbHm+B0j20CnhWrZrXzcXvwTHnzOSuoc 1AAXg0KDbvyo+7PvTrsGQfHhT1FZSRzIUToofVmFlvEIO6/LiYMAYWCgIiX9nPvv RlvdtavTST+cY19yZamo5X0XU5cgI2tbtVWKEHJQ2VcglCgwFg5K0kZ0O1NMKbcZ KBagY3PVTiHnYP+LwSTW6EU9DNq0eLYG39mz4N6CqGkXZjGgh2YXZ6Sl2qRuO/5e Rd9HcJXKqPKqMuRpQ2PA5U3U6QSyrUz7/fmi5dsOxnR6pdR53kjUVSvbOqBFHXw= =I1/R -END PGP SIGNATURE- -- 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
Re: [Bitcoin-development] Feedback requested: "reject" p2p message
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" 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
Re: [Bitcoin-development] Feedback requested: "reject" p2p message
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 -- 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
Re: [Bitcoin-development] Feedback requested: "reject" p2p message
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
Re: [Bitcoin-development] Feedback requested: "reject" p2p message
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
Re: [Bitcoin-development] Advisory: PHP library Bitcoin SCI weak key generation
That's correct. There's no source control so I've mirrored the weak functions. The MiniKey function: http://pastie.org/8435726 The PrivKey function: http://pastie.org/8435731 > Date: Mon, 28 Oct 2013 08:46:34 +1000 > Subject: Re: [Bitcoin-development] Advisory: PHP library Bitcoin SCI > weak key generation > From: gavinandre...@gmail.com > To: a86...@outlook.com > CC: bitcoin-development@lists.sourceforge.net > > Thanks for the warning; to be clear, "the Bitcoin SCI library" is this > project? >http://bitfreak.info/index.php?page=tools&t=bitsci > > > On Mon, Oct 28, 2013 at 8:25 AM, Andres Home > mailto:a86...@outlook.com>> wrote: > For those developers who are using the Bitcoin SCI library (maybe > others too, I > found two total and could only make contact with one), I would advise > that you > review how your software handles private key creation. > > -- > -- > 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
Re: [Bitcoin-development] Advisory: PHP library Bitcoin SCI weak key generation
Thanks for the warning; to be clear, "the Bitcoin SCI library" is this project? http://bitfreak.info/index.php?page=tools&t=bitsci On Mon, Oct 28, 2013 at 8:25 AM, Andres Home wrote: > For those developers who are using the Bitcoin SCI library (maybe others > too, I > found two total and could only make contact with one), I would advise that > you > review how your software handles private key creation. > -- > -- 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
[Bitcoin-development] Advisory: PHP library Bitcoin SCI weak key generation
For those developers who are using the Bitcoin SCI library (maybe others too, I found two total and could only make contact with one), I would advise that you review how your software handles private key creation. Up until today, the Bitcoin SCI library used the Mersenne Twister PRNG or the GMP library's PRNG directly to generate private keys. This has been somewhat resolved in the most recent version (October 27th), but only for the createNewMiniKey() function. Even if you haven't been using this library, it would be a fine oportunity to check your key generation functions if you do not interface directly with bitcoind. Affected keys have 32bits of entropy, possibly up to 56bits depending on the build of PHP, a low enough amount that would allow GPU based attacks on keys in the lower ranges. I do not know how many keys have been created using either function . I also don't share the authors optimism that this isn't an issue. -- 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
Re: [Bitcoin-development] Feedback requested: "reject" p2p message
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 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 > -- 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
Re: [Bitcoin-development] Feedback requested: "reject" p2p message
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 -- 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
Re: [Bitcoin-development] Feedback requested: "reject" p2p message
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 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 < > jeanpaulkogel...@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 > -- 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
