Topic: Off-chain anonymous transactions by secure transfer of private keys - page 4. (Read 17282 times)

My main concern is on malware - the Payment Protocol (as hard as it is to implement properly on a secure device, IMHO) provides a way to address that, while this would create another trust issue to be solved.

Overall the idea looks interesting - there's some significant chatter those days about using smartcards as generic certified key generation devices - such as Fido/U2F https://sites.google.com/site/oauthgoog/gnubby - and this fits right in.

On a side note regarding smartcard platforms, I've done some research on the existing and open (as in, you can buy them right now without NDAs) Java Card that would be suitable for bitcoin applications and JCOP 2.4.2 looks nice (supporting Elliptic Curve key generation, SHA256 and ECDSA with SHA256) - it can be found on the Yubikey Neo. I've ported the BTChip application to it as a proof of concept and will be releasing the code shortly with a GPL license.

There's also another very interesting application for this technology/idea: Bitcoin addresses are anything but human-readable and since they are supposed to change with each incoming payment, there's no chance for the user to remember them.

The Bitcoin Payment Protocol (https://en.bitcoin.it/wiki/BIP_0070) addresses this concern by allowing payment requests to be signed using standard X.509 certificates. However, this requires the Bitcoin client to redo all the work that the browser has already done when accessing the site over HTTPS, present the certificate to the user for verification, etc. Browsers already do that and have done it for years and people are starting to get used to the iconography and visual cues that come with this process ("green lock", "green address bar", various warnings in the browser that the certificate doesn't match, etc).

So I was thinking that we could reuse this knowledge and leave the verification and the UI to the browser and the user. People already know how to check the certificate and ensure that they're not sending money to a phishing site. When they enter their credit card number on a site, they only have to check that the site is genuine, not check the merchant's bank account number or ask the bank to confirm that it really belongs to the merchant.

Users could simply pay by entering the private key of a Bitcoin address holding the funds in a text field on the site (just like they enter their credit card details) after they verify that the site is genuine. It would then be up to the merchant to sweep the funds to the correct address. This would also make it a lot easier to track down payments since they would no longer have to match incoming payments from the Bitcoin network to invoices/payment requests issued over HTTPS.

This could also work in face to face transactions - you would give the key to the other person after you are personally satisfied that they are who they say they are (or ask them for an ID if you don't). I guess what I'm trying to say is that people (and their computers) are becoming pretty good at identifying sites and other people, so maybe we should reuse that knowledge.

What do you think?

I don't think it's going to be an "all or nothing" situation - I'm definitely not trying to replace the blockchain transactions, I am trying to augment them. Just as beeblebrox said, whenever they need anonymity or instant confirmation, people will pay off-chain. For large amounts and high security, they will go to the blockchain. For instance, I fully expect merchants to "redeem" their private keys onto the blockchain every now and then.

The "off-the-blockchain" transaction chain could be shorter or longer depending on how much you trust the system and how anonymous you want/need to be. This is why I'm trying to make it clear what the system knows and what its capabilities are and intentionally limit its abilities in order to prevent it from being abused by the issuer (which could be us or a licensee).

My comment was not specific to OtherCoin.

In general though, I don't expect any services that provide weaker security guarantees than blockchain transactions to survive in the long term. As more value moves into the ecosystem the incentive to steal will grow, and the thieves will target the softest targets first.

I could be wrong, but I think the blockchain is a case where we must put all our eggs in one basket.

Thank you beeblebrox! My answer was directed at justusranvier, I was just explaining that we do not hold our users' bitcoins in any way and we have no idea if/when transactions take place and what the value of those transactions is.

I'm not sure if this reply is directed at me or at  justusranvier.  If it was at me,  I would like to say that I do understand what you scheme is: it is very similar to this one that I outlined as an example of an electronic off-chain transaction using DRM on personal computers and phones- https://bitcointalksearch.org/topic/m.1578079 (elsewhere in that thread I even say that it is possible to use smart cards).

The reason I mention bank-like off chain transactions above was because for most people conducting off-chain transactions with large amounts of money they would prefer the safety and reassurances that a bank like institution provides (eg: similar to how in the real world not many every day citizens by new cars/houses/businesses with cash-- they use bank cheques and the like).

Local off-chain electronic private key transfer is a great alternative for smaller items and would appeal to the masses, it would be very convenient for transactions like buying groceries and petrol etc.  Most people would accept the security risk associated for small amounts like this (eg: in the current fiat world few people here in Australia have reservations loading bus cards with a $20-to-$100 or so).   However, personally I wouldn't use private key transfer for anything more than a few thousand and I think will you find that many people wouldn't even use it for that much-- maybe just a few hundred.

There is a real need for your scheme and it is a great development.  Previously I've offered 50BTC for an open-source smart phone version for secure private key transfer, however at the moment smart-phones don't seem to have the necessary hardware-- Samsung KNOX comes close.  So I'll pledge 15BTC to your smart card idea on successful completion and public release (non-open source accepted).
  

In the case of the OtherCoins, we're definitely not "holding bitcoins on the user's behalf". They're Bitcoins and remain Bitcoins, accessible at any time without contacting any external servers. The idea is to just allow them to be passed on to another person without going through the blockchain, but they can be used on the Bitcoin network just as easily - the OtherCoin smartcard simply makes sure that you can only do one or the other - it keeps parties honest, it doesn't hold your bitcoins.

If you read this thread, you'll see that it doesn't have the notion of Bitcoins and balances and doesn't even know what address you're using.

That depends on how how you define the boundary of a transaction.

In my case, there is nearly a 1:1 relationship between off-chain transactions and blockchain transactions related to buying and selling Bitcoins.

For example, when I purchase via Coinbase, they first allocate some of their bitcoins reserves to me via an internal database operation, which could be considered an off chain transaction, but as soon as those bitcoins are accessible I immediately withdraw them to my own wallet.

As far as I'm concerned, I'm not performing any off chain transactions because I never consider the purchase complete until the bitcoins I have bought move on the blockchain to an address I control.

I understand that several startups have a strong financial incentive to push a different paradigm, to convince users to let them hold their bitcoins on their behalf. When they inevitably steal/lose/confiscate their user's funds I won't be affected.

And these people include almost everyone here,  indeed I'll speculate and assume you yourself have participated in an off-chain transaction. 

Ask yourself this question: "Have I ever used an exchange to buy or sell bitcoin?"-- cause if you have then it most likely involved an off-chain transaction.

Off chain transactions are only suitable for people who don't require certainty as to actually owning the bitcoins they think they own.

I've been waiting for this....   https://bitcointalksearch.org/topic/the-fundamental-flaw-in-bitcoin-147933 ... and so it begins.

I'll make a prediction here-- the popularity of off-line transaction will mean that bitcoin fees never peak above 200 BTC/day averaged over a month.  In fact they may have already peaked-- more people use bitcoin now than ever before and yet the fee's have never passed 100BTC/day at seven day rolling average and seem to be declining when averaged over longer time spans. ( http://blockchain.info/charts/transaction-fees  )

Once electronic schemes like become popular for smaller amounts and large off-chain bank-like transfers for larger amounts there will be little reason for anyone to use on-chain for normal commercial transactions.

Sure.
Take your time and good luck with your projects!
They look promising - far more promising than bitcoin 0.9

You are right Piotr, it can be made into a standalone wallet (and I expect others to do just that once the OtherCoin card is released). My focus right now is completing development on the JavaCard / smartcard side and adding compatibility with the standard Android Bitcoin wallet. But I am also the author of VisualBTC (https://bitcointalksearch.org/topic/ann-visualbtc-android-based-hardware-offline-wallet-using-animated-qr-codes-210371) so at some point in the future I could also try to merge the two. I'm just taking it one step at a time .

Yes, thank you - it does answer my question.

Though I disagree with the part that a card cannot go without a wallet.
I believe a card can be a wallet and the authority certifying it's software can be both; a great business model and a great invention for the masses.

And BTW, this thread is the best offline bitcoin payment solution/proposal/debate that I have seen so far.


Yes, I understand that a card does not have a display, not OK/Cancel buttons - thus it cannot be a wallet per se.
But if you sell it together with a secured terminal - the card in such a terminal is the wallet.
The wallet that is quite secured, IMO, and most important: one that can be used offline.
You trust the smart card telling you how many bitcoins are protected by a private key that it is giving to you...
And the card itself does not need to be familiar with bitcoin protocol whatsoever - it's just a simple wallet.

I just realized, an easy way to think about all this is if you're familiar with GSM networks - the SIM card (a smartcard) secures the key that is used to identify you to the network. It does not speak the GSM protocol, it cannot talk to towers or call numbers or receive texts. It just securely runs an authentication protocol with the network, using the phone to relay its messages. The SIM card never knows if your subscription is even active or how much credit you have (if it's a prepaid account).

OtherCoin works in a similar way - it only secures keys and offers some guarantees regarding their status (never revealed before). The wallet runs the Bitcoin protocol and handles everything else. The only thing it cannot do itself is sign transactions to send funds away, it asks the card to reveal its half of the key or just send it to the other card in encrypted form.

It doesn't have to be done in the card, that's the job of the wallet. The card secures the key, the wallet knows about balances. Once you send the key to the recipient, his card gets the key and the wallet verifies that the public key / address has the expected funds on it. The card simply verifies that the received private key corresponds to the public key and that it has never been revealed, that's all. The wallet is the one that checks the balance (either by parsing the SPV chain or actually looking at the blockchain) and confirms that the funds are really there (of course, there could be _more_ funds than it expects if someone sent additional Bitcoins to that address after the sender created the proof, but I guess the recipient would not mind ).

Yes and yes. They are both there. I already have them working (ECDSA on secp256k1) but the only place the Koblitz curve is used is to calculate the public key corresponding to the private key received (to check that the sender didn't just send a random number but the actual private key to the public key it's pretending to use).

The card is just a microSD card, with no network capabilities. So it has to be plugged into something to work and that something is your smartphone. And in order to prevent the card (that you might not fully trust) from knowing what you are doing with your funds, the smartphone also generates a keypair (public + private key) that it combines with the keypair the card has generated to get to the final Bitcoin public key / address to use.

Of course, there's nothing stopping a wallet from just using what the card gives it (that is take the public key from the card and run it through SHA256/RIPEMD and generate an address).

The card always controls its part of the private key and without that part the wallet cannot make payments but can receive payments and monitor the blockchain. It's also the wallet that runs all the Bitcoin functionality (checking balances, sending funds, etc). The card is just a private key generator that either keeps the key to itself or sends it securely to another card.

Does that answer your question? You can't go completely without a wallet, you would need at least a screen and some network connectivity. But the wallet will not be a specific wallet, any wallet should be able to just send/receive requests to/from the card. It's a simple library to send/receive APDUs (http://en.wikipedia.org/wiki/Smart_card_application_protocol_data_unit) through filesytem operations.

SPV is definitely a path worth exploring.

But @drazvan, do you even have ECDSA and the Kobuz curve on your platform?

Verifying SPV proof is trivial in embedded hardware. It's just a linked list of 80 byte headers, hashing each and checking the prev and hash under target, it can be streamed so they don't need to be in memory the whole time.

In any case, this is getting a bit far afield of what the othercoin design is... there are a lot of potentials in this space.