Bitcoin Forum
November 09, 2024, 05:58:35 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Is bitcoin protocol evolving?  (Read 1207 times)
ybcoin (OP)
Member
**
Offline Offline

Activity: 80
Merit: 10


View Profile
September 27, 2013, 07:17:06 AM
 #1

HI, guys, I am not a technology expert, I don't know programming,

so I need to ask this question: by asking this question, Is bitcoin protocol evolving, I want to know if there has been any hardfork in bitcoin history?

As far as I can understand, there are many software client for mining and wallet, mining pools etc. however,these softwares don't change any bitcoin protocol, because in order to change protocol, a consensus of more than 50% total network computing power need to be reached, so a hardfork can be proceeded.  Am I right about this?

I have talked about reaching an hardfork consensus with some other folks, and we end up thinking not possible to reach it.

Does that mean bitcoin cannot evolve?

eager for your answers.

Thanks a lot.


GoldSilverBitcoin
Member
**
Offline Offline

Activity: 80
Merit: 10


Gold Silver Bitcoin: It's your choice


View Profile WWW
September 27, 2013, 07:27:08 AM
 #2

Lots of questions there. Lots of answers here.

http://bitcoin.org/en/alert/2013-03-11-chain-fork

As for Bitcoin evolution, this chapter in Bitcoinomics talks about the future:

https://www.goldsilverbitcoin.com/future-of-money-bitcoinomic/

Here is a good thread with some Hearn in it on BTC protocol buffering:

https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147

ybcoin (OP)
Member
**
Offline Offline

Activity: 80
Merit: 10


View Profile
September 27, 2013, 07:52:17 AM
 #3

Lots of questions there. Lots of answers here.

http://bitcoin.org/en/alert/2013-03-11-chain-fork

As for Bitcoin evolution, this chapter in Bitcoinomics talks about the future:

https://www.goldsilverbitcoin.com/future-of-money-bitcoinomic/

Here is a good thread with some Hearn in it on BTC protocol buffering:

https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147

Thanks a lot, I will read them,

but could you please also give me a simple yes or no to answer my question?

eb3full
VIP
Full Member
*
Offline Offline

Activity: 198
Merit: 101


View Profile
September 27, 2013, 12:01:50 PM
 #4

https://en.bitcoin.it/wiki/Hardfork_Wishlist

Not that this list is imminent. Maybe Gavin can give us some idea of when there might be a task force involved in ironing out what should be included in the next hardfork?

"With four parameters I can fit an elephant, and with five I can make him wiggle his trunk." John von Neumann
buy me beer: 1HG9cBBYME4HUVhfAqQvW9Vqwh3PLioHcU
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
September 27, 2013, 02:20:10 PM
 #5

consensus of more than 50% total network computing power
Computing power has nothing to do with hardforks.

Hardforks are not a great path to evolution. They're dangerous and potentially coercive. They must be undertaken with the consent of effectively _all_ users. They should be avoided unless there are no other reasonable alternatives.

Although many things have changed and advanced, it's arguable if we've ever had a hardfork or not: Very old nodes can still validate the chain, though they will non-deterministically fail because of semi-hard-forking database management bugs that have been fixed.

Fortunately, we don't have to have hardforks to evolve:  The P2P protocol is a matter between individual peers. They can negotiate whatever options they want. We have replaced the p2p protocol.  Most interesting and important changes to the blockchain validation rules can be accomplished via softforking changes. E.g. P2SH is effectively a radical change in how transaction spending rules are encoded and was accomplished without a hard fork.

In Bitcoin evolution is slow.  There are wallets which cannot be updated because they run on platforms controlled by corporations which are hostile to user-freedom (in particular, there is an i phone wallet app that produces signatures with an invalid encoding). There are multiple implementations of the Bitcoin protocol, but even with the BIP process their implementers have simply declined to implement some functionality, and its lack of universal availability makes it unusable to users. etc. But the system itself is a gigantic moving machine and failure is difficulty— even impossible— to fix, if something goes wrong so it's hard to say that slowness is a bad thing at all. Slowness helps ensures there is understanding and consent and reduces risk.
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
September 27, 2013, 03:55:23 PM
 #6

consensus of more than 50% total network computing power
Computing power has nothing to do with hardforks.

Hardforks are not a great path to evolution. They're dangerous and potentially coercive. They must be undertaken with the consent of effectively _all_ users. They should be avoided unless there are no other reasonable alternatives.

Although many things have changed and advanced, it's arguable if we've ever had a hardfork or not: Very old nodes can still validate the chain, though they will non-deterministically fail because of semi-hard-forking database management bugs that have been fixed.

Fortunately, we don't have to have hardforks to evolve:  The P2P protocol is a matter between individual peers. They can negotiate whatever options they want. We have replaced the p2p protocol.  Most interesting and important changes to the blockchain validation rules can be accomplished via softforking changes. E.g. P2SH is effectively a radical change in how transaction spending rules are encoded and was accomplished without a hard fork.

In Bitcoin evolution is slow.  There are wallets which cannot be updated because they run on platforms controlled by corporations which are hostile to user-freedom (in particular, there is an i phone wallet app that produces signatures with an invalid encoding). There are multiple implementations of the Bitcoin protocol, but even with the BIP process their implementers have simply declined to implement some functionality, and its lack of universal availability makes it unusable to users. etc. But the system itself is a gigantic moving machine and failure is difficulty— even impossible— to fix, if something goes wrong so it's hard to say that slowness is a bad thing at all. Slowness helps ensures there is understanding and consent and reduces risk.

I heard that anything before 0.3 would not work (even before the latest BIP50 fork). Is that true and what's that about?

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
September 27, 2013, 04:06:39 PM
 #7

I heard that anything before 0.3 would not work (even before the latest BIP50 fork). Is that true and what's that about?
No, anything 0.2.9 or higher should work with no more effort than helping it find a peer (ignoring the fact that the BIP50 stuff means that there is a good chance it'll get stuck), prior to 0.2.9 and back to the original release will work so long as you provide a gateway node that will accept the old checksumless version messages.
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
September 27, 2013, 04:33:38 PM
 #8

I heard that anything before 0.3 would not work (even before the latest BIP50 fork). Is that true and what's that about?
No, anything 0.2.9 or higher should work with no more effort than helping it find a peer (ignoring the fact that the BIP50 stuff means that there is a good chance it'll get stuck), prior to 0.2.9 and back to the original release will work so long as you provide a gateway node that will accept the old checksumless version messages.


So where would they stop? Block 252,451 or some random earlier block?

I find that we don't have a centralized page (preferably on the wiki) to describe all forks since 0.1. There is one at https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures but it doesn't provide much details.

As I can identify, we had the following forks in chronological order

Disable OP_LSHIFT etc
Limit the number of sig check commands
Fix output overflow
P2SH
v2 block
BIP50 (hard fork)

Do I miss any? (I consider the "Block hash collision via merkle tree" a bug fix, not a fork, because the malformed blocks are always rejected by all versions)

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
September 27, 2013, 05:32:34 PM
 #9

So where would they stop? Block 252,451 or some random earlier block?
They may not stop at all.  The behavior fixed in BIP50 is non-deterministic. They'll likely stop if they see a reorg of a couple large blocks, but it depends on the minutia of how the database records aligned to page boundaries.

Quote
As I can identify, we had the following forks in chronological order
All of those (save BIP50) are reductions in what the network will accept, so they don't break compatibility.
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1111


View Profile
September 27, 2013, 05:39:23 PM
 #10

So where would they stop? Block 252,451 or some random earlier block?
They may not stop at all.  The behavior fixed in BIP50 is non-deterministic. They'll likely stop if they see a reorg of a couple large blocks, but it depends on the minutia of how the database records aligned to page boundaries.

Quote
As I can identify, we had the following forks in chronological order
All of those (save BIP50) are reductions in what the network will accept, so they don't break compatibility.

Yes, they are softforks. Do I miss any?

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
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!