Bitcoin Forum
May 10, 2024, 06:31:17 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Damage Estimation of Low Hashrate  (Read 1621 times)
Vandroiy (OP)
Legendary
*
Offline Offline

Activity: 1036
Merit: 1002


View Profile
April 23, 2011, 03:57:22 PM
 #1

As posted in another thread, I stumbled over a scenario in which total mining power might fall if there is no sufficiently small limit on the number of transactions per block:
http://bitcointalk.org/index.php?topic=6284.0

The discussion on whether it will happen aside, this thread is about what happens if it happens.

My guess would be that, in such a case, we'd end up with a miner supply that's not super-small, but nowhere near the supercomputer level we're currently running for. This scenario has the obvious benefit of low transaction fees, but is generally feared because of an attack that can split the block chain, reverting a past transaction. (Other dangerous effects?)

Any estimates on the troubles we face, considering a fairly large, world-wide Bitcoin network? Might there be methods to construct "insurance miners" that jump in on unwanted splits of the block chain? Maybe changes in the protocol, further rules to counter splits?

A Bitcoin network based on as few miners as possible would be a great success, we would have beautifully low transaction fees. Maybe what I fear as a danger might be a benefit, if there's a way to keep it stable against attacks. The "valid chain insurance" mining groups would behave great in that respect. Maybe this is the solution to the whole problem?
1715365877
Hero Member
*
Offline Offline

Posts: 1715365877

View Profile Personal Message (Offline)

Ignore
1715365877
Reply with quote  #2

1715365877
Report to moderator
1715365877
Hero Member
*
Offline Offline

Posts: 1715365877

View Profile Personal Message (Offline)

Ignore
1715365877
Reply with quote  #2

1715365877
Report to moderator
TalkImg was created especially for hosting images on bitcointalk.org: try it next time you want to post an image
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715365877
Hero Member
*
Offline Offline

Posts: 1715365877

View Profile Personal Message (Offline)

Ignore
1715365877
Reply with quote  #2

1715365877
Report to moderator
1715365877
Hero Member
*
Offline Offline

Posts: 1715365877

View Profile Personal Message (Offline)

Ignore
1715365877
Reply with quote  #2

1715365877
Report to moderator
1715365877
Hero Member
*
Offline Offline

Posts: 1715365877

View Profile Personal Message (Offline)

Ignore
1715365877
Reply with quote  #2

1715365877
Report to moderator
BitterTea
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250



View Profile
April 23, 2011, 04:23:24 PM
 #2

I don't understand how fewer miners = lower fees. What's their incentive to keep fees low?
Vandroiy (OP)
Legendary
*
Offline Offline

Activity: 1036
Merit: 1002


View Profile
April 23, 2011, 06:13:00 PM
Last edit: April 23, 2011, 06:35:38 PM by Vandroiy
 #3

If a miner would earn a lot (high fees), more miners would join, and thus the assumption of few miners wouldn't be valid anymore. Edit: ah, sorry, I'm talking about a situation in which the transaction limit is not an issue. It seems to be a common opinion that we don't really want transaction fees forced up by setting a harsh limit on the transaction rate.

It's not really the topic of the thread though. I just wonder how dangerous a state of a small hashrate would be. The dynamics of fee height and amount of miners are the topic of the thread I linked to.

We just had a little discussion about this on IRC... apparently, there might be ways to fend off attacks against Bitcoin better than by just overpowering the attacker, e.g. by giving advantages to miners working on a more "trustworthy looking" chain. I've not seen a formal version of this suggestion yet though.
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!