Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
Using a desktop website and mobile device for 2/3 multisig in lieu of a hardware device (trezor) and desktop website (mytrezor) works, but the key is that the device used to input the two signatures cannot be in the same band. What you are protecting against are MITM attacks. The issue is that if a single device or network is compromised by malware, or if a party is connecting to a counterparty through a channel with compromised security, inputing 2 signatures through the same device/band defeats the purpose of 2/3 multisig. Maybe I'm not following the conversation very well, but if you have a small hardware device that first displays a signed payment request (BIP70) and then only will sign what is displayed, how can a MITM attacker do anything other than deny service? They'd have to get malware onto the signing device, which is the vector that a simplified signing device is specifically designed to mitigate. TREZOR like devices with BIP70 support and third party cosigning services are a solution I really like the sound of. I suppose though that adding BIP70 request signature validation and adding certificate revocation support starts to balloon the scope of what is supposed to be a very simple device though. Regardless, I think a standard for passing partially signed transactions around might make sense (maybe a future extension to BIP70), with attention to both PC - small hardware devices and pushing stuff around on the Internet. It would be great if users had a choice of hardware signing devices, local software and third-party cosigning services that would all interoperate out of the box to enable easy multisig security, which in the BTC world subsumes the goals of 2FA. --adam -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fwd: Proposed additional options for pruned nodes
FYI on behalf of jgarzik... -- Forwarded message -- From: Jeff Garzik jgar...@bitpay.com Date: Tue, May 12, 2015 at 4:48 PM Subject: Re: [Bitcoin-development] Proposed additional options for pruned nodes To: Adam Weiss a...@signal11.com Maybe you could forward my response to the list as an FYI? On Tue, May 12, 2015 at 12:43 PM, Jeff Garzik jgar...@bitpay.com wrote: You are the 12th person to report this. It is SF, not bitpay, rewriting email headers and breaking authentication. On Tue, May 12, 2015 at 12:40 PM, Adam Weiss a...@signal11.com wrote: fyi, your email to bitcoin-dev is still generating google spam warnings... --adam -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
Recent versions of mailman strip DKIM signatures, rewrite the envelope-from to use an address at the list's domain and set reply-to to the original authors address to resolve the DMARC issue. I'm on several lists that do this and it works just fine. +1 on moving the list. Given the fact that the mails are archived in public, it's not really a huge deal how it takes place. One month sounds reasonable (although I think it could be done on a shorter timescale). I'd setup the new list to allow subscriptions, but keep it moderated to keep discussion from moving until the cut, send lots of warnings and then on the big day unmoderate one and moderate the other. It's a great opportunity to hardfork something in Bitcoin without risk of breakage, losses or entertaining melodrama. : ) --adam ps. I think SF will let project admins download mbox archives of the list, the new admins should be able to import them to keep archive consistency in one place. On Mon, Jun 15, 2015 at 6:13 AM, Mike Hearn m...@plan99.net wrote: Bear in mind the problem that stops Jeff's messages getting through is that mailman 1.0 doesn't know how to handle DKIM properly. Switching to a different mailman provider won't fix that. Does mailman 3.0 even fix this? I found it difficult to tell from their website. There's a big page on the mailman wiki that suggests they fixed it by simply deleting the signatures entirely, which won't work. DMARC policies state that mail *must* be signed and unsigned/incorrectly signed message should be discarded. The user documentation for mailman 3 doesn't seem to exist? The links on the website are docs for 2.1, perhaps they released mailman 3 without refreshing the docs. Google Groups may be controversial but if I recall correctly the main issue was the question of whether you needed a Google account or not. I'm pretty sure you can just send an email to groupname+subscr...@googlegroups.com even if you don't have a Google account. But of course this is a bizarre standard to hold mailing list software to: mailman asks users to create an account for each listserv in order to manage a subscription too! -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
