Topic: Micro payment hubs (Read 1110 times)

Guys, what about sponsoring the development of such micropayment hubs (or gateway, as I called them)?
Is there a developer interested in such a work?

Best regards,
ilpirata79

sound very nice

Fair enough, I did ask that.

If it was 1 cent per channel, then that is almost a micropayment itself.

With channels, there is also the cost of the ECDSA signature verification.  That could end up being expensive, if the micropayments are small enough.

Bandwidth costs also matter.  Is sending the extra micropayment more expensive than verifying it and is that more expensive than the amount being sent.

It'll be a long way before they can be as incompetent as the banks, people may talk crap but when money really matters they will vote with their feet.

https://bitcointalksearch.org/topic/micro-payments-with-off-chain-transactions-344267

Hopefully things will sort themselves out once miners have to really struggle to turn a profit.  That day will come eventually

Edit: That or lots of bad press about how Bitcoin advocates lied about it having low transaction fees...

I like back of the envelope calculations but the mining market is so horrendously broken (it operates in something close to an information vacuum) that it's really impossible to say where it should be or what would happen. But a lot lower than today, that's for sure.

I often wish Satoshi had implemented a smoother inflation graph.

Was intending to answer this:

Sure, of course.  I just like to be precise, as it has implications when thinking about collective miner strategies.  Not relevant here though.

Thanks. 

For a standard implementation, the size is closer to 250 bytes, so 50 times higher.  That means 35 cents.

Hoewever, most pools are very well connected, at least to other pools, so that drops it down again.


It is a cost that should be accounted for.

Not sure where the other estimate is, but here's mine:

Using the CDF of the exponential distribution to estimate the probability of a block being orphaned during its propagation, the expected orphan "cost"* is approximately

c ~= r(1-exp(-t/T)) ~= rt/T

where r is the block reward, T is the block period, and t is the fractional hashing power-weighted mean time to get the block to the rest of the miners.  (Not too hard to show this precisely.)  The latter approximation is valid since t/T ~= 5/600 << 1**.

Then the marginal cost to add a transaction is

dc ~= r dt/T

where dt is the marginal increase in block propagation time.

Assuming a functional fee market between users and miners, and a profit margin of m for the miner, then the fee paid is

f = (1 + m) dc ~= (1 + m) r dt/T

Note that since f doesn't depend on t, only dt, the latency "cost"* is built into the basic "cost"* of mining a block, and shouldn't affect fees, ultimately.  Thus, supposing the transaction has been well-propagated in advance, so that only the first D bytes of the txid needs to be broadcast, and assuming the (weighted) mean number of hops to the other miners is n and the mean bandwidth on these paths is B, then we have roughly (with some underlying assumptions)

dt ~= nD/B

So

f ~=  (1 + m) D/T n/B r

Plugging in some rough estimates:

r ~= 25 BTC
T ~= 600s
m ~= 0.06
n ~= 5
D ~= 5 bytes
B ~- 1 Mb/s

=> f ~= 0.000009 BTC

At today's exchange rate of ~800 USD/BTC, this is 0.7 cents.

With a high-bandwidth, well-connected minernet, n/B, and thus f, could probably be reduced by one or two orders of magnitude***.  This could always be used to counteract any crazy rise in the exchange rate, though it may be considered somewhat of a degradation of decentralization.

* "cost" is in quotations because it's not really a cost per se, but a reduction in expected revenue
** http://bitcoinstats.com/network/propagation/

*** Edit: actually, hashing and lookup times would become the bottleneck at this point:

dt ~= nD/B ~= 3*5*8/10⁸ s ~= 10^-6 s

and this is ~ the time to do a SHA256 hash.

How low do you think they would go?  Wasn't there a calculation somewhere about the potential block orphan probability vs extra bandwidth.  That set the current (or one of the previous) fees.


True.

I guess with mirco-payments, risk is low anyway.  You send a payment over 2 hops and if you are ripped off, you don't use that hub anymore.

The hubs would similarly not forward payments via other nodes that have ripped them off.

Some kind of proof of receipt would be needed though.

It has been thought about and discussed before, somewhere in the forums. I don't have links to those discussions at hand unfortunately.

We can solve the issue another way, by finding methods to reduce the fees (smartfees etc). But for a hub/spoke design,  you could start with a single hop implementation and find ways to extend it to multi-hub with pathfinding later.

The issue with using channels for micropayments is setting them up.

At 0.0001BTC per transaction, that works out as 2 X 10 cents for each channel.  In addition, the channel open transaction needs confirms before it is accepted.  6 confirms is probably not required though.

Hubs could be used to get around this.  A user could establish a 0.01BTC channel with a hub for 0.0001 for a long duration (i.e. 60 days).  That works out at $10, so it isn't that big a deal if it gets locked away.

Similarly, content providers could establish (receive) channels from their hubs.

A transaction between the user and the content provider could be achieved by routing it user -> hub1 -> hub2 -> content provider.  In theory, the user's client could even poll a few hubs to see which has the cheapest commission to send to the content provider.  This would create competition between the hubs.

Once a user has setup channels with a few hubs, confirmation times are no longer relevant, since the payment is through the channels.

The effect is pretty much what Ripple does, except the required trust is lower.

Has there been consideration of a system like this?  Ideally, the market between hubs could be implemented as a p2p system.

There is still some trust required though.  Is there a way to do an atomic payment over the multi-hop channels?