Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-23 Thread Mike Hearn

 This happened to one of the merchants at the Bitcoin 2013 conference in
 San Jose. They sold some T-shirts and accepted zero-confirmation
 transactions. The transactions depended on other unconfirmed transactions,
 which never confirmed, so this merchant never got their money.


Beyond the fact that this risk can be priced in when enough data is
available, I'd be interested to talk to this merchant and dig into what
happened a bit.

For example:

   1. Was the dependent tx non-standard?
   2. Was it double spent?
   3. Could a wallet have co-operated with the P2P network to detect and
   flag whatever the issue was?

My own experience has been that when this happens, it's usually not the
result of outright maliciousness (especially not at a Bitcoin t-shirt
seller at a Bitcoin conference!) but rather something messed up somewhere
and the software in use just didn't detect it well enough.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-02-23 Thread Mike Hearn

 DHKE will not improve the situation. Either we use a simple method to
 transfer a session key or a complex method.


You're right that just sending the session key is simpler. I originally
suggested doing ECDHE to set up an encrypted channel for the following
reasons:

   1. URIs are put in QR codes more often than NFC tags. QR codes have
   limited space. The more stuff you pack into them, the slower and flakier
   the scanning process becomes.

   For normal wallets, doing ECDH over secp256k1 to derive a session key
   means we can reuse the address that was put in the URI already for
   pre-BIP70 wallets, thus we don't have to expand the URI at all except
   perhaps to flag that crypted Bluetooth connections are supported. Win!

   2. If the wallet is a watching wallet, this won't work and in that case
   you would need to put a separate key into the URI. However, this key is
   ephemeral and does not need to be very strong. So we can generate a regular
   secp256k1 key and then put say 5-8 prefix bytes into the URI as a new
   parameter. The public key can then be provided in full in the clear over
   the Bluetooth connection and the session key derived. If we put the session
   key into the URI in full, then we could not use this trick. Win!

   3. It's quite common in low tech scenarios like little coffee shops to
   just print a QR code and put it in the menu, or sticky tape it to the back
   wall of the shop.

   In these cases, it's possible that the device is actually hanging around
   in the shop somewhere but having the QR code somewhere larger and more
   accessible than the shop devices screen is highly convenient. However it
   means the data is entirely static.

   Putting/reusing an identity key from the URI means the session keys are
   always unique and known only to both devices, even though the bootstrap
   data is public.

   4. Doing ECDHE to derive the keys means we can derive a MAC key as well
   as an AES key. Otherwise you have the issue of exchanging both, which again
   uses up valuable bootstrap space.

So for a small increase in session setup complexity we potentially avoid
troubling problems down the line where people the same functionality from
NFC and QR code based bootstrap, but we can't provide it.

These discussions keep coming up. I think the next step is for someone to
upgrade Andreas' wallet to support encrypted connections and the TBIPs, to
see what happens.

Re: the h= parameter. I only objected to requiring this when the payment
request is also signed. It adds complexity, uses space, and the rationale
was the PKI can't be trusted even though it's been used to protect credit
card payments for 20 years without any issues. In the case of unsigned
payment requests, sure ... but with a proper implementation of an encrypted
Bluetooth channel it'd be unnecessary as the channel establishment process
would guarantee authenticity anyway.

But don't let me hold you guys back! I'd rather see something that works
than an endless debate about the perfect arrangement of hashes and URI
parameters :)
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-02-23 Thread Mike Hearn

 I read from your answer that even if we use ECDHE, we can't use it for
 every situation.


Which situations do you mean? I think it can be used in every situation.
It's the opposite way around - a fixed session key in the URI cannot be
used in every situation.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-02-23 Thread Andreas Schildbach
On 02/23/2015 01:18 PM, Mike Hearn wrote:
 I read from your answer that even if we use ECDHE, we can't use it for
 every situation.
 
 Which situations do you mean? I think it can be used in every situation.
 It's the opposite way around - a fixed session key in the URI cannot be
 used in every situation.

Ok sorry probably I read wrong.



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-02-23 Thread Andreas Schildbach
On 02/23/2015 11:58 AM, Mike Hearn wrote:

 You're right that just sending the session key is simpler. I
 originally suggested doing ECDHE to set up an encrypted channel
 for the following reasons: [...]

I read from your answer that even if we use ECDHE, we can't use it for
every situation. So in any case we need the simple bootstrap via a
session key parameter. My suggestion is defer ECDHE for now but keep it
in mind. We can add it later I think.

 These discussions keep coming up. I think the next step is for someone
 to upgrade Andreas' wallet to support encrypted connections and the
 TBIPs, to see what happens.

I happily step up and do the implementation work on the app side. A
first step could be:

- If there is an s parameter present wrap the Bluetooth connections
with AES. Sounds good?



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-02-23 Thread Jan Vornberger
Hey!

On Sun, Feb 22, 2015 at 05:37:16PM -0500, Andy Schroder wrote:
 It's maybe not a bad idea for the wallet to try all payment_url
 mechanisms in parallel. Should we add this as a recommendation to
 wallets in TBIP75?

It doesn't need to be a recommendation I think, but maybe it would be
good to mention that a wallet may do that, if it wants.

 I actually also happen to be using nfcpy. I am having some
 reliability issues as well with it. What exactly are your problems?

Aw, interesting. Sometimes transfers seem to start and then not complete
in some way and occasionally the NFC dongle is then totally 'stuck' in some
way afterwards, that even after restarting the Python script or
reloading the driver nothing works anymore. I have to actually unplug
the dongle and plug it in again. Obviously not exactly production ready.
I had the same problems with the command line tools based on libnfc, so
it might be a problem lower down the stack. I'm not sure I have the
expertise to troubleshoot that.

 I have seen your video before. I guess I'm wondering how your
 prototype works with bitpay and bluetooth. Doesn't bitpay sign the
 payment request for you with an https based payment_url? If so, how
 do you add the bluetooth payment_url while keeping their signature
 valid?

Good point, I'm currently simply removing the signature, so that I can
modify the payment request. I haven't spoken with BitPay yet, but I hope
that they will extend their API at some point to set additional
payment_urls or provide a Bluetooth MAC and then I can do it properly
with signed requests.

 In your video it looks like the phone still has cellular and
 wifi reception (it is not offline).

You are right, I forgot to actually disable wifi and cellular data when
recording the video. But as you know it would work the same way offline.

 Regarding the NFC data formats. I would like to clarify that the
 wallets are having those events dispatched by the android OS. The
 URI and mime type events are sent to the application in the same
 way as from other sources such as a web browser, e-mail, stand alone
 QR code scanner app, etc.. So, I don't think the wallet actually
 knows it is receiving the event from NFC. That is one reason why so
 many existing wallets happen to support BIP21 payment request via
 NFC. Andreas can correct me if I am wrong on these statements. I'm a
 little weary sending the mime type based format over NFC because
 of backwards compatibility and because of the long certificate chain
 that needs to be transferred. You want that tap to be as robust and
 fast as possible. A bluetooth connection can have a retry without
 any user interaction.

There is a specific NFC intent that you have to list in your Android
manifest, but you are right that if you already support BIP21 URIs then
it is often fairly easy and quick to also support them via NFC.

Whereas the mime type approach means that you necessarily need to be
able to actually understand BIP70, which a lot of wallet don't yet. But
personally that wouldn't hold me back using the mime type if I feel it's
the better experience. Those wallets simply have to fall back on
scanning the QR code in the meantime and then get up to speed on their
NFC and BIP70 support.

I'm still concerned that the fact, that Bluetooth is often disabled, is a
problem for the UX. And it's not just a one-time thing as with NFC,
which is - in my experience - also often disabled, but then people turn
it on and leave it on. But with Bluetooth the Android system is geared
much more towards turning it off after use and people have this general
idea of 'it uses energy, so I should disable it' and sometimes also
'Bluetooth is insecure and if I leave it on I will get hacked'. So
chances are, Bluetooth will be off most of the time, which means
everytime you pay the dialog 'Turn on Bluetooth?' will pop up, which
isn't exactly streamlined.

So the advantage of transmitting the whole BIP70 payment request via NFC
I see is, that you don't need Bluetooth to get the payment request and
for sending the transaction back the wallet can then make an intelligent
decision and first try via HTTP and only after that fails, say something
like: You are currently offline, turn on and transmit via Bluetooth
instead?. Much less confusing to the user, in my opinion.

Another idea could be to request the permission BLUETOOTH_ADMIN which,
as far as I know, allows you to programmatically turn on Bluetooth
without user interaction. The wallet could then have a setting somewhere
that says 'automatically turn on Bluetooth during payments' which would
enable and then disable (if it was off before) Bluetooth during the
payment process. That should also be a decent compromise, at the cost of
another permission.

 There is also the ack memo that I mentioned in reference [2]. I
 think we can improve upon this really. Can we make a new status
 field or different bluetooth message header? I know Andreas didn't
 want to change it because that is 

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

2015-02-23 Thread Mike Hearn

 At the moment I'm also modifying BitPay's memo field to contain 'ack', as
 Andreas' wallet otherwise reports a failure if I transmit the original via
 Bluetooth. :-)


Huh?
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Request for comments on hybrid PoW/PoS enhancement for Bitcoin

2015-02-23 Thread Chris Page
I'm soliciting feedback on an idea to will improve security, increase the
number of full nodes, and provide more avenues for bitcoin distribution.
The idea is still in its infancy, but I need constructive feedback before I
take this further, or decide to abandon the idea.

In particular, my ego is in check and I'm ready to be made a fool, but in
turn, I'll be that much better educated, so fair trade!

Here is the high-level overview:

1) A new block B0 is mined and broadcast as usual

2) Full nodes verify block B0. A subset of these nodes broadcast a new
endorsement message endorsing the block as valid, and preferred.

3) Miners, now assembling and beginning mining a new block (B1), add
endorsements of B0 to B1's coinbase transaction, sharing the block reward
with endorsers of B0.

As proposed, the idea of Block Endorsement requires a new message, but fits
into current structures.

Here some details about each of the steps above, and what it buys us:

1) The mining of block B0: No changes to current process or format.  Blocks
are mined and broadcast as they are today.

2)  Only a subset of nodes are eligible to endorse a block, and hence, only
a subset are eligible for an endorsement reward.  We restrict to avoid a
flood of endorsement messages by every node following the announcement of
each new block.  An endorsement message needs to identify exactly one block
at a specific height that it is endorsing.  It needs to include a payout
address that meets certain validation criteria relative to the block it is
endorsing.  A valid payout address will include some proof of stake (PoS),
whether that be that it has a 1+ bitcoin balance, some age weighted
balance, or something else is TBD.  The reason for PoS is that it should
not be the case that a subversive miner could easily fabricate a valid
endorsement payout address.  The other requirement is that the tail bits of
a valid endorsement payout address, when masked (size of mask TBD) need to
match the trailing bits of the hash of the block it is validating.   This
directly ties endorsements to a specific block, and makes it
computationally inexpensive to verify/relay, or drop invalid endorsement
messages. The combination of PoS and mask will restrict the number of valid
addresses.  There are no restrictions on which endorsements a miner can
include, as long as they are valid.  As part of new block validation, full
nodes would need to do all that they do now, but they would also need to
validate endorsements included in the coinbase transaction.

3) Miners consider whether to include endorsement payouts as part of their
coinbase transaction.  They need not do so, but by including endorsements,
they significantly increase the likelihood that their block will be
selected.

CHANGE TO BEST CHAIN SELECTION

Block Endorsement requires a change to the best chain selection algorithm
to encourage miners to include endorsement payouts.  Because there is an
incentive to include endorsers, there is an incentive to broadcast mined
blocks as soon as possible.

For the purpose of best chain selection, a block should get a significant
bonus to its work (10%) for each valid endorsement payout included in a
block's valid coinbase transaction.  How many endorsements should be
permitted is a design parameter which is in play, but let's assume that up
to 10 endorsements are permitted.   For the purpose of block selection, a
block's work, with 10 endorsements, is be effectively doubled.

EFFECT ON 51% ATTACK

With Block Endorsement, because of the extra weight given to a block that
has endorsements, a sustained 51% attack becomes more expensive.  Valid
blocks with full endorsements would win out over the attack blocks unless
the attacker was able to not only control 51% of the compute power, but to
also control sufficient endorsements to overcome the rest of the network.
To prevent an attacker from just using suitable addresses as endorsers from
the blockchain, a full node would have to maintain a list of recently
broadcast endorsement messages for TBD (100) blocks to prove the validity
of the endorsements.  Quite possibly we might need to provide a way for a
booting node to request lists of endorsers.

CHANGE TO BLOCK REWARD

Miners would share block rewards with endorsers using a defined formula
which is TBD.  Endorsement rewards would be as much as 20% (design
parameter) of the block reward, and shared evenly between all endorsers
included in the coinbase.

CHANGE TO MINING STRATEGIES

When a new block is broadcast, miners will begin assembling yet another
block.  Meanwhile, full nodes would validate the new block, and
endorsements would propagate quickly thereafter to all miners.  This should
not take long as it is easy to identify whether or not an address is a
valid endorser.  I would expect shortly after assembling a block, there
would be a number of potential endorsers to include in the coinbase tx, and
if 10 were not available, a miner could decide to wait, or begin mining

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

2015-02-23 Thread Mike Hearn

 But via Bluetooth it checks for 'ack' directly:


We need a BIP70 conformance suite really. There are so many deviations from
the spec out there already and it's brand new :(
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-02-23 Thread Jan Vornberger
On Mon, Feb 23, 2015 at 05:59:34PM +0100, Mike Hearn wrote:
 
  At the moment I'm also modifying BitPay's memo field to contain 'ack', as
  Andreas' wallet otherwise reports a failure if I transmit the original via
  Bluetooth. :-)
 
 
 Huh?

For HTTP it checks whether 'nack' is _not_ presented:

  
https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/offline/DirectPaymentTask.java#L133

But via Bluetooth it checks for 'ack' directly:

  
https://github.com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/offline/DirectPaymentTask.java#L238

The latter should probably be at least changed to the reverse check as
for HTTP, but in general some non-memo way of doing that would be nice
of course.

Jan

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] BIP proposal -- wallet extensions

2015-02-23 Thread Mem Wallet
Working on a proposal for extensions based on bip44 conventions.

Most interesting is: Fully Deterministic GPG keys.

https://github.com/taelfrinn/bip44extention

Would welcome any comments or interest
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-02-23 Thread Eric Voskuil
Mike,

Before addressing other issues I could use some clarification on your
intent.

In one statement you refer to derivation of a session key from a bitcoin
address (passed via NFC):

 doing ECDH over secp256k1 to derive a session key means we can reuse
 the address that was put in the URI already for pre-BIP70 wallets

In another statement you refer to derivation of a session key from a
public key (passed via  BT):

 The public key can then be provided in full in the clear over the
 Bluetooth connection and the session key derived.

I don't see how you propose to treat the bitcoin address as a secp256k1
public key, or do you mean something else?

e

On 02/23/2015 02:58 AM, Mike Hearn wrote:
 DHKE will not improve the situation. Either we use a simple method to
 transfer a session key or a complex method.
 
 You're right that just sending the session key is simpler. I originally
 suggested doing ECDHE to set up an encrypted channel for the following
 reasons:
 
  1. URIs are put in QR codes more often than NFC tags. QR codes have
 limited space. The more stuff you pack into them, the slower and
 flakier the scanning process becomes.
 
 For normal wallets, doing ECDH over secp256k1 to derive a session
 key means we can reuse the address that was put in the URI already
 for pre-BIP70 wallets, thus we don't have to expand the URI at all
 except perhaps to flag that crypted Bluetooth connections are
 supported. Win!
 
  2. If the wallet is a watching wallet, this won't work and in that case
 you would need to put a separate key into the URI. However, this key
 is ephemeral and does not need to be very strong. So we can generate
 a regular secp256k1 key and then put say 5-8 prefix bytes into the
 URI as a new parameter. The public key can then be provided in full
 in the clear over the Bluetooth connection and the session key
 derived. If we put the session key into the URI in full, then we
 could not use this trick. Win!
 
  3. It's quite common in low tech scenarios like little coffee shops to
 just print a QR code and put it in the menu, or sticky tape it to
 the back wall of the shop.
 
 In these cases, it's possible that the device is actually hanging
 around in the shop somewhere but having the QR code somewhere larger
 and more accessible than the shop devices screen is highly
 convenient. However it means the data is entirely static.
 
 Putting/reusing an identity key from the URI means the session keys
 are always unique and known only to both devices, even though the
 bootstrap data is public.
 
  4. Doing ECDHE to derive the keys means we can derive a MAC key as well
 as an AES key. Otherwise you have the issue of exchanging both,
 which again uses up valuable bootstrap space.
 
 So for a small increase in session setup complexity we potentially avoid
 troubling problems down the line where people the same functionality
 from NFC and QR code based bootstrap, but we can't provide it.
 
 These discussions keep coming up. I think the next step is for someone
 to upgrade Andreas' wallet to support encrypted connections and the
 TBIPs, to see what happens.
 
 Re: the h= parameter. I only objected to requiring this when the payment
 request is also signed. It adds complexity, uses space, and the
 rationale was the PKI can't be trusted even though it's been used to
 protect credit card payments for 20 years without any issues. In the
 case of unsigned payment requests, sure ... but with a proper
 implementation of an encrypted Bluetooth channel it'd be unnecessary as
 the channel establishment process would guarantee authenticity anyway.
 
 But don't let me hold you guys back! I'd rather see something that works
 than an endless debate about the perfect arrangement of hashes and URI
 parameters :)
 



signature.asc
Description: OpenPGP digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-02-23 Thread Natanael
Den 23 feb 2015 08:38 skrev Andy Schroder i...@andyschroder.com:

 I agree that NFC is the best we have as far as a trust anchor that you
are paying the right person. The thing I am worried about is the privacy
loss that could happen if there is someone passively monitoring the
connection. So, in response to some of your comments below and also in
response to some of Eric Voskuil's comments in another recent e-mail:

From the sources I can find NFC don't provide full privacy, but some
modulations are MITM resistant to varying degrees, some aren't at all, and
they are all susceptible to denial of service via jammers.

If the merchant system monitors the signal strength and similar metrics, a
MITM that alters data (or attempts to) should be detectable, allowing it to
shut down the connection.

Using NFC for key exchange to establish an encrypted link should IMHO be
secure enough.

http://resources.infosecinstitute.com/near-field-communication-nfc-technology-vulnerabilities-and-principal-attack-schema/
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

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

Hi Andreas,

DHKE will not improve the situation. Either we use a simple method to
transfer a session key or a complex method.

 but at least the session could not be decrypted from recordings.

DHKE doesn't offer greater forward secrecy than private transfer of a
session key, in fact it's lesser.

 Anyway, establishing a mostly secure session is clearly an improvement
 to no protection at all. If we can't find a solution to the dilemma of
 how to exchange the secret, I suggest going ahead with what we have and
 make the best from it.

I don't see that there is a dilemma. The current proposal has a
significant privacy problem that can be easily resolved, and the
resolution actually makes the implementation simpler.

e

 On 02/23/2015 08:36 AM, Andy Schroder wrote:
 I agree that NFC is the best we have as far as a trust anchor that you
 are paying the right person. The thing I am worried about is the privacy
 loss that could happen if there is someone passively monitoring the
 connection. So, in response to some of your comments below and also in
 response to some of Eric Voskuil's comments in another recent e-mail:

 Consider some cases:

 If NFC is assumed private, then sending the session key over the NFC
 connection gives the payer and the payee assumed confidence that that a
 private bluetooth connection can be created.

 If the NFC actually isn't private, then by sending the session key over
 it means the bluetooth connection is not private. An eavesdropper can
 listen to all communication and possibly modify the communication, but
 the payer and payee won't necessarily know if eavesdropping occurs
 unless communication is also modified (which could be difficult to do
 for a really low range communication).

 If we send a public key of the payee over the NFC connection (in place
 of a session key) and the NFC connection is assumed trusted (and is
 unmodified but actually monitored by an eavesdropper) and use that
 public key received via NFC to encrypt a session key and send it back
 via bluetooth, to then initiate an encrypted bluetooth connection using
 that session key for the remaining communication, then the payee still
 receives payment as expected and the payer sends the payment they
 expected, and the eavesdropper doesn't see anything.

 If we send a public key of the payee over the NFC connection (in place
 of a session key) and the NFC connection is assumed trusted (and is
 actually modified by an eavesdropper) and use that public key received
 via NFC to encrypt a session key and send it back via bluetooth, to then
 initiate an encrypted bluetooth connection using that session key for
 the remaining communication, then the payee receives no payment and the
 attack is quickly identified because the customer receives no product
 for their payment and they notify the payee, and hopefully the problem
 remedied and no further customers are affected. The privacy loss will be
 significantly reduced and the motive for such attacks will be reduced.
 It's possible a really sophisticated modification could be done where
 the attacker encrypts and decrypts the communication and then relays to
 each party (without them knowing or any glitches detected), but I guess
 I'm not sure how easy that would be on such a close proximity device?

 Erick Voskuil mentioned this same problem would even occur if you had a
 hardwired connection to the payment terminal and those wires were
 compromised. I guess I still think what I am saying would be better in
 that case. There is also more obvious physical tampering required to
 mess with wires.

 I'm not sure if there is any trust anchor required of the payer by the
 payee, is there? Eric also mentioned a need for this. Why does the payer
 care who they are as long as they get a payment received? Just to avoid
 a sophisticated modification that I mention above? I can see how this
 could be the case for a longer range communication (like over the
 internet), but I'm not convinced it will be easy on really short ranges?
 It's almost like the attacker would be better off to just replace the
 entire POS internals than mess with an attack like that, in which case
 everything we could do locally (other than the payment request signing
 using PKI), is useless.

 I'm not a cryptography expert so I apologize if there is something
 rudimentary that I am missing here.

 Andy Schroder

 On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
 On 02/23/2015 12:32 AM, Andy Schroder wrote:
 I guess we need to decide whether we want to consider NFC communication
 private or not. I don't know that I think it can be. An eavesdropper can
 place a tiny snooping device near and read the communication. If it is
 just passive, then the merchant/operator won't 

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

2015-02-23 Thread Andreas Schildbach
I think at this point I'd like to bring back my original suggestion of
using DHKE (Diffie-Hellman) or simlar. I know we'd still need to
transmit some secret that could be eavesdropped, but at least the
session could not be decrypted from recordings.

Anyway, establishing a mostly secure session is clearly an improvement
to no protection at all. If we can't find a solution to the dilemma of
how to exchange the secret, I suggest going ahead with what we have and
make the best from it.


On 02/23/2015 08:36 AM, Andy Schroder wrote:
 I agree that NFC is the best we have as far as a trust anchor that you
 are paying the right person. The thing I am worried about is the privacy
 loss that could happen if there is someone passively monitoring the
 connection. So, in response to some of your comments below and also in
 response to some of Eric Voskuil's comments in another recent e-mail:
 
 Consider some cases:
 
 If NFC is assumed private, then sending the session key over the NFC
 connection gives the payer and the payee assumed confidence that that a
 private bluetooth connection can be created.
 
 If the NFC actually isn't private, then by sending the session key over
 it means the bluetooth connection is not private. An eavesdropper can
 listen to all communication and possibly modify the communication, but
 the payer and payee won't necessarily know if eavesdropping occurs
 unless communication is also modified (which could be difficult to do
 for a really low range communication).
 
 If we send a public key of the payee over the NFC connection (in place
 of a session key) and the NFC connection is assumed trusted (and is
 unmodified but actually monitored by an eavesdropper) and use that
 public key received via NFC to encrypt a session key and send it back
 via bluetooth, to then initiate an encrypted bluetooth connection using
 that session key for the remaining communication, then the payee still
 receives payment as expected and the payer sends the payment they
 expected, and the eavesdropper doesn't see anything.
 
 If we send a public key of the payee over the NFC connection (in place
 of a session key) and the NFC connection is assumed trusted (and is
 actually modified by an eavesdropper) and use that public key received
 via NFC to encrypt a session key and send it back via bluetooth, to then
 initiate an encrypted bluetooth connection using that session key for
 the remaining communication, then the payee receives no payment and the
 attack is quickly identified because the customer receives no product
 for their payment and they notify the payee, and hopefully the problem
 remedied and no further customers are affected. The privacy loss will be
 significantly reduced and the motive for such attacks will be reduced.
 It's possible a really sophisticated modification could be done where
 the attacker encrypts and decrypts the communication and then relays to
 each party (without them knowing or any glitches detected), but I guess
 I'm not sure how easy that would be on such a close proximity device?
 
 Erick Voskuil mentioned this same problem would even occur if you had a
 hardwired connection to the payment terminal and those wires were
 compromised. I guess I still think what I am saying would be better in
 that case. There is also more obvious physical tampering required to
 mess with wires.
 
 I'm not sure if there is any trust anchor required of the payer by the
 payee, is there? Eric also mentioned a need for this. Why does the payer
 care who they are as long as they get a payment received? Just to avoid
 a sophisticated modification that I mention above? I can see how this
 could be the case for a longer range communication (like over the
 internet), but I'm not convinced it will be easy on really short ranges?
 It's almost like the attacker would be better off to just replace the
 entire POS internals than mess with an attack like that, in which case
 everything we could do locally (other than the payment request signing
 using PKI), is useless.
 
 I'm not a cryptography expert so I apologize if there is something
 rudimentary that I am missing here.
 
 Andy Schroder
 
 On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
 On 02/23/2015 12:32 AM, Andy Schroder wrote:
 I guess we need to decide whether we want to consider NFC communication
 private or not. I don't know that I think it can be. An eavesdropper can
 place a tiny snooping device near and read the communication. If it is
 just passive, then the merchant/operator won't realize it's there. So, I
 don't know if I like your idea (mentioned in your other reply) of
 putting the session key in the URL is a good idea?
 I think the trust by proximity is the best we've got. If we don't
 trust the NFC link (or the QR code scan), what other options have we
 got? Speaking the session key by voice? Bad UX, and can be eavesdropped
 as well of course.



 --

 Download 

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

2015-02-23 Thread Eric Voskuil
On 02/23/2015 03:11 PM, Mike Hearn wrote:
 I don't see how you propose to treat the bitcoin address as a
 secp256k1 public key, or do you mean something else?

 Sorry, I skipped a step. I shouldn't make assumptions about what's
 obvious.

No problem, we don't all have the same context. I may have missed prior
discussion.

 The server would provide the public key and the client would
 convert it to address form then match against the URI it has scanned.
 If it didn't match, stop at that point.

Does this not also require the BT publication of the script for a P2SH
address?

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] replace-by-fee v0.10.0rc4

2015-02-23 Thread Jeff Garzik
On Sun, Feb 22, 2015 at 6:29 PM, Eric Lombrozo elombr...@gmail.com wrote:
 As for 0-conf security, there are instances where 0-conf transactions make a
 lot of sense - i.e. paying for utilities, ISP, web hosting, or other such
 services which could be immediately shut off upon detection of a
 double-spend.

Indeed.  0-conf risk calculus must include business conditions.

Business cases such as placing an order for a physical good, making an
in-person purchase at a brick-n-mortar store, or subscriptions already
have countermeasures in place if funds go astray.  Order fulfilment
can be stopped, subscriptions cancelled, photos handed to police.

A thief wants to maximize return, which usually means either stealing
a few large amounts or many small amounts.  Double-spending against a
SatoshiDICE clone is easy to automate.  Many other purchase situations
are difficult to repeat without getting caught, or the level of effort
(cost) is greater than the payout of double-spending a small amount.
0-conf is typically only used for small amounts, where useful theft
relies on high repetition.

Purely online, mostly anonymous services like SatoshiDICE will be
easily attacked if they accept 0-conf transactions as there is little
customer/reputation relationship to leverage.  However, that
observation cannot be easily applied to most other businesses.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/

--
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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-23 Thread Eric Voskuil
Andy, adding to my previous post below:

On 02/23/2015 01:40 AM, Eric Voskuil wrote:
 On 02/22/2015 11:36 PM, Andy Schroder wrote:
...
 It's possible a really sophisticated modification could be done where
 the attacker encrypts and decrypts the communication and then relays to
 each party (without them knowing or any glitches detected), but I guess
 I'm not sure how easy that would be on such a close proximity device?
 
 If the NFC tap is sufficiently private, privacy is easy to achieve for
 the subsequent communication. If it is not, privacy can be completely
 compromised. The question is only how much more difficult is the attack.
 
 With the public cert tap, the level of difficulty is much lower for
 capturing selected payment requests. The interloper no longer needs to
 invade the space of the NFC terminal and can instead impersonate the
 payer from a safe distance. Nobody gets paid, but privacy is compromised.

This problem in the preceding paragraph can be resolved by sending a
unique public key on each NFC tap. In that case an attacker would need
to monitor the NFC communication.

The talk of wrapping the connection in SSL led me to believe you were
talking about a static public certificate. However that's not a
necessary assumption here and may not be what you intended.

 The level of difficulty in the case where the interloper wants to taint
 transactions may appear lower, but it is not:
 
 With the session key tap the interloper must compromise the NFC location
 and then monitor the BT traffic. Monitoring BT traffic without being
 party to the connection is presumably not rocket surgery, but not
 standard BT design either.
 
 With the public cert tap the interloper must also compromise the NFC
 location and communicate over BT. Therefore the hardware and physical
 attack requirements are similar. The only added difficulty is that the
 attack on the NFC terminal attack is active (modifying the MAC address
 directing the payer to the BT service).

I believe your central claim was that the difference in the two
bootstrapping approaches (public key vs. session key) is that by using a
unique public key per tap, the attack requires an active vs. passive
attack on the NFC terminal. I just wanted to make clear here that I
agree with that assessment.

The symmetric key approach is based on the idea that these attacks are
comparable in difficulty and otherwise identical in privacy loss.

However, the difference in implementation amounts to about +23
additional encoded characters for the BT/LE URL, assuming use of the
secp256k1 curve for DHE. This is really not a material issue in the case
of the NFC tap. The entire URI+URL could be as small as:

bitcoin:?r=bt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP

In comparison to a symmetric key:

bitcoin:?r=bt:12rAs9mM/12drXXUifSrRnXLGbXg8E

It also does not change the protocol design or complexity at all - it
would just swap out an AES key for a secp256k1 public key.

bitcoin:[address]?bt:mac/key

If that gets us aligned I'm all for it.

 However impersonating the payer is just a matter of software - no more
 difficult than the session key attack. In fact it may be much easier to
 implement, as the attack can use supported BT features because the
 attacker has directed the payer to connect to him and is connecting to
 the receiver as if he was a payer.
 
 But it gets worse for the public cert tap, since a more sophisticated
 attacker can set himself up in the same position without subverting the
 NFC terminal at all. By broadcasting a more powerful BT service on the
 same advertised MAC address, the attacker can capture traffic and relay
 it to the intended service.

I'm retracting the last paragraph, since the interloper, without
invading the NFC connection (by substituting the public cert), could not
read the relayed traffic. It was getting late :/

 So in sum, reliance on a public cert makes the communication less
 private under the same physical set of constraints. The difference
 results from the receiver allowing non-proximate payers to impersonate
 proximate payers from a distance by generating their own session keys
 and submitting them over BT.

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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-23 Thread Mike Hearn

 I don't see how you propose to treat the bitcoin address as a secp256k1
 public key, or do you mean something else?


Sorry, I skipped a step. I shouldn't make assumptions about what's obvious.
The server would provide the public key and the client would convert it to
address form then match against the URI it has scanned. If it didn't match,
stop at that point.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development