Quote from: jim618 on September 27, 2012, 04:34:33 PM

Hello Isis,

I need to read through what you are proposing a couple more times before I completely get it but it comes over much more "bitcoin-ey" than before which I think will make it easier to implement.

One thing I wanted to clarify - currently MultiBit is not a full node so it only uses the user-agent when it connects to a Satoshi node. It does not currently announce itself as a peer as it cannot accept incoming requests for anything.

Were you planning to add (Open Pay) transaction relaying ?
Matt Corallo has been working on getting bitcoinj closer to a fully validating node so you might want to talk to him (if you have not already done implemented it) as I would expect he would be beefing up the networking of bitcoinj in this area.

I'm working on a fork of bitcoinj that can handle the messaging and message relaying. If your wallet knows it got a payment, it will know it got a payment request as well. What you do from there is up to you as a wallet implementer.

Quote

It still would not be a validating peer so I do not think it could announce itself as such without messing up other users.

Also, am I right in thinking that the card reader can send out multiple requests for the same amount of BTC (either maliciously or by design) ? Previously the private key was on the card and the card signed it but is now the backend MultiBit doing the actual signing ?
That changes the potential attack vectors quite a lot as previously if the card was not in a device there was no way the private key could sign anything. If the backend MultiBit is sitting connected to the network 100% of the time listening for relevant OpenPay transactions its attack surface is much higher.

The full node & validation problem are one reason why I made the switch I've mentioned in my last post.

"On Card" validation is something only possible with the EMV card option which is slated for a later release because as I said, "we need to do a lot of paperwork to get ISO to recognize us." The change here is relevant to magstripe aka the ANY CARD option.

With ANY CARD, a key is generated deterministicly from the numbers on the front of the card and I do mean ANY CARD, I recommend an old expired or spent gift card, or a dead credit card, doesn't matter it's just the seed for a keypair.

This keypair is not intended to be used as a wallet key, it's just there so the merchant can send a valid message with a "from & to" address and provide a signature on that message that corresponds to something that a client can recognize as "the key to my masters house" so to speak.

Once the "send me money" message hits the wallet software, it is up to the wallet to determine whether or not to fund the request. I recommend at a minimum, either allowing the user to set a spending limit for when they are away from the keyboard, or popping a dialog box that says "Hey are you really trying to send money to this guy?"

The funds to be used come from the general wallet, and should follow the same path as it currently does when you want to send someone money. However the key generated from the card is a marker and should not be a wallet key.

Quote

Hope those questions make sense.

:-)

Hope my answers make sense. BTW still can't get MultiBit to compile, looks like it depends on a version of bitcoinj "0.3-SNAPSHOT" that maven can't resolve. Any ideas, please PM me.