[Bitcoin-development] [SPAM] Re: determining change addresses using the least significant digits
On Friday, February 06, 2015 3:16:13 AM Justus Ranvier wrote: On 02/04/2015 02:23 PM, Isidor Zeuner wrote: Hi there, traditionally, the Bitcoin client strives to hide which output addresses are change addresses going back to the payer. However, especially with today's dynamically calculated miner fees, this may often be ineffective: A user sending a payment using the Bitcoin client will usually enter the payment amount only up to the number of digits which are considered to be significant enough. So, the least significant digits will often be zero for the payment. With dynamically calculated miner fees, this will often not be the case for the change amount, making it easy for an observer to classify the output addresses. A possible approach to handle this issue would be to add a randomized offset amount to the payment amount. This offset amount can be small in comparison to the payment amount. Another possible approach is to randomize the number of change outputs from transaction to transaction. Doing this, it would be possible to make change outputs that mimic real spends (low number of s.d.) This uses more data. Why not just round change down (effectively rounding fee up)? Luke -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Thanks Paul, for writing up your protocol! First thoughts: For a BIP standard, I think we should skip bitcoin: URIs entirely and publish BIP70 payment requests instead. URIs mainly stick around because of QR codes limited capacity. BIP70 would partly address the copycat problem by signing payment requests. In your Motivation section, I miss some words about NFC. NFC already addresses all of the usability issues mentioned and is supported by mobile wallets since 2011. That doesn't mean your method doesn't make sense in some situations, but I think it should be explained why to prefer broadcasting payment requests over picking them up via near field radio. On 02/05/2015 09:01 AM, Paul Puey wrote: Airbitz has developed and implemented a method for communicating a bitcoin URI across Bluetooth (BLE) or any other P2P, mid range, wireless, broadcast medium. The currently documented implementation is available in our iOS and Android mobile wallet (updated Android version with BLE coming in about 1 week). We would like to have the BIP pulled into Github for review and discussion. Here is the current BIP: BIP: TBD Title: P2P Wireless URI transfer Authors: Thomas Baker tom’at’airbitz.co http://airbitz.co, Paul Puey paul’at’airbitz.co http://airbitz.co Contributors: Joey Krug joeykrug’at’gmail.com http://gmail.com Status: proposal Type: Standards Track Created: 2015-01-12 Table of Contents * Abstract * Motivation * Specification * Compatibility * Examples * References Abstract This is a protocol for peer-to-peer wireless transfer of a URI request using an open broadcast or advertisement channel such as Bluetooth, Bluetooth Low Energy, or WiFi Direct. Motivation There are disadvantages for a merchant (requester) and customer (sender) to exchange a URI request using QR codes that can be eliminated by using wireless broadcast or advertisements. Current QR code scan method to transfer a request URI from merchant (Requester) to customer (Sender) is cumbersome. A usual scenario is a merchant with a POS terminal for order entry and a separate tablet for transacting payments with bitcoin, and a customer with a smartphone. After the order is entered, the merchant enters payment request information into the tablet, generates the QR code representing the URI, and presents this to the customer. The customer prepares to scan the QR code with their smartphone by maneuvering the camera to the tablet. The tablet screen must be relatively clean, point at the customer, and held steady. The smartphone camera lens must be clean, point at the tablet screen, come into range, and held steady to focus and wait for a QR scan. Environmental conditions such as bright outdoor sunlight, indoor spot lights, or significant distance between QR code and camera can create difficult and cumbersome experiences for users. Using a wireless local broadcast allows the merchant to just enter the payment and wait. The tablet and smartphone are not maneuvered to align in any way. The customer observes broadcast listings, selects the appropriate one from possible simultaneous broadcasts from other POS stations nearby, examines the URI request details such as amount, and decides whether to send funds, initiating a bitcoin network transfer. The merchant and customer then receive the transaction confirmations and are done with the sale. Merchant and customer devices are kept private and secured in their own possession. The URI and other broadcast identification (Joe’s Grill #1) only contain public information. However, a copycat broadcaster acting as MITM might duplicate the broadcast simultaneously as the merchant, attempting to lure the customer to send funds to the copycat. That attack is mitigated with this broadcast method because of the partial address in the broadcast. Specification Requester generates a bitcoin URI request of variable length, and a limited descriptive identifier string. Requester then broadcasts the URI’s partial public address (paddress) plus identifier (id) over a publicly visible wireless channel. Sender scans for broadcasts on their device, examines and selects the desired request by the identifier and partial address. This connects a data channel to Requester. Requester sends full URI back over the data channel. Sender device ensures paddress is part of the full URI public address and checks the full address integrity. Checking the broadcast and full URI integrity prevents a copycat device within range from copying the partial address and fooling the customer into sending funds to the copycat instead. Below is a description of the protocol through Bluetooth Smart (Low Energy). Requestor Sender - Bitcoin transaction roles Peripheral Central- Bluetooth GAP definitions Mode Mode 1
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
For a BIP standard, I think we should skip bitcoin: URIs entirely and publish BIP70 payment requests instead. Agreed - it's not clear to me at all that this partial address scheme is actually secure. The assumption appears to be that the MITM must match the address prefix generated by the genuine merchant. But if they can do a wireless MITM they can just substitute their own address prefix/partial address, no? To avoid MITM attacks the sender must know who they are sending money to, and that means they must see a human understandable name that's cryptographically bound to the right public key. Displaying partial addresses to the user is not going to solve this unless users manually compare key prefixes across the screens which is even less convenient than a QR code. I think it should be explained why to prefer broadcasting payment requests over picking them up via near field radio. This is probably an artifact of Apple's restrictions on iOS. Only the iPhone 6 has NFC hardware and Apple don't expose it via any public API. It can however support Bluetooth LE. Apple isn't a big deal in Germany because iPhone only achieved about 17% market share during the quarter when the iPhone 6 launched. Normally it's closer to 10-13%. Most other markets are similar. However in the USA, UK, Australia and Japan iOS is still a big deal and NFC is going to be seen as a non-universal solution there. At least, until Apple catches up and provides an NFC API. It's certainly not a problem to have a working radio based broadcast system, though the theoretician in me wonders what happens when lots of people are trying to pay simultaneously for something that has equal cost . e.g. buying movie tickets at a counter. NFC and QR codes prevent any kind of oops I paid for someone elses stuff confusion. In practice of course Bitcoin payments are not normally popular enough for this to be a problem outside of Bitcoin community events. -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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 broadcast. And if the payer receives multiple, it constitutes a DOS on the scenario, potentially unintentional. The issue of confused payments remains in other situations though. Agree, the problem of the payer strongly identifying the receiver requires either proximity (NFC or QR code scan from the known-good source) or PKI/WoT. The problem can't be resolved through a broadcast. For the coffee shop use case, it'd be nicer (I think) if we aim for a Square-style UI where the device broadcasts a (link to) a photo of the user combined with a bluetooth MAC. Then the merchant tablet can show faces of people in the shop, and can push a payment request to the users device. That device can then buzz the user, show a confirmation screen, put something on their smart watch etc or just auto-authorise the payment because the BIP70 signature is from a trusted merchant. User never even needs to touch their phone at all. I'm imagining myself walking around broadcasting my photo and MAC address while hucksters push payment requests to me for approval, while recording my photo and correlating it to my address. It will pretty quickly turn in to a scenario where I need to touch something before this is turned on. On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey p...@airbitz.co mailto:p...@airbitz.co wrote: The BIP70 protocol would preclude individuals from utilizing the P2P transfer spec. It would also require that a Sender have internet connectivity to get the payment protocol info. BLE could enable payment w/o internet by first transferring the URI to from Recipient to Sender. Then in the future, we could sign a Tx and send it over BLE back to the recipient (who would still need internet to verify the Tx). This is an important use case for areas with poor 3G/4G connectivity as I've experience myself. Also, due to Android issues, NFC is incredibly clunky. The URI Sender is required to tap the screen *while* the two phones are in contact. We support NFC the same way Bitcoin Wallet does, but unless the payment recipient has a custom Android device (which a merchant might) then the usage model is worse than scanning a QR code. BLE also allows people to pay at a distance such as for a donation to a live performer. We'll look at adding this to the Motivation section. From: Andreas Schildbach andreas@sc... - 2015-02-05 13:47:04 Thanks Paul, for writing up your protocol! First thoughts: For a BIP standard, I think we should skip bitcoin: URIs entirely and publish BIP70 payment requests instead. URIs mainly stick around because of QR codes limited capacity. BIP70 would partly address the copycat problem by signing payment requests. In your Motivation section, I miss some words about NFC. NFC already addresses all of the usability issues mentioned and is supported by mobile wallets since 2011. That doesn't mean your method doesn't make sense in some situations, but I think it should be explained why to prefer broadcasting payment requests over picking them up via near field radio. 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 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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 facial recognition. Yes you could photograph people but it's way more burdensome. Sorry to go off topic a little. On Feb 5, 2015, at 3:50 PM, Mike Hearn m...@plan99.net 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 MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC. Payment spam might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue. -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition. We're talking about BLE, still? The radio tech that runs in the so called junk bands because propagation is so poor? My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls. Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup. Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it. -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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 MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC. Payment spam might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue. -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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 MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC. Interesting take on privacy. But the market will of course decide. Would the merchant be broadcasting payment requests in the clear, or would they be encrypted with a public key of the spender? Payment spam might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue. Not sure I'd shoot for a system that's guaranteed to require PKI with blacklisting and spam filtering. 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 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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 hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location. e On Feb 5, 2015, at 1:36 PM, Mike Hearn m...@plan99.net 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 recognition. We're talking about BLE, still? The radio tech that runs in the so called junk bands because propagation is so poor? My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls. Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup. Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it. -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Airbitz has developed and implemented a method for communicating a bitcoin URI across Bluetooth (BLE) or any other P2P, mid range, wireless, broadcast medium. The currently documented implementation is available in our iOS and Android mobile wallet (updated Android version with BLE coming in about 1 week). We would like to have the BIP pulled into Github for review and discussion. Here is the current BIP: BIP: TBD Title: P2P Wireless URI transfer Authors: Thomas Baker tom’at’airbitz.co, Paul Puey paul’at’airbitz.co Contributors: Joey Krug joeykrug’at’gmail.com Status: proposal Type: Standards Track Created: 2015-01-12 Table of Contents - Abstract - Motivation - Specification - Compatibility - Examples - References Abstract This is a protocol for peer-to-peer wireless transfer of a URI request using an open broadcast or advertisement channel such as Bluetooth, Bluetooth Low Energy, or WiFi Direct. Motivation There are disadvantages for a merchant (requester) and customer (sender) to exchange a URI request using QR codes that can be eliminated by using wireless broadcast or advertisements. Current QR code scan method to transfer a request URI from merchant (Requester) to customer (Sender) is cumbersome. A usual scenario is a merchant with a POS terminal for order entry and a separate tablet for transacting payments with bitcoin, and a customer with a smartphone. After the order is entered, the merchant enters payment request information into the tablet, generates the QR code representing the URI, and presents this to the customer. The customer prepares to scan the QR code with their smartphone by maneuvering the camera to the tablet. The tablet screen must be relatively clean, point at the customer, and held steady. The smartphone camera lens must be clean, point at the tablet screen, come into range, and held steady to focus and wait for a QR scan. Environmental conditions such as bright outdoor sunlight, indoor spot lights, or significant distance between QR code and camera can create difficult and cumbersome experiences for users. Using a wireless local broadcast allows the merchant to just enter the payment and wait. The tablet and smartphone are not maneuvered to align in any way. The customer observes broadcast listings, selects the appropriate one from possible simultaneous broadcasts from other POS stations nearby, examines the URI request details such as amount, and decides whether to send funds, initiating a bitcoin network transfer. The merchant and customer then receive the transaction confirmations and are done with the sale. Merchant and customer devices are kept private and secured in their own possession. The URI and other broadcast identification (Joe’s Grill #1) only contain public information. However, a copycat broadcaster acting as MITM might duplicate the broadcast simultaneously as the merchant, attempting to lure the customer to send funds to the copycat. That attack is mitigated with this broadcast method because of the partial address in the broadcast. Specification Requester generates a bitcoin URI request of variable length, and a limited descriptive identifier string. Requester then broadcasts the URI’s partial public address (paddress) plus identifier (id) over a publicly visible wireless channel. Sender scans for broadcasts on their device, examines and selects the desired request by the identifier and partial address. This connects a data channel to Requester. Requester sends full URI back over the data channel. Sender device ensures paddress is part of the full URI public address and checks the full address integrity. Checking the broadcast and full URI integrity prevents a copycat device within range from copying the partial address and fooling the customer into sending funds to the copycat instead. Below is a description of the protocol through Bluetooth Smart (Low Energy). Requestor Sender - Bitcoin transaction roles Peripheral Central- Bluetooth GAP definitions Mode Mode 1 |-| - Requestor Advertises partial bitcoin: URI + Name | ... | 2 |-| - Subscribe then send sender's Name, requesting a response 3 |-| - ACK 4 |-| - request Read Characteristic from peripheral 5 |-| - Sender receives full bitcoin: URI 1. Peripheral advertises over a service UUID a BLE extended advertisement with a Scan Response containing the partial address of a bitcoin URI and a Name, any plain text. The entire response is limited to 26 characters. The first 10 make up the first 10 characters of the bitcoin URI public address where to send bitcoin, and must be present. The remaining characters are any plain text such as “The Habit 1” or “Starbucks-Reg 1”, more human readable information. The partial address serves as a check against a nearby attacker who may try
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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* section is specifically so that a recipient can broadcast their name/handle. Not so the recipient would broadcast the name of the Sender. On Thu, Feb 5, 2015 at 12:50 PM, Mike Hearn m...@plan99.net 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 MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC. Payment spam might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue. -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see Monkey Dude on my list and simply ask him is that you? If so, I send it. If there are two Monkey Dude's Then I have to bother with the address prefix, but not otherwise. [image: logo] *Paul Puey* CEO / Co-Founder, Airbitz Inc +1-619-850-8624 | http://airbitz.co | San Diego http://facebook.com/airbitz http://twitter.com/airbitz https://plus.google.com/118173667510609425617 https://go.airbitz.co/comments/feed/ http://linkedin.com/in/paulpuey https://angel.co/paul-puey *DOWNLOAD THE AIRBITZ WALLET:* https://play.google.com/store/apps/details?id=com.airbitz https://itunes.apple.com/us/app/airbitz/id843536046 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 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 hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location. e On Feb 5, 2015, at 1:36 PM, Mike Hearn m...@plan99.net 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 recognition. We're talking about BLE, still? The radio tech that runs in the so called junk bands because propagation is so poor? My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls. Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup. Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it. -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one. e On Feb 5, 2015, at 2:07 PM, Paul Puey p...@airbitz.co wrote: So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see Monkey Dude on my list and simply ask him is that you? 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 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 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 hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location. e On Feb 5, 2015, at 1:36 PM, Mike Hearn m...@plan99.net 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 recognition. We're talking about BLE, still? The radio tech that runs in the so called junk bands because propagation is so poor? My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls. Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup. Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it. -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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 specifically so that a recipient can broadcast their name/handle. Not so the recipient would broadcast the name of the Sender. [image: logo] *Paul Puey* CEO / Co-Founder, Airbitz Inc +1-619-850-8624 | http://airbitz.co | San Diego http://facebook.com/airbitz http://twitter.com/airbitz https://plus.google.com/118173667510609425617 https://go.airbitz.co/comments/feed/ http://linkedin.com/in/paulpuey https://angel.co/paul-puey *DOWNLOAD THE AIRBITZ WALLET:* https://play.google.com/store/apps/details?id=com.airbitz https://itunes.apple.com/us/app/airbitz/id843536046 On Thu, Feb 5, 2015 at 12:50 PM, Mike Hearn m...@plan99.net 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 MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC. Payment spam might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue. -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
The implementation on Airbitz does not encourage or even let a user broadcast a photo. Just an address prefix and name/handle. And it's only broadcast during the Receive request. Not generally while the app is running although that's up to the implementation. [image: logo] *Paul Puey* CEO / Co-Founder, Airbitz Inc +1-619-850-8624 | http://airbitz.co | San Diego http://facebook.com/airbitz http://twitter.com/airbitz https://plus.google.com/118173667510609425617 https://go.airbitz.co/comments/feed/ http://linkedin.com/in/paulpuey https://angel.co/paul-puey *DOWNLOAD THE AIRBITZ WALLET:* https://play.google.com/store/apps/details?id=com.airbitz https://itunes.apple.com/us/app/airbitz/id843536046 On Thu, 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 facial recognition. Yes you could photograph people but it's way more burdensome. Sorry to go off topic a little. On Feb 5, 2015, at 3:50 PM, Mike Hearn m...@plan99.net 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 MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC. Payment spam might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue. -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Although not perfect, and it may require visual/verbal verification, I don't see what the trust issue is. [image: logo] *Paul Puey* CEO / Co-Founder, Airbitz Inc +1-619-850-8624 | http://airbitz.co | San Diego http://facebook.com/airbitz http://twitter.com/airbitz https://plus.google.com/118173667510609425617 https://go.airbitz.co/comments/feed/ http://linkedin.com/in/paulpuey https://angel.co/paul-puey *DOWNLOAD THE AIRBITZ WALLET:* https://play.google.com/store/apps/details?id=com.airbitz https://itunes.apple.com/us/app/airbitz/id843536046 On Thu, Feb 5, 2015 at 2:05 PM, Eric Voskuil e...@voskuil.org wrote: 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* section is specifically so that a recipient can broadcast their name/handle. Not so the recipient would broadcast the name of the Sender. On Thu, Feb 5, 2015 at 12:50 PM, Mike Hearn m...@plan99.net 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 MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC. Payment spam might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue. -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Nakapay
All this talk about URI's, bluetooth, P2P wireless transmissions, etc... Ultimately, it is about a better user interface. Guys, I've already made Bitcoin invoicing and payments exceptionally easy with Nakapay. Now if only there's a wallet developer out there who would integrate it ... -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Personally I like the simplicity of tapping two phones together to make payment - it should be quicker and easier than scanning QR codes and it's a trust model that's hard to misunderstand. Is NFC good enough for that? I fear even with NFC it is possible to produce a device with longer range than one would expect. What happened to the idea of tapping two devices together and then comparing the timing of the tap (as detected by the phones' accelerometers) to make spoofing a transaction harder? I remember hearing about that years ago - is that still a thing? roy On Thu, Feb 05, 2015 at 02:10:51PM -0800, Eric Voskuil wrote: A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one. e On Feb 5, 2015, at 2:07 PM, Paul Puey p...@airbitz.co wrote: So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see Monkey Dude on my list and simply ask him is that you? 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 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 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 hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location. e On Feb 5, 2015, at 1:36 PM, Mike Hearn m...@plan99.net 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 recognition. We're talking about BLE, still? The radio tech that runs in the so called junk bands because propagation is so poor? My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls. Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup. Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it. -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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-the-air technology. You could try securing it using a CA or other identity server, but now you've excluded ad-hoc person-to-person payments. Plus, you need an active internet connection to reach the CA. You can try using proximity as a substitute for identity, like requiring NFC to kick-start the connection, but at that point you might as well use QR codes. This BIP is not trying to provide absolute bullet-proof security, since that's impossible given the physical limitations of the Bluetooth technology. Instead, it's trying to provide the best-possible security given those constraints. In exchange for this, we get greatly enhanced usability in common scenarios. There are plenty of usable, real-world technologies with big security holes. Anybody with lock-picking experience will tell you this, but nobody is welding their front door shut. The ability to go in and out is worth the security risk. Bluetooth payments add a whole new dimension to real-world Bitcoin usability. Do we shut that down because it can't be made perfect, or do we do the best we can and move forward? -William -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/05/2015 02:08 PM, Paul Puey wrote: Although not perfect, and it may require visual/verbal verification, I don't see what the trust issue is. I agree that with manual verification between the parties the worst problem becomes DOS, which is certainly not catastrophic. But the objective is to the extent possible improve upon the cumbersome process of QR code, NFC signal, or textual address scanning. Given that there would be no way to know you are under attack, with the exception of manual confirmation, it would seem unwise to ever rely on the automation. If the automation cannot be relied upon, it may actually make matters worse. People would either take their chances by relying on it or go through a more complex process. In terms of the difficulty of an attack, it's important to recognize that all attacks (DOS, privacy, integrity) in this scenario can be fully-automated and executed over the air by a black box at some distance: * DOS is possible by rebroadcasting a similar request. * Privacy is compromised by monitoring for payment requests and correlating them to location and potentially images of parties. * Integrity is compromised by either: (1) Rebroadcasting a similar transaction with a bogus address but with the same leading characters; can't be spent but you lose your money. (2) Rebroadcasting with a valid address that doesn't match the leading characters, in the expectation that the user doesn't check manually. Regarding possible mitigation via BIP-70: 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 cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. So the initial broadcast needs privacy, but then of course it cannot be a broadcast - it need to be a narrow cast. That brings us back to proximity-based establishment. I think that you could get away with this for a while, simply because of 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 jamming the original. You then only see one. e On Feb 5, 2015, at 2:07 PM, Paul Puey p...@airbitz.co mailto:p...@airbitz.co wrote: So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see Monkey Dude on my list and simply ask him is that you? 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 e...@voskuil.org mailto: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 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 hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location. e On Feb 5, 2015, at 1:36 PM, Mike Hearn m...@plan99.net mailto:m...@plan99.net 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 recognition. We're talking about BLE, still? The radio tech that runs in the so called junk bands because propagation is so poor? My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls. Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup. Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
I would like to shortly express my opinion: - Having BT as an alternative is good idea but it must be secure enough - Signed BIP70 should be enough. I see only two issues regarding BIP70 (but they apply also to TCP/IP, not just BT): key revocations and MITM attacks by governments. - Broadcasting faces is very bad idea IMHO. - Comparing addresses seems complicated but if hash was displayed as a unique, picture hard to be mistake or long phrase, it could be more convenient. - Maybe storing public key (I do NOT mean bitcoin address!) of merchant after successful transaction is good compromise? Another idea: I noticed it's extremely easy to compare two strings if they are the same size (in terms of millimeters, not number of characters). If the hash of signing key was printed on a sign near the POS in specified size (90% of smallest available screen?) and phone would scale correctly, just putting the phone near the sign would be enough to instantly spot whether the hashes are same. Maybe instead of hex/base58 hash encoding use colored barcode. But I'm not sure if it would improve things. 2015-02-05 23:49 GMT+01:00 Roy Badami r...@gnomon.org.uk: Personally I like the simplicity of tapping two phones together to make payment - it should be quicker and easier than scanning QR codes and it's a trust model that's hard to misunderstand. Is NFC good enough for that? I fear even with NFC it is possible to produce a device with longer range than one would expect. What happened to the idea of tapping two devices together and then comparing the timing of the tap (as detected by the phones' accelerometers) to make spoofing a transaction harder? I remember hearing about that years ago - is that still a thing? roy On Thu, Feb 05, 2015 at 02:10:51PM -0800, Eric Voskuil wrote: A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one. e On Feb 5, 2015, at 2:07 PM, Paul Puey p...@airbitz.co wrote: So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see Monkey Dude on my list and simply ask him is that you? 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 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 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 hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location. e On Feb 5, 2015, at 1:36 PM, Mike Hearn m...@plan99.net 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 recognition. We're talking about BLE, still? The radio tech that runs in the so called junk bands because propagation is so poor? My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls. Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup. Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it. -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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 cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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 cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? Hi Martin, The problem is that you need to verify the ownership of the public key. A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). But the problem is then establishing that secret over a public channel. You can bootstrap a private session over the untrusted network using a trusted public key (PKI/WoT). But the presumption is that you are already doing this over the web (using TLS). That process is subject to attack at the CA. WoT is not subject to a CA attack, because it's decentralized. But it's also not sufficiently deployed for some scenarios. 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 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
Hello, With the recent discussion started today regarding another bluetooth communication proposal created by Airbitz, I'd like to bring people's attention back to this proposal that saw little discussion last fall. I guess I'm not sure why two proposals are being created. Is their some advantage of using bluetooth low energy over standard bluetooth (I'm not well versed in bluetooth low energy)? This NFC coupled approach seems to avoid a lot of issues with identifying the correct payee. You can see this proposed scheme demonstrated in action in a POS application in the video link below which demonstrates it with my fuel pump and Andreas Schildbach's wallet. There was a small discussion that occurred after my original announcement below. If you are new to this e-mail list, you can find an archive of those few replies here: https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html Since this original announcement, a few improvements have been made to the proposal: 1. Improved documentation and explanation of the use cases in Schildbach's wallet's wiki 1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests 2. Issue with the payment_url field has resolved by changing to a repeated field and requiring the wallet to search for the protocol they want to use, rather than expecting it to be a certain element number in the list. 1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki Although there are some interesting use cases of Airbitz's proposal's work flow, tapping an NFC radio with a 5 mm range requires much less brain power and time than picking the correct name on the app's screen. The manual name picking is going to be especially crazy in a very congested location. The payer isn't ever going to want to have to try and figure out what register or payment terminal they are at for most applications I would ever use. I'd like to see something happen with this technology. I've also noticed that micropayment channels have little formality to being established practically and it would be awesome if they could be managed over bluetooth as well. Maybe more improvements to the payment protocol can simultaneously result (and also extended to bluetooth) that embrace the establishment of micropayment channels. Andy Schroder On 10/17/2014 03:58 PM, Andy Schroder wrote: Hello, I'd like to introduce two proposed BIPs. They are primarily focused on implementing the payment protocol using bluetooth connections. I've been working on automated point of sale devices and bluetooth communication is critical in my mind due to the potential lack of internet access at many points of sale, either due to lack of cellular internet coverage, lack of payee providing wireless internet, and/or due to financial constraints of the payer prohibiting them from maintaining a cellular internet service plan. These BIPs are largely modeled after the current functionality of Andreas Schildbach's android Bitcoin Wallet's bluetooth capability. I've discussed the communication scheme with him in depth and believe these proposals to clearly and accurately represent the communication scheme. There is also an additional h= parameter added to the bitcoin: URI scheme which applies to both bluetooth and http payment protocol requests which allows for a hash of the payment request to be included. This hash was proposed by Andreas as an amendment to BIP72, but others preferred not to amend BIP72 since it has already been put into place. The current version of Schildbach's bitcoin wallet already supports the h parameter. I'd appreciate feedback from everyone, particularly wallet developers as widespread bluetooth support among wallets is very important to me. I'm also very new to this mailing list as well as the BIP writing process, so I'd appreciate your understanding if my conventions are not standard. I am currently using the naming conventions TBIP, so that I can propose /temporary/ BIP numbers, and cross reference between the two. Obviously these will change if the BIPs are formally adopted. You can find a copy of these proposed BIPs at the following links: * https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki * https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki If you are interested, you can see a demonstration of many of the proposed features using Schildbach's wallet and my fuel pump in a video I recently created: https://youtu.be/kkVAhA75k1Y . The main thing not implemented is multiple URLs for the payment protocol, so, as a hack, I'm just presenting https vi QR code and bluetooth via NFC on my fuel pump for now. There are a few known issues that could be improved to this bluetooth communication scheme as well as the general payment protocol and myself and Andreas would like to receive feedback regarding concerns and potential solutions. Some of
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/05/2015 03:34 PM, Roy Badami wrote: For peer-to-peer payments, how common do we think that the payment is of an ad hoc nature rather than to a known contact? If I want to pay my friends/colleagues/etc over a restaurant table there's no reason why I couldn't already have their public keys in my contact list - then it would be pretty straightforward to have a watertight mechanism where I would know who I was paying. You could probably even relatively securely bootstrap a key exchange over SMS, relying only on the contacts already having each other in their phonebooks. 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 certainly communicate in private as peers where you trust that you share a public key. The core issue here is really bootstrapping of that trust in an ad hoc manner. As for comsumer-to-merchant transactions where the merchant is a bricks and mortar merchant, IMHO it absolutely has to be pay that terminal over there. It's the trust model we all currently use - whether paying cash or card - and it's the only trust model that works IMHO (and customers and businesses alike are well aware of the risks of a fraudster standing behind the counter pretending to be an employee accepting payment - and by and large are pretty good at mitigating it). OTOH as we've discussed here before there are many use cases where the custoemr doesn't actually know or care about the name of the shop or bar they walked into but is pretty damn sure that they need to make payment to the person over there behind the counter. Yes, proximity is practically the universal solution to the problem of the payer identifying the correct seller in any face-to-face scenario. Granted, there are cases taht dont' fall into either of the above - but they're the cases that are (a) harder to figure out how to authenticate and consequently (b) the use cases that are going to be most subject to attempted fraud. When identification is required (show me some id before I pay you) it equates to the BIP-70 scenario 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 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-the-air technology. You could try securing it using a CA or other identity server, but now you've excluded ad-hoc person-to-person payments. Plus, you need an active internet connection to reach the CA. You can try using proximity as a substitute for identity, like requiring NFC to kick-start the connection, but at that point you might as well use QR codes. This BIP is not trying to provide absolute bullet-proof security, since that's impossible given the physical limitations of the Bluetooth technology. Instead, it's trying to provide the best-possible security given those constraints. In exchange for this, we get greatly enhanced usability in common scenarios. There are plenty of usable, real-world technologies with big security holes. Anybody with lock-picking experience will tell you this, but nobody is welding their front door shut. The ability to go in and out is worth the security risk. Bluetooth payments add a whole new dimension to real-world Bitcoin usability. Do we shut that down because it can't be made perfect, or do we do the best we can and move forward? -William -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development 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 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. http://goparallel.sourceforge.net/___
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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 actually secure and convenient way to do it. You should do that too. :) I was analyzing the model as you described it to me. A formal analysis of the security model of a particular implementation, based on inference from source code, is a bit beyond what I signed up for. But I'm perfectly willing to comment on your description of the model if you are willing to indulge me. Shortly, how it works: The initiator of the connection sends commit message containing the hash of his temporary public ECDH part, second party sends back their public ECDH part and then initiator sends his public ECDH part in open. All three messages are hashed together and the first two bytes are used to select two words from a shared dictionary which are displayed on the screen of both the initiator and the second party. The parties communicate those two words and verify they match. How do they compare words if they haven't yet established a secure channel? If an attacker wants to do MITM, he has a chance of choosing right public parts 1:65536. There is no way to brute-force it, since that would be noticed immediately. If instead of two words based on the first two bytes, four words from BIP39 wordlist were chosen, it would provide entropy of 44 bits which I believe should be enough even for paranoid people. How this would work in Bitcoin payment scenario: user's phone broadcasts his name, merchant inputs amount and selects the name from the list, commit message is sent (and then the remaining 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 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 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 cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? Hi Martin, The problem is that you need to verify the ownership of the public key. A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). But the problem is then establishing that secret over a public channel. You can bootstrap a private session over the untrusted network using a trusted public key (PKI/WoT). But the presumption is that you are already doing this over the web (using TLS). That process is subject to attack at the CA. WoT is not subject to a CA attack, because it's decentralized. But it's also not sufficiently deployed for some scenarios. 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 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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. :) In case of RedPhone, you read those words verbally over not-yet-verified channel relying on difficulty of spoofing your voice. Also the app remembers the public keys, so you don't need to verify second time. I suggest you to try RedPhone (called Signal on iPhone) yourself. It's free/open source, Internet-based and end-to-end encrypted. You may find it useful some day. Also I'm willing to help you with trying it after I wake up. (~8 hours: Send me private e-mail if you want to.) 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 actually secure and convenient way to do it. You should do that too. :) I was analyzing the model as you described it to me. A formal analysis of the security model of a particular implementation, based on inference from source code, is a bit beyond what I signed up for. But I'm perfectly willing to comment on your description of the model if you are willing to indulge me. Shortly, how it works: The initiator of the connection sends commit message containing the hash of his temporary public ECDH part, second party sends back their public ECDH part and then initiator sends his public ECDH part in open. All three messages are hashed together and the first two bytes are used to select two words from a shared dictionary which are displayed on the screen of both the initiator and the second party. The parties communicate those two words and verify they match. How do they compare words if they haven't yet established a secure channel? If an attacker wants to do MITM, he has a chance of choosing right public parts 1:65536. There is no way to brute-force it, since that would be noticed immediately. If instead of two words based on the first two bytes, four words from BIP39 wordlist were chosen, it would provide entropy of 44 bits which I believe should be enough even for paranoid people. How this would work in Bitcoin payment scenario: user's phone broadcasts his name, merchant inputs amount and selects the name from the list, commit message is sent (and then the remaining 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 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 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 cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? Hi Martin, The problem is that you need to verify the ownership of the public key. A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). But the problem is then establishing that secret over a public channel. You can bootstrap a private session over the untrusted network using a trusted public key (PKI/WoT). But the presumption is that you are already doing this over the web (using TLS). That process is subject to attack at the CA. WoT is not subject to a CA attack, because it's decentralized. But it's also not sufficiently deployed for some scenarios. e - -- Odoslané z môjho Android zariadenia pomocou K-9 Mail. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iI8EAREKADcFAlTUDKEwHE1hcnRpbiBIYWJvdmF0aWFrIDxtYXJ0aW4uaGFib3Zz dGlha0BnbWFpbC5jb20+AAoJED6C3NvqapyUfUgA/2j6jQELBtSrNsle7ybGq1D8 uWgGwevguCnjPd0pEpWgAP42sS/ekCqs1v9wbART9fLprZTBk4YPllwXifss+9sa zQ== =J4w/ -END PGP SIGNATURE- -- Dive into the World of Parallel Programming. The Go Parallel Website,
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
For peer-to-peer payments, how common do we think that the payment is of an ad hoc nature rather than to a known contact? If I want to pay my friends/colleagues/etc over a restaurant table there's no reason why I couldn't already have their public keys in my contact list - then it would be pretty straightforward to have a watertight mechanism where I would know who I was paying. You could probably even relatively securely bootstrap a key exchange over SMS, relying only on the contacts already having each other in their phonebooks. As for comsumer-to-merchant transactions where the merchant is a bricks and mortar merchant, IMHO it absolutely has to be pay that terminal over there. It's the trust model we all currently use - whether paying cash or card - and it's the only trust model that works IMHO (and customers and businesses alike are well aware of the risks of a fraudster standing behind the counter pretending to be an employee accepting payment - and by and large are pretty good at mitigating it). OTOH as we've discussed here before there are many use cases where the custoemr doesn't actually know or care about the name of the shop or bar they walked into but is pretty damn sure that they need to make payment to the person over there behind the counter. Granted, there are cases taht dont' fall into either of the above - but they're the cases that are (a) harder to figure out how to authenticate and consequently (b) the use cases that are going to be most subject to attempted fraud. roy On Thu, Feb 05, 2015 at 03:02:56PM -0800, 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-the-air technology. You could try securing it using a CA or other identity server, but now you've excluded ad-hoc person-to-person payments. Plus, you need an active internet connection to reach the CA. You can try using proximity as a substitute for identity, like requiring NFC to kick-start the connection, but at that point you might as well use QR codes. This BIP is not trying to provide absolute bullet-proof security, since that's impossible given the physical limitations of the Bluetooth technology. Instead, it's trying to provide the best-possible security given those constraints. In exchange for this, we get greatly enhanced usability in common scenarios. There are plenty of usable, real-world technologies with big security holes. Anybody with lock-picking experience will tell you this, but nobody is welding their front door shut. The ability to go in and out is worth the security risk. Bluetooth payments add a whole new dimension to real-world Bitcoin usability. Do we shut that down because it can't be made perfect, or do we do the best we can and move forward? -William -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
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 links now I'm encouraged, but I see several things that I'd like to discuss at greater length than is appropriate here. 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. For payment purposes the lower bandwidth isn't much of a hit. e On 02/05/2015 03:38 PM, Andy Schroder wrote: Hello, With the recent discussion started today regarding another bluetooth communication proposal created by Airbitz, I'd like to bring people's attention back to this proposal that saw little discussion last fall. I guess I'm not sure why two proposals are being created. Is their some advantage of using bluetooth low energy over standard bluetooth (I'm not well versed in bluetooth low energy)? This NFC coupled approach seems to avoid a lot of issues with identifying the correct payee. You can see this proposed scheme demonstrated in action in a POS application in the video link below which demonstrates it with my fuel pump and Andreas Schildbach's wallet. There was a small discussion that occurred after my original announcement below. If you are new to this e-mail list, you can find an archive of those few replies here: https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html Since this original announcement, a few improvements have been made to the proposal: 1. Improved documentation and explanation of the use cases in Schildbach's wallet's wiki 1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests 2. Issue with the payment_url field has resolved by changing to a repeated field and requiring the wallet to search for the protocol they want to use, rather than expecting it to be a certain element number in the list. 1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki Although there are some interesting use cases of Airbitz's proposal's work flow, tapping an NFC radio with a 5 mm range requires much less brain power and time than picking the correct name on the app's screen. The manual name picking is going to be especially crazy in a very congested location. The payer isn't ever going to want to have to try and figure out what register or payment terminal they are at for most applications I would ever use. I'd like to see something happen with this technology. I've also noticed that micropayment channels have little formality to being established practically and it would be awesome if they could be managed over bluetooth as well. Maybe more improvements to the payment protocol can simultaneously result (and also extended to bluetooth) that embrace the establishment of micropayment channels. Andy Schroder On 10/17/2014 03:58 PM, Andy Schroder wrote: Hello, I'd like to introduce two proposed BIPs. They are primarily focused on implementing the payment protocol using bluetooth connections. I've been working on automated point of sale devices and bluetooth communication is critical in my mind due to the potential lack of internet access at many points of sale, either due to lack of cellular internet coverage, lack of payee providing wireless internet, and/or due to financial constraints of the payer prohibiting them from maintaining a cellular internet service plan. These BIPs are largely modeled after the current functionality of Andreas Schildbach's android Bitcoin Wallet's bluetooth capability. I've discussed the communication scheme with him in depth and believe these proposals to clearly and accurately represent the communication scheme. There is also an additional h= parameter added to the bitcoin: URI scheme which applies to both bluetooth and http payment protocol requests which allows for a hash of the payment request to be included. This hash was proposed by Andreas as an amendment to BIP72, but others preferred not to amend BIP72 since it has already been put into place. The current version of Schildbach's bitcoin wallet already supports the h parameter. I'd appreciate feedback from everyone, particularly wallet developers as widespread bluetooth support among wallets is very important to me. I'm also very new to this mailing list as well as the BIP writing process, so I'd appreciate your understanding if my conventions are not standard. I am currently using the naming conventions TBIP, so that I can propose /temporary/ BIP numbers, and cross reference between the two. Obviously these will change if the BIPs are formally adopted. You can find a copy of these proposed BIPs at the following links:
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Commit protocol provides both better user experience and better security. Dňa 6. februára 2015 1:49:12 CET používateľ Paul Puey p...@airbitz.co napísal: The trust can be considered bootstrapped by visual verification of the address prefix. If we are really concerned about someone jamming a Bluetooth signal in a coffeeshop then the UI can encourage verification of the prefix. Much like how regular Bluetooth requires 'pairing' via entering a 4-6 digit code. Paul Puey CEO / Co-Founder, Airbitz Inc 619.850.8624 | http://airbitz.co | San Diego On Feb 5, 2015, at 3:46 PM, Eric Voskuil e...@voskuil.org wrote: 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 cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? Hi Martin, The problem is that you need to verify the ownership of the public key. A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). But the problem is then establishing that secret over a public channel. You can bootstrap a private session over the untrusted network using a trusted public key (PKI/WoT). But the presumption is that you are already doing this over the web (using TLS). That process is subject to attack at the CA. WoT is not subject to a CA attack, because it's decentralized. But it's also not sufficiently deployed for some scenarios. e - -- Odoslané z môjho Android zariadenia pomocou K-9 Mail. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iI8EAREKADcFAlTUD/AwHE1hcnRpbiBIYWJvdmF0aWFrIDxtYXJ0aW4uaGFib3Zz dGlha0BnbWFpbC5jb20+AAoJED6C3NvqapyUPwgA/0eVlJYeA3fYmVb1zVA8j1l/ kjOhc9CIDYL9ifk8N0t/AP4mC4CwmZoNXqr24le5WdYeBeyHMiDMtJrRfwQkN1LG dQ== =pY76 -END PGP SIGNATURE- -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
On 02/05/2015 04:49 PM, Paul Puey wrote: The trust can be considered bootstrapped by visual verification of the address prefix. Another (unspendable) address can trivially match the prefix. Imagine someone walking around in a mall with a phone in the pocket with a malicious app, just disrupting business by causing money to be burned. Manual verification doesn't fix this attack. If we are really concerned about someone jamming a Bluetooth signal in a coffeeshop then the UI can encourage verification of the prefix. I don't think it would be great to constrain a standard implementation to low cost purchases or the need for manual verification, but again manual prefix verification isn't actually a solution. Much like how regular Bluetooth requires 'pairing' via entering a 4-6 digit code. An appeal to the security of BT bootstrapping 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 On Feb 5, 2015, at 3:46 PM, Eric Voskuil e...@voskuil.org mailto:e...@voskuil.org wrote: 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 cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? Hi Martin, The problem is that you need to verify the ownership of the public key. A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). But the problem is then establishing that secret over a public channel. You can bootstrap a private session over the untrusted network using a trusted public key (PKI/WoT). But the presumption is that you are already doing this over the web (using TLS). That process is subject to attack at the CA. WoT is not subject to a CA attack, because it's decentralized. But it's also not sufficiently deployed for some scenarios. 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 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] determining change addresses using the least significant digits
On Wed, Feb 04, 2015 at 03:23:23PM +0100, Isidor Zeuner wrote: Hi there, traditionally, the Bitcoin client strives to hide which output addresses are change addresses going back to the payer. However, especially with today's dynamically calculated miner fees, this may often be ineffective: A user sending a payment using the Bitcoin client will usually enter the payment amount only up to the number of digits which are considered to be significant enough. So, the least significant digits will often be zero for the payment. With dynamically calculated miner fees, this will often not be the case for the change amount, making it easy for an observer to classify the output addresses. A possible approach to handle this issue would be to add a randomized offset amount to the payment amount. This offset amount can be small in comparison to the payment amount. Any thoughts? Have you looked at Armory? IIRC they do this kind of stuff. -- 'peter'[:-1]@petertodd.org 165ecbd638ec09226f84c34d3d775d34ca5df4abfa8cb57c signature.asc Description: Digital signature -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
On Wed, Feb 04, 2015 at 02:54:43PM +0100, Isidor Zeuner wrote: Hi there, comments in-line: I later wrote up the idea in the context of adding Zerocoin to Bitcoin: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html For the sake of maximum clarity with respect to modelling the value of a Bitcoin, I don't think that approaches which change the number of coins that can possibly be circulated should be encouraged. So, I like the idea of having the sacrificed coins appearing in the mining fees in a future block. But what is meant with OP_DEPTH in this context? From what I read, this operation just manipulates the stack size when evaluating the script, so I don't see how it would affect miner incentives. Oh, where I was saying OP_DEPTH, I was referring to a *hypothetical* opcode; I'd forgotten when I wrote that post that OP_DEPTH is an real opcode. These days I'd suggest you use the (upcoming on BTC/live on Viacoin) OP_CHECKLOCKTIMEVERIFY opcode instead. Pretty simple really: current blockheight + 1 year worth of blocks CHECKLOCKTIMEVERIFY -- 'peter'[:-1]@petertodd.org 165ecbd638ec09226f84c34d3d775d34ca5df4abfa8cb57c signature.asc Description: Digital signature -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Although consumer to merchant is a use case for BLE I would argue that NFC has a higher chance of providing a better user experience in most cases since, at least on Android, a user can tap their phone without even having a wallet running. The URI handler will launch the wallet for them. However a dedicated, user facing, screen can give certainty that the user is connecting to the correct recipient. 1. Because it can show an address prefix 2. It can display the users nickname/handle upon connecting which is only sent to the merchant upon a point to point connection. Not a broadcast. The Airbitz wallet already does this on the recipient side. A popup shows the most recent person connecting to the recipient. Paul Puey CEO / Co-Founder, Airbitz Inc 619.850.8624 | http://airbitz.co | San Diego On Feb 5, 2015, at 3:34 PM, Roy Badami r...@gnomon.org.uk wrote: For peer-to-peer payments, how common do we think that the payment is of an ad hoc nature rather than to a known contact? If I want to pay my friends/colleagues/etc over a restaurant table there's no reason why I couldn't already have their public keys in my contact list - then it would be pretty straightforward to have a watertight mechanism where I would know who I was paying. You could probably even relatively securely bootstrap a key exchange over SMS, relying only on the contacts already having each other in their phonebooks. As for comsumer-to-merchant transactions where the merchant is a bricks and mortar merchant, IMHO it absolutely has to be pay that terminal over there. It's the trust model we all currently use - whether paying cash or card - and it's the only trust model that works IMHO (and customers and businesses alike are well aware of the risks of a fraudster standing behind the counter pretending to be an employee accepting payment - and by and large are pretty good at mitigating it). OTOH as we've discussed here before there are many use cases where the custoemr doesn't actually know or care about the name of the shop or bar they walked into but is pretty damn sure that they need to make payment to the person over there behind the counter. Granted, there are cases taht dont' fall into either of the above - but they're the cases that are (a) harder to figure out how to authenticate and consequently (b) the use cases that are going to be most subject to attempted fraud. roy On Thu, Feb 05, 2015 at 03:02:56PM -0800, 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-the-air technology. You could try securing it using a CA or other identity server, but now you've excluded ad-hoc person-to-person payments. Plus, you need an active internet connection to reach the CA. You can try using proximity as a substitute for identity, like requiring NFC to kick-start the connection, but at that point you might as well use QR codes. This BIP is not trying to provide absolute bullet-proof security, since that's impossible given the physical limitations of the Bluetooth technology. Instead, it's trying to provide the best-possible security given those constraints. In exchange for this, we get greatly enhanced usability in common scenarios. There are plenty of usable, real-world technologies with big security holes. Anybody with lock-picking experience will tell you this, but nobody is welding their front door shut. The ability to go in and out is worth the security risk. Bluetooth payments add a whole new dimension to real-world Bitcoin usability. Do we shut that down because it can't be made perfect, or do we do the best we can and move forward? -William -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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.
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
The trust can be considered bootstrapped by visual verification of the address prefix. If we are really concerned about someone jamming a Bluetooth signal in a coffeeshop then the UI can encourage verification of the prefix. Much like how regular Bluetooth requires 'pairing' via entering a 4-6 digit code. Paul Puey CEO / Co-Founder, Airbitz Inc 619.850.8624 | http://airbitz.co | San Diego On Feb 5, 2015, at 3:46 PM, Eric Voskuil e...@voskuil.org wrote: 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 cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? Hi Martin, The problem is that you need to verify the ownership of the public key. A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). But the problem is then establishing that secret over a public channel. You can bootstrap a private session over the untrusted network using a trusted public key (PKI/WoT). But the presumption is that you are already doing this over the web (using TLS). That process is subject to attack at the CA. WoT is not subject to a CA attack, because it's decentralized. But it's also not sufficiently deployed for some scenarios. e -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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: A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). I said this could only be accomplished using a shared secret or a trusted public key. Exchanging a value that is derived from a pair of public keys is a distinction without a difference. The problem remains that the parties must have a secure/out-of-band channel for communicating this value. The fact that they are face-to-face establishes this channel, but that brings us back to the original problem, as it requires manual verification - as in visual/audible scanning of the two values for comparison. At that point the visual comparison of the address, or some value derived from it, is simpler. In case of RedPhone, you read those words verbally over not-yet- verified channel relying on difficulty of spoofing your voice. Also the app remembers the public keys, so you don't need to verify second time. This is reasonable, but wouldn't help in the case of an ad-hoc connection between parties who don't know each other well. I suggest you to try RedPhone (called Signal on iPhone) yourself. It's free/open source, Internet-based and end-to-end encrypted. You may find it useful some day. Also I'm willing to help you with trying it after I wake up. (~8 hours: Send me private e-mail if you want to.) I appreciate the offer. I really don'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 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 actually secure and convenient way to do it. You should do that too. :) I was analyzing the model as you described it to me. A formal analysis of the security model of a particular implementation, based on inference from source code, is a bit beyond what I signed up for. But I'm perfectly willing to comment on your description of the model if you are willing to indulge me. Shortly, how it works: The initiator of the connection sends commit message containing the hash of his temporary public ECDH part, second party sends back their public ECDH part and then initiator sends his public ECDH part in open. All three messages are hashed together and the first two bytes are used to select two words from a shared dictionary which are displayed on the screen of both the initiator and the second party. The parties communicate those two words and verify they match. How do they compare words if they haven't yet established a secure channel? If an attacker wants to do MITM, he has a chance of choosing right public parts 1:65536. There is no way to brute-force it, since that would be noticed immediately. If instead of two words based on the first two bytes, four words from BIP39 wordlist were chosen, it would provide entropy of 44 bits which I believe should be enough even for paranoid people. How this would work in Bitcoin payment scenario: user's phone broadcasts his name, merchant inputs amount and selects the name from the list, commit message is sent (and then the remaining 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 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 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 cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? Hi
[Bitcoin-development] Bitcoin Core 0.10.0rc4 tagged
FYI, I've just tagged v0.10rc4, and pushed my signatures to the gitian.sigs repository. Please start your gitian builders! Changes relative to rc3: - 1eb14af Increase block download timeout base from 10 to 20 minutes. - 3916a81 Increase coverage of DERSIG edge cases - 6da2028 Add RPC test for DERSIG BIP switchover logic - 773c30d BIP66 changeover logic - 18695f0 Example unit tests from BIP66 - abfbeaf Change IsDERSignature to BIP66 implementation - b6347bf Fix priority calculation in CreateTransaction - 2448d34 Avoid storing a reference passed to SignatureChecker constructors - 1bbad80 Use separate SignatureChecker for CMutableTransaction - 6a02ef8 [Qt] don't allow amount changes when AmountSpinBox is read-only - b61940b Change Coin Control first column label - c5044bc sleep-wait on genesis block during init with -reindex - b24ff47 Make empty byte arrays pass CheckSignatureEncoding() - ed4206a fix crash: CoinControl space bug - 58259ad qt: fix broken unicode chars on osx 10.10 - aaf55d2 186a517 Add a -rpckeepalive option to disable RPC use of HTTP persistent connections. Hopefully this will be the last release candidate before the 0.10 final release. Wladimir -- 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. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Thanks for all the feedback Eric. You know we value all that you have to say. That's what this forum is for. We're looking for great ideas to harden this protocol and we're not closed to better ideas and we'll improve it as suggestions come up. Paul Puey CEO / Co-Founder, Airbitz Inc 619.850.8624 | http://airbitz.co | San Diego On Feb 5, 2015, at 5:05 PM, Eric Voskuil e...@voskuil.org wrote: On 02/05/2015 04:49 PM, Paul Puey wrote: The trust can be considered bootstrapped by visual verification of the address prefix. Another (unspendable) address can trivially match the prefix. Imagine someone walking around in a mall with a phone in the pocket with a malicious app, just disrupting business by causing money to be burned. Manual verification doesn't fix this attack. If we are really concerned about someone jamming a Bluetooth signal in a coffeeshop then the UI can encourage verification of the prefix. I don't think it would be great to constrain a standard implementation to low cost purchases or the need for manual verification, but again manual prefix verification isn't actually a solution. Much like how regular Bluetooth requires 'pairing' via entering a 4-6 digit code. An appeal to the security of BT bootstrapping 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 On Feb 5, 2015, at 3:46 PM, Eric Voskuil e...@voskuil.org mailto:e...@voskuil.org wrote: 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 cryptographically tainted. This is also the problem with BIP-70 over the web. TLS and other security precautions aside, an interloper on the communication, desktop, datacenter, etc., can capture payment requests and strongly correlate transactions to identities in an automated manner. The payment request must be kept private between the parties, and that's hard to do. What about using encryption with forward secrecy? Merchant would generate signed request containing public ECDH part, buyer would send back transaction encrypted with ECDH and his public ECDH part. If receiving address/amount is meant to be private, use commit protocol (see ZRTP/RedPhone) and short authentication phrase (which is hard to spoof thanks to commit protocol - see RedPhone)? Hi Martin, The problem is that you need to verify the ownership of the public key. A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). But the problem is then establishing that secret over a public channel. You can bootstrap a private session over the untrusted network using a trusted public key (PKI/WoT). But the presumption is that you are already doing this over the web (using TLS). That process is subject to attack at the CA. WoT is not subject to a CA attack, because it's decentralized. But it's also not sufficiently deployed for some scenarios. e -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements
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 possible for this bluetooth application considering the connection is not yet encrypted (mentioned below), and even if it were, it seems like it is always going to be better in case there is some vulnerability. From my testing with a bluetooth radio inside my metal cabinet, the range is ~5 meters, which is more than enough. However, the connection is actually a bit slow when the whole certificate chain is included (~3-4s). You can sort of see this in my video (http://youtu.be/kkVAhA75k1Y?t=7m39s). A lot of the time is actually spent verifying the signature, and I'm not sure how much of it is doing the fetching (I haven't done any detailed timings using adb logcat and looking at the log entries), but I do know it is a little slower than an HTTPS payment request fetch over wifi (~2-3s). The reason I know most of the time is the signature verification is because an HTTPS payment request fetch over wifi and verification using breadwallet on apple is much faster (1s) than HTTPS payment request on bitcoin wallet on android (apparently apple has a significantly more optimized signature verification algorithm). Bottom line is that there may be ~1s time transferring the data with this current bluetooth connection. Not sure how slow it will be with the BLE connection. Time is everything in a point of sale application. So, I guess what I am saying is it seems like the lower speed and range gain with bluetooth low energy are not a benefit in my opinion. I'm not sure that the latency gain will be a benefit either unless the speed issues I am noticing with regular bluetooth are actually a latency issue with just getting the connection established, or actually transmitting the payment request data. How much power is going to be used for just a few second payment? It's not like the bluetooth connection is maintained for a long time like it may be in other non bitcoin use cases. Where is a more appropriate place to discuss the other issues you have at length? 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 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] determining change addresses using the least significant digits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/04/2015 02:23 PM, Isidor Zeuner wrote: Hi there, traditionally, the Bitcoin client strives to hide which output addresses are change addresses going back to the payer. However, especially with today's dynamically calculated miner fees, this may often be ineffective: A user sending a payment using the Bitcoin client will usually enter the payment amount only up to the number of digits which are considered to be significant enough. So, the least significant digits will often be zero for the payment. With dynamically calculated miner fees, this will often not be the case for the change amount, making it easy for an observer to classify the output addresses. A possible approach to handle this issue would be to add a randomized offset amount to the payment amount. This offset amount can be small in comparison to the payment amount. Another possible approach is to randomize the number of change outputs from transaction to transaction. Doing this, it would be possible to make change outputs that mimic real spends (low number of s.d.) - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU1DH9AAoJECpf2nDq2eYjt2gP/3gpojJey2URkWWk0sg9dpHU OsD37TCbrwUaS/K8UMKsuc45FSJU/EeYpaVz9r1Ifm/IeaFYPIX0tEm17n3hkcAG QPmt/xAZn9GVyPWYKjmVDmx574pqiJLeZh8bP788sZsGc4Gk7NNJniVGLtsmvFCb ZOtwS8v7UuJZx6awydrpNhw/+SsQn9Xdb8fcLqmFKWDpG2Mlrv+ds34NMlGbfO2r PqCMw1Y12J0HXLisOCGQNZNdG9mVjKw3MP0GGjUlOM+ibrrorqoO5Ifo2RGuElgw LZkzzDzg6kO8iuNOV7Jg1lz5WftRjgLRSCcMq4V+793zGJW9BeISeDcKQ2ZlWMXB Hu83m4vCYOJeECdKGWlhyTmKNNHshsiPz3SBDLxP8uR80UkS3waDIXwLxGX9Pa63 uleaZ2qHQ/0UdC9opN3Snn33M701dHNJH9iXfhf/MVnUZ0FjzsLXaJ0F0208ZxCX qGCAv5y1ijrDlCLTvakZJRIruXgxNPqtErzP9GtgXeGeDc8tRv00WiM9Olpu0EXd yjhAZGydcE3Ec2cNo+teWjeDt4Ga4OYDb7i08eegaDuj5MCDcDtlgfwNjdKbre1x S7pKKDn8V03/WST1x9fWjM04NxeSjJ0yRjOAxkLV/mlDX6lQEYJL/W+MJLvpOnTC LtZrkSmSTJ7ZR0tMgpAe =8EVe -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
The BIP70 protocol would preclude individuals from utilizing the P2P transfer spec. It would also require that a Sender have internet connectivity to get the payment protocol info. BLE could enable payment w/o internet by first transferring the URI to from Recipient to Sender. Then in the future, we could sign a Tx and send it over BLE back to the recipient (who would still need internet to verify the Tx). This is an important use case for areas with poor 3G/4G connectivity as I've experience myself. Also, due to Android issues, NFC is incredibly clunky. The URI Sender is required to tap the screen *while* the two phones are in contact. We support NFC the same way Bitcoin Wallet does, but unless the payment recipient has a custom Android device (which a merchant might) then the usage model is worse than scanning a QR code. BLE also allows people to pay at a distance such as for a donation to a live performer. We'll look at adding this to the Motivation section. [image: logo] *Paul Puey* CEO / Co-Founder, Airbitz Inc +1-619-850-8624 | http://airbitz.co | San Diego http://facebook.com/airbitz http://twitter.com/airbitz https://plus.google.com/118173667510609425617 https://go.airbitz.co/comments/feed/ http://linkedin.com/in/paulpuey https://angel.co/paul-puey *DOWNLOAD THE AIRBITZ WALLET:* https://play.google.com/store/apps/details?id=com.airbitz https://itunes.apple.com/us/app/airbitz/id843536046 From: Andreas Schildbach andreas@sc... - 2015-02-05 13:47:04 Thanks Paul, for writing up your protocol! First thoughts: For a BIP standard, I think we should skip bitcoin: URIs entirely and publish BIP70 payment requests instead. URIs mainly stick around because of QR codes limited capacity. BIP70 would partly address the copycat problem by signing payment requests. In your Motivation section, I miss some words about NFC. NFC already addresses all of the usability issues mentioned and is supported by mobile wallets since 2011. That doesn't mean your method doesn't make sense in some situations, but I think it should be explained why to prefer broadcasting payment requests over picking them up via near field radio. -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Thanks for CC'ing me Mike. Having trouble receiving maillist list posts. Even if a user could get the BIP70 URL in the URI, they would still need internet to access the URL. This BLE spec doesn't preclude BIP70, but can work with it while still allowing individuals without a certificate to broadcast a request. The issue of confused payments becomes less so if the Recipient broadcasts a name along with the 10 digit public addr prefix. Only if there is a name conflict will the user have to be concerned with the prefix. The name can be something like Mikes Coffee #1 and it can have a Register #1 at the counter. A customer facing screen can also show the 10 digit prefix. [image: logo] *Paul Puey* CEO / Co-Founder, Airbitz Inc +1-619-850-8624 | http://airbitz.co | San Diego http://facebook.com/airbitz http://twitter.com/airbitz https://plus.google.com/118173667510609425617 https://go.airbitz.co/comments/feed/ http://linkedin.com/in/paulpuey https://angel.co/paul-puey *DOWNLOAD THE AIRBITZ WALLET:* https://play.google.com/store/apps/details?id=com.airbitz https://itunes.apple.com/us/app/airbitz/id843536046 On Thu, Feb 5, 2015 at 12:28 PM, Mike Hearn m...@plan99.net wrote: BIP70 requests can be sent over bluetooth as well, as can transactions. Bitcoin Wallet can already send money even when offline by doing this. It's transparent to the user. I mean original Bluetooth in this context - BLE has incredibly tight data constraints and isn't really meant for data transfer. Yes Android Beam has a pretty stupid UI. You can actually tap the devices, take them away and then press, but that's not obvious at all. There have been new APIs added in recent releases that give more control over this, so it's possible we can revisit things and make the UI better these days. 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. The issue of confused payments remains in other situations though. For the coffee shop use case, it'd be nicer (I think) if we aim for a Square-style UI where the device broadcasts a (link to) a photo of the user combined with a bluetooth MAC. Then the merchant tablet can show faces of people in the shop, and can push a payment request to the users device. That device can then buzz the user, show a confirmation screen, put something on their smart watch etc or just auto-authorise the payment because the BIP70 signature is from a trusted merchant. User never even needs to touch their phone at all. On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey p...@airbitz.co wrote: The BIP70 protocol would preclude individuals from utilizing the P2P transfer spec. It would also require that a Sender have internet connectivity to get the payment protocol info. BLE could enable payment w/o internet by first transferring the URI to from Recipient to Sender. Then in the future, we could sign a Tx and send it over BLE back to the recipient (who would still need internet to verify the Tx). This is an important use case for areas with poor 3G/4G connectivity as I've experience myself. Also, due to Android issues, NFC is incredibly clunky. The URI Sender is required to tap the screen *while* the two phones are in contact. We support NFC the same way Bitcoin Wallet does, but unless the payment recipient has a custom Android device (which a merchant might) then the usage model is worse than scanning a QR code. BLE also allows people to pay at a distance such as for a donation to a live performer. We'll look at adding this to the Motivation section. [image: logo] *Paul Puey* CEO / Co-Founder, Airbitz Inc +1-619-850-8624 | http://airbitz.co | San Diego http://facebook.com/airbitz http://twitter.com/airbitz https://plus.google.com/118173667510609425617 https://go.airbitz.co/comments/feed/ http://linkedin.com/in/paulpuey https://angel.co/paul-puey *DOWNLOAD THE AIRBITZ WALLET:* https://play.google.com/store/apps/details?id=com.airbitz https://itunes.apple.com/us/app/airbitz/id843536046 From: Andreas Schildbach andreas@sc... - 2015-02-05 13:47:04 Thanks Paul, for writing up your protocol! First thoughts: For a BIP standard, I think we should skip bitcoin: URIs entirely and publish BIP70 payment requests instead. URIs mainly stick around because of QR codes limited capacity. BIP70 would partly address the copycat problem by signing payment requests. In your Motivation section, I miss some words about NFC. NFC already addresses all of the usability issues mentioned and is supported by mobile wallets since 2011. That doesn't mean your method doesn't make sense in some situations, but I think it should be explained why to prefer broadcasting payment requests over picking them up via near field radio. -- Dive into the World of Parallel Programming. The Go
Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Even if a user could get the BIP70 URL in the URI, they would still need internet to access the URL. The way Bitcoin Wallet does it, the bitcoin URI includes a MAC address where you can download the request from. BIP70 does not depend on internet access or HTTP, plus, you don't have to sign them. The name field might work but requires the merchant to set it, e.g. by asking the payer what their name is, then typing it in, then the payer has to wait for it to show up. By this point it's probably faster to have scanned a QR code. Re: security. I'll repeat what I wrote up-thread in case you didn't see it: it's not clear to me at all that this partial address scheme is actually secure. The assumption appears to be that the MITM must match the address prefix generated by the genuine merchant. But if they can do a wireless MITM they can just substitute their own address prefix/partial address, no? To avoid MITM attacks the sender must know who they are sending money to, and that means they must see a human understandable name that's cryptographically bound to the right public key. Displaying partial addresses to the user is not going to solve this unless users manually compare key prefixes across the screens which is even less convenient than a QR code. -- 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. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
