The operational costs are very low. The time value of money will have to be paid by the customer, but it shouldn't be prohibitive. If the interest rate is 0.5% per month, that's more or less the cost of using this scheme (better than Bit-Pay's 1% or PayPal's 3%+), and you get instant payments which can be arbitrarily small. And if you make it shorter than 1 month it is proportionally less - with 6 days it's 0.1%. And, if a customer both sends and receives payment, and is willing to trust the processor with a small amount, he can cancel out most payments and thus not need a large channel, decreasing the cost per transaction.

Bitcoin and its ecosystem isn't supposed to replace just PayPal. It should replace cash, checks, credit card, bank transfers etc., and allow a whole new world of microtransactions. The latter is one key issue this proposal solves - for small transactions 0.5% isn't much, but the cost of processing the transaction by all network nodes in the world is.

What, in your opinion, is the difference between miners and banks in this regard? Sure, miners are anonymous by default, but Bitcoin banks can also be anonymous, unlicensed and operating through TOR if they want. Exchanges have a problem because they deal with traditional money which isn't a cryptocurrency.

What makes Bitcoin decentralized is that there are many nodes and miners, with a low barrier of entry to becoming one. The situation is almost as good if there are multiple payment processors which have a low barrier of entry and trust requirement. Barrier of entry is really the key issue, and what the raw Bitcoin network allows, with all its power, is the lowering of barrier of entry to processors.

You may also want to take a look at my new idea for trustless payment processors: https://bitcointalk.org/index.php?topic=91732.0.

RSMPPS is not hopping-proof.

I think I've found a way to combine hashcoin's method for Instant TX for established business relationships and Gavin's more recent ideas for Off-the-chain transactions to allow any party to send bitcoins to any other party, with instant confirmation, without adding to the transaction count of the blockchain (thus scalability-friendly), with absolutely minimal need for trust in a third party. The disadvantage is that it requires bitcoins to be tied up, so it is less effective the more time value bitcoins have.

hashcoin's method, if I understand it correctly, allows establishing a payment channel from user A to user B with the following properties:
1. A has to tie up X BTC for a period of time decided in advance (say a month).
2. During this time, A can't do anything with those bitcoins other than paying to B.
3. Establishing a channel does not constitute payment. B can't take the money, and if B vanishes A will still get it back at the end of the period.
4. While the channel is up, A can use it to pay B multiple times, up to a total of X BTC.
5. Each such payment is done by private communication between A and B, doesn't require communication with the network or a separate transaction, and is instantly confirmed - once B gets the necessary information from A, he can be sure it cannot be reversed.
6. At the end of the term, all payments are settled together with 2 small transactions.
7. If A vanishes mid-term, B can still claim his payments so far at the end. If B vanishes mid-term, A can still claim everything that he hasn't paid yet, and in some cases even the funds that he has paid.
8. The receiver can close the channel before its expiration date if it's no longer needed, freeing the tied up funds.


The question is what to do if I don't know in advance who I'm going to pay. And the answer is simple - have an eWallet of sorts that never holds anyone's money, but simply establishes payment channels to and from each of its customers.

Say Alice and Bob are both users of the payment processor Trent. Trent establishes channels to Alice and Bob, and Alice and Bob establish channels to Trent. The amounts and period will be determined by how much money each expects to move.

If Alice needs to pay Bob, she pays Trent through the channel, and informs him that Bob is the recipient. Trent then pays Bob through the channel. The payments are instantly confirmed and there is no need to add a transaction to the blockchain for this.

Instead of one transaction per payment, we have about 4 transactions per user per period over which there can be many payments. And the processor is never trusted with more than the amount of a single payment by a single customer.

The BTC amount of the channel, which is constantly tied up, should suffice for the payments that are expected to be made over the period. The shorter the period, the less funds need to be tied up, but the more transactions need to enter the blockchain in a time unit. There's a tradeoff for which an optimal solution will be found on a case-by-case basis. No doubt, Trent will charge his customers for the service of tying up his own funds for the downstream channel. Either party of course can create a new channel when the current channel end up not sufficing, at the cost of more blockchain transactions.

There is no need for Alice and Bob to be using the same payment processor. The processors can have reciprocity agreements between them and allow funds to be sent from one to another. If there is some trust between them, they can cancel out small payments without saturating the channel, reducing the amount they need to tie up for this.

There is very little barrier of entry to becoming a processor, so there will be many highly competitive processors.

Unlike the current version of Gavin's idea, this is resistant to collusion, to accounting errors of the processor, and to the processor vanishing thus making the coins unspendable.


It may be hard to imagine anyone tying up his funds for this, when weekly interest rates of 2% are easy to be found. But this isn't going to last forever - as Bitcoin grows and stabilizes, ROI for safe investments will settle down, and the time value of money will approach what we are familiar with in traditional economics (probably even less, because there is no inflation). It will be reasonable to keep bitcoins as-are as a long-term investment, and by that point one may as well tie them up in a channel to his payment processor.


EDIT: It appears I've missed this comment by jav, where he also mentions the receiving end can be a payment processor. But he doesn't go as far as suggesting that the processor should also use outgoing channels.

It's not really centralization because there can be many such third parties. The barrier to entry is low and the trust required is low.

The methods can be used to reduce network traffic as much as we want, depending on what tradeoffs we are willing to make. The local/eWallet separation for small/large transactions could easily cut 99%.

Nope, I just like calling him that as a homage to Sir Gavin's character in King Arthur's Disasters.

If all else fails, yes. A transaction will always be cheaper if it doesn't need to be processed by every Bitcoin node on the planet, it's just a matter of finding how to make it reasonably secure without it.

Whom is this directed at? The solutions I mentioned don't centralize Bitcoin.

By the way, Sir Gavin has recently posted about a new way to scale Bitcoin, Off-the-chain transactions. I haven't studied it yet but it looks promising.

400% to be exact.

BFL FPGA singles can be used to trade-in.

Lightweight clients.

Hash functions aren't broken overnight. When cracks start to be found in SHA256 we can worry about this.

Change the protocol so a given % of blocks needs to be SHA256 and a different % some other function, and change the percentages gradually. This gives hardware owners less to worry about, and ample time to develop ASIC for the new function.

We should focus on stuff that are relevant now, and defer stuff that will be relevant in decades.

Compatibility-breaking changes aren't made on the fly.

But you have p2pool, so why is it so important to change the protocol?

I don't think you understand how Bitcoin works. Proof-of-work is what secures transactions from double-spending.

ASIC doesn't lock Bitcoin into SHA256, it just means that switching to a new hash function should be gradual over several years.

Um, no. Simple changes to the protocol take months. Difficult, compatibility-breaking, unjustified changes would take years. So would getting the entire economy to move to an alt coin.

ASIC equipment available to the public is good for Bitcoin.

If the bond is sold for 1.3 BTC, if he keeps 1 BTC sitting in GLBSE for a permanent 100% bid wall, he only has 0.3 BTC to invest in Pirate or elsewhere, and will still need to generate 0.07 BTC weekly, or 23% weekly ROI. I don't believe they can do that. More likely is that they will place some bids for day-to-day demand, and given time will replenish executed bids, withdrawing from investments if necessary.

And, they didn't commit to doing even that. They said that they will execute any asks within a reasonable time frame, without any clue what is "reasonable".

And, usagi can cancel any bids at any time, so this doesn't really answer Vandroiy's question.

Coinlab, Coinbase, probably Bit-Pay and BitInstant.

Let's try to clarify to some terms.

Speculation: Buying bitcoins for the sole reason that you believe the exchange rate will go up and that you will profit from it. (You can take a position on BTC without buying bitcoins, and you can speculate negatively, but let's leave that).

Speculative value: The effect on the Bitcoin price caused by people speculating.

Fundamental value: The price Bitcoin would have in an equilibrium in which nobody speculates.

Hoarding: There is no such thing, it's a description of a person's mentality rather than any action or underlying metric.

Demand: People wanting bitcoins over the equivalent amount in a different currency with the current exchange rate. Demand can be either speculative (due to anticipation of appreciation) or fundamental (because Bitcoin has superior properties), or a combination of both.


Now, speculation is its own thing and is affected by many factors, but we'll put it aside since your question was about the fundamental value. To understand what effects it, we will picture a world in which nobody can profit or lose from changes in the BTC exchange rate. In such a world, what would the price be?

To find it we can use two simple invariants - the total purchasing power of all bitcoins is equal to the number of bitcoins times the purchasing power of a bitcoin, and the total purchasing power of all bitcoins is equal to the sum of the purchasing power held in bitcoins by all Bitcoin owners.

Since converting between Bitcoin and fiat has exchange costs, one wouldn't convert between them on the spot for every transaction; he would keep a certain amount of each, where the amount scales with how much he plans to use. If there are more businesses accepting Bitcoin directly (with a discount due to no fees), he'll spend more purchasing power in Bitcoin form, and thus hold more purchasing power in bitcoins at any given point. This applies both to people who have a Bitcoin income and will not be as quick to sell it, and people with a fiat income who will want to convert it to bitcoins to be able to enjoy discounts and all the other Bitcoin features.

If you apply this to every individual, and then use the two invariants, you'll find that the more businesses are accepting Bitcoin, the higher the fundamental value of a bitcoin will be.

This is a stable equilibrium because every disruption will be corrected. If the price becomes higher, people with bitcoins will find themselves with more Bitcoin purchasing power than they need, so they will sell some, lowering the price. If the price becomes lower, people will sell less to make sure they have the Bitcoin purchasing power they need.

Because it's a pre-order. He's getting the funds now so he can use them to order the units. He's keeping his BFL exposure in check this way.

I would argue that Digicash failed not because of anyone's bad business decisions, but because it had someone doing business decisions, i.e. it was centralized.


Anyway, while this may not be a clear definition of the problem Bitcoin is solving, here is a list of advantages it has (adapted from http://www.bitcoin.org.il/אז-למה-בכלל-צריך-את-זה/).

1. Easy to send payments internationally without fees.
2. No chargebacks.
3. International.
4. Easy to get started with receiving bitcoins.
5. Possibility of microtransactions.
6. No inflation.
7. No single point of failure.
8. Payment is done via digital signatures rather than giving away your password.
9. Objective public record of payments made in case of disputes.
10. An option for small countries without a viable currency of their own.
11. No need to rely on financial institutes with poor service.
12. A powerful scripting language that allows more advanced transactions than "A is paying X to B", and derivatives of the technology such as Namecoin.
13. Privacy.
14. No restrictions on whom you can pay.

With 47% the attacker has a chance to succeed, but no certainty. With >50% he is guaranteed to win eventually, no matter how many blocks are waited (though "eventually" can be a very long time, on average inversely proportional to the excess).

I usually call it the >50% attack.

It doesn't scale linearly. I wouldn't be surprised if a single node could technically serve all users. But we need many nodes to keep the network healthy, robust and competitive. My guesstimate is that 3,000 is good, and that's just as true when there are 1B users as when there are 1M.

Assuming each transaction is 1KB, we're talking about 10K tps * 1KB = 10 MB/s per node, which is a high-end home internet connection now, let alone a business-grade connection in the future. It should be well within the ability of any company that receives a lot of payments and has an interest both in the health of Bitcoin and its own safety of payments.

I'm more of a theory guy but there's progress. We have some lightweight clients, and there's a new construct design by etothepii that gives lightweight clients even more power than in Satoshi's original design. Also I think there's work being done with respect to pruning, which will keep storage requirements relatively low.

Yes, I believe even with the existing ideas and technology it can technically scale to a billion transactions per day. No doubt there will also be new ideas and hardware advances that will make things even easier. If someone comes up with a completely different architecture that is even more scalable, Bitcoin can migrate to it while keeping people's savings intact.

Also, as MoonShadow points out, it doesn't need to scale to a billion raw transactions per second. Bitcoin's role main role is to be a superior alternative to physical cash; just as there are services to overcome the deficiencies of cash, so can there be services to overcome any deficiencies of Bitcoin. But because Bitcoin is digital and has a very powerful scripting system, these services can be much more lightweight and competitive, and hence better and more efficient, than with the current system.

For example, you can have a client that stores the majority of your savings locally (preferably with some multiple signature arrangement for added safety) but automatically keeps some in an eWallet service. Whenever you make a small transaction it is done internally in the eWallet (with reciprocity with other eWallets); only for large transfers/eWallet replenishment you make a raw Bitcoin transaction. This already can cut maybe 90% transactions.

Also, solutions such as Ripple and Open Transactions can work much better with Bitcoin as their foundation, and they have much lower resource requirements for global commerce.


The real problem isn't with the feasibility, it's with the incentive structure. Running a node should be relatively easy, but it will still have costs, and not much direct gain - it's a Tragedy of the Commons problem. There could be a situation where everyone tries to freeload on the other. This can be resolved if the costs can be kept low enough that companies won't be fussy about it, with a market for node services, or with a transaction propagation incentivization schemes as in the "On Bitcoin and Red Balloons" paper.

And, the real problem isn't with the marginal resource cost of handling transactions, either. It's with the amortized cost of securing transactions with hashing. Depending on how strong the incentives of potential attackers, funding the defense efforts is going to cost a lot for the Bitcoin economy, regardless of the technical solution chosen. This I think is the main challenge, and while there are some proposed mitigating schemes, they are not popular.