An Open Letter to the Developers from the Bitcoin Community

[marky89]

"consensus" comes after the when  hashing power

...

all this voting would do is allow everyone to express there willingness to upgrade to a potential change.

i think it's unreasonable to assume voting will ever show 90% of miners all voting for the the same BIP when all 3 BIPs are perfectly valid options

Agree re: hashing power; investors and large bitcoin entities like BitPay are irrelevant.

Why? BIP66 achieved 95% consensus before forking. I see no reason why this can't be achieved again. If not, it would appear the supermajority prefers the status quo to a controversial hard fork.

The very point is that not all BIPs are perfectly valid options.....

Because the community is much larger than it was with more diametrical views.

May I ask you why 95%? Why not 100%? What percentage is considered safe enough? What percentage is considered low enough to avoid any changes being blocked by an harmful minority?

So? A hard fork should not be easy to implement. Whether or not the community has diametrical views -- and I assure you, it did on the subject of block size limit 5 years ago -- is just not relevant. 95% has proven to work in the past and is well outside the realm of a simple majority + a lucky streak. 75% is considerably lower than past hard forks, and surely risks breaking consensus. Lower consensus thresholds may make it easier to implement hard forks, but it considerably increases the risk of permanently breaking consensus. This comes down to game theory -- it is not a simple fact that "best behavior" prevails always. I think that those who believe that a 70-30 or 60-40 split, for instance, can only result in the minority being forced into the majority and consensus will prevail, are making a very bold claim.

we'll get ready to test that theory buddy cuz something's gotta give on this block limit shit.

Maybe. Or maybe not.

Anyone can go ahead and fork the code, lowering the consensus threshold however much they want, perhaps even below a simple majority. I would hope that miners do not support such nonsense.

[Patel]

Half of the "bitcoin community" doesn't know whats good for itself.

I trust the Bitcoin Core developers, as they have done a good job maintaining and scaling bitcoin for years.

Whoever wants to use BitcoinXT/Censorcoin/Unfungiblecoin/SuperLongPropagationCoin altcoin, feel free, but don't come back to Bitcoin when your transactions require KYC and AML and miners have to show passports or government ID to clear your transactions.

[Mickeyb]

Half of the "bitcoin community" doesn't know whats good for itself.

I trust the Bitcoin Core developers, as they have done a good job maintaining and scaling bitcoin for years.

Whoever wants to use BitcoinXT/Censorcoin/Unfungiblecoin/SuperLongPropagationCoin altcoin, feel free, but don't come back to Bitcoin when your transactions require KYC and AML and miners have to show passports or government ID to clear your transactions.

Yes, there is truth about non technical people that don't know enough. I would hope, if it would come to voting, that these people would simply stay away from voting and not mess around with the things they don't understand enough about.

Of course, nothing in this world is perfect, so this voting wouldn't be as well. I also imagine that there would be people who would try and take an advantage of the system. These are all drawbacks, I agree.

[adamstgBit]

Half of the "bitcoin community" doesn't know whats good for itself.

I trust the Bitcoin Core developers, as they have done a good job maintaining and scaling bitcoin for years.

Whoever wants to use BitcoinXT/Censorcoin/Unfungiblecoin/SuperLongPropagationCoin altcoin, feel free, but don't come back to Bitcoin when your transactions require KYC and AML and miners have to show passports or government ID to clear your transactions.

Yes, there is truth about non technical people that don't know enough. I would hope, if it would come to voting, that these people would simply stay away from voting and not mess around with the things they don't understand enough about.

Of course, nothing in this world is perfect, so this voting wouldn't be as well. I also imagine that there would be people who would try and take an advantage of the system. These are all drawbacks, I agree.

Of course the voting wouldn't be perfect, but it might be better then you think.

to sign a message with a cold storage bitcoin address ( paper wallet ) there's some work involved in doing that securely. you wouldn't expect to get  votes from poeple who didn't understand / didn't feel strongly about any option.

also if your voting with BTC or Hashing power, you have a stake in bitcoin and want nothing but good things for bitcoin, if you are unsure which option to choose you might realize that it's better for you not to vote.

[David Rabahy]

I moved about 10% of my total wealth into Bitcoin; wise or stupid is yet to be determined.  I went in assuming a significant chance of the whole thing going to zero.

If the transaction rate grows then the current 1MB block size will eventually force higher fees; so?  Oh, I know, if the fees get too high then Bitcoin loses one of the advantages it has over other systems.  So?  ...  Oh, I know, Bitcoin fails.  So?  I knew that was a risk going in.  So?  I go on less cruises in the future.  So?  My kids get less inheritance.  So?  ...

I happen to work in the computer industry.  As such the challenge in front of me often is to get systems to handle more and more workload.  To this part of me it is obvious we will eventually need a larger block size.  Apparently there is a 32MB limit buried in some library.  I recommend jumping to that limit as soon as is reasonable; keeping fees low.  Moreover we need to get to work on overcoming that limit.  Btw, if the workload isn't there then the blocks won't be large; I think some folks miss this point.  It seems some folks wrongly fear every block will be huge.  Using the block size to resist spam is a case of using the wrong tool.  Anyone with a network link that can't keep up; too bad.  Anyone with a lack of storage; too bad; although pruning would be just delightful.  Anyone with a lack of processing power; too bad.

In between these extreme positions (how can one guy see both sides?) are the fancy approaches.  Whatever.  Enjoy.  I do run a full node and would be interested in having the option for getting paid for the services I provide.  Miners get paid; why can't full node operators get paid?

Bottom line; let the debate continue.  If no change comes then we will live with higher fees.  So?  ...

[brg444]

I moved about 10% of my total wealth into Bitcoin; wise or stupid is yet to be determined.  I went in assuming a significant chance of the whole thing going to zero.

If the transaction rate grows then the current 1MB block size will eventually force higher fees; so?  Oh, I know, if the fees get too high then Bitcoin loses one of the advantages it has over other systems.  So?  ...  Oh, I know, Bitcoin fails.  So?  I knew that was a risk going in.  So?  I go on less cruises in the future.  So?  My kids get less inheritance.  So?  ...

I happen to work in the computer industry.  As such the challenge in front of me often is to get systems to handle more and more workload.  To this part of me it is obvious we will eventually need a larger block size.  Apparently there is a 32MB limit buried in some library.  I recommend jumping to that limit as soon as is reasonable; keeping fees low.  Moreover we need to get to work on overcoming that limit.  Btw, if the workload isn't there then the blocks won't be large; I think some folks miss this point.  It seems some folks wrongly fear every block will be huge.  Using the block size to resist spam is a case of using the wrong tool.  Anyone with a network link that can't keep up; too bad.  Anyone with a lack of storage; too bad; although pruning would be just delightful.  Anyone with a lack of processing power; too bad.

In between these extreme positions (how can one guy see both sides?) are the fancy approaches.  Whatever.  Enjoy.  I do run a full node and would be interested in having the option for getting paid for the services I provide.  Miners get paid; why can't full node operators get paid?

Bottom line; let the debate continue.  If no change comes then we will live with higher fees.  So?  ...

I suggest you consider this proposal by Adam Back if you haven't:

https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07937.html

[adamstgBit]

I moved about 10% of my total wealth into Bitcoin; wise or stupid is yet to be determined.  I went in assuming a significant chance of the whole thing going to zero.

If the transaction rate grows then the current 1MB block size will eventually force higher fees; so?  Oh, I know, if the fees get too high then Bitcoin loses one of the advantages it has over other systems.  So?  ...  Oh, I know, Bitcoin fails.  So?  I knew that was a risk going in.  So?  I go on less cruises in the future.  So?  My kids get less inheritance.  So?  ...

I happen to work in the computer industry.  As such the challenge in front of me often is to get systems to handle more and more workload.  To this part of me it is obvious we will eventually need a larger block size.  Apparently there is a 32MB limit buried in some library.  I recommend jumping to that limit as soon as is reasonable; keeping fees low.  Moreover we need to get to work on overcoming that limit.  Btw, if the workload isn't there then the blocks won't be large; I think some folks miss this point.  It seems some folks wrongly fear every block will be huge.  Using the block size to resist spam is a case of using the wrong tool.  Anyone with a network link that can't keep up; too bad.  Anyone with a lack of storage; too bad; although pruning would be just delightful.  Anyone with a lack of processing power; too bad.

In between these extreme positions (how can one guy see both sides?) are the fancy approaches.  Whatever.  Enjoy.  I do run a full node and would be interested in having the option for getting paid for the services I provide.  Miners get paid; why can't full node operators get paid?

Bottom line; let the debate continue.  If no change comes then we will live with higher fees.  So?  ...

I suggest you consider this proposal by Adam Back if you haven't:

https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07937.html

I suggest we consider all options and vote! 

[brg444]

I moved about 10% of my total wealth into Bitcoin; wise or stupid is yet to be determined.  I went in assuming a significant chance of the whole thing going to zero.

If the transaction rate grows then the current 1MB block size will eventually force higher fees; so?  Oh, I know, if the fees get too high then Bitcoin loses one of the advantages it has over other systems.  So?  ...  Oh, I know, Bitcoin fails.  So?  I knew that was a risk going in.  So?  I go on less cruises in the future.  So?  My kids get less inheritance.  So?  ...

I happen to work in the computer industry.  As such the challenge in front of me often is to get systems to handle more and more workload.  To this part of me it is obvious we will eventually need a larger block size.  Apparently there is a 32MB limit buried in some library.  I recommend jumping to that limit as soon as is reasonable; keeping fees low.  Moreover we need to get to work on overcoming that limit.  Btw, if the workload isn't there then the blocks won't be large; I think some folks miss this point.  It seems some folks wrongly fear every block will be huge.  Using the block size to resist spam is a case of using the wrong tool.  Anyone with a network link that can't keep up; too bad.  Anyone with a lack of storage; too bad; although pruning would be just delightful.  Anyone with a lack of processing power; too bad.

In between these extreme positions (how can one guy see both sides?) are the fancy approaches.  Whatever.  Enjoy.  I do run a full node and would be interested in having the option for getting paid for the services I provide.  Miners get paid; why can't full node operators get paid?

Bottom line; let the debate continue.  If no change comes then we will live with higher fees.  So?  ...

I suggest you consider this proposal by Adam Back if you haven't:

https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07937.html

I suggest we consider all options and vote! 

never

gonna

happen

[adamstgBit]

I moved about 10% of my total wealth into Bitcoin; wise or stupid is yet to be determined.  I went in assuming a significant chance of the whole thing going to zero.

If the transaction rate grows then the current 1MB block size will eventually force higher fees; so?  Oh, I know, if the fees get too high then Bitcoin loses one of the advantages it has over other systems.  So?  ...  Oh, I know, Bitcoin fails.  So?  I knew that was a risk going in.  So?  I go on less cruises in the future.  So?  My kids get less inheritance.  So?  ...

I happen to work in the computer industry.  As such the challenge in front of me often is to get systems to handle more and more workload.  To this part of me it is obvious we will eventually need a larger block size.  Apparently there is a 32MB limit buried in some library.  I recommend jumping to that limit as soon as is reasonable; keeping fees low.  Moreover we need to get to work on overcoming that limit.  Btw, if the workload isn't there then the blocks won't be large; I think some folks miss this point.  It seems some folks wrongly fear every block will be huge.  Using the block size to resist spam is a case of using the wrong tool.  Anyone with a network link that can't keep up; too bad.  Anyone with a lack of storage; too bad; although pruning would be just delightful.  Anyone with a lack of processing power; too bad.

In between these extreme positions (how can one guy see both sides?) are the fancy approaches.  Whatever.  Enjoy.  I do run a full node and would be interested in having the option for getting paid for the services I provide.  Miners get paid; why can't full node operators get paid?

Bottom line; let the debate continue.  If no change comes then we will live with higher fees.  So?  ...

I suggest you consider this proposal by Adam Back if you haven't:

https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07937.html

I suggest we consider all options and vote! 

never

gonna

happen

its

already

happening

https://www.blocktrail.com/BTC

[BitProdigy]

I just hope the developers have something interesting to say this Sunday. I will be watching live on the edge of my seat. Hopefully they have something to say about the consensus building process. I do see all of this as the growing pains for Bitcoin. I am hopeful for a successful conclusion that reinforces the notion that bitcoin is anti fragile and the consensus mechanism works for deciding one a solution and putting that into action with little to no resistance throughout the community.

I don't want to see opposing sides doing battle. I don't want to see the bitcoin community and the block chain split in two. I would much rather see and cooperative effort to arrive at a solution that everyone is happy with or at least doesn't hate, so that we can move forward and get back to the journey at hand which is to the moon.

[VeritasSapere]

I think before people start using the word "consensus" they should actually read the one use of that word in the whitepaper.

Consensus is not a thing you achieve before a change, it is a thing that happens after a change.

The BitcoinXT thing is a perfect example of consensus as envisioned in the whitepaper. Someone builds a new version of Bitcoin and puts it out there. The users and miners of Bitcoin vote with their feet (ie: processing power) and reject it, and we move on.

The idea that we need to discuss a change until we achieve consensus is deeply flawed (and the most bearish indicator for Bitcoin to-date IMO). Stop looking for agreement. Just build it, ship it, and see who uses it. Just like Mike and Gavin did, and as Satoshi predicted.

I agree, I think you have a good understanding of how the Bitcoin consensus should work, simple yet elegant.