Bitcoin的四个障碍系列之第二部分--交易

以下文章均由GOOGLE翻译,有很多翻译错误的地方,欢迎网友们指正如有兴趣请网站留言帮ME翻译,如果准确率高将BTC支付酬劳.

这是我Bitcoin的四个障碍系列的第二部分。我以前处理的可用性。今天，我会看一看交易。更具体而言，交易量和它的缺乏。人们正在讨论是否Bitcoin是一个交易系统，现金等值项目，保值的，或别的东西。我相信大多数人都使用它作为价值储存现在 - 预期炒作的手段，充分发挥其潜力将实现。我还没有看到一个这样的系统在一个很长很长的时间的潜在。但它仍然有一段路要走到那里。

人不使用它作为保值的东西比其他的原因，我认为，是其缺乏可用性。有一个强大的经济压力，内bitcoin交易量。而这，本身就是第二个Bitcoin必须清除的障碍 。

有些人认为，人们不会在Bitcoin只要支付，因为它是在这个速度扣除。这样的说法并没有在所有的经济意义 。如果我能够使用我的人均可支配收入（读“怪胎玩具预算”）使用Bitcoin，我会立即这样做 。当我的薪水每个月的最后一个抵达，我想我的可支配部分转换Bitcoin，并用它来 ​​购买的东西，在一个月的过程中。当我的东西支付月中旬，这意味着我有购买的怪胎玩具时Bitcoin升值，通缩的两个星期，在我的背上。对我来说这意味着更多的玩具！立即获胜。商家得到相同的通货紧缩的好处，直到变化和其他一些，更重要的的好处，我将返回 。

尽管强大的商业案例，这是不可能的的，今天拉断。因此，我将结束与一些技术性的建议。

有些讽刺的是，我做这个幻灯片演示文稿时，我写了这个系列的一部分：

这是很有趣的事件的步伐是如此之高，事情发生之前，我得到一个机会来形容他们为什么会的。这方面的发展，预计在博客后，定于6月16日，这是一部分Bitcoin的四位车手3，但它已经发生了 。内存经销商真正钉：

这就像现金 - 免费使用，没有人会收取任何交易费用。

这里的商业案例，为客商。就在这里。信用卡公司脱脂关闭的每一次购买5％左右。正如银行处理现金。  每次购买。这将增加一倍的利润，在一个典型的业务，如果你能摆脱它的钱。这是一个令人信服的理由，切换到另一个支付交易系统，即使你是立足于您的业务一切都在您当地的法定货币。

因此，让我们考虑如何从这里我们可以建立我们走向未来的桥梁 。由于所有的价格都在列出的法定货币，让我们假设，暂时不会改变。让我们的交易量，而不是确定使用Bitcoin前保龄球引脚作为法定货币支付系统，与一些有实力的买方和卖方，所述的经济方面利益的支付系统。这将是未来迈向金融生态Bitcoin稍后驱动。

我需要能够支付一个10€T恤“bitcoin相当于”就像我可以为它付出与“塑料相当于”。

所以这里有什么欠缺，我看到它的方式，都是一些非常简单的服务器端和客户端组件。我需要能够支付我与一个单一的点击新玩具，商人需要能够迅速产生的一个Bitcoin金额服务器端（目前的汇率计算）支付通常在当地法律中列出的项目招标，呈现就像商人今天薪酬与签证表格。

和IT需求要简单和容易。

技术建议大纲 - 服务器端

假设网网站，这是代码的数量和起飞的交易量所需的抽象级别：

使用Bitcoin;

无效的Application_Start (...)
{
  ... ...
  Bitcoin.Connect（）;
  Bitcoin.TransactionReceived =
    新BitcoinEventHandler（BitcoinReceived）;
  ... ...
}

私人字符串BitcoinPaymentLiteral（购物车车）
{
  / /这个文字被添加到“立即付款”页面
  / /购物车中的视图。

  / /生成的地址，并把这个车
  BitcoinAddress newAddress =
    Bitcoin.CreateAddress（cart.Amount，“欧元”，车）;

  / /创建文本

  字符串字面= String.Format（
    “点击<a href=\"{0}\">这里</ a>支付€{1：N2}”+
    “使用฿{2：N2}”，
    newAddress.PaymentUrl，
    cart.Amount，
    newAddress.ExpectedAmountBtc）;

  返回文字;
}

无效BitcoinReceived（对象发件人，
    BitcoinEventArgs级）
{
  / /这个事件被触发时，当我们收到BTC资金。
  / /这是必然中的Application_Start。

  BitcoinAddress地址= eventArgs.Address;
  购物车购物车（购物车）address.Cookie;
  cart.ProcessReceivedPayment（）;
}

无效Application_End (...)
{
  ... ...
  Bitcoin.Disconnect（）;
  Bitcoin.TransactionReceived -= BitcoinReceived;
  ... ...
}

这对于服务器端的。但注意到，BitcoinAddress.PaymentUrl方法，我们需要的东西，以及客户端。所以... ...

技术建议大纲 - 客户端

这是一个简单的建议，可以在任何一个Firefox /浏览器插件从一个bitcoin客户端实施：

当有人点击一个链接在bitcoin：金额/地址格式，使用点击的页面的域，并在/ bitcoinlogo.png获取的方方面的形象，并用它要求在一个对话框，确认： “[图]，你支付{金额}这个店请求。是或否？“。如果有的话，转移的资金来解决。

地址是简单。的金额应该是人类可读的，因此，我建议为以下格式金额：

{金额} [K |米| U]

在很短的一段时间，我们可能会看到价格为0.00141 bitcoin的事情。但打字像手 - 这是肯定会发生在支付环节的许多网页（认为“捐献这里”） - 是一个小数错误，校对，甚至在错误的主要来源。因此，我建议从一开始就具有前缀。

金额0.00141本来可以更好书面1.41米（1.41 millibitcoin），或1410u为那些喜欢（1410 microbitcoin）。这使得它更具可读性。可读性强可取。（同样的k前缀工程公斤，很可能只会用于购买豪宅和豪华跑车，我不预见需要为一个大型的前缀。）

英文原文如下:

This is part two in my series about Bitcoin’s Four Hurdles. I have previously addressed usability. Today, I will take a look at transactions. More specifically, transaction volume and the lack of it.

People are discussing whether Bitcoin is a transaction system, a cash equivalent, a store of value, or something else. I believe most people are using it as a store of value right now — an instrument of speculation in anticipation that its full potential will materialize. I have not seen a system with such a potential in a very, very long time. But it still has some way to go to get there.

The reason people are not using it as something else than a store of value, I argue, is its lack of usability. There is a strong economic pressure to get the intra-bitcoin transaction volume going. And this, in itself, is the second hurdle that Bitcoin must clear.

Some people have argued that people won’t pay in Bitcoin for as long as it is deflating at this rate. That argument makes no economic sense at all. If I were able to use my disposable income (read “geek toy budget”) using Bitcoin, I would do so immediately. When my paycheck arrived on the last of every month, I would convert my disposable part to Bitcoin, and use it to buy stuff over the course of the month. When I pay for something in the middle of the month, that means I have got two weeks of Bitcoin appreciation-deflation in my back when buying the geek toys. That means more toys for me! Immediate win. The merchant gets the same deflation benefits until change-in and some other, more important benefits, which I’ll be returning to.

Despite the strong business case, this is impossibly hard to pull off today. Therefore, I’ll be ending with some technical proposals.

Somewhat sarcastically, I made this slide as part of a presentation when I wrote this series:

It is quite interesting that the pace of events is so high, that things happen before I get a chance to describe why they will. This development is predicted in the blog post that is scheduled for June 16, which is part three of Bitcoin’s four drivers, but it has already happened. Memory Dealers really nail it:

It’s like cash — it’s free to use and nobody will charge any transaction fees.

Here’s the business case for merchants. Right here. The credit card companies skim about 5% off of every purchase. As do banks handling cash. Every purchase. That’s money that would double the profit margin in a typical business if you could get rid of it. That’s a compelling reason to switch to another payment transaction system, even if you’re basing everything in your business on your local legal tender.

So let’s consider how we can build our bridges from here into the future. As all prices are listed in the legal tender currency, let’s assume that won’t change for the time being. Let’s instead identify the front bowling pin for transaction volume as using Bitcoin as a payment system for the legal tender currency; a payment system with some strong economic side benefits for both buyer and seller, as described. This will be a future driver towards moving more of the financial ecosystem to Bitcoin later on.

I need to be able to pay for a €10 T-shirt with “bitcoin equivalent” just like I can pay for it with “plastic equivalent”.

So what’s lacking here, the way I see it, are some very very simple server-side and client-side components. I need to be able to pay for my new toy with one single click, and the merchant needs to be able to quickly generate a Bitcoin amount server-side (based on the current exchange rate) to pay the item normally listed in the local legal tender, just like the merchant presents a pay-with-Visa form today.

And it needs to be simple and easy.

Technical proposal outline — server side

Assuming a .Net site, this is the amount of code and the level of abstraction that is needed for the transaction volume to take off:

using Bitcoin;

void Application_Start(...)
{
  ...
  Bitcoin.Connect();
  Bitcoin.TransactionReceived +=
    new BitcoinEventHandler (BitcoinReceived);
  ...
}

private string BitcoinPaymentLiteral(ShoppingCart cart)
{
  // This literal is added to the "Pay Now" page
  // in the shopping cart view.
  // Generate address and tie it to this cart
  BitcoinAddress newAddress =
    Bitcoin.CreateAddress (cart.Amount, "EUR", cart);
  // Create the literal
  string literal = String.Format (
    "Click <a href=\"{0}\">here</a> to pay €{1:N2} " +
    "using ฿{2:N2}",
    newAddress.PaymentUrl,
    cart.Amount,
    newAddress.ExpectedAmountBtc);
  return literal;
}

void BitcoinReceived (object sender,
    BitcoinEventArgs eventArgs)
{
  // This event is fired when we receive funds in BTC.
  // It is bound in Application_Start.
  BitcoinAddress address = eventArgs.Address;
  ShoppingCart cart = (ShoppingCart) address.Cookie;
  cart.ProcessReceivedPayment();
}

void Application_End(...)
{
  ...
  Bitcoin.Disconnect();
  Bitcoin.TransactionReceived -= BitcoinReceived;
  ...
}

That’s it for the server side. But noticing that BitcoinAddress.PaymentUrl method, we need something client-side as well. So…

Technical proposal outline — client side

This is a simple proposal that can be implemented in anything from a bitcoin client to a Firefox/Chrome plugin:

When somebody clicks on a link in the bitcoin:amount/address format, use the domain of the page clicked and fetch the square-aspect image at /bitcoinlogo.png, and use it to ask for a confirmation in a dialog: “[image] this shop requests that you pay {amount}. Yes or No?”. If yes, transfer the funds to address.

The address is straightforward. The amount should be human readable, and therefore I suggest the following format for amount:

{amount}[k|m|u]

In a short while, we might see things priced at 0.00141 bitcoin. But typing it in like that by hand — which is certainly going to happen on many webpages in a payment link (think “donate here”) — is a major source of error in getting the decimals wrong, even on proofreading. Therefore, I suggest having prefixes in from the start.

The amount 0.00141 could have been better written as 1.41m (1.41 millibitcoin), or 1410ufor those who prefer (1,410 microbitcoin). It makes it much more readable. Readability is strongly preferable. (The k prefix works similarly for kilo and will probably only be used to buy mansions and luxury sports cars. I do not foresee a need for a mega prefix.)