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 wrote: > > Another concept... > > It shoul

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 red

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

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

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 com

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] Subject: Re: Proposal to address Bitcoin malware

2015-02-03 Thread Eric Voskuil
multiple devices with the home, etc - and needs to do this even if using a third party. On the other hand, walking around with all necessary factors, or keeping them in the same safe, is tantamount to having just one factor. e > On 02/02/2015 02:54 PM, Eric Voskuil wrote: >> On Feb 2, 201

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Eric Voskuil
On 02/05/2015 12:28 PM, Mike Hearn wrote: > The donation to live performer example is good - there's no issue of > accidentally paying for someone else in this context as there's only one > recipient, but many senders. I'm not sure you could assume this, even if the payer only received one broadca

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Eric Voskuil
Yes, a stellar device for mass surveillance coupled with transaction tainting. e > On Feb 5, 2015, at 1:19 PM, Brian Hoffman wrote: > > This sounds horrible. You could basically monitor anyone with a wallet in a > highly populated area and track them super easily by doing facial > recognitio

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Eric Voskuil
On 02/05/2015 12:50 PM, Mike Hearn wrote: > I'm imagining myself walking around broadcasting my photo and MAC > address while hucksters push payment requests to me for approval > > I hate to break it to you, but you broadcast a photo of your face every > time you walk outside ;) > > Bluet

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Eric Voskuil
BLE has an advertised range of over 100m. http://www.bluetooth.com/Pages/low-energy-tech-info.aspx In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver. WiFi hots

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Eric Voskuil
Hi Paul, The issue is in the establishment of trust. Anyone can broadcast the initial information. e > On Feb 5, 2015, at 2:01 PM, Paul Puey wrote: > > The broadcast is ONLY done when the wallet is in Receive mode. Same as when > the QR code is visible. The use of the *Name* section is speci

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Eric Voskuil
u?" If so, I > send it. If there are two "Monkey Dude's" Then I have to bother with the > address prefix, but not otherwise. > >> On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil wrote: >> BLE has an advertised range of over 100m. >> >> http://www.bl

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Eric Voskuil
the narrow fields we are working in presently. But in a bitcoin world it would be very problematic. For this reason I wouldn't want to encourage standardization on this approach. e On 02/05/2015 02:10 PM, Eric Voskuil wrote: > A MITM can receive the initial broadcast and then spoof it by j

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Eric Voskuil
On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote: >> A BIP-70 signed payment request in the initial broadcast can resolve the >> integrity issues, but because of the public nature of the broadcast >> coupled with strong public identity, the privacy compromise is much >> worse. Now transactions are c

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Eric Voskuil
nario in the bitcoin model. This is also required in order guard against repudiation (give me a signed receipt). > On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote: >> On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil wrote: >>> A MITM can receive the initial broadcast an

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Eric Voskuil
g two > messages), merchant spells four words he sees on the screen and buyer > confirms transaction after verifying that words match. So the assumption is that there exists a secure (as in proximity-based) communication channel? e > 2015-02-06 0:46 GMT+01:00 Eric Voskuil : >> On 02/05/20

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

2015-02-05 Thread Eric Voskuil
Hi Andy, This is good stuff. I've spent quite a bit of time on this question, but set aside most of it earlier in the year in order to make some progress in other areas. I did review what I found available at the time pertaining to the Schildbach implementation and these questions. Skimming the li

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Eric Voskuil
pping isn't exactly flattering. You know I love Airbitz, and I know you guys are extremely privacy conscious. I personally would have no problem using this feature under certain circumstances. My question is only whether it would be wise to standardize on the proposal as-is. e >

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread Eric Voskuil
on't trust *any* smartphone as a platform for secure communication/data. But encrypting on the wire does of course shrink the attack surface and increase the attacker's cost. e > Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil napísal: >> On 02/05/2015 04:04 PM, MⒶrtin H

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

2015-02-05 Thread Eric Voskuil
Agree, range is not an issue. The trade-off is in battery vs. total time, which would be influenced primarily by the battery sensitivity of the platform. I'll send you a note to follow up. e On 02/05/2015 05:40 PM, Andy Schroder wrote: > Hello, > > I personally would prefer as low of range as po

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

2015-02-06 Thread Eric Voskuil
On 02/06/2015 12:40 AM, Andreas Schildbach wrote: > On 02/06/2015 01:36 AM, Eric Voskuil wrote: > >> The main advantage of BLE over BT is that it uses much less power, with >> a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can >> be even greater and

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-06 Thread Eric Voskuil
On 02/06/2015 12:59 AM, Roy Badami wrote: >> In this case there is no need for P2P communication, just pay to an >> address you already have for the other party. If you want to avoid >> address reuse, use stealth addressing. >> >> But yes, if you don't have a stealth address for the other party you

Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

2015-02-10 Thread Eric Voskuil
On 02/10/2015 02:41 AM, Natanael wrote: > Den 10 feb 2015 11:34 skrev "MⒶrtin HⒶboⓋštiak" > mailto:martin.habovst...@gmail.com>>: >> >> Why would anyone want to do anything about payment before choosing >> what he wants to buy and for what price? I've never used Amazon but >> isn't filling a form w

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-10 Thread Eric Voskuil
tin HⒶboⓋštiak wrote: > 2015-02-06 2:29 GMT+01:00 Eric Voskuil : >> On 02/05/2015 04:36 PM, Martin Habovštiak wrote: >>> I believe, we are still talking about transactions of physical >>> people in physical world. So yes, it's proximity based - people >>> tell

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-10 Thread Eric Voskuil
; user-friendliness. I think for a broadcast model (e.g. Bluetooth only) that is the only want to ensure integrity and privacy. A narrow cast can use proximity to establish trust. > 2015-02-10 17:55 GMT+01:00 Eric Voskuil : >> Martin, >> >> I like your idea for the commit pr

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-22 Thread Eric Voskuil
Hi Jan, This is really nice work. WRT the Schroder and Schildbach proposal, the generalization of the "r" and "payment_url" parameters makes sense, with only the potential backward compat issue on payment_url. > TBIP75 furthermore proposes to include an additional 'h' parameter > which would be

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-22 Thread Eric Voskuil
One correction inline below. e On 02/22/2015 02:39 PM, Eric Voskuil wrote: > Hi Jan, > > This is really nice work. > > WRT the Schroder and Schildbach proposal, the generalization of the "r" > and "payment_url" parameters makes sense, with only th

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-22 Thread Eric Voskuil
On 02/22/2015 02:37 PM, Andy Schroder wrote: > I'd like to see some discussion too about securing the bluetooth > connection. Right now it is possible for an eavesdropper to monitor the > data transferred. Yes, this should be a prerequisite issue to all others. > I'd personally like to see if wr

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-22 Thread Eric Voskuil
On 02/22/2015 03:32 PM, Andy Schroder wrote: > On 02/22/2015 06:06 PM, Eric Voskuil wrote: >> On 02/22/2015 02:37 PM, Andy Schroder wrote: >>> I'd like to see some discussion too about securing the bluetooth >>> connection. Right now it is possible for an eave

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-22 Thread Eric Voskuil
On 02/22/2015 03:35 PM, Andy Schroder wrote: >> On 02/22/2015 02:39 PM, Eric Voskuil wrote: >>> Hi Jan, >>> >>> This is really nice work. >>> >>> WRT the Schroder and Schildbach proposal, the generalization of the "r" >>

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-23 Thread Eric Voskuil
On 02/22/2015 11:36 PM, Andy Schroder wrote: > I agree that NFC is the best we have as far as a trust anchor that you > are paying the right person. The thing I am worried about is the privacy > loss that could happen if there is someone passively monitoring the > connection. We have the same obj

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-23 Thread Eric Voskuil
On 02/23/2015 01:49 AM, Andreas Schildbach wrote: > I think at this point I'd like to bring back my original suggestion of > using DHKE (Diffie-Hellman) or simlar. I know we'd still need to > transmit some secret that could be eavesdropped, Hi Andreas, DHKE will not improve the situation. Either

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-23 Thread Eric Voskuil
Mike, Before addressing other issues I could use some clarification on your intent. In one statement you refer to derivation of a session key from a bitcoin address (passed via NFC): > doing ECDH over secp256k1 to derive a session key means we can reuse > the address that was put in the URI alre

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-23 Thread Eric Voskuil
On 02/23/2015 03:11 PM, Mike Hearn wrote: >> I don't see how you propose to treat the bitcoin address as a >> secp256k1 public key, or do you mean something else? > > Sorry, I skipped a step. I shouldn't make assumptions about what's > obvious. No problem, we don't all have the same context. I may

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-23 Thread Eric Voskuil
Andy, adding to my previous post below: On 02/23/2015 01:40 AM, Eric Voskuil wrote: > On 02/22/2015 11:36 PM, Andy Schroder wrote: ... >> It's possible a really sophisticated modification could be done where >> the attacker encrypts and decrypts the communication and then rel

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-25 Thread Eric Voskuil
nJC3hVH7W6yB2Wtw24ztzGtBc4 base64url: bitcoin:?r=bt:ABBgss5s/A3xWlhB1GI_t2NMR9Zq9E47hZOzmZ6eZTS8sbq-liugh I prefer base58 because it's available to all bitcoin libraries, nearly as compact as base64 (+1 byte in our example) and better standardized. Some embedded device people might care about havi

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-25 Thread Eric Voskuil
there would be no other way to distinguish between customers in some scenarios and this is the safest approach. We certainly won't run out of numbers, and unused sessions can be discarded based on any number of criteria, including discarding all but the most recent. That may may be sufficient for you

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-25 Thread Eric Voskuil
implements to something > more consistent? Could you spell this out, I'm not familiar with the implementation, just the proposals. > Maybe we can create a new UUID for this secure service > so Schildbach's bitcoin wallet can still maintain backwards compatibility. That may be

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-25 Thread Eric Voskuil
The list appears dead, this is a test. e signature.asc Description: OpenPGP digital signature -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-03-02 Thread Eric Voskuil
On 02/26/2015 04:30 AM, Andreas Schildbach wrote: > On 02/24/2015 11:41 AM, Mike Hearn wrote: >> On 02/23/2015 04:10 PM, Eric Voskuil wrote: >>> Does this not also require the BT publication of the script for a P2SH >>> address? >> >> You mean

Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-03-25 Thread Eric Voskuil
On 02/14/2015 05:13 AM, Peter Todd wrote: > So stop wasting your time. Help get the consensus critical code out of > Bitcoin Core and into a stand-alone libconsensus library... done https://github.com/libbitcoin/libbitcoin-consensus > ... > Then ... when the next time we decide to soft-fork Bitc

Re: [Bitcoin-development] Proposed alternatives to the 20MB step

2015-06-02 Thread Eric Voskuil
On 06/01/2015 08:55 AM, Mike Hearn wrote: >> Decentralization is the core of Bitcoin's security model and thus that's what gives Bitcoin its value. > No. Usage is what gives Bitcoin value. Nonsense. Visa, Dollar, Euro, Yuan, Peso have usage. The value in Bitcoin is *despite* it's far lesser usag

Re: [Bitcoin-development] Proposed alternatives to the 20MB step

2015-06-02 Thread Eric Voskuil
On 06/02/2015 04:03 AM, Mike Hearn wrote: > > 1,000 *people* in control vs. 10 is two orders of > > magnitude more decentralized. > > > Yet Bitcoin has got worse by all these metrics: there was a time > before mining pools when there were ~thousands of people mining with > their local CPU