I'm currently working on MultiBit Merchant (see https://github.com/gary-rowe/MultiBitMerchant/wiki/Introduction) which might go some way to helping local merchants operate their own businesses directly in Bitcoin. As part of my "October of Bitcoin" I'll be working to bring it up to MVP status in the next 30 days. This will involve me taking an entire month off work (unpaid) to dedicate my efforts full time to the project. If anyone would like to help out I need folks with Java and HTML/CSS/JavaScript skills. I maintain a blog about it here: http://gary-rowe.com/agilestack/2012/06/06/multibit-merchant-genesis/Once I'm getting close to something useful for people I'll post a proper announcement and support thread. |
|
|
|
Does Multibit Merchant offer any solution(s) for this problem or does the owner of the webshop get there bitcoins and still needs to go to an exchange and trade there bitcoins for euros/dollars/pounds? (I'm the lead developer for MultiBit Merchant) As part of my October of Bitcoin I'll be pushing MultiBit Merchant to a minimum viable product (MVP). This means that I have to strip out as much extraneous work as possible to hit that tight deadline. The MVP is unlikely to have automated fiat exchange in place, although prices will be quoted in real time from MtGox in a range of local currencies. However, I am also involved with the XChange project and as part of that there is a push to introduce a Deposit/Withdraw API in addition to the trading API. Using XChange it should be possible to take bitcoins, deposit them onto the exchange offering the best deal at your market depth (arbitrage) and perform a trade to fiat. That fiat can then be withdrawn to your selected account using the exchange's provided mechanisms. XChange is a Java library, but because it runs on the JVM (now known as the mlvm) it is possible for it to be accessed by any other language running on the technology (think Clojure, Jython, JRuby etc). In time, this will make it trivial for anyone using the mlvm to be able to interoperate with a wide range of exchanges. |
|
|
|
Wow, I think this was David Deutsch proposed proof for MWI of QM.
For interested parties, MWI is the Many Worlds Interpretation of Quantum Mechanics and basically states that all possible events occur in parallel worlds. See http://plato.stanford.edu/entries/qm-manyworlds/. |
|
|
|
|
I am in the process of providing one more solution to this problem - it is pre-alpha at this moment but is rapidly progressing.
If you have professional experience (or are considered highly skilled) in any of the following I would be willing to pay you in bitcoins (at reasonable UK freelancer rates) for your work:
* writing marketing copy
* developing marketing strategies for driving traffic to a site
* writing blog articles on technical subjects
* software development in Java or Ruby
* creating Balsamiq mockups based on solid UX principles
The workflow would be: I give you a task, you discuss and complete it, I review it and once accepted I pay you for your time. The tasks will be tightly scoped and clear and requiring a few hours effort.
|
|
|
|
This is super insecure!!! Bitcoin URI is the best way to do this, there is a reason no one uses 402 response http header
Would you mind walking me through the security issues with this approach? The 402 response for "payment/bitcoin" contains a Bitcoin URI, and can be served up through HTTPS to avoid MITM attacks. Short of a server compromise I'm not sure what the attack vector is. Yes I can, and if your just use the 402 http header as a way to tell programs thru an api to pay, and return a bitcoin URI is fine. BUTTTTTTTT someone was describing using 402 to start the client to start the payment process and locking down the browser, this is a security flaw. PHP can start a 402 and use javascript to control everything so the user would have no idea until funds are flowing. Thanks for the extra detail. From what you describe, you're worried that the browser would handle the Bitcoin URI differently as a result of a 402 than it would as a result of, say, a user clicking on a link. That is not the case. Having the additional information from the server that a payment is about to be made, the browser can tighten its security to provide a temporary locked down sandbox while the payment process goes through. Simply clicking a link does not give the browser this information. Of course, a compromised browser would have the option of rewriting data, but that would happen with any HTML feed and the browser manufacturers go to some lengths to detect internal compromise. That is outside the scope of this proposal. Regarding a PHP/JavaScript attack by controlling the browser to make the payment, this is mitigated by the Bitcoin client (the protocol handler) asking the user to confirm the payment in the same way as clicking on the link does. The browser isn't in charge of the payment, an external app is. EDIT To emphasise that JavaScript is not permitted to take over the mouse pointer and drive it around the screen http://stackoverflow.com/a/4752512/396747 |
|
|
|
This is super insecure!!! Bitcoin URI is the best way to do this, there is a reason no one uses 402 response http header
Would you mind walking me through the security issues with this approach? The 402 response for "payment/bitcoin" contains a Bitcoin URI, and can be served up through HTTPS to avoid MITM attacks. Short of a server compromise I'm not sure what the attack vector is. |
|
|
|
Yes, sure, I was thinking of something like that.
After being pushed back and trying again - this time with money in your hands - you'll be granted access. Similar to HTTP authentication mechanisms.
That's the idea. Of course this approach is not limited to Bitcoin. PayPal could do something similar, but they would set the 402 Location header to some kind of credential entry page. |
|
|
|
I think there should be a way for the user to hand a signed Bitcoin transaction directly to the webserver requesting the coins. Because there is no guarantee that even a non-confirmed transaction will ever arrive. Perhaps the sender does not even have Internet access (the web page could be on a local LAN only).
Bear in mind that this is HTTP error response code. Essentially, you have just rocked up and asked for a premium resource and been pushed back. If you know in advance that this requires payment then you perform something like the following: > GET /premium/track/10 > Bitcoin-Transaction: <signed tx using generally defined non-HTTP standard> I leave the implementation of the bit above as an exercise for the reader  |
|
|
|
I don't think it's a good idea. This HTTP code could be useful for micro-payments, to give instant access to a newspaper article for example. But Bitcoin is not suitable for micro-payments, and nobody wants to wait for X confirmations before being able to continue browsing the web.
A 402 response code will not cause the browser to freeze up while payment is made. Instead, it simply communicates the need for payment to the browser which, in the case of Bitcoin, would occur out of band through the blockchain. To address your concerns over micro-payments - that is a policy decision to be made by the merchant running the server. If they choose to allow 0-confirm transactions for small value items then that is up to them. For larger value items, the merchant may choose to only accept a 6-confirm transaction before shipment. However, if the product is software then a trial version can be downloaded immediately, with a note stating that the full license key will be made available under a particular URI once payment is fully confirmed (or simply emailed for those less concerned about privacy). All of the above are policy decisions for the merchant, HTTP cares not about this. The 402 response code still provides an efficient communication of a demand for payment and a means for the browser to accomplish this. |
|
|
|
I don't think that the Bitcoin URI on its own is sufficient. Bitcoin provides a strong case to make the 402 PAYMENT_REQUIRED HTTP response code much more useful and I would like to solicit further comments from the community on this. Here is a simplified version of Matt's original proposal: Current credit card approachThe HTTP traffic surrounding a standard credit card intercept looks like this: > GET /premium/track/10 > Accept: audio/ogg < 302 FOUND < Location: https://secure.example.org/cc-form.htmlThe above response initiates a chain of requests and responses involving the entry of a number of credentials which culminates in the server accepting that payment has been made and then delivering the content. What should be noted is that the use of the 302 FOUND is subverting the semantics of the HTTP response code. The resource has not been temporarily moved, rather a new process has been introduced. There is a specific HTTP response code for this scenario but it has not been given sufficient detail in the current HTTP specification. Proposed internet currency approachThere are many competing technologies in the online payment space. However, Bitcoin has the advantage of having a single URI providing all the information required to make a secure payment. > GET /premium/track/10 > Accept: audio/ogg; payment/litecoin; q=0.2, payment/bitcoin Bitcoin response < 402 PAYMENT_REQUIRED < Location: bitcoin:1KzTSfqjF2iKCduwz59nv2uqh1W2JsTxZH?amount=0.5&label=Track10 In the second approach, the client is able to specify a range of preferred payment protocols which the server can negotiate. The above request would be interpreted as "I want audio/ogg, but if payment has to be made then I prefer Bitcoin but Litecoin is acceptable". Since an appropriate HTTP response code is being given the client knows that it has to initiate a payment. This could trigger additional security measures and warnings to the user. The Location header provides a URI which can be handled by the client, such as a HTTPS URI, or by a dedicated protocol handler such as a Bitcoin client. I've been in discussion with Michael Leonhard who manages the http://http402.org/ site and he is of the opinion that Roy Fielding or Tim Berners-Lee might be interested in this. |
|
|
|
Cool, I knew my 30k SO rep would be good for something  I picked those numbers based on how much Bitcoin I could personally part with for this cause, estimating at about 10BTC. However, if people will chip in to the tip jar, I can up those numbers. Gary -- sent you 0.2 BTC. Verified. Many thanks! |
|
|
|
Cool, I knew my 30k SO rep would be good for something Let's just ignore that 1 SER (Stack Exchange Rep) is valued at (0.2 BTC / 10000) * $11 = $0.00022. It is kind of the community to donate some BTCs for the tremendous resource that is Stack Exchange. This initiative does provide the following side-effects (at least): 1) promotes the visibility of Bitcoins ("Hey, what's that Bitcoin address meme about? More unicorns?") 2) helps locate SO contributors with high rep who are interested in Bitcoin ( bitcoin.stackexchange.com also helps here) 3) promotes the propster site As a side note, several progressive recruitment agents have noted that a high rep on Stack Exchange has been mentioned by prospective clients. They use it as a quick filter for "technical knowledge with solid communication skills". So maybe it is good for something else. |
|
|
|
|
Good idea. Does this work for general StackExchange profiles, rather than the narrow scope of StackOverflow?
For example, my rep on Programmers Stack Exchange is >10 000 but on Stack Overflow it is merely > 1000.
|
|
|
|
I'm sure many of you already have a long term backup strategy in place for those precious private keys. However, I thought I post here about the M-Disc from Millenniata for those who are unware that they can use a cheap DVD writer to store their data for 1000 years or more using the modern equivalent of carving the data into stone. There is an interesting write up from PC Pro about it here: http://www.pcpro.co.uk/blogs/2012/07/19/m-disc-the-dvd-that-lasts-forever/And the main site: http://millenniata.com/ |
|
|
|
|
I'll be attending for sure.
It would be very interesting to hear the views of the folks at Visa etc. I imagine that the good folks in those organisations will be well aware of Bitcoin, but will rightly be treating it as a largely insignificant threat to their current operations. After all, the market capitalization of Bitcoin is probably less than their daily network operations bill.
However, Bitcoin offers a unique opportunity. Imagine that they decided to use the Bitcoin network themselves in order to reduce the costs of their own money transfers and secure network infrastructure costs. This could represent a considerable internal saving for them.
Also, if they chose to act as a gateway for Bitcoin (after buying up large quantities themselves) they would be able to take advantage of the one-off rise in value against other currencies which would serve as a profitable investment. Shareholders would be pleased when their dividend statement arrived.
Over time, they would be able to divest themselves of some of the restrictions they are forced to operate under in order to provide fraud protection which would only serve to improve the efficiency of their organisation. This in turn would lead to a reduction in margin, but would be offset by a significant rise in volume due to reaching previously inaccessible markets (people without bank accounts, the third world poor etc).
Merchants would benefit from reduced transaction fees and a better overall service (irreversible transactions = fewer complaints to the helpdesk etc).
It would be good to see a gatekeeper become an innkeeper.
|
|
|
|
|
If your entire supply and distribution chain operates in Bitcoin, there is no need for Bitpay. However, until that time (if it ever arrives) it provides an excellent service by solving the problem of conveniently exchanging bitcoins to fiat.
It is definitely not a middleman.
|
|
|
|
Perhaps something like this (for giggles): Your post advocates a
( ) technical ( ) legislative ( ) market-based ( ) vigilante
approach to stopping Bitcoin. Your idea will not work. Here is why it won't work. One or more of the following may apply to your particular idea, and it may have other flaws which vary from country to country due to their own legal systems:
( ) Scammers can easily use it to bilk unsuspecting consumers/merchants
( ) Merchants and other legitimate businesses would be adversely affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against the combined Bitcoin community co-operating to undermine it
( ) It will stop Bitcoin for two weeks and then we'll be stuck with something broken
( ) Users of other payment services will not put up with it
( ) Google/Apple/Microsoft will not put up with it
( ) The police will not put up with it
( ) It requires too much cooperation from miners and/or Bitcoin user base
( ) It requires immediate total cooperation from everyone outside of Bitcoin at once
( ) Many people cannot afford to lose business or alienate potential employers
( ) Criminals will use anything that is convenient/presents an opportunity
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting this kind of meddling
( ) Lack of a centrally controlling authority for Bitcoin
( ) Open Bitcoin nodes in foreign countries
( ) Difficulty of searching enormous alphanumeric address space of all Bitcoin addresses
( ) Difficulty of beating the 51% mining power threshold
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept other people's problems as their own
( ) Huge existing software investment in web infrastructure
( ) Susceptibility of protocols other than Bitcoin to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Armies of offline, strongly protected Linux boxes
( ) Ad-hoc mesh networks not dependent on telecommunications companies
( ) Off-grid power generation (solar, wind, biomass etc)
( ) Offline or out-of-band Bitcoin transactions (physical coins, private key exchange)
( ) Eternal arms race involved in all filtering or censorship approaches
( ) Extreme efficiency of Bitcoin in comparison to other payment systems
( ) Chargebacks
( ) Inflation or quantitative easing
( ) Difficulty and cost of storing physical assets securely
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme intelligence, charm and good looks of the people who do business with Bitcoin
( ) Honesty on the part of the majority of the Bitcoin community
( ) M of N signatures in Bitcoin (escrow, web of trust etc)
( ) General script capability of Bitcoin
( ) Increasing the number of decimal places beyond the current value
( ) Self-adjusting difficulty value of the Bitcoin block solution
( ) Bandwidth costs that are unaffected by client filtering
( ) TOR
( ) Strong peer-reviewed cryptography
( ) Mathematics
( ) Economics
( ) Physics
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) Not everyone will opt-in
( ) Bitcoin protocol considerations should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to conduct business without being censored
( ) Countermeasures should not involve fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Fees should be reasonable and transparent
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Fixed Bitcoin addresses are cumbersome
( ) I don't want the government running my currency
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
( ) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Have you considered an alternative career?
|
|
|
|
|
Show Posts
