Bitcoin Forum
June 03, 2024, 01:59:21 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Bitcoin enhancement proposal  (Read 1442 times)
Cryddit
Legendary
*
Offline Offline

Activity: 924
Merit: 1129


View Profile
December 29, 2013, 08:22:01 PM
 #21

I think I agree that the way Bitcoin is structured it must eventually become centralized, and that centralization will be the end of the era of bitcoin as we knew it.  Once centralized, it will inevitably be controlled by governments.  Once controlled by governments, it will inevitably become just a payment network for fiat currency.  If its structure did not favor centralization, we would not have mining pools in the first place.  

That is sad, but it's not going to happen immediately.  In order to prevent it we would need a fundamentally different reward structure and means of securing the block chain.  But we're not going to get that in Bitcoin.

Also, we shan't have to wait 127 years for the end of mining.  You said it yourself; the reward is halved every four years.  That means that it goes from 25 to 12.5 to 6.25 to 3.125 to 1.6  in just 5 halvings, or 20 years.  In another 5 halvings, forty years from now, it'll be less than 0.025 BTC, which is close enough to zero that it doesn't really matter after that.  Mining, insofar as it continues to be relevant given the threat of centralization and takeover by governments, will sink or swim on fee support in our lifetimes, not those of our descendants.

zatoichi (OP)
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
December 29, 2013, 08:29:21 PM
Last edit: December 29, 2013, 09:19:20 PM by zatoichi
 #22

I realize that the suggestion is in its infancy but I am hoping for people to see that perhaps it is Bitcoin that has failed in the details. I wonder if the inventor pushed the final date way into the future so he wouldn't have to rip his eyes out when it crashes. I mean why not 20 years? Of course it may crash way before 2140.

Doesn't the blockchain show where the new bitcoins are awarded? Isn't the node a party to that transaction? If so, you should be able to get a minimum count (just remove duplicates).
DannyHamilton
Legendary
*
Offline Offline

Activity: 3416
Merit: 4658



View Profile
December 29, 2013, 09:59:00 PM
 #23

Also, we shan't have to wait 127 years for the end of mining.  You said it yourself; the reward is halved every four years.  That means that it goes from 25 to 12.5 to 6.25 to 3.125 to 1.6  in just 5 halvings, or 20 years.  In another 5 halvings, forty years from now, it'll be less than 0.025 BTC, which is close enough to zero that it doesn't really matter after that.

You are mistaken.

Block subsidy is issued in integer units (no decimals).

The original subsidy was 5 000 000 000 integer units (commonly referred to by the nickname "satoshi").

The current subsidy is 2 500 000 000 integer units.

In 5 halvings the subsidy will be 160 000 000 integer units.

In an additional 5 halvings (forty years from now), the subsidy will be 5 000 000 integer units.  That is significantly more than 0 (by 6 orders of magnitude).

Whether those 25 mBTC will matter will depend largely on what the exchange rate of bitcoins is at the time.

If bitcoin exchange rate is $10 000 per mBTC, then 25 mBTC will be $250 000 per block.
DannyHamilton
Legendary
*
Offline Offline

Activity: 3416
Merit: 4658



View Profile
December 29, 2013, 10:12:12 PM
 #24

Doesn't the blockchain show where the new bitcoins are awarded?

No.  The only information the blockchain has about where the bitcoins are awarded is the transaction outputs of the coinbase transaction.  These outputs simply encumber some value(s) with a requirement of a digital signature from a particular private key (or set of private keys) to be reassigned elsewhere.  There is no "node" information at all.

Isn't the node a party to that transaction?

There are never any "nodes" that are party to any transactions.  Transactions are a list of unspent outputs (as inputs to the transaction), a set of signatures providing proof that the transaction is authorized to spend those previously unspent outputs, and a list of new unspent outputs encumbered with a condition that must be met to spend those new unspent outputs (typically a signature from a private key that is associated with a bitcoin address).  This is entirely "nodeless".  Transactions are relayed from node to node with no knowledge of where they originated.  The only difference with the coinbase transaction is that there is no list of previously unspent outputs or signatures, only new unspent outputs encumbered with the condition that must be met to pend them.

If so, you should be able to get a minimum count (just remove duplicates).

Understand yet why there is no way to know how many nodes (or miners, or mining pools) exist?
zatoichi (OP)
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
December 29, 2013, 10:45:50 PM
 #25

I recently realized that knowing the network size at all times is not necessary. What is necessary to know at all times is whether the count is greater than the "ideal". The exact number does not matter until it falls below the ideal. Obviously the larger the network the more secure it is but the ideal would be the lowest number that constitutes a specific threat level considered acceptable. What would be nice about this would be that the largest processors would have an incentive to keep their rates high enough so competition exists. Their penalty for reducing prices below competitive rates is an decrease in the recovery ratio.

Where are Bohm and Jacopini when we need them? They figured out the minimum number of programming constructs that could satisfy any algorithm. They came up with three. I'm sure the number of nodes for adequate security would be much larger but it might also be easily confirmed as existing at any one time (a simple ACK?)
Pages: « 1 [2]  All
  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!