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

2015-02-02 Thread Brian Erdelyi
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

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

2015-02-02 Thread Brian Erdelyi
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

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

2015-02-02 Thread Brian Erdelyi
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

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

2015-02-02 Thread Brian Erdelyi
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 pe...@worcel.com wrote: Where would you

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

2015-02-02 Thread Joel Joonatan Kaartinen
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

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

2015-02-02 Thread Pieter Wuille
On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell gmaxw...@gmail.com 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

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

2015-02-02 Thread Eric Voskuil
On Feb 2, 2015, at 11:53 AM, Mike Hearn m...@plan99.net 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

Re: [Bitcoin-development] Export format for xpub

2015-02-02 Thread Pavol Rusnak
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 it

Re: [Bitcoin-development] Export format for xpub

2015-02-02 Thread Andreas Schildbach
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 pitty .. as

Re: [Bitcoin-development] Export format for xpub

2015-02-02 Thread Andreas Schildbach
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 to

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

2015-02-02 Thread Eric Voskuil
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 of the

Re: [Bitcoin-development] Export format for xpub

2015-02-02 Thread Andreas Schildbach
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=bc=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 hierarchy

Re: [Bitcoin-development] Export format for xpub

2015-02-02 Thread Pavol Rusnak
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

2015-02-02 Thread Andreas Schildbach
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 BIP44

Re: [Bitcoin-development] Export format for xpub

2015-02-02 Thread Wladimir
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

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

2015-02-02 Thread Gregory Maxwell
On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille pieter.wui...@gmail.com 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] Export format for xpub

2015-02-02 Thread Pavol Rusnak
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 how

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

2015-02-02 Thread Eric Voskuil
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] Proposal to address Bitcoin malware

2015-02-02 Thread Brian Erdelyi
We're way ahead of you guys ;) https://www.bitcoinauthenticator.org/ 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

2015-02-02 Thread Mike Hearn
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 on

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

2015-02-02 Thread Brian Erdelyi
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 as a

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

2015-02-02 Thread Eric Voskuil
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 brian.erde...@gmail.com wrote: Another

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

2015-02-02 Thread Eric Voskuil
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

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

2015-02-02 Thread Mike Hearn
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

2015-02-02 Thread Pedro Worcel
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

2015-02-02 Thread Brian Erdelyi
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

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

2015-02-02 Thread Martin Habovštiak
Do you have anything that is NOT some web application? 2015-02-02 18:59 GMT+01:00 Mike Hearn m...@plan99.net: 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

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

2015-02-02 Thread Martin Habovštiak
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

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

2015-02-02 Thread Brian Erdelyi
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