Automated Checkout Systems need to be written for Bitcoin to...
Upon Checkout at an online merchant.... the system creates a unique new Bitcoin Receiving Address just for me, and just for this specific order.
Then, the system automatically records and attaches THAT Bitcoin Receiving Address, to THAT order, in the merchant's system.
Later, the system should be able to automatically detect the fact that the proper amount was received, on that address, for that specific order, and initiate shipment of the product...
The mybitcoin.com shopping cart interface (SCI) already has what you need.
|
|
|
Ironically, the spamming has created an incentive to pay at least a 0.01 TX fee (the Bitcoin Faucet does this now).
|
|
|
For merchant point-of-sale (POS) systems, the merchant should display a QR-code on a screen. The customer uses their mobile phone to snap a picture of the QR-code Automated processing software reads the QR-code in the picture, determines that it is a payment request from merchant CoffeeYourDrugOfChoice, Inc. for 35 BTC, and prompts the customer to approve the payment. Presuming sufficient payment processor speed (see the snack machine thread), you could probably get away with zero-confirmation, instant bitcoin-denominated purchases.
|
|
|
Subscriptions are quite difficult for bitcoin, because bitcoin lacks a sort of "demand payment" feature. Demand payments occur when you give a merchant a "secret" (ie. your CC number / expire date), that enables direct withdrawal from your account.
Community-wise, I'd bet most bitcoin users would shy away from a system that enables third parties to withdraw bitcoins from you at their convenience.
The closest you can probably come is adding a "cron" feature to mtgox or bitcoin, which sends payments on a pre-defined schedule, to pre-defined bitcoin addresses. Such a feature leaves the user in control of their wallet, as they can cancel a "cron job" at any time.
|
|
|
Anybody have any success in implementing a mtgox merchant option?
Worked fine on the test web page I created; but since it required JavaScript, I did not want to implement it in production.
|
|
|
Patch updated to move prepare-work and prepare-hash-buffer code into separate functions.
Again, no code changes, just code movement.
The patch now looks similar to m0mchil's getwork patch, and makes integrating remote mining much easier.
|
|
|
I have actually bought gas and amazon.com stuff using the Wal-Mart VISA gift card.
|
|
|
In terms of something to use in America, I was thinking perhaps something like a Wal-Mart gift card might be a bit more universal. The nice thing is that you could use the money for nearly anything you might want, at least if you are interested in buying cheap Chinese goods or want to buy some groceries. There might be some resistance as there is sort of a cultural meme fighting Wal-Mart too in terms of some who don't want that store to take over all retail business in America (a perceived if not actual threat) but it at least would be a realistic way to convert bitcoins to dollars without having to go directly through credit cards or services like PayPal. As far as I know, you can't do a "charge back" on a Wal-Mart gift card, unless you purchased it with a credit card in the first place. That becomes Wal-Mart's problem, not yours.
Wal-Mart gift cards are VISA, and may be used at any store that accepts VISA.
|
|
|
URL: http://yyz.us/bitcoin/patch.bitcoin-modularize_minerThis patch is similar to patches sometimes seen in the Linux kernel. Analogous to an algebraic reduction, or a step in a mathematic proof, this patch intentionally makes zero functional code changes. It moves two chunks of code -- hash meter and check-solution -- from the BitcoinMiner() function into separate functions. This change makes it easier to integrate remote mining.
|
|
|
Doesn't have to be a gas card; it could be any VISA debit card.
Several Liberty Reserve exchangers permit transfer to debit card. Certainly a market niche exists for BTC-to-debit services. Anybody know reputable services that produce gift or debit cards?
|
|
|
Another 100BTC donation headed your way.
Working on shopping cart plug-ins for bitcoin is an important step in making bitcoin easy to use.
|
|
|
Once we have a standard mining interface, it would be easier to separate mining from the core client altogether.
Indeed. That's all that needs to be in the core -- remote mining support.
|
|
|
Think about what happens when a new Bitcoin install is downloading from block #1... ...you download blocks from 1 .. 74000 before being able to verify or generate coins. Your point?
|
|
|
For a while I have been annoyed that mtgox is restricting how much LR we can withdraw from our accounts to $1000/day. I have emailed and explained that LR and BTC should not be subject to US banking regulations and even if he wants to play it safe the quantity for cash withdrawls before a currency transaction report (CTR) is $3000 not $1000.
The $1000/day limit is quite normal and expected, if you do not wish to register as a Money Services Business (MSB) with FinCEN. I found this guidance while researching for The Bitcoin Store. For the sake of mtgox.com's longevity, I hope this withdrawal limit remains. You do not want the US government to even mistakenly shut down mtgox, do you? And I for one would not trust random users' interpretation of US laws. You will find crazy people who will explain that it is not required to pay US taxes to the IRS. We all ignore these nutters, continue to pay our taxes, and continue to stay out of jail.
|
|
|
In a future with a successful Bitcoin, most generation would likely be performed at a net loss by persons or institutions with the most interest in Bitcoins security.
No! Thats a tragedy of the commons situation. It just doesn't work. If Bitcoin will have to rely on that it's doomed. It's not a tragedy of the commons because generators will have interest in seeing the network continue to function.
|
|
|
I'm not "sold" on bitcoins, in that, I have no clue if they will succeed or fail. I think failure potential is >50%, and that it's a high risk endeavor.
It's also an intriguing concept, fun to play with, and a potential "disruptive change", a genuinely new idea in the area of currencies, which hasn't seen many truly unique ideas in the past 100 years.
|
|
|
It also sets up an interesting DOS attack where potentially a miner with a large bank of computers could charge very high transaction fees, slowing down or even potentially stopping trades. I guess the way to stop that would be to get a bunch of computers for yourself and hope you can squeeze in a successful hash at least for yourself to get your transactions put into the network without a fee (presuming you can be selective on the fees for your friends and own addresses).
Well, you can do all sorts of stuff if you have >50% of network CPU power.
|
|
|
That's a good point about fee competition, but I'm wondering about near-term implications of this spam flood, too, like - What happens to the transactions that don't make it into the current block? (somewhat rhetorical question... the answer is "they keep piling up in memory" AFAICS, but that raises a bigger question -- how to deal with ever-larger TX cache?)
- Will this create a de facto situation where TX fee is required for "normal" bitcoin users?
- Would it make sense to introduce a consensus blacklist, of abusive bitcoin addresses? ie. miners could -- at their discretion -- simply drop TX's with the blacklisted addresses.
|
|
|
I'm not so ready to blame this on MrBurns.
|
|
|
Someone is apparently "testing" the main bitcoin network by flooding it with 0.01 BTC transactions from A->A and B->B, where A and B are two random public keys. You can watch at http://theymos.ath.cx:64150/bbe We've hit the free transaction limit on each block, for many blocks now -- appears to be ~219 free transactions per block. "real" transactions do not appear DoS'd at this time, presumably due to logic that prioritizes, in part, based on transaction value. <soapbox> Free TX's are just asking for permanent level of spam. There should be a cost to each TX, even if it's only 0.001 BTC or so. </soapbox>
|
|
|
|