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] 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

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

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 brianchoff...@gmail.com wrote: This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing

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 ;) Bluetooth

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

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 p...@airbitz.co 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*

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

2015-02-05 Thread Eric Voskuil
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 e...@voskuil.org wrote: BLE has an advertised range of over 100m. http://www.bluetooth.com/Pages/low-energy-tech-info.aspx In the case of mass surveillance

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

2015-02-05 Thread Eric Voskuil
. 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 jamming the original. You then only see one. e

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

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

2015-02-05 Thread Eric Voskuil
, William Swanson wrote: On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil e...@voskuil.org wrote: A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one. You are right, of course. There is no way to make Bluetooth 100% secure, since it is an over

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

2015-02-05 Thread Eric Voskuil
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 e...@voskuil.org: 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

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

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

2015-02-05 Thread Eric Voskuil
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 On Feb 5, 2015, at 3:46 PM, Eric Voskuil e...@voskuil.org mailto:e

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

2015-02-05 Thread Eric Voskuil
surface and increase the attacker's cost. e Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil e...@voskuil.org napísal: On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote: That's exactly what I though when seeing the RedPhone code, but after I studied the commit protocol I realized it's

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 connection latency lower than BT

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 can

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

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

2015-02-03 Thread Eric Voskuil
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, 2015, at 11:53 AM http://airmail.calendar/2015-02-02%2011:53:00%20MST, Mike Hearn wrote: In sending the first-signed transaction to another for second signature, how

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

2015-02-10 Thread Eric Voskuil
: 2015-02-06 2:29 GMT+01:00 Eric Voskuil e...@voskuil.org: 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 the words by mouth. :) Notice from my original comment

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 martin.habovst...@gmail.com 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

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

2015-02-10 Thread Eric Voskuil
to ensure integrity and privacy. A narrow cast can use proximity to establish trust. 2015-02-10 17:55 GMT+01:00 Eric Voskuil e...@voskuil.org: Martin, I like your idea for the commit protocol in that it resolves the vandalous address substitution attack. However, I don't see a way to prevent

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 Bitcoin

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 if the URI you're serving is like this? bitcoin:3aBcD

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

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

2015-02-25 Thread Eric Voskuil
that base58 is just for bitcoin addresses (not true) or designed for humans... that's sort of the point, but it's also good for URLs. e On 02/23/2015 09:55 PM, Eric Voskuil wrote: 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

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

2015-02-25 Thread Eric Voskuil
three values would be base58, as opposed to one base58 and two base64url). There may be some idea that base58 is just for bitcoin addresses (not true) or designed for humans... that's sort of the point, but it's also good for URLs. e On 02/23/2015 09:55 PM, Eric Voskuil wrote: Andy, adding

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-02-25 Thread Eric Voskuil
bitcoin wallet can still maintain backwards compatibility. That may be necessary depending on the implementation of existing terminals, but I'm not familiar enough to speculate. e On 02/24/2015 05:14 PM, Eric Voskuil wrote: * Add a s= parameter that uses a unique public key for each session

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

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 a

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 the potential backward compat issue on payment_url

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 eavesdropper to monitor the data transferred. Yes

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 and payment_url parameters makes sense, with only the potential backward compat issue

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
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 have

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 relays to each party

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 usage.

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 CPUs and