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

On 02/02/2015 11:58 AM, Brian Erdelyi wrote:> >>Confusing or not, the reliance on multiple signatures as offering >>greater security than single relies on the independence of multiple >secrets. If the secrets cannot be shown to retain independence in the >>envisioned threat scenario (e.g. a user's

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille wrote: > The much simpler alternative is just adding this to BIP66's DERSIG > right now, which is a one-line change that's obviously softforking. Is > anyone opposed to doing so at this stage? Thats my preference. ---

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell wrote: > So I think we should just go ahead with R/S length upper bounds as > both IsStandard and in STRICTDER. I would like to fix this at some point in any case. If we want to do that, we must at least have signatures with too-long R or S values

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

One clarification below. e On 02/02/2015 02:54 PM, Eric Voskuil wrote: > On Feb 2, 2015, at 11:53 AM, Mike Hearn wrote: >> >> In sending the first-signed transaction to another for second >> signature, how does the first signer authenticate to the second >> without compromising the independence

Re: [Bitcoin-development] Export format for xpub

On 03/02/15 01:05, Andreas Schildbach wrote: > I don't think that parameterizing will work, we can't predict future > BIPs. It's the same as for BIP43, in the end we agreed on just putting > the BIP number. Hm, let me put the questions the other way around: What gap limit should a wallet use if i

Re: [Bitcoin-development] Export format for xpub

On 02/02/2015 03:56 PM, Pavol Rusnak wrote: > To me it seems more important to describe how addresses should be > discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G) > instead of how the xpub was created/obtained (bip32 vs bip44). > > What do you thing about changing ?h=bip32

Re: [Bitcoin-development] Export format for xpub

On 02/02/2015 03:47 PM, vv01f wrote: >>> Uff, I would expect MMDD there so it's human readable as well. >> >> Those strings are not meant to be read by humans. MMDD is more >> complicated than necessary, given that Bitcoin deals with seconds since >> epoch everywhere. > > First that is a

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

On Feb 2, 2015, at 11:53 AM, Mike Hearn wrote: >> In sending the first-signed transaction to another for second signature, how >> does the first signer authenticate to the second without compromising the >> independence of the two factors? > > Not sure what you mean. The idea is the second fac

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

> There are a couple of attack vectors to consider: > > * The recipient's machine is compromised > * The sender's machine is compromised Excellent point of the recipient being compromised. -- Dive into the World of Pa

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

Transaction initiated and signed on device #1. Transaction is sent to device #2. On device #2 you verify the transaction and if authorized you provide the second signature. Brian Erdelyi Sent from my iPhone > On Feb 2, 2015, at 5:09 PM, Pedro Worcel wrote: > > Where would you verify that?

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

There are a couple of attack vectors to consider: * The recipient's machine is compromised * The sender's machine is compromised BIP-70 and other ways of having the sender verify the destination on a second device will help protect against sender compromise. For a person-to-person situation, you

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

I think what he is saying is that there is no point in having three signatures if they are not segregated in a secure manner. This is to say, if you use your computer as one "factor", and a third party website as another, but you use the same computer to access the website, there is no gain in

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

Where would you verify that? On 2/3/2015 10:03 AM, Brian Erdelyi wrote: Joel, The mobile device should show you the details of the transaction (i.e. amount and bitcoin address). Once you verify this is the intended recipient and amount you approve it on the mobile device. If the address wa

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

Joel, The mobile device should show you the details of the transaction (i.e. amount and bitcoin address). Once you verify this is the intended recipient and amount you approve it on the mobile device. If the address was replaced, you should see this on the mobile device as it won’t match wher

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

If the attacker has your desktop computer but not the mobile that's acting as an independent second factor, how are you then supposed to be able to tell you're not signing the correct transaction on the mobile? If the address was replaced with the attacker's address, it'll look like everything is o

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

> Confusing or not, the reliance on multiple signatures as offering greater > security than single relies on the independence of multiple secrets. If the > secrets cannot be shown to retain independence in the envisioned threat > scenario (e.g. a user's compromised operating system) then the be

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

> > In sending the first-signed transaction to another for second signature, > how does the first signer authenticate to the second without compromising > the independence of the two factors? Not sure what you mean. The idea is the second factor displays the transaction and the user confirms it

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

Confusing or not, the reliance on multiple signatures as offering greater security than single relies on the independence of multiple secrets. If the secrets cannot be shown to retain independence in the envisioned threat scenario (e.g. a user's compromised operating system) then the benefit red

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

In sending the first-signed transaction to another for second signature, how does the first signer authenticate to the second without compromising the independence of the two factors? Sent from my iPhone > On Feb 2, 2015, at 10:40 AM, Brian Erdelyi wrote: > > Another concept... > > It shoul

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

> Bitcoin Authenticator is a desktop app+mobile app pair. It pairs with your > phone over wifi, cloud push, maybe Bluetooth as well. I forget exactly. > > It's done in the same way as Lighthouse, so it runs Win/Mac/Linux on desktop > and Android on mobile. > > It could be adapted to use BitGo

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

> > Do you have anything that is NOT some web application? > Bitcoin Authenticator is a desktop app+mobile app pair. It pairs with your phone over wifi, cloud push, maybe Bluetooth as well. I forget exactly. It's done in the same way as Lighthouse, so it runs Win/Mac/Linux on desktop and Android

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

> We're way ahead of you guys ;) > > https://www.bitcoinauthenticator.org/ > - does this already, currently in alpha I’m just late to the party I guess. Thanks for the links. -

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

Martin, Yes, the second signing could be done by a mobile device that I owned and controlled (I wasn't thinking that initially). I was thinking that online services are popular because of convenience and there should be a better way to address security (privacy issues not withstanding). I thi

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

Do you have anything that is NOT some web application? 2015-02-02 18:59 GMT+01:00 Mike Hearn : > We're way ahead of you guys ;) > > On Mon, Feb 2, 2015 at 6:54 PM, Martin Habovštiak > wrote: >> >> Good idea. I think this could be even better: >> >> instead of using third party, send partially sig

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

We're way ahead of you guys ;) On Mon, Feb 2, 2015 at 6:54 PM, Martin Habovštiak < martin.habovst...@gmail.com> wrote: > Good idea. I think this could be even better: > > instead of using third party, send partially signed TX from computer > to smartphone. In case, you are paranoid, make 3oo5 add

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

Good idea. I think this could be even better: instead of using third party, send partially signed TX from computer to smartphone. In case, you are paranoid, make 3oo5 address made of two cold storage keys, one on desktop/laptop, one on smartphone, one using third party. If it isn't enough, add req

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

Another concept... It should be possible to use multisig wallets to protect against malware. For example, a user could generate a wallet with 3 keys and require a transaction that has been signed by 2 of those keys. One key is placed in cold storage and anther sent to a third-party. It is no

Re: [Bitcoin-development] Export format for xpub

On 02/02/15 15:17, Andreas Schildbach wrote: > Yes, except that BIP32-hierarchy and BIP44 differ in some requirements > (e.g. gap limit). Right. To me it seems more important to describe how addresses should be discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G) instead of ho

Re: [Bitcoin-development] Export format for xpub

On 02.02.2015 15:17, Andreas Schildbach wrote: >> Uff, I would expect MMDD there so it's human readable as well. > > Those strings are not meant to be read by humans. MMDD is more > complicated than necessary, given that Bitcoin deals with seconds since > epoch everywhere. First that is a

Re: [Bitcoin-development] Export format for xpub

On 02/02/2015 01:59 PM, Pavol Rusnak wrote: >> It's h=bip32 for the hierarchy used and > > Do I understand this correctly and h=bip32 hierarchy means that both > > xpub/0/i and xpub/1/j chains are scanned? (So it applies to BIP44 > generated xpubs as well?) Yes, except that BIP32-hierarchy and BIP

Re: [Bitcoin-development] Export format for xpub

On 02/02/15 13:38, Andreas Schildbach wrote: > It's h=bip32 for the hierarchy used and Do I understand this correctly and h=bip32 hierarchy means that both xpub/0/i and xpub/1/j chains are scanned? (So it applies to BIP44 generated xpubs as well?) > c=123456 for the creation date of the wallet (

Re: [Bitcoin-development] Export format for xpub

On 02/02/15 12:33, Mike Hearn wrote: > We generally don't edit BIPs like that after they've been written except to I think this could end up in BIP43, which deals with hierarchies and is still in Draft state although widely used. Allocating new BIP seems like a overkill to me. -- Best Regards /

Re: [Bitcoin-development] Export format for xpub

On 02/02/2015 12:33 PM, Mike Hearn wrote: > I looked at what Andreas is doing a few days ago - basically it's just > an xpub string with a ?a=b&c=d query string added to the end, with a > hierarchy type specifier and something else I forgot, encoded into a QR > code. It's h=bip32 for the hierarch

Re: [Bitcoin-development] Export format for xpub

On Mon, 2 Feb 2015, Levin Keller wrote: Hello everyone, I think this is my first email to this mailinglist so I will shortly introduce myself: I am Levin and the CEO of Coyno (www.coyno.com). Based in Berlin, mathematician. Bitcoiner since 2011. And now the reason for this email: Andreas (S

Re: [Bitcoin-development] Export format for xpub

We generally don't edit BIPs like that after they've been written except to add helpful links, examples etc and other things that don't add new functionality. For this you'd write a new BIP. It doesn't have to be hard. The process is: 1) Adapt the template BIP and fill it out with your motivation,

[Bitcoin-development] Export format for xpub

Hello everyone, I think this is my first email to this mailinglist so I will shortly introduce myself: I am Levin and the CEO of Coyno (www.coyno.com). Based in Berlin, mathematician. Bitcoiner since 2011. And now the reason for this email: Andreas (Schildbach) just released a new update of his