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 gmaxw...@gmail.com 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=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Making fee estimation better
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, Oct 26, 2013 at 12:25 AM, Gavin Andresen
gavinandre...@gmail.com wrote:
I feel like there is a lot of in the weeds discussion here about
theoretical, what-if-this-and-that-happens-in-the-future scenarios.
I would just like to point out (again) that this is not intended to be The
One True Solution For Transaction Fees And Transaction Prioritization. If
you've got a better mechanism for estimating fees, fantastic! If it turns
out estimates are often-enough wrong to be a problem and you've got a
solution for that, fantastic!
This discussion seems to be a lot of hot air over a simple observation that
estimates are imperfect and always will be. I do not understand you vehement
opposition the notion that a backup is a good thing except in the context that
replacement to change fees is halfway to profit-seeking replacement by fee.
Peter Todd:
You did a fair bit of leg work for replace-by-fee. Seems to me that
replace-for-fee will help prep infrastructure to eventual replace-by-fee usage,
while avoiding some of the politics around zero-conf transactions.
Go dust off your code and make it happen. I want to see a mempool
implementation similar to what you did for me on replace-for-fee, and I
understand much of the code is written in any case. This time I also want to
see a increasetxfee RPC command, and erasewallettx RPC command to deal with
duplicates. (I know touching the wallet code is scary) Having all will enable
usage, and I can imagine getting pools to use this will be easy enough.
(eligius?)
Here is your 4BTC bounty. In the event I am not around Gregory Maxwell can also
adjudicate. If both you and him feel someone else deserves it, by all means
send them the funds
bitcoind decodescript
522102d527466a144aac2030cd16d8be3d91231af26a95c2f8fc345a0ea0e8d53ac3914104d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e71417834104f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce453ae
{
asm : 2
02d527466a144aac2030cd16d8be3d91231af26a95c2f8fc345a0ea0e8d53ac391
04d34775baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f168809d36e2da1162f03412bf23aa5f949f235eb2e7141783
04f005d39733ec09a1efa0cf8dcf3df50691e22c2374ff9a96d1d9ecb98a1e866c9f558a9fa1ba8ef0bbbad01f396768c0cb2dda9924dc0aaee1481604a8bd9ce4
3 OP_CHECKMULTISIG,
reqSigs : 2,
type : multisig,
addresses : [
1L9p6QiWs2nfinyF4CnbqysWijMvvcsnxe,
1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv,
1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB
],
p2sh : 3BST1dPxvgMGL3d9GPCHvTyZNsJ7YKTVPo
}
(I realized right after my Tor payment protocol bounty that I would need some
bit of uniqueness like a bounty-specific pubkey to disambiguate multiple such
bounties!)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSbg9wAAoJEEWCsU4mNhiPROQH/j+eWccx7oSVsr94cgGu7qza
kdnA7B6BAlnCPg3D+nqEFKDqzOyFppeHLadCCIYHHc5iVRfJuu9J1Gh9lgMCuyCW
qN7ZOBCARjiVOqrHPQR1pf18i0ko7dQWw2hZjy51XKuFxAsHwZpB/fzQCbVVzyB6
l5SECCou58bJ/x7B0L93K+yjXuMGnvi9jqiLAKkLWYDzVm7TeVWNVQr04B7sqi6A
mY+BfG61e7sqM2UJd69yGLeQdEfghYTmtA+EaaqYS0L11m7yFGZdUqD7UNy1FKO7
44M1JTh2ANnQRjSTJWOBXQNHMa/mxDCji1VFUtJhZKEuOZyWpGm7HMH1D3vcvcQ=
=4flN
-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=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 0.8.5 setup.exe is corrupt
I downloaded 0.8.5 windows setup .exe and it says it is corrupted even after i try re-download it maybe it needs to be rearchived? -- 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=60135991iu=/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
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=60135991iu=/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=60135991iu=/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=60135991iu=/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 Mon, Oct 28, 2013 at 2:26 AM, Andreas Schildbach andr...@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. -- 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=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol for onion URLs.
I think its a mistake relying directly on X509, its subject to corrpution attacks, involves ASN.1 and enough openSSL X.500 encoding abiguity (or other code base) to be a security nightmare. Why not make the payment messages signed by bitcoin keys. If someone wants to associate with X.509 they can put a bitcoin address on their SSL site. If someone can get into your site deeply enough to modify your SSL served code and you're trying to run ecommerce you have other problems. Never the less if they care they can clear sign the bitcoin addr with xmlsig and their X.509 private key, and/or with PGP and a WoT. I think its smarter to pollute bitcoin main with X509. Make a little helper util if there are not enough xmlsig tools that you cant pick one up opensource for multiple languages. This then avoids the binding to Tor - you can publish a bitcoin address authenticated anyway you like. Eg tahoe-LAFS auth/integrity, i2p, tor, pgp - you name it. Maybe I voice this opinion a bit late in the cycle, but I think it would do bitcoin a favor otherwise its a camels nose in the tent into the TLAs that control their own X.509 CAs, or issue NSL letters for CA private keys, or forged certs. It's all happening and thanks to Snowden we now have even more evidence... Adam On Fri, Oct 25, 2013 at 09:06:48PM -0700, Gregory Maxwell wrote: On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr l...@dashjr.org wrote: Is there any point to additional encryption over tor (which afaik is already encrypted end-to-end)? Is there a safe way to make this work through tor entry nodes/gateways? The x.509 in the payment protocol itself is for authentication and non-repudiation, not confidentiality. It's used to sign the payment request so that later there is cryptographic evidence in the event of a dispute: He didn't send me my alpaca socks! Thats not the address I told you to pay! He told me he'd send my 99 red-balloons, not just one! No way, that was the price for 1 red-balloon! Just using SSL or .onion (or whatever else) gets you confidentiality and authentication. Neither of these things get you non-repudiation. It'd be nice to have a way to support namecoin-provided keys too... The payment protocol is extensible, so I hope that someday someone will support namecoin authenticated messages (but note: this requires namecoin to support trust-free SPV resolvers, otherwise there is no way to extract a compact proof that can be stuck into a payment request) and GPG authenticated messages. But those things will require a fair amount of code (even fixing the namecoin protocol in the nmc case), and GPG could be done just by externally signing the actual payment request like you'd sign any file... and considering the sorry state of their _practical_ usability, I don't think they're worth doing at this time. By contrast, I _think_ the tor onion support would require only a relatively few lines of code since it could just be the existing x.509 mechanism with just a simple special validation rule for .onion, plus a little tool to repack the keys. I think it would easily be more widely used than namecoin (though probably both would not really be used, as gavin notes). w/ Gavin's comments I'll go check in with the tor folks and see if anyone has ever though of doing this before and if there is already a canonical structure for the x.509 certs used in this way. -- 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=60135991iu=/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=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol for onion URLs.
On Mon, Oct 28, 2013 at 1:14 PM, Adam Back a...@cypherspace.org wrote: Maybe I voice this opinion a bit late in the cycle, but A bit late is one way to put it. All these topics and more were discussed to death a year ago when the payment protocol was first being designed. Bluntly, I think we're all sick of it. You are welcome to PGP sign your payment requests if you want to. If not, then please see my FAQ for discussion: https://bitcointalk.org/index.php?topic=300809.msg3225143#msg3225143 tl;dr - the right way to tackle governments getting bogus certs issued is certificate transparency. All other suggestions tend to boil down to here's some handwaving that doesn't actually solve the problem. By the way, the evidence from the Snowden case rather reinforces the strength of the CA system. Did we see stories about bulk usage of fake certificates? No. What we read is that the increased usage of SSL was a major game-changer for intelligence agencies. They solve SSL by compiling databases of private keys they obtain in various ways. True to form when the FBI wanted access to LavaBit, they tried to obtain his private keys rather than just push a convenient give me a fake cert button, and when it became known that Lavabit had to hand over their key, GoDaddy revoked their certificate. Industry policies forced their hand and those policies don't have a get-out clause for the FBI. It's without a doubt that there are government-issued fake certs floating about, somewhere, just due to the scale of hacking that's been taking place. However, demanding perfection in a system that handles security for over a billion people and tens of millions of operators is unreasonable. All we can ask for is that it it's being improved, which through initiatives like cert transparency, it is. Please, let's call time on these discussions. They long ago ceased to have any value. -- 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=60135991iu=/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
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 -- 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
