Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

2015-06-15 Thread Adam Weiss
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. : )


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 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 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 mailing list

[Bitcoin-development] Fwd: Proposed additional options for pruned nodes

2015-05-12 Thread Adam Weiss
FYI on behalf of jgarzik...

-- Forwarded message --
From: Jeff Garzik
Date: Tue, May 12, 2015 at 4:48 PM
Subject: Re: [Bitcoin-development] Proposed additional options for pruned
To: Adam Weiss

Maybe you could forward my response to the list as an FYI?

On Tue, May 12, 2015 at 12:43 PM, Jeff Garzik 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 wrote:

 fyi, your email to bitcoin-dev is still generating google spam warnings...


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.;117567292;y___
Bitcoin-development mailing list

Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware

2015-02-03 Thread Adam Weiss

 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.

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.
Bitcoin-development mailing list