Topic: [DRAFT] qwk'n'easy instant payments (Read 2368 times)

Seriously, a Finney attack on a retail point of sale (e.g. Starbucks, Walmart) is extremely unlikely unless the difficulty drops back down to far less than it is today. Say, less than 1000. And if that happened, the merchant probably wouldn't be accepting Bitcoins. Anybody who has enough hashing power to pull off a Finney attack today has 50 BTC just from that block, and likely hundreds or thousands more BTC; it is highly unlikely that they're going to rip you off for a coffee or their weekly shop.

Just plain sending a double-spend to other network nodes, though, is cheap and could be done from a mobile phone. There already exist tools which listen to the network (e.g. jgarzik's blkmond) and it would be easy to integrate this detection into a point of sale system. In the event this happens, the question then becomes which spend gets accepted by the network. And that won't be answered for sure until the next block is found. The customer can spend those few minutes talking to the loss prevention guys.

Also, even without the protection of listening for double-spends, accepting a transaction at retail point of sale with 0 confirmations is far safer than accepting a credit/debit card. Those can be charged back for months afterward and for many of those it costs too much for the merchant to fight them. With Bitcoin your transaction is settled in minutes and by the time the customer is in the parking lot the money is yours forever.

Note that all of this applies only to retail point of sale transactions where the customer is interacting with a retail employee. Vending machines, self-service checkout, web-based transactions, etc., need to be handled differently.

Ok, that describes what I was missing.  The assumption is that with additional software (to make multiple connections and listen for double-spends) the merchant is not at any real risk of a 0-confirmed / race attack being successful.


One reason there have been no complaints could be that few merchants currently complete a sale based on a 0-confirmed transaction.

This is what I believe needs to be tested, with results measured and reported, before I as a merchant would take the risk.

Specifically, the test I would want to see the results for is to emulate is a typical point-of-sale scenario -- say where a customer pays using the Bitcoin-android mobile client (and thus has 100% control over the timing with the ability to simultaneously send a message to commence the double-spend) and the merchant's cashier is running the Bitcoin client (the "Satoshi client") with default settings.

No, that doesn't hold. These attacks all have a cost. If you can't find a merchant where the cost is worth the gain, it doesn't matter that it can be done in a lab. The attack won't happen in the real world (or rather, won't happen enough to be worth worrying about).


That's not how the attacks against 0-confirmed transactions work. Either you have to race the payments and try to confuse the network, but that can be detected just by listening on many connections for a few seconds ... no slower than a credit card payment. Or you have to execute a Finney attack and find a block, buy from the merchant, then broadcast your double-spending block. But that requires you to be able to choose the time of payment precisely. It's not feasible to execute in the physical world. Only online merchants that have fully automated sales are vulnerable. And, it requires you to mine a block. If you aren't a pool that's going to take a lot of time and energy. If you spend more on hardware, time and energy than the value of what you're stealing, the attack makes no sense.


All merchants and users run the Satoshi client today, it does not alert you if a double spend occurs, yet there have been no complaints about reversed transactions as far as I know. So yes, I strongly doubt such attacks have occurred. And with current speeds I don't think they'll happen anytime soon either.

I'm not sure why you are specifying that this be a "real merchant".  If these attacks can be proven successful in a lab setting they will be attempted against "real merchants" as well.

With a typical point-of-sale transaction, the customer is long gone by the time the current block is solved (which is the first point at which the merchant can realize that a double-spend had occurred).  If the attack can be even just occasionally successful it will be attempted.

If this race attack is successful in maybe one out of twenty attempts even, I couldn't imagine that merchants would go along with that level of financial risk and/or resulting administrative hassle.

Assuming the merchant is just running a normal node and has no double-spend monitoring occurring, I wouldn't doubt that successful attacks would occur.

I saw it and found it just a little bit overdone, but great job on instawallet by the way!
I thought long and hard about the minimum requirements for my approach and finally came up with two simple calls to the API. I see no need for a call to have amount X sent to address Y, when you can easily setup a wallet containing amount X and have the complete wallet sent to address Y. It just turns what i would like to see as a one-use-wallet into a fullblown online wallet service. Which is more than is actually needed for the job.
Of course, your API could also be seen as an extended version of my minimal approach, and i certainly encourage that.
I just wish you would include my get() action, i'd certainly love to see that  



Precisely. I want shadywallet.com to come along and do just that. And crookedwallet.net, scammywallet.us and phonywallet.org as well. Centralization problem solved. Let the market / customers / merchants decide which wallet service to use, i guess they won't go with shadywallet.com, but they might.



As far as i understood it, the Ripple project tries to build up something like a web of trust for payment purposes, right? I totally agree that that would be a very good means of finding instant wallet services to use. Even though i personally believe that the market will sort things out even without.

There's already a way to handle over-centralization of payment processing - it's Bitcoin. There doesn't need to be anything more. If Bitcoin is too difficult to integrate or the fees too high, it can be improved to make it easier or cheaper.

There is a third case, a variant of the Finney attack: After sending your transaction A to the merchant, you feed your conflicting transaction B to your miner (and don't broadcast it). If you happen to be the one who finds the next block (let's say you have 5% of the network hashing power, so a chance of 1 in 20), transaction A gets reversed. You can do that at no additional risk. Besides of course, that you might not find the next block and transaction A gets through.

This is still important to keep in mind, for situations where the attacker can just try lots of times and refund the things that went through. So for example if a site has some kind of balance where you can deposit Bitcoins and withdraw them later.

I'm also not so sure about racing the network being so hard: Open one connection to the merchant's Bitcoin daemon and a number of connections to all of the major mining pools. Then, at the exact same time, send transaction A over the merchant connection and transaction B to all the pools. I think you have a pretty good chance of getting transaction B into the next block, while the merchant saw A.

For this reason, I would advise merchants to not accept incoming connections (of course an attacker could wait until he sees a connection from the merchant.. might take a long time though, so maybe not much of a risk). But even in this case, you could try something like this: Open one connection to Deepbit and a bunch of other connections all over the network. Send transaction B to Deepbit and transaction A all across the network. You might end up with most of the network seeing A, but with a decent chance that Deepbit will find the next block and has B included.

All that said, I do agree though, that in a lot of cases accepting zero-confirmations is probably fine: If you sell something that isn't all that expensive (compared to 50 BTC), can't be easily refunded and you don't accept incoming connections.


I'm not sure if you saw it, but a few days ago I released an API for Instawallet. It's not mentioned on the site yet, but documented here: http://forum.bitcoin.org/index.php?topic=26910.0 . From the looks of it, you could probably do what you describe with the API.

But more generally: Why do you think this would be more decentralized than Mt.Gox's vouchers? In the end it comes down to who the merchant trusts. Does he trust the voucher? does he trust that Instawallet will pay them? Of course it would be nice to have a standardized way for doing this (and to that end, I think the vouchers aren't the best approach to that), but shadyonlinewallet.com can come along and implement the API as well.

So ultimately it's about trust again, trust between the merchant and the payment processor. And this is why I consider the Ripple Project very interesting in this context. In theory, it could help to formalize a trust network between merchants and payment processors, that isn't just a simple "Merchant A trusts wallet B", but could also be "Merchant A trusts Wallet B, which trusts Merchant C, which trusts Wallet D" allowing for funds to flow from Wallet D to Merchant A even though they don't trust each other directly.

Unfortunately the Ripple Project hasn't all that much code to use right now. Just centralized server solutions which isn't going to fly with the Bitcoin crowd and doing this properly decentralized is a pretty hard problem, so I'm not holding my breath.

Bitbills are expensive. Very much so.

I think the easiest solution for instant payments (AFK) is to use Bitbills or a local currency.
For vending machines there might be some special solution.

I know and read both.

The reason i still come up with this topic is another one. My proposal is not really about security.
I cannot stress this enough, i'm talking about centralization here.

Geeks tend to believe that technical solutions will solve non-technical problems.
And this is basically a non-technical problem.
It's all about acceptance.

Merchants will use centralized payment processors, i have no doubt about that.
How do i know? They already do. On a day-to-day basis.
They are not interested in the technical details behind their credit card processor.
What they are interested in, is easy deployment. Wide acceptance. Low fees.
With the "regular" approach to bitcoin payments, we are setting up a huge hurdle in front of them.

I have no doubt about it, sooner or later, a centralized, simple-to-use payment system, which uses bitcoin only as the underlying means of transportation and storage, will be on the market. And people will adopt it. Why? Because it's easy to use. Low fees. Widely accepted.

My only concern is, who will that payment provider be? For the moment, i tend to believe that MtGox is leading the field, even though they don't publicly present themselves as a payment processor yet. But they have the infrastructure. They have the users.

I've just seen too many cases of monopolization of internet technologies over the past few years to want to see the same happen to bitcoin.

There's nothing i can do about centralization, because it will eventually occur, like it or not. But i may be able to help and ease the level of centralization, by propagating a system that will enable a broader field of service providers to offer the same service within a short period of time, as long as this technology is still in its infancy.

To just give you an example:
I recall a time when people asked each other "what's your hotmail?" when they wanted to know the other guy's email address. Centralization of email was imminent. But, due to the sound design of the email protocol, and the ease of deploying email services, there was never really a danger of monopolization. Of course, we do have a huge level of centralization with only a handfull of email providers today, but there's nothing stopping you from using your own smtp-server instead of going for a gmail-account. Webmail services failed at building up a large enough userbase to be able to actively exclude the users outside their network. They probably would have, given half a chance.

I propose we do the same for payment processors for bitcoin. Set up an easy-to-deploy protocol that makes merchants, customers and service providers happy, so that monopolization will become difficult.

My draft is just that, a first attempt at defining such a protocol, with the minimum technical requirements i personally can think of.

See this FAQ entry on the vending machine use case:

  https://en.bitcoin.it/wiki/FAQ#Do_you_have_to_wait_10_minutes_in_order_to_buy_or_sell_things_with_BitCoin?

and this thread it links to

  https://bitcointalksearch.org/topic/m.3819

which discusses vending machines specifically. Satoshi says it isn't worth the cost of carrying out an attack just to get a bag of crisps or whatever, and his reasoning is still sound. Bear in mind that to reverse a zero tx transaction, you either have to race the network (hard, as Satoshi points out) or mine your own block containing a double spend: also hard, given that every seconds delay after you find your reversal block is a second somebody else could find and broadcast a non-fraudulent one.

A vending machine could easily run a lightweight client, though in practice it probably wouldn't (ie the vending machine company would run a node and use RPC between them).

I see a some problems with that approach, mainly it's just a matter of implementation. Imagine the vending machine mentioned above. Should a fullblown bitcoin client with a permanent internet connection be installed in this thingy? Most certrainly not. The merchant will want to use some kind of centralized payment processor, just to keep the design of the machine simple. If we already offered him an API as proposed, that would help a lot in quicker adoption of bitcoin in its entirety.
 


I agree, but still think this is valid only for shops, restaurants and the like. With vending machines, i don't think acceptance of 0/unconfirmed will be the way to go.

It's not "grossly irresponsible". It's quite safe to sell material things for zero confirms today. I wouldn't run a currency exchange that way, but for dispatching goods or vending downloads or selling food at a supermarket/restaurant it's perfectly OK.

Merchants need to understand the risks involved with handling particular forms of payment, this is no different to today. Bitcoin, even with zero confirms, is much safer (for the merchant) than credit card payments or PayPal.

If network speeds enter a period of long term decline then the risks will shift over time, but Stefan has convinced me the right way to handle this is with quick and simple insurance policies rather than technical measures. Finney attacks or chain switches are likely to be very rare, even when network speeds are lower than today, so it doesn't make sense to over-complicate things for merchants.

Your established relationships scheme is a good idea, and would work nicely for things like currency exchanges. But let's not go overboard. If TX fraud is so easy, please go ahead and demonstrate some real attacks against real merchants (you can get their permission to try beforehand).

The MtGox voucher system is interesting, but I wouldn't use it myself. A regular Bitcoin payment works just as well.

Er sorry but IMO "just accept with zero confirmations" is grossly irresponsible and terrible advice.  Sure it's likely OK now, but if everyone did business this way, I think the incentive for mass small-tx-amount fraud would become quite large.

OP here is how to do instant TX securely, with someone you have an business relationship with:

https://forum.bitcoin.org/index.php?topic=25786.0

This won't work for something like restaurants.  However, the above scheme could also be used to implement a payment processor that doesn't need to be trusted to hold any funds, other than during the instant they are transferred.

I don't think anything is needed beyond what Bitcoin already offers. "Instant payments" already exist, just accept payment with zero confirmations.

The technical difficulty of carrying out an attack against you is quite high even with no blocks - the attacks that do work (eg finney attack) require precise timing, so aren't suitable for things like defrauding a restaurant.

I guess your absolutely correct about the buying of an existing userbase and the huge promotion.

But they got me like this:

I once auctioned somthing on ebay, and received a paypal payment, even though i didn't have an account with them.
I stood confronted with two options:
- accept the payment by setting up a paypal account.
- tell the buyer to go and pay the way i liked.

Since i didn't feel like having an argument about it, i simply went for the first option, even though i was not really happy with that.

A while later i even had my paypal account closed (which was difficult, because paypal seriously tried to resist), because i was really unhappy with their service.

So, i don't disagree with you, but i think you underestimate the power of "putting money on the table", as i would call it.

Go to a shop in the US and try to pay with a EUR banknote. Tell the merchant, that's the only money you have. The merchant will be faced with the options of either making a complicated deal involving a foreign country, or not dealing at all.
Most merchants will not accept. But with money on the table, a few will.

And if we all put our bitcoins on the table whenever it seems appropriate, sooner or later we will get a growing base, no doubt about that.

Not to nitpick, but PayPal e-mail payments were useless unless the recipient subsequently signed up for an account -- it's not as if they'd just cut a cheque for the recipient if he didn't want anything to do with PayPal.

PP built their userbase in two ways:  1) By buying an existing userbase (x.com, which was acquired/merged into Confinity and renamed PayPal) and by a huge promotion that gave everyone who signed up $5.   


Frank

References

The original thread where i brought this up:
http://forum.bitcoin.org/index.php?topic=25426.0

And now for the big thing:

Do you remember paypal? How did they get their customer base?
As a paypal user you could simply send anybody a paypal-payment, regardless of him having an account with paypal or not.
You could simply send money to an email address, that was their killer application.

With instawallet cheques, we can do the same.

You want to pay somebody in bitcoins, but the other guy doesn't know them yet?
Send him an email with an instawallet cheque.
He doesn't even need to setup an account with the instawallet provider.
All he has to do, is get the bitcoin client and claim that cheque!
Spread the word, pay with cheques!

Early draft of specification (it is probably not perfect right now, and will require explanation and some working on it):



instawallet service

MUST offer 2 actions:
- key () { key, wallet-address }
- get ( key, pay-to-address ) { success }

key() is used without any parameters and will create a new instawallet.
      It returns the key to that wallet and the wallet-address.

get() requires parameters key and pay-to-address.
      It will transmit the complete contents of the wallet to pay-to-address.
      Returns success / no success.
      It would be easy to implement a partial withdraw with a second parameter, of course,
      but it would be pointless, as you will see later. It's all-out or nothing.

SHOULD offer 1 action:
- val ( wallet-address ) { value }

val() requires the parameter wallet-address.
      wallet-address is an actual bitcoin address.
      It will display the amount of btc in that wallet, ie: the value.
      val() is actually not mandatory. as it is not necessary to the process.
      It may be useful in a lot of situations, that is why it is there.

Actually, i tend to omit the val() action completely. It has been pointed out to me that some people see a need for it, but i fail at agreeing with them. If i want to make an instant payment, i couldn't care less about first showing that i actually have the money. It's either pay or not pay.


Other actions may be implemented, but are not mandatory.
For example for easier setup of larger amounts of wallets, prettier printing, whatever.


The instawallets created by this api will further on be referred to as cheques.
They resemble cheques in many ways.
They are issued by the owner of the bank account, who also defines their value.
They may be easily revoked by their owner, as long as they have not been cashed in.
They require a third party (namely a bank in the case of regular cheques) to actually cash in.
They require the receiver to trust the bank for a limited amount of time, until payment finally arrives in cash or on your bank account.



consumer app (for example on smartphone)
could use the api to create new cheques, with amounts of
0.01, 0.02, 0.05, 0.1, 0.2, 0.5, 1 BTC and the like.
Those would have to be loaded with that amount of bitcoins, thus altering their denomination.
In general, a newly created cheque will have a denomination of 0, and will receive it's denomination by payments to its bitcoin address, just the same as with regular cheques.
Once created, the addresses of these wallets are stored in the app.
For an instant payment to be made, this app could produce a number of wallet addresses, along with their respective keys, to match the amount to be paid.
For example, to make a payment of 1.25 BT, you would use three cheques with denominations 1, 0.2 and 0.05.
Of course, it is always possible to create a 1.25 BTC cheque, but due to transaction times, that would require some amount of time. An instawallet provider could easily create a new action to make that instant for it's registered customers.

It could display the addresses only, to enable the merchant to check whether or not the consumer actually has the money he pretend to have. a call to the val() action would be required to do that.

It could display and/or transmit the addresses with keys, thus enabling the merchant to actually claim the value of these wallets.



vending machine (or merchant app on smartphone)
inserting a printout of a cheque into a vending machine / or transmitting by any other means the cheque to that vending machine, would enable the machine to claim the amount of this particular cheque.
It will do so by accessing the get() action along with the key and the merchants bitcoin-address.
It would be required for the machine / merchant to trust the issuing instant wallet service, that the payment will actually be done.
Therefore, it is expected that merchants will only trust in proven instawallet services, propably with a good reputation, low fees, a high level of security, etc. etc.