Bitcoin Forum

Just a simple what i think a solution is to the problem of secure, instant and somewhat decentralized transactions. this solution does not give the bs answer, just give all your money to some central authority.

This would rely heavily a non existent open source platform that has yet to be made.

the system would not be account based, but more email based. it would not require a brand new account name/password. just you supply your real name and email address in the website and everything else works through email where you need verification.

example:
i want to buy some stuff from walmart
i go to walmart.com and put my name "ctoon6" and my email "example@example.com"
walmart.com sends an email with a unique public bitcoin address that i send any amount of coins i want.
i send BTC5 to the public address
walmart sends another email back that is signed and says how many coins i sent along with a random pin number and password.
in the same email i get a link to an image to print out a card for use at the store. it would require the pin with the card, vaid for x amount of time
i could also get the card printed out at walmart if i wanted also. the card is only required at a storefront.
if i type my email address into walmart.com it would send an email of how many coins i have and my account information and such.
if i want my coins back i type in my email address at walmart.com and the amount i want back
they send an email and i click a link in the email that takes me to a page where i specify the public address.

in short, every store or company or site has their own account systems. this is better than a single, and pointless system where you have to trust 1 company with all your money that you want to spend versus a bunch of smaller ones where you would only loose at most like USD100 worth. this does not address the vending machine problem, unless every vending machine company formed a coalition or something.

Sounds a lot like gift cards.

I buy a gift card from Wal*mart for 5BTC, and it is only usable at Wal*mart.

yep, except more online, instant(kinda), and more secure.

and you can take the money out if you want, and its really meant for personal use.

Wait, what problem is this supposed to solve? You don't have the "fast transaction problem" when ordering things online.

Yup, payments show up instantly and are probably good for most cases. No need to wait for confirmation. But how in the world can I buy a 2000 BTC car without waiting an hour! ;)

That's not the point. Online, you'll have plenty of confirmations long before the product gets into the UPS truck. (If you're selling digital products like e-books, then you have to wait for a confirmation or take your chances.) For transactions conducted in person, the seller simply needs to be reasonably sure that you didn't attempt a double spend attack - which itself requires careful timing and some luck along with >50% of the network. And in any case, if you tried it on the car dealer, they could just call the cops. After all, they know who you are anyway. :)

This is the problem. There is an example: I'm in a shopping center and buy stuffs in a little store inside. I pay it (without waiting confirmations). But then, I choose going to another store, it's simple and fast, walking three footsteps there is the next store and buy again. Double spending.

That's the risk of not using escrows or intermediaries (maybe i'm wrong)

You are, its nowhere near that easy. When two conflicting transactions exist clients that have already seen the first transaction will not broadcast the second. Meaning that unless you get new peers your attempt at a double spend will be killed instantly. Even if you do manage to get new peers by the time you get a new set of connections your first transaction will have spread too much. In any shopping center all the shops will have each other as peers, the first shop received your first transaction nano second after you sent them. When you attempt to double spend over there their client will have seen your first transaction and know immediately that it is a double spend attempt.

Right. The next shop will know that those coins were spent before the first shopkeeper puts your stuff in a bag.

My solution would be following:

1. Create simple app/plugin to the main bitcoin client, which serves let's say port 29239
2. Let's say mtgox wants to promote instant transactions, and enables the plugin. Plugin now serves address https://mtgox.com:29239/ (https required)
3. I am a merchant, and want to trust transactions created by mtgox, eg. people who use mtgox client can pay at my store instantly. I add also instawallet, mybitcoin.com and several other trustworthy e-wallets to my trust list. (just an example...)
4. When I receive a payment, I instantly send a request to https://mtgox.com:29239/{{ txid }} and other services. The plugin returns a value depending whether the transaction is approved by mtgox or not. Repeat this for all the services.
5. If some service returns true, I can approve the transaction and be happy.

=> confirmation approved form 20 minutes to just mere seconds (only from trusted sources though...)

https://i.imgur.com/wZY0i.jpg

Sorry  ;D

i think you guys are missing the point. this is not really for online stuff, although it would be usefull in certain situations like μpayments to avoid a lot of fees, just send in BTC2 and not have to send any more for a month or so.

This idea also would work good in malls. you could go to the malls website and put money in that way, or right at the door. there would be at least 1 block done by the time you wanted to buy something. and really 1 block is good enough for smaller purchases below $500.

in addition, why are you guys so easy to just go to the simple solution of "hey, lets give all our money to this guy over here, we can trust him, right?". not only would you pay more, you are defeating the purpose of bitcoin.

overall i think my idea is both easy to understand and safe. it requires no additional passwords to remember and is as secure as your email account (although some people are stupid so i dont know, maby a text based system, use your phone number instead.).

Wait, so I have to go to some shop's website and buy a voucher before I go to the shop? This sounds inconvenient and unnecessary.

yes, but it would be quick and easy. and it helps avoid the very likely situation of everyone dumping their coins on a single website bank thing. this is bad because even if the company does not steal your coins, they still could accidentally delete them or someone could hack into the systems. because the system would be opensource, people could audit the code.

Why should I go to all this trouble when I could just spend bitcoins in the shop?

you can, but it does not provide any real security for the shop, and the shop may not even accept them without waiting for a block. this is the solution to the problem where you don't want to wait 10 minutes or more for your stuff, and provide security for the shop against double spending.

I see the system to be very fair, shops should not have to just accept 0 block transactions.

The shop doesn't need to wait for a block if you are paying in person.

why not, if they just accept unverified transactions they are asking to get ripped off.

This has been discussed in detail many times. Waiting is required for online transactions where the buyer is in control of the timing of the transaction and could potentially execute a 51% attack or a race attack. The 51% attack is not as viable in a transaction which takes place in person because the attacker can't control the timing of an in person transaction easily enough, and the race attack is easy to thwart simply by watching network activity for a few seconds. NOTE that this doesn't apply to vending machines.

Or maybe we phase out POS purchases completely...

Im not talking about that, as the 51% attack is silly at best. im talking about sending multiple signed transactions into the network at the same time. i go to walmart, you go to other store. use self checkout when the store is kinda empty. then just send a text to your buddy to push the button at the same time. id imagine in the future you would have a 5 second window to do it.


yeah, why dont you go buy a watermelon on ebay and see how that turns out.

But you just described the race attack! Again, all you have to do is watch the network for a few seconds, as already stated, to see that the coins that were supposedly sent to you were also apparently sent to someone else.

i misread your post, you can not watch the network for already existing transactions and always be 100% sure. as the network grows in size it may have unpredictable effects. sure right now you can check easily, but who knows. the store could be compromised over time by an attacker having a bunch of nodes that broadcast normal transactions, but refuses to broadcast ones not in its favor. botnets serve this purpose well and could be rented out for yet another purpose.

Are you just thinking out loud (so to speak)?

i guess, but you can not know for sure what the future will be. super peers would definitely reduce transaction latency, so it may not be a problem, you can always take gnutella as an example though, as it is very similar.

OK. Well, I recommend giving it more thought. For instance, in this scenario the attack requires that both transactions be broadcast, but that the merchant sees one transaction first and the miners see the other transaction first. Refusing to relay doesn't help this attack succeed unless you've somehow successfully separated the merchant from the rest of the bitcoin network. That's where you need not only a botnet, but a lot of luck. How are you going to prevent the merchant's bitcoind from connecting to a bitcoind not in your control, and then seeing what you're up to? If you don't have an "Internet kill switch" then this will be very hard to do. And by this time you've spent far more money than you can rip off Wal-Mart for at the register. Plus, they'll likely figure it out before you get to the parking lot.

yes it does depend a lot on luck, but even if only 1/4 of the nodes they connect to are not honest, it would slow down how fast you see transactions.

and another factor to consider is volume. right now i estimate we are only seeing less than 1% at most. its probably below .1% of the amount if bitcoin takes off mainstream and is used as real currency. at this point i could see it being more burdensome to propagate all of them, and thus it would be slower. and i would also guess there would be less nodes with ports forwarded too. so sending more data with less nodes could be a problem, not only for race attacks, but the network in general.

yes all them numbers are pulled outa my ass, but id guess they are fairly optimistic.

I don't know if anyone else has this though - I can't be the only one....

Is it that hard to imagine someone setting up a bitcoin processing guarantee service, maybe even as a part of a bitcoin POS solution.  The service provider would have a pool of mining power combined with some well-distributed (network topography as well as geographically) bitcoin nodes.

The service provider would aggressively distribute their transactions to the network, as well as watch the network for "suspicious traffic", and give the merchant a red/green light on any given transaction within seconds - less time it currently takes someone to enter their PIN or sign a credit card slip, for example.

The service provider would also guarantee the transaction, in return for a transaction fee above-and-beyond the normal bitcoin transaction fee.  Maybe the merchant can choose how long they want to wait, the longer the wait (30 seconds instead of 3 seconds?) the less the fee.  Maybe the service provider strikes up a deal with some of the larger mining pools to always take their transactions (even fee-free ones) in return for a slice of the service fee in the event of the pool solving the block.

This provides the merchant with the certainty and speed they need, at a reasonable price compared to the price of processing credit card transactions.

That's just one idea, maybe other people have different ideas...

is the customer giving the money to the payment processor?

No, it's the merchant that pays - after all it's the merchant that wants the guaranteed payment.  If this ends up costing half of 1% of the transaction cost then the merchant either eats the cost or ups all bitcoin prices by half of 1%  (not dissimilar to the way some merchants charge extra for processing credit cards).

Of did I misunderstand the question?  Maybe I did.

The money goes from the customer to the merchant.  However the merchant's POS system is connected to the bitcoin network and the payment processor's computers (which are just part of the bitcoin network).  The payment processor doesn't touch the money - they are told of the transaction and watch for double-spend for a couple of seconds before returning an OK signal to the POS machine.  As part of the payment processor covering their own arse against double spends on "their" network, they send this particular payment all over the bitcoin network.

I'm sure someone could do some numbers and work out the probabilities of double spends vs time, based on how distributed a particular half of the double spend is distributed across the network.  Those figures would determine how much the processor needs to charge to insure against double spends.

Also remember that if you want to double spend against the RodylandBitcoinPaymentGuarantee System, you need to ensure that one half of the double spend is on a part of the network that isn't readily reached by the nodes owned by this system.  And the more isolated the node with the double spend, the less likely that transaction will be accepted by the network...

And if the RodylandBitcoinPaymentGuarantee System and the BitcoinGuaranteeByCtoon6 System decide to share transactions aggressively, that makes double spends even harder....

For many merchants that would be best, except possibly in the case where the customer's choice of currency to pay with happens to correspond with the currency the merchant wishes to be paid with.

In all the other cases, that is, in any case where the currency the customer wants to pay with is not the same currency as the one the merchant wishes to be paid with, most small merchants who are not forex players would probably prefer that the customer pay the payment processor the not-what-the-merchant-actually-wants currency and the payment processor pays the merchant the currency the merchant does actually want.

-MarkM-

Or VISA/MC get into the business of selling pre-paid credit cards for bitcoins, merchants don't have to change anything and everyone is happy.

you guys may be right, but i don't really see it. why just give the money to a payment processor.

additional step to getting funds
could have some security implications
more costly, it could be cheaper to buy one of them php enabled vps a month if you get enough transactions. secuity is not an issue because the coins would only be on there for a short while.

It might be hard to imagine now because there is only 1, maby 2 stable bitcoin wallet manager things.(GUIs to not count because we need a pure php solution or similar, java could work, but php would be best because pretty much all providers have it)