Micropayments?

[pj]

You are mixing up different things.
 ...
 - Performance of transaction processing

...
The latter is, by design, subject to the market (see transaction fees)

That transaction processing is subject to the market does not eliminate the requirement (in my view) to understand its algorithmic performance characteristics.

[davout]

The latter is, by design, subject to the market (see transaction fees)

That transaction processing is subject to the market does not eliminate the requirement (in my view) to understand its algorithmic performance characteristics.
[/quote]

 - I'm a client, I broadcast a transaction to the network and all of its miners,
 - I'm a miner, I get the transaction, I include it in my merkle tree (inexpensive), and I keep mining. The mining algorithm is basically brute force SHA hashing on a fixed size message, so it's o(1) in relation to the number of transactions that are included in the currently mined block.
 - If I find a block I broadcast it (see research on P2P technology in relation to performance/thoughput/you name it)
 - A block is broadcast to me, I update my merkle tree and root and I keep crunching (every 10 minutes on average), I would (maybe naively) assume that the merkle tree update is o(n) in relation with the number of transactions that were previously included in the candidate block

Hmm, writing this post I'm starting to think it might be nice to have a full fledged, peer reviewed, detailed, and thorough analysis of all the factors that need to be balanced for optimal performance but that doesn't change my main opinion which is that bitcoin won't be good at micro-payments.

[pj]

- I'm a miner, I get the transaction, I include it in my merkle tree (inexpensive), and I keep mining. The mining algorithm is basically brute force SHA hashing on a fixed size message, so it's o(1) in relation to the number of transactions that are included in the currently mined block.

So ... how does this work after bitcoin has been successful for several decades, and we have trillions of past transactions, but only hundreds of millions of active users providing meaningful compute power for mining?

In other words, does the cost of mining increase over time with a higher exponent than the number of computationally useful mining nodes?
 

Hmm, writing this post I'm starting to think it might be nice to have a full fledged, peer reviewed, detailed, and thorough analysis of all the factors that need to be balanced for optimal performance but that doesn't change my main opinion which is that bitcoin won't be good at micro-payments.

I am quite willing to agree that bitcoin as currently conceived is not well suited for micro-payments, without some additional supporting infrastructure, outside of the core bitcoin mechanism.

However, it might be possible, once such a full fledged analysis of these factors had been done that this would illuminate the way to core algorithmic improvements in this or other useful regards.

[davout]

So ... how does this work after bitcoin has been successful for several decades, and we have trillions of past transactions, but only hundreds of millions of active users providing meaningful compute power for mining?

In other words, does the cost of mining increase over time with a higher exponent than the number of computationally useful mining nodes?

See http://www.bitcoin.org/bitcoin.pdf chapters 7 and 8

I am quite willing to agree that bitcoin as currently conceived is not well suited for micro-payments, without some additional supporting infrastructure, outside of the core bitcoin mechanism.

However, it might be possible, once such a full fledged analysis of these factors had been done that this would illuminate the way to core algorithmic improvements in this or other useful regards.

You seem to assume that it is desirable that bitcoin be good at micro-payments, I don't think it has any importance whether the core protocol is inefficient at it or not.

[pj]

See http://www.bitcoin.org/bitcoin.pdf chapters 7 and 8

Good - thanks.

You seem to assume that it is desirable that bitcoin be good at micro-payments, I don't think it has any importance whether the core protocol is inefficient at it or not.

Of course I think it is desirable.  Why would I think not?

I agree that it appears out of reach, at least given our current understanding.

But if the core mechanism provided perfect security and instant validation of millions of simultaneous payment requests of value from tiny fractions of a BTC to billions of BTCs, why would that not be desirable?

The closer we can push the core mechanisms to that ideal  imaginary  goal, the better, all else being equal.

First however we need to reverse engineer the protocols, validate that specification with the successful implementation of alternative, fully compatible, clients, and subject the network behavior to a rigorous algorithmic complexity analysis.  I presume there are others with similar goals, who have already made some progress in such directions.  As I read through old posts on this forum, I will likely find postings mentioning such efforts.

[freetx]

You seem to assume that it is desirable that bitcoin be good at micro-payments, I don't think it has any importance whether the core protocol is inefficient at it or not.

I think we need to clarify 2 issues, which are really distinct. Since I started this thread I'm responsible for not clarifying this. When we are talking about "micropayments" (a bad choice of a term on my end) there are 2 issues:

• Payments that are an order of magnitude less than normal "useful" transactions (eg. .001 USD)
• Payments that happen at greater than 2 decimal places precision

These are actually 2 distinct concerns, and it is the 2nd issue that I'm most concerned with. Mainly because BTC is by design a natural deflationary currency (its value of BTC relative to USD has already gone up 5x since July).

Even if Bitcoin only achieves a moderate success of having 200K active users, given the fact that only 5M BTC are in existence, this is going to lead to heavy deflationary pressure.

I don't have an economic concerns about this - as the Keynesians have been consistently been proved wrong with regard to liquidity concerns - double so since as a purely electronic currency its trivial for us move a decimal place over.

So, my point is that inevitably *all* transactions are going naturally require moving one decimal place over. We are going to have a sort of reverse Zimbabwe problem on our hands, particularly how to on-the-fly add more decimal places.

Honestly, I think the choice of only having 21M possible BTC was a design flaw. Precisely because its going to force us into an unnatural and unwieldily situation with regards to decimal places. What do you even call .00001? Why introduce this complexity in the first place? In retrospect I think it would've been better to have a 2B maximum cap, solely for the reason is it would help keep notional representations into the whole integer range.   

[davout]

Of course I think it is desirable.  Why would I think not?

I don't know what your desires are unless you express them.

But if the core mechanism provided perfect security and instant validation of millions of simultaneous payment requests of value from tiny fractions of a BTC to billions of BTCs, why would that not be desirable?

Perfection would be nice of course. But it would be just as nice to me to have mechanisms handling that outside of the core mechanism.

The closer we can push the core mechanisms to that ideal  imaginary  goal, the better, all else being equal.

That's not realistic, you'll always have trade-offs.

First however we need to reverse engineer the protocols, validate that specification with the successful implementation of alternative, fully compatible, clients, and subject the network behavior to a rigorous algorithmic complexity analysis.  I presume there are others with similar goals, who have already made some progress in such directions.  As I read through old posts on this forum, I will likely find postings mentioning such efforts.

Yes, there is a documentation of the protocol.

[davout]

Honestly, I think the choice of only having 21M possible BTC was a design flaw. Precisely because its going to force us into an unnatural and unwieldily situation with regards to decimal places. What do you even call .00001? Why introduce this complexity in the first place? In retrospect I think it would've been better to have a 2B maximum cap, solely for the reason is it would help keep notional representations into the whole integer range.   

This is a non-issue, make a client that displays your balance in nanoCoins and BOOM, your supply is now 21,000,000,000,000,000 NTC
Protocol and client evolutions will introduce 10 extra decimal places if it ever becomes a need.

[pj]

That's not realistic, you'll always have trade-offs.

Just because something doesn't seem realistic at present doesn't mean we should not prefer it, were it available.

[pj]

This is a non-issue, make a client that displays your balance in nanoCoins and BOOM, your supply is now 21,000,000,000,000,000 NTC

It may be a non-issue to the minority of us who can shift decimal points about with ease, but for the majority of humans, currency units need to be scaled to practical values.

[davout]

That's not realistic, you'll always have trade-offs.

Just because something doesn't seem realistic at present doesn't mean we should not prefer it, were it available.

My point is : I do not think bitcoin will be good at handling lots of micro-payments, it is by design. Nor do I desire this capacity. Of course, if someone removes limitations without impacting the core functionality, sure!

But from my experience and the information I gathered from different sources it seems to me that it can't be achieved in such a way, therefore I think micro-payments will be handled by bitcoin banks, not by the block chain. And from my experience, this position seems to be a consensus amongst the bitcoin community.

[pj]

My point is : I do not think bitcoin will be good at handling lots of micro-payments, it is by design. Nor do I desire this capacity. Of course, if someone removes limitations without impacting the core functionality, sure!

But from my experience and the information I gathered from different sources it seems to me that it can't be achieved in such a way, therefore I think micro-payments will be handled by bitcoin banks, not by the block chain. And from my experience, this position seems to be a consensus amongst the bitcoin community.

We're in agreement.  I just understood your "not desire" position to mean "it would be wrong even if we could", whereas I take it now that you meant "it is not something I seek, because it almost certainly cannot be found."

Peace.

[davout]

It may be a non-issue to the minority of us who can shift decimal points about with ease, but for the majority of humans, currency units need to be scaled to practical values.

You misunderstood, nanoCoins would be integers displayed to the user handled under the hood as 1e-9 BTC.
Transferring 1 BTC to this client would display a balance of 1,000,000,000.
This really shouldn't be worried about

[freetx]

It may be a non-issue to the minority of us who can shift decimal points about with ease, but for the majority of humans, currency units need to be scaled to practical values.

You misunderstood, nanoCoins would be integers displayed to the user handled under the hood as 1e-9 BTC.
Transferring 1 BTC to this client would display a balance of 1,000,000,000.
This really shouldn't be worried about

Technically it won't need to be worried about, logistically it will.

You want Amazon to eventually support BTC right? Does their current system support .000001 precision?

[pj]

This really shouldn't be worried about

People do not work in isolation, seeing BTC's only via their BTC client.

They also talk about them, read about them, see such values displayed on potential offers to buy and sell, ...

Human factors absolutely should be worried about.

[davout]

Technically it won't need to be worried about, logistically it will.
You want Amazon to eventually support BTC right? Does their current system support .000001 precision?

Whether merchant X or Y supports bitcoin is up to them, if they see a profit opportunity, they will make it happen, no matter how many decimal places bitcoin has.

People do not work in isolation, seeing BTC's only via their BTC client.

They also talk about them, read about them, see such values displayed on potential offers to buy and sell, ...

Human factors absolutely should be worried about.

You guys are worrying about something that could only happen if bitcoin was widely adopted, fearing that it would prevent its adoption by new users. You see how it is a non-issue ?

[pj]

You guys are worrying about something that could only happen if bitcoin was widely adopted, fearing that it would prevent its adoption by new users. You see how it is a non-issue ?

You're changing your tune, from
  "It should not be worried about -- it's a non-issue because users would not  notice if their clients were displaying nano-bitcoins",
to
  "it should not be worried about now, because it will not matter for a long time."

Well, if it will matter in a long time, then (1) it might be easier to address now, while bitcoin is young, (2) if it is not addressed, it could harm acceptance, as some savier people will not adapt something in the short term that doesn't have a long term path to success, and (3) you're still wrong that users would not notice whether their client displayed bitcoins or nano-bitcoins.

[davout]

You're changing your tune, from
  "It should not be worried about -- it's a non-issue because users would not  notice if their clients were displaying nano-bitcoins",
to
  "it should not be worried about now, because it will not matter for a long time."

I'm merely presenting two sides of the same coin and two reasons to not worry about something that is in no way an issue.

Well, if it will matter in a long time, then (1) it might be easier to address now, while bitcoin is young,

Nobody knows whether it will actually matter, maybe bitcoin will be used the same way as gold, to store value, maybe it will be used everyday by my girlfriend, maybe it will be used to back other currencies.

(2) if it is not addressed, it could harm acceptance, as some savier people will not adapt something in the short term that doesn't have a long term path to success,

What could really harm acceptance is a weak economy where it is hard to get a hold of real goods and service in exchange for your currency, no matter whether this currency is called "bitcoin", "bitcent", "nanocoin", or "john mac douglas the third".

and (3) you're still wrong that users would not notice whether their client displayed bitcoins or nano-bitcoins.

I never said users wouldn't notice, I said they wouldn't care, as long as they get to manipulate almost-integer values.

It's not how many bitcoins are issued that matters, it's whether it's possible to order 24/7 sushi with them that matters.

Educate yourself about the protocol, you'll discover that it's future-proof in lots of ways.

You're free to keep worrying, that would suck though, I don't like worrying.

[Cdecker]

Well and there I was assuming the really nice part of Bitcoin was it's being completely decentralized, by letting "banks" do the aggregation you not only create single points of control but also single points of failure. It's nice that they also act as aggregation points, there's no discussing this, but the system should be developed in a direction where it becomes better scalable and may potentially handle all transactions natively, as long as we're not there I'm be fine with having aggregation points but the ultimate goal should always be a currency handled only by the peers.

P.S.: micropayments is not the only place this applies, basically the network does not care if I move 0.01 Bitcoins or 100 Bitcoins, but we'll incur the same problems when growing in the near future.

[RHorning]

That's not realistic, you'll always have trade-offs.

Just because something doesn't seem realistic at present doesn't mean we should not prefer it, were it available.

My point is : I do not think bitcoin will be good at handling lots of micro-payments, it is by design. Nor do I desire this capacity. Of course, if someone removes limitations without impacting the core functionality, sure!

But from my experience and the information I gathered from different sources it seems to me that it can't be achieved in such a way, therefore I think micro-payments will be handled by bitcoin banks, not by the block chain. And from my experience, this position seems to be a consensus amongst the bitcoin community.

In its current capacity and form, I don't think Bitcoin can be used for micro-payments in the manner as being suggested here.  I am quite certain that the current restriction on payments less than 0.01 BTC is going to be relaxed... indeed I would make a call for that to happen now simply because when parity hits for 1 BTC == 1 USD that fractions less than 0.001 BTC are going to be necessary simply to function with the Bitcoin economy.  I also think that within the standard Bitcoin client there ought to be a way to "adjust" fees and set up rules for how you (or I) would accept transaction fees based on a number of criteria.  For the most part, barring some huge crushing load on the Bitcoin network, I would like to hope that a cent would be allowed to be transferred without fees or certainly for marginal fees somewhat less than a cent.  It is something I think most miners would be willing to incorporate into their fee structure too.

This is built into the network protocol, but the current standard implementation doesn't permit the inclusion of these smaller transactions and certainly doesn't account for the deflation of the currency as is happening right now.  That is a big deal that does need to be addressed. 

The current "standard" restriction of charging 0.01 BTC for transactions less than 0.01 BTC is something that ought to change, but that still doesn't deal with very small micropayments that are less than the rough equivalent in 2000 inflation-adjusted U.S. Dollars of less than $0.01 USD equivalent in bitcoins.  I think that is the main thing being suggested here on this thread and that is to me indeed something that ought to be included, but it would require a slightly different protocol than currently exists for Bitcoins.  Regardless, I see the day that Bitcoin might be used routinely in such a way that miners are going to be expecting fees on the order of what is now about 50 cents or maybe even a buck in terms of the current value of FRNs and it is still useful to think of how to accomplish microtransactions using Bitcoins, because it has value in and of itself.

Two approaches that I can think of basically involve either a peer-to-peer system or a central server for interchange of micropayments.  Both approaches essentially follow this basic principle:

Micropayments are "authorized" for a certain Bitcoin address and transmitted to an accounting system of some sort.  When somebody "owes" past a given threshold (as established through some sort of protocol... either an agreement of sorts or perhaps the threshold is set by the person receiving the micropayments), their "account" will have to be settled by transmitting Bitcoins in presumably a large enough quantity that transaction fees won't eat up the cost of transmitting the payment.

The idea here too is that those who go past the threshold are simply kicked from the micropayment system, so there is an incentive to settle up accounts.  This threshold, if it is kept low enough and depending on what is being offered for the micropayments, isn't going to be the end of the world if somebody simply refuses to pay up.  Many on-line services usually have a trial period trying to encourage people to sign up, so you can say that this payment threshold is simply the freebies that you would give away anyway to entice people into using the service in the first place.

In terms of a central server system, the largest problem there is that you give up anonymity as the server at least knows your IP address (discounting proxies and other by-passes.... those can still be traced BTW) and other ways to trace who you are can be done with such a system.  In a peer to peer system, anonymity can be stronger but it would also be easier to "cheat the system".

As a way to keep hardcore "cheaters" from gaming the system, you can even have "tiered" services where you must maintain at least some sort of account, where those who routinely settle up accounts can have access to a broader range of services.  It doesn't stop somebody from ripping off a whole bunch of people, but you have an investment into your account by doing so and keeping those who would generate random new accounts by the thousands from being able to leech off of the system.  In order to get "the good stuff" you need to show at least some resemblance of a history of making payments... a "credit history" as it were and a "credit score" that shows that you can be trusted within the network.  A new account would obviously lack such a history.

This is something that I think is important to work on, but it would be outside of the scope of the main Bitcoin protocol except for settling up accounts and acknowledging payment.  Payment to a given Bitcoin address certainly can be verified.