Bitcoin Forum
February 20, 2019, 10:49:47 AM
 News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 Home Help Search Login Register More
 Pages: [1]
 Author Topic: Is the hashing power of the users insignificant?  (Read 154 times)
monsterer2
Full Member

Offline

Activity: 346
Merit: 108

 March 01, 2018, 11:09:15 AM

I was just doing some back-of-a-napkin style calculations to figure out the hashing power of the users of bitcoin, and whether it would even be worth looking into trying to harness it in some way.

Recalling that the difficulty is the expected number of hashes taken to solve a block, with current difficulty at 3007383866429, and assuming we have normal CPUs with an average of 10Mh/s (this may be optimistic), and assuming sending a transaction took 1 second of hashing, we'd have enough hash power in plain transaction sending to rival a 1% hash-power miner, if the network was sending 5 transactions per second*.

Is this significant enough to try and capture? Is it even possible to do so?

* 3007383866429 = 3007383 mega hashes
3007383 / 10 Mh/s = 300738 seconds to solve a block in 10 minutes
300738 / 600 seconds in 10 minutes  = 500 tps for 100% network hash power

1550659787
Hero Member

Offline

Posts: 1550659787

Ignore
 1550659787

1550659787
 Report to moderator
1550659787
Hero Member

Offline

Posts: 1550659787

Ignore
 1550659787

1550659787
 Report to moderator
1550659787
Hero Member

Offline

Posts: 1550659787

Ignore
 1550659787

1550659787
 Report to moderator
The Ultimate Bitcoin mixer
with an advanced technology.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
DannyHamilton
Legendary

Offline

Activity: 2198
Merit: 1391

 March 01, 2018, 03:07:25 PMMerited by ETFbitcoin (1), 13abyknight (1)

I'm not sure where you got your information from, but you seem to have quite a few things wrong, and some other things that simply don't make sense (perhaps you can explain better?).

Recalling that the difficulty is the expected number of hashes taken to solve a block,

It is not.

with current difficulty at 3007383866429, number of h

The current difficulty is 923,233,068,449 (932 million)
The current average hashes to solve a block is 4,790,315,043,600,000,000,000 (4.79 sextillion)
That's 7,983,858,406,000,000,000 hashes PER SECOND (7.98 quintillion)

and assuming we have normal CPUs with an average of 10Mh/s (this may be optimistic),

That depends a LOT on the CPU.

A high end Intel Core i7 can manage more than 60 Mh/s
The Core i5 will top out closer to 20 Mh/s

and assuming sending a transaction took 1 second of hashing,

I'm not sure what you mean by this.  Generating a transaction to send typically requires less than a half-dozen hashes.  At 10Mh/s that's fractions of a millisecond.

we'd have enough hash power in plain transaction sending to rival a 1% hash-power miner, if the network was sending 5 transactions per second*.

I'm not sure what you're trying to say here.  If I can create a transaction with less than 6 hashes, then 5 transactions in one second will be approximately 30 hashes per second.
Compare this to the global mining power of 7983858406000000000 hashes per second and transaction creation is equivalent to a 0.000000000000000376% miner.

Is this significant enough to try and capture?

Capture?  What do you mean by "capture"?

Is it even possible to do so?

I don't know.  I can't tell what you're trying to do with the hash power.

* 3007383866429 = 3007383 mega hashes
3007383 / 10 Mh/s = 300738 seconds to solve a block in 10 minutes
300738 / 600 seconds in 10 minutes  = 500 tps for 100% network hash power

I'm not sure what you are saying here, my I get the feeling that you've got a lot of things wrong.

tromp
Hero Member

Offline

Activity: 579
Merit: 524

 March 01, 2018, 04:09:20 PM

Recalling that the difficulty is the expected number of hashes taken to solve a block

you forgot a factor 2^32 in there...
ETFbitcoin
Legendary

Offline

Activity: 1596
Merit: 1553

Use SegWit and enjoy lower fees.

 March 01, 2018, 04:28:16 PM

There's no correlation between mining difficulty and nodes capability to process transaction.

If you're talking about mining difficult and mining hashrate, the difficulty adjust mining hashrate every 2 week. If you're talking about miner/nodes capability to process/verify transaction, that depends on their computing power and bandwitch

 ░░░░░▄▄██████▄▄░░▄████▀▀▀▀▀▀████▄░███▀░░░░░░░░░░▀█▀████░░░▄██████▄▄░░░██░░░░░█████████░░░░██▌░░░░█████████████████░░░░█████████████████░░░░░███████████████████▄░░▀██████▀░░░████▀█▄▄░░░░░░░░░░▄███░░▀████▄▄▄▄▄▄████▀░░░░░▀▀██████▀▀ .ChipMixer.{ MIXING REINVENTED FOR YOUR PRIVACY #.ChipMixer. ░░░░░▄▄██████▄▄░░▄████▀▀▀▀▀▀████▄░███▀░░░░░░░░░░▀█▀████░░░▄██████▄▄░░░██░░░░░█████████░░░░██▌░░░░█████████████████░░░░█████████████████░░░░░███████████████████▄░░▀██████▀░░░████▀█▄▄░░░░░░░░░░▄███░░▀████▄▄▄▄▄▄████▀░░░░░▀▀██████▀▀
monsterer2
Full Member

Offline

Activity: 346
Merit: 108

 March 01, 2018, 04:34:29 PM

I'm not sure where you got your information from, but you seem to have quite a few things wrong, and some other things that simply don't make sense (perhaps you can explain better?).

Recalling that the difficulty is the expected number of hashes taken to solve a block,

It is not.

My bad. I had been assuming (16 bit hashing analogue to skip writing all the characters):

Code:
diff_1=0xffff
Code:
difficulty = diff_1 / target
, so
Code:
target = diff_1 / difficulty
, so for a 16 bit hash, and difficulty 1 it would be
Code:
target = 0xffff / 1 = 0xffff
would result in a single hash being lower than the target, hence my reasoning.

Probably should have looked up the actual values.

monsterer2
Full Member

Offline

Activity: 346
Merit: 108

 March 02, 2018, 10:20:25 AM

Ok, so lets try this again with the right numbers, and some background explanation:

The question I was asking was: do the users of bitcoin collectively posses enough raw hashing power in their CPUs to rival the miners? Assuming we change bitcoin to force users to send a PoW with their transaction which takes them 1 second to compute on a 10 Mh/s CPU, combining this with the transaction throughput the network currently has, what would their hashing power be?

So, we've got (assuming 5 transactions per second)

Code:
10 Mh/s * 5 tps = 50 Mh/s

Comparing to the miners 7,983,858,406,000 Mh/s, we end up with users currently having 0.000000000626% of the miners hashing power, if we force them to send a 1s PoW with each transaction.

This is obviously completely and totally insignificant, and not worth trying to capture to improve chain security. So, what would it take for the users to rival the miners?

At 10 Mh/s, how many tps do we need?

Code:
7,983,858,406,000 / (50 / 5) = 798,385,840,600 tps

Mmmm, not likely, so instead how many seconds would we need to force users to spend computing a PoW at 5 tps?

Code:
7,983,858,406,000 / 50 = 159,677,168,120 seconds

or 5063 years per transaction.

bob123
Hero Member

Offline

Activity: 826
Merit: 830

 March 02, 2018, 12:09:50 PM

The question I was asking was: do the users of bitcoin collectively posses enough raw hashing power in their CPUs to rival the miners? Assuming we change bitcoin to force users to send a PoW with their transaction which takes them 1 second to compute on a 10 Mh/s CPU, combining this with the transaction throughput the network currently has, what would their hashing power be?

I can't answer this question with certainty, but i don't think the 'bitcoin users cpus' surpass the 'hashing power' of the massive amount of ASIC's controlled by (all) miner. By far.

So, what would it take for the users to rival the miners?
At 10 Mh/s, how many tps do we need?

I'm not sure what you are trying to say.
The 'users' would need more hashing power (than the miner) to 'rival the miners'. Or how was that question meant?

The Mh/s are completely independent from the TPS.
The transactions per second are dependend from:
1) the amount of TX's with fit into a block (on average) and
2) the time it takes to generate a block (on average)

 ░░░░░▄▄██████▄▄░░▄████▀▀▀▀▀▀████▄░███▀░░░░░░░░░░▀█▀████░░░▄██████▄▄░░░██░░░░░█████████░░░░██▌░░░░█████████████████░░░░█████████████████░░░░░███████████████████▄░░▀██████▀░░░████▀█▄▄░░░░░░░░░░▄███░░▀████▄▄▄▄▄▄████▀░░░░░▀▀██████▀▀ .ChipMixer.{ MIXING REINVENTED FOR YOUR PRIVACY #.ChipMixer. ░░░░░▄▄██████▄▄░░▄████▀▀▀▀▀▀████▄░███▀░░░░░░░░░░▀█▀████░░░▄██████▄▄░░░██░░░░░█████████░░░░██▌░░░░█████████████████░░░░█████████████████░░░░░███████████████████▄░░▀██████▀░░░████▀█▄▄░░░░░░░░░░▄███░░▀████▄▄▄▄▄▄████▀░░░░░▀▀██████▀▀
Jet Cash
Legendary

Online

Activity: 1162
Merit: 1519

TEMP and VOM member

 March 02, 2018, 03:53:59 PM

I suspect he is trying to harness some of . the processing power on all the nodes that are online, and use that for a bit of mining.

My node is only online whilst I am synchronising the blockchain, and it runs as a background task. I'm afraid that I wouldn't want to give up any processing, especially if I didn't get any reward ( would I keep the coins if I found a block? )

I need information and schematics for the Butterfly Labs Bitforce SC Orion ASIC miner
jnano
Member

Offline

Activity: 241
Merit: 18

 March 03, 2018, 06:45:42 PM

Comparing to the miners 7,983,858,406,000 Mh/s
DannyHamilton's 7.9 zettahash was per block, not per second (though it should actually be 14.4 zettahash).
The current total hash power is about 24 exahash/second. Not that it helps with making the idea more feasible.

monsterer2
Full Member

Offline

Activity: 346
Merit: 108

 March 03, 2018, 07:07:33 PM

Comparing to the miners 7,983,858,406,000 Mh/s
DannyHamilton's 7.9 zettahash was per block, not per second (though it should actually be 14.4 zettahash).
The current total hash power is about 24 exahash/second. Not that it helps with making the idea more feasible.

Mmmm, yeah, just divide every result by 600. Still doesn't help with the idea though.

Interestingly, Iota's entire security model is based around professional miners never participating, because if they did, double spends would be as utterly trivial as the users mining power under my example was insignificant, for the exact same reasons.

 Pages: [1]