Hey, that's pretty cool, I like the idea of using the contactless interface for confirmation. I also like the fact that you've implemented RIPEMD in JavaCard, I couldn't find any NXP JCOP-based chips that had it natively implemented. Good work!

@fordlincoln Thank you! I really appreciate the support!

@Mavi I don't know where you live, but if your local police force can arrest you just because a random guy claims you stole something from him, I wouldn't want to live there. Of course, they are free to investigate and you have proof of what happened, so it should only take a few minutes to explain (and the guy that wrongfully reported it will be in serious trouble). Following your line of reasoning, if I sell my TV to my neighbor, I can then call the cops and have him arrested for stealing my TV. Or I could buy a new Macbook Air on Amazon then call my bank and say it wasn't me (although there is proof it has been delivered to my door and I signed for it).

What I'm trying to say is that yes, there are crazy people out there, but doing what you're describing means messing with 2 relatively powerful entities: the police and your bank. I might not know who you are, but your bank does and holds your money and the police also does can can make your life miserable if you waste their time (and taxpayers money).

Well, not exactly ... I mean yes, you could call the cops and tell them I stole your card. But the fact that there is no central authority doesn't mean no logs are kept at all. I can show the cops the transaction (as logged by my device), the outgoing Bitcoin transfer to your address. They could then simply email the issuer (us) and get details on how this works. Then you get arrested for attempted fraud (declaring your card as stolen when in fact you have authorized the transaction and received goods (in the form of Bitcoin) in return immediately). I would say it's rather risky. Also, if you declare the card stolen, the bank cancels it immediately, so you can only do this once (and be left without the card for a few days until a new one is issued). If your new card mysteriously gets "stolen" again, your bank will most probably "get medieval on your a**" for trying to defraud them.

Also, "if this guy don't use regular exchanges, he is most likely a criminal" - sure ... and if he uses Bitcoins he must be a criminal as well, we all know Bitcoins are only used to buy drugs and pay for kiddie porn ... </sarcasm> . You do know Bitcoins can also be exchanged in person (http://www.localbitcoins.com/), some people just don't want to go through the hassle of opening an account with a big exchange, submitting tons of personal data, then waiting for weeks to deposit or withdraw their money (due to various "unexpected banking problems" or what they're called nowadays).

@callem @StarfishPrime I've just (very quickly) read the OpenCXP document but I don't see how it relates to what I've proposed here. It appears to be a protocol that would allow secure POS terminals to process (=sign!) transactions on behalf of users for in-person transactions.

What I'm proposing here is simply a way to reuse the existing credit card processing infrastructure and existing ATMs around the world to create a distributed BTC/USD exchange. You pay BTC to someone and in turn that someone allows you to withdraw funds from / charge his credit card remotely for the corresponding amount in USD.

If you're referring to the OtherCoin project, we can move the conversation to that thread (https://bitcointalk.org/index.php?topic=321085) - but I still don't see how OpenCXP would apply since it appears to be designed for consumer to merchant transactions, fully registered in the blockchain, not off-chain anonymous person to person transactions like the Othercoin.

Regarding the Yubikey Neo, yes, it can sign Bitcoin transactions. The problem with it is that it has no screen, so you can't verify the details of the transaction unless you trust the terminal. There are ways to make an untrusted (public) terminal into a trusted one but I won't go into details here.

For this particular application, it doesn't really matter what protocol is used between the terminal and the card, as long as a middle man can intercept the transaction request, show the value of the transaction to the user (or check it against a preauthorized amount - the equivalent of the BTC being transferred the other way) and then forward it (or not) to the card.

Regarding smartcards, they are perfectly safe if the effort expended to extract the secrets costs more than the value of the secrets obtained. Smartcards also have a significant advantage compared to online systems - you need physical access to them in order to try to extract their secrets. A chip and pin card in your pocket cannot be attacked since you have no interface to it.

No, the flaw described in that paper I linked to is only needed if you don't actually know the PIN of the card - in our case, the PIN _is_ known, the card owner knows it. The security of the system is not in the PIN itself, you could even give it to the person withdrawing the funds because transactions are screened before they hit the actual chip - remember, the credit card is inserted into a reader connected to a computer that the credit card owner controls. So each request for payment or withdrawal can be screened and abnormal transaction requests can be blocked before they even hit the smartcard chip.

So while it's still a "man in the middle" type of process, it's not used to attack the card but to screen each request and make sure the card owner approves.

You also need hardware to mine Bitcoins and I haven't heard miners complaining about it. You also need hardware to secure your wallets (like the Trezor). Is there any reason you dislike hardware?


Think again: http://hackaday.com/2010/02/12/chip-and-pin-broken-and-other-security-threats/ . The owner can also type the PIN locally and ignore whatever the remote terminal (the ATM) is sending.

Care to elaborate? You see no value in being able to immediately get cash for your Bitcoins at any ATM (without waiting for weeks to withdraw from the exchange)? Or buying Bitcoins with your credit card with no minimums or restrictions from a remote user? Or the fact that all of the above happens in a distributed fashion, directly between seller and buyer, with no central authority and no transaction logs?

Hello everyone,

I was trying to figure out how we could create a truly decentralized BTC to USD (or any other currency) exchange, without requiring physical proximity or wire transfers and still make it as good as a BTC to cash exchange (no chargeback, etc).

So here's what I came up with: what if, in exchange for a certain amount in BTC, I am able to allow another Bitcoin users to remotely use my chip-and-pin card to buy goods (or withdraw money from an ATM) possibly half-way across the world? I would have a tiny smartcard reader at home and software running on my computer that relays requests from a remote ATM or POS to the credit card inserted into the reader. It is actually possible to screen the transaction before it hits the smartcard chip and even assign a one-time-use PIN to the remote user.

The remote user would need an emulated smartcard that actually relays requests to/from the actual card sitting in a reader somewhere. Initially this would be connected to some computer or phone via cable, at a later time it could simply be something like the Coin (https://onlycoin.com/), talking to your phone over Bluetooth.

This could also be made considerably easier if the ATM or POS support NFC transactions (believe it or not, ATMs in Europe have started to offer this option - you no longer insert the card but only touch the ATM (not POS!) with the card). Then the person who wants to withdraw the cash could simply use his phone to emulate a card (Android 4.4 KitKat for instance has native software NFC card emulation) and tunnel the requests to the real card where the card owner screens the transaction and approves/denies it.

The beauty of this is that in the end, one party gets Bitcoins and the other one gets cash from the ATM. Just like in a face-to-face transaction, but possibly from different corners of the world, to/from people that have never met before.

Would you be interested in this? I have prototyped part of it (the tunneling of requests to/from a real card and using NFC at the other end to emulate it to a POS or ATM), the transaction screening part is not done yet. The plan is to make this part of OtherCoin (https://bitcointalk.org/index.php?topic=321085), my off-chain Bitcoin payment system, but I have the feeling that this could be interesting outside my system as well.

Let me know what you think.
Razvan

Yes, maybe my example wasn't the best choice. What I'm trying to achieve is a way for parties to include arbitrary contracts (or terms and conditions) with their transactions (not just parcel tracking) - some of the checks could be done automatically, but since the oracle is only contacted in the case of a dispute, parties agree to pay for the arbitration services. More like a "jury of your peers" - humans that look at the terms of the contract that parties agreed to and decide if it has been followed.

In my OtherCoin project (https://bitcointalk.org/index.php?topic=321085.0) I plan to add this as a way for users to earn a few satoshis by acting as mediators / judges in disputes between other users and merchants.

Hello everyone,

I'm not sure if anyone has implemented something like this (coinworker.com doesn't seem to do what I want), so here goes: is there a service that allows me to post small tasks that validate transactions (for instance, "check that tracking number XXXXXX on USPS has been delivered and signed for by FIRSTNAME LASTNAME") and return a signed response that can be verified automatically?

This could be put together with Amazon's Mechanical Turk and a frontend interface that takes the answers, determines if a consensus (or majority) has been reached (workers generally agree that the conditions have been met) and then sign the response to indicate this (or sign the given Bitcoin transaction in a multisig situation).

The conditions would have to be described in a human-readable format (sort of like a short "terms and conditions" document) that can be posted to workers to get their confirmation.

In off-chain payment systems (such as my OtherCoin project - https://bitcointalk.org/index.php?topic=321085.0 ), the funds could be transferred back to the payer if the workers agree that the service has not been provided / goods have not been delivered.

The payer must also have an option to not submit the transaction at all to the oracle (if there is no disagreement with the payee - services _have_ been provided / goods _have_ arrived, etc). If there is a disagreement, the payee/merchant asks the oracle to arbitrate - in turn, the oracle asks a number of (paid) workers to run the instructions given and answer yes/no. The answer is then returned in a signed format to the requester (usually the seller) - in the case of OtherCoin, that results in the private key being unblocked. In the case of direct Bitcoin transactions, the oracle applies its signature to a transaction.

Does something like this exist already? If it does, I would pay to use it / integrate it into our OtherCoin project.

What do you mean Mike? According to https://en.bitcoin.it/wiki/Private_key, sweeping means:


Why would this require rebuilding indexes? Is that because the wallet would need to get a list of all the unspent outputs that are associated to that private key?

I haven't said I do not trust SSL or the payment protocol, I just described a way to pay someone when you only have their certificate (this could be a business or a person). They wouldn't have to create a Bitcoin address or do anything else, you could send them BTC and make sure that only the holder of the private key that corresponds to that certificate can redeem it.

Hello everyone,

I was thinking about how a client could send a payment on a website and make sure that only the owner of that website can redeem it. The Payment Protocol (if implemented) is one option, but here's a crazy idea:

1. Payer generates a new Bitcoin private key and assembles a transaction that pays the amount he wants to pay to the corresponding public key.
2. Payer fetches the SSL certificate of the website, verifies its validity, then takes the private key it has generated and encrypts it with the public key of the website.
3. This encrypted private key is then attached to the transaction (using unspendable outputs or other similar techniques - if the site uses RSA-2048, it will not fit into the 80 bytes that Bitcoin will allow for additional data per transaction)

At a later time, the website owner uses his website's private key to decrypt the message containing the private key of the transaction, then sweeps the funds to his wallet. He still needs to wait for the transaction to confirm (since the sender might try to cheat and spend it again given that he also has the private key). But I think this would be an interesting way to pay to someone's X.509 certificate (that is "I agree to pay X BTC to whoever this certificate describes"), even in the absence of a destination Bitcoin address.

Ideas?

I'm not sure if this has been proposed before, but I think it would be a good idea to make transactions with unusually high transaction fees attached to them non-standard.

Unless I am missing some legitimate use cases for very high transaction fees, they are almost always the result of a mistake or malware (like in the case of hardware wallets that do not verify the transaction chain but do verify the value of the output - those are vulnerable to a denial of service type of attack by lying about the value of the inputs and making them pay a lot of money in fees).

Are there any legitimate reasons for someone to pay 1 BTC (or even 0.1 BTC at today's exchange rates) for a regular transaction? 0.1 BTC would mean a transaction size of 1MB (at 0.0001/kB).

I've described how private key transfer could be used in person to person transactions (between trusted parties) or by online merchants - even in the absence of a secure chip - in this thread: https://bitcointalk.org/index.php?topic=329320.0 .

I plan to make this a part of the OtherCoin ecosystem at a certain point - if the recipient supports OtherCoin off-chain transactions, the key will be securely pushed to him that way. If he doesn't support it, payment can still take place by a transfer of private keys, if said key is encoded in a short human-readable phrase (a PayPhrase) that can be read over the phone or simply typed in an input field on a website.

I hope to see a future when Bitcoin addresses will go the way of IP addresses - they're still the basis of communication but nobody uses them directly or types them into anything. Humans are not meant to read those and I think the same applies to Bitcoin addresses.

BTW, the Electrum seed system is useful when you want to encode an existing random private key into a set of words (basically translating chunks of 32 bytes into sets of 3 words). This would require both the sender and the recipient to use the same word list.

However, if the private key is generated by randomly choosing words from the list, a much simpler way is to run the generated phrase through SHA256 or a similar hashing algorithm and use the result of that as the key. This has significant advantages: each party can use its own word list, the word list can be in any language - this could prove useful for non-English speakers, especially in the case of remittances. The downside is that the entropy situation is not as clear (see https://bitcointalk.org/index.php?topic=157820.0 for a discussion). But since the generated PayPhrase is not expected to live more than a few hours/days, it is probably safe enough for the purposes I described here.

 

Yes, it could be used to encode public keys as well - the problem with those is that they're 64 bytes long - so if you use the standard Electrum encoding (3 words for every 32 bits) you end up with 48 words!

What I'm proposing is a way to use the transfer of private keys, in a human-readable format, as transfer of value between parties. They would be used as temporary "vouchers" - so the funds will not be attached to that particular private key for long, they would be immediately transferred to a secure wallet by the recipient. See the thread above for details.

There is one additional advantage - the PayPhrase can be used for truly decentralized remittances. The recipient of the funds does not need a Bitcoin wallet, he can just go to an agent (or an ATM), type in (or say) the PayPhrase, then the agent or the ATM sweeps the funds and gives the recipient his cash. Each ATM or agent will have its own wallet, so when the sender transfers the money he doesn't know who will end up receiving it.

The agent or the ATM does not need to talk to a central server - he simply takes the PayPhrase, checks that the Bitcoins are there, transfers them to a safe wallet and gives the recipient his cash (minus his commission I guess).

The parties should already have a secure channel set up in order for the payer to receive the address that the payee wants him to send the funds to. If that channel is not secure, the payer has no way of knowing it's sending the coins to the the correct person.

The other option would be for the payee to use a single address (and lose the privacy features), one that payers could add to their address books. But first time payers would still be vulnerable.



They can do that right now, without my extension! X can transfer some coins to an address he controls, then claim it was a payment to Y and that Y has lax security and lost the funds. You can't have both anonymity and proof of spending. If there is a way to publicly prove that you've paid Y some funds, then Y is no longer anonymous. Of course, you can prove that you've paid "some address that supposedly belongs to Y".


The Payment Protocol (https://en.bitcoin.it/wiki/BIP_0070) will solve part of the problem, but it cannot stop malware from just replacing Payment Protocol-enabled addresses with simple (unprotected) ones - I've described this a bit in the Trezor thread at https://bitcointalk.org/index.php?topic=122438.msg3448363#msg3448363 .

Finally, there are already services that accept private keys as payment ... you might have heard of some of them (MtGox, BIPS). See https://en.bitcoin.it/wiki/Private_key and also http://www.othercoin.com/mtgprvkey.png for a screenshot.