Bitcoin Forum
May 08, 2024, 10:39:33 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Micro payment hubs  (Read 1097 times)
TierNolan (OP)
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
January 29, 2014, 04:52:48 PM
 #1

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?

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
1715207973
Hero Member
*
Offline Offline

Posts: 1715207973

View Profile Personal Message (Offline)

Ignore
1715207973
Reply with quote  #2

1715207973
Report to moderator
1715207973
Hero Member
*
Offline Offline

Posts: 1715207973

View Profile Personal Message (Offline)

Ignore
1715207973
Reply with quote  #2

1715207973
Report to moderator
"There should not be any signed int. If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715207973
Hero Member
*
Offline Offline

Posts: 1715207973

View Profile Personal Message (Offline)

Ignore
1715207973
Reply with quote  #2

1715207973
Report to moderator
1715207973
Hero Member
*
Offline Offline

Posts: 1715207973

View Profile Personal Message (Offline)

Ignore
1715207973
Reply with quote  #2

1715207973
Report to moderator
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1129


View Profile
January 29, 2014, 05:05:49 PM
 #2

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.
TierNolan (OP)
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
January 29, 2014, 11:38:00 PM
 #3

We can solve the issue another way, by finding methods to reduce the fees (smartfees etc).

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.

Quote
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.

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
d'aniel
Sr. Member
****
Offline Offline

Activity: 461
Merit: 251


View Profile
January 30, 2014, 08:29:36 AM
Last edit: January 30, 2014, 09:02:18 AM by d'aniel
 #4

We can solve the issue another way, by finding methods to reduce the fees (smartfees etc).

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.
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/108 s ~= 10-6 s

and this is ~ the time to do a SHA256 hash.
TierNolan (OP)
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
January 30, 2014, 09:28:19 AM
 #5

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

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.

Quote
* "cost" is in quotations because it's not really a cost per se, but a reduction in expected revenue

It is a cost that should be accounted for.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
d'aniel
Sr. Member
****
Offline Offline

Activity: 461
Merit: 251


View Profile
January 30, 2014, 09:40:40 AM
 #6

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

Thanks.  

For a standard implementation, the size is closer to 250 bytes, so 50 times higher.  That means 35 cents.
Was intending to answer this:
How low do you think they would go?

Quote
Quote
* "cost" is in quotations because it's not really a cost per se, but a reduction in expected revenue
It is a cost that should be accounted for.
Sure, of course.  I just like to be precise, as it has implications when thinking about collective miner strategies.  Not relevant here though.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1129


View Profile
January 30, 2014, 10:10:55 AM
 #7

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.

d'aniel
Sr. Member
****
Offline Offline

Activity: 461
Merit: 251


View Profile
January 30, 2014, 10:26:02 AM
 #8

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

Edit: That or lots of bad press about how Bitcoin advocates lied about it having low transaction fees...
ilpirata79
Sr. Member
****
Offline Offline

Activity: 353
Merit: 253


View Profile
January 30, 2014, 10:32:24 AM
 #9

https://bitcointalk.org/index.php?topic=344267.0
oakpacific
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
January 30, 2014, 12:56:04 PM
 #10

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

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

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://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
TierNolan (OP)
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
January 30, 2014, 01:05:51 PM
 #11

Was intending to answer this:
How low do you think they would go?

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Analyticse
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile WWW
January 30, 2014, 01:07:39 PM
 #12

sound very nice
ilpirata79
Sr. Member
****
Offline Offline

Activity: 353
Merit: 253


View Profile
January 30, 2014, 01:39:07 PM
 #13

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
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!