Yo, Adam, check it out. This guy totally stole your idea...
http://wallstreettechnologist.com/2015/08/23/articles-of-bitcoin-constitution-a-genesis-block-of-governance/
Topic: Decentralized decision making, hashing toward a better bitcoin (Read 4631 times)
August 24, 2015, 10:08:03 PM
"The people want this" 
I'm so fucking tired of hearing this. I thought Bitcoin was exactly about putting a check on unreasonable people demand. Guess that was underestimating "the people"
I'm so fucking tired of hearing this. I thought Bitcoin was exactly about putting a check on unreasonable people demand. Guess that was underestimating "the people"
you're being unreasonable.
bitcoin is about getting everyone to agree to the same rules.
this thread is about making that easier when changing the rules.
what other rules are up for debate .... ? shall we corral and brigade the mobs to clamour for permanent bitcoin inflation now that network fees are being rendered useless as a technology?
no, no one would agree to that, but it might be fun to put that to a vote and see how fast hashing power comes to the consensus that it shouldn't do this.
idk how about transaction manubility?
kinda hard to imagine there wont be anymore debating with the devs
maybe we wont have such a crazy debate as block size limit for a long time, but does not mean being able to poll the network couldn't help them make better decisions, maybe dev are going to run out of work once block size limit is implemented, who knows!
August 24, 2015, 09:30:12 PM
"The people want this"
I'm so fucking tired of hearing this. I thought Bitcoin was exactly about putting a check on unreasonable people demand. Guess that was underestimating "the people"
I'm so fucking tired of hearing this. I thought Bitcoin was exactly about putting a check on unreasonable people demand. Guess that was underestimating "the people"
you're being unreasonable.
bitcoin is about getting everyone to agree to the same rules.
this thread is about making that easier when changing the rules.
what other rules are up for debate .... ? shall we corral and brigade the mobs to clamour for permanent bitcoin inflation now that network fees are being rendered useless as a technology?
August 24, 2015, 02:00:34 PM
"The people want this"
I'm so fucking tired of hearing this. I thought Bitcoin was exactly about putting a check on unreasonable people demand. Guess that was underestimating "the people"
I'm so fucking tired of hearing this. I thought Bitcoin was exactly about putting a check on unreasonable people demand. Guess that was underestimating "the people"
you're being unreasonable.
bitcoin is about getting everyone to agree to the same rules.
this thread is about making that easier when changing the rules.
August 24, 2015, 01:53:30 PM
I really doubt this is the last of the disagreements devs will face when it comes to forking bitcoin soft or hard, there is clearly a demand for this "voting system"; already something like it has manifested itself in a half baked manner. see : https://bitcointalksearch.org/topic/the-vote-that-counts-miners-and-mikes-worst-case-scenario-1160026
there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.
here are a few thoughts about the details that might make this process more streamlined:
by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.
all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"
when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.
when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )
to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to undecided. included the possibility of knocking off "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.
there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.
here are a few thoughts about the details that might make this process more streamlined:
by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.
all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"
when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.
when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )
to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to undecided. included the possibility of knocking off "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.
Adam.
If you would have followed the dev list at all in the last year you would have realized a plethora of similar proposition have been suggested and would always be rejected with a consensual NACK for many obvious reasons. There is essentially no practical way to identify, qualify & quantify users in the network so as to "weight" their "votes".
hashing power And amount of BTC ??
when someone uses a 50BTC wallet to send 0.001BTC to an address associated with voting for BIPXXX add 50votes the to economic majority pie chart
when blocks are minted with a version associated with voting for BIPXXX add it to the Hashing power pie chart
easy as pie.
its happening one way or the other.... why fight it?
As gool ol Romanian chap Mircea would say : read the logs.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
and i'd tell him to look around.
https://bitcointalksearch.org/topic/the-vote-that-counts-miners-and-mikes-worst-case-scenario-1160026
people want this, why not its a pie chart!! who doesn't like pie charts
"The people want this"
I'm so fucking tired of hearing this. I thought Bitcoin was exactly about putting a check on unreasonable people demand. Guess that was underestimating "the people"
August 24, 2015, 01:37:08 PM
I really doubt this is the last of the disagreements devs will face when it comes to forking bitcoin soft or hard, there is clearly a demand for this "voting system"; already something like it has manifested itself in a half baked manner. see : https://bitcointalksearch.org/topic/the-vote-that-counts-miners-and-mikes-worst-case-scenario-1160026
there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.
here are a few thoughts about the details that might make this process more streamlined:
by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.
all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"
when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.
when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )
to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to undecided. included the possibility of knocking off "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.
there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.
here are a few thoughts about the details that might make this process more streamlined:
by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.
all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"
when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.
when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )
to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to undecided. included the possibility of knocking off "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.
Adam.
If you would have followed the dev list at all in the last year you would have realized a plethora of similar proposition have been suggested and would always be rejected with a consensual NACK for many obvious reasons. There is essentially no practical way to identify, qualify & quantify users in the network so as to "weight" their "votes".
hashing power And amount of BTC ??
when someone uses a 50BTC wallet to send 0.001BTC to an address associated with voting for BIPXXX add 50votes the to economic majority pie chart
when blocks are minted with a version associated with voting for BIPXXX add it to the Hashing power pie chart
easy as pie.
its happening one way or the other.... why fight it?
As gool ol Romanian chap Mircea would say : read the logs.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
and i'd tell him to look around.
https://bitcointalksearch.org/topic/the-vote-that-counts-miners-and-mikes-worst-case-scenario-1160026
people want this, why not its a pie chart!! who doesn't like pie charts
August 24, 2015, 01:31:46 PM
I really doubt this is the last of the disagreements devs will face when it comes to forking bitcoin soft or hard, there is clearly a demand for this "voting system"; already something like it has manifested itself in a half baked manner. see : https://bitcointalksearch.org/topic/the-vote-that-counts-miners-and-mikes-worst-case-scenario-1160026
there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.
here are a few thoughts about the details that might make this process more streamlined:
by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.
all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"
when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.
when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )
to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to undecided. included the possibility of knocking off "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.
there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.
here are a few thoughts about the details that might make this process more streamlined:
by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.
all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"
when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.
when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )
to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to undecided. included the possibility of knocking off "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.
Adam.
If you would have followed the dev list at all in the last year you would have realized a plethora of similar proposition have been suggested and would always be rejected with a consensual NACK for many obvious reasons. There is essentially no practical way to identify, qualify & quantify users in the network so as to "weight" their "votes".
hashing power And amount of BTC ??
when someone uses a 50BTC wallet to send 0.001BTC to an address associated with voting for BIPXXX add 50votes the to economic majority pie chart
when blocks are minted with a version associated with voting for BIPXXX add it to the Hashing power pie chart
easy as pie.
its happening one way or the other.... why fight it?
As gool ol Romanian chap Mircea would say : read the logs.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
August 24, 2015, 01:26:39 PM
I really doubt this is the last of the disagreements devs will face when it comes to forking bitcoin soft or hard, there is clearly a demand for this "voting system"; already something like it has manifested itself in a half baked manner. see : https://bitcointalksearch.org/topic/the-vote-that-counts-miners-and-mikes-worst-case-scenario-1160026
there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.
here are a few thoughts about the details that might make this process more streamlined:
by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.
all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"
when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.
when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )
to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to undecided. included the possibility of knocking off "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.
there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.
here are a few thoughts about the details that might make this process more streamlined:
by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.
all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"
when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.
when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )
to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to undecided. included the possibility of knocking off "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.
Adam.
If you would have followed the dev list at all in the last year you would have realized a plethora of similar proposition have been suggested and would always be rejected with a consensual NACK for many obvious reasons. There is essentially no practical way to identify, qualify & quantify users in the network so as to "weight" their "votes".
hashing power And amount of BTC ??
when someone uses a 50BTC wallet to send 0.001BTC to an address associated with voting for BIPXXX add 50votes the to economic majority pie chart
when blocks are minted with a version associated with voting for BIPXXX add it to the Hashing power pie chart
easy as pie.
its happening one way or the other.... why fight it?
August 24, 2015, 01:11:32 PM
I really doubt this is the last of the disagreements devs will face when it comes to forking bitcoin soft or hard, there is clearly a demand for this "voting system"; already something like it has manifested itself in a half baked manner. see : https://bitcointalksearch.org/topic/the-vote-that-counts-miners-and-mikes-worst-case-scenario-1160026
there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.
here are a few thoughts about the details that might make this process more streamlined:
by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.
all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"
when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.
when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )
to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to undecided. included the possibility of knocking off "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.
there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.
here are a few thoughts about the details that might make this process more streamlined:
by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.
all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"
when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.
when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )
to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to undecided. included the possibility of knocking off "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.
Adam.
If you would have followed the dev list at all in the last year you would have realized a plethora of similar proposition have been suggested and would always be rejected with a consensual NACK for many obvious reasons. There is essentially no practical way to identify, qualify & quantify users in the network so as to "weight" their "votes".
August 24, 2015, 01:01:12 PM
That is not a question... No miners will make any significant switch unless they get equally significant node support
Switching to XT is the conservative decision, as illustrated in the figure below.
That is if anyone actually plans to move to XT, which they don't.
Seriously wake up Peter, no one is buying it.
14% of the nodes are buying it as of today. That's up from 0% a little over a week ago. Let's see how much of the hash power is buying it two months from now...
This morning we had a broad show of support for BIP101 (Gavin's proposal) from several major Bitcoin companies. Personally, I don't care whether they run XT or a BIP101 patch for Core---their commitment to implement BIP101-support by December is a big step towards consensus.
...
Source: http://blog.blockchain.com/wp-content/uploads/2015/08/Industry-Block-Size-letter-All-Signed.pdf
All part of the little coordinated XT push. A good cop/bad cop trap for suckers to fall in. Unscrupulous lobbying of VC-backed companies willing to throw a bone to the investors for more funding rounds.
"Look Mr. Banker, we just upgraded the Bitcoin network to support 8X more transactions, that should get us some users! You all know Bitcoin users LOVE to make transactions right, right?"
Quote
Until today, our involvement has consisted of listening, researching and testing.
Where is the research? Can we see the "tests"?
Can't these industry "leaders" wait until the actual industry has met for a final push to a resolution (Scaling Bitcoin) until picking sides?
Speaking of "ivory tower" what use should we, the community, make of this pathetic PR coup? Are we supposed to just swallow this and take it for granted these guys have done their research? Of course we shouldn't shame them with our suspicion or any reconsideration or validation of their actual motivations and reasoning.
These are the bankers of the Bitcoin world and you are sucking up them without any discretion because...they're VCs & entrepreneurs so they must know what they're doing and surely what they are doing is for the best of everyone in Bitcoin, right. Right?
August 24, 2015, 11:52:17 AM
That is not a question... No miners will make any significant switch unless they get equally significant node support
Switching to XT is the conservative decision, as illustrated in the figure below.
[img]http://-snip-[img]
That is if anyone actually plans to move to XT, which they don't.
Seriously wake up Peter, no one is buying it.
14% of the nodes are buying it as of today. That's up from 0% a little over a week ago. Let's see how much of the hash power is buying it two months from now...
[img]http://-snip-[img]
This morning we had a broad show of support for BIP101 (Gavin's proposal) from several major Bitcoin companies. Personally, I don't care whether they run XT or a BIP101 patch for Core---their commitment to implement BIP101-support by December is a big step towards consensus.
[img]http://-snip-[img]
Source: http://blog.blockchain.com/wp-content/uploads/2015/08/Industry-Block-Size-letter-All-Signed.pdf
Core devs "There is no need for bigger blocks!"
Bunch of idiots in their ivory tower...
August 24, 2015, 11:47:51 AM
That is not a question... No miners will make any significant switch unless they get equally significant node support
Switching to XT is the conservative decision, as illustrated in the figure below.
That is if anyone actually plans to move to XT, which they don't.
Seriously wake up Peter, no one is buying it.
14% of the nodes are buying it as of today. That's up from 0% a little over a week ago. Let's see how much of the hash power is buying it two months from now...
This morning we had a broad show of support for BIP101 (Gavin's proposal) from several major Bitcoin companies. Personally, I don't care whether they run XT or a BIP101 patch for Core---their commitment to implement BIP101-support by December is a big step towards consensus.
Source: http://blog.blockchain.com/wp-content/uploads/2015/08/Industry-Block-Size-letter-All-Signed.pdf
August 24, 2015, 11:45:20 AM
I really doubt this is the last of the disagreements devs will face when it comes to forking bitcoin soft or hard, there is clearly a demand for this "voting system"; already something like it has manifested itself in a half baked manner. see : https://bitcointalksearch.org/topic/the-vote-that-counts-miners-and-mikes-worst-case-scenario-1160026
there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.
here are a few thoughts about the details that might make this process more streamlined:
by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.
all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"
when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.
when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )
to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to undecided. included the possibility of knocking off "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.
there no question development would benefit from being able to poll the network, and i believe everyone would appreciate being asked to vote.
here are a few thoughts about the details that might make this process more streamlined:
by default when a new set of BIPs are set up for voting, mining a block without making any change to the version number would indicate undecided or not voting, same would go for the BTC, and this hashing power / BTC would not be tallied on the pie charts. we could assume undecided votes would side with the voting majority.
all voting would have the option "none of the BIPs are acceptable, therefore there should be no change"
when a BIP is modified all votes for that BIP go back to undecided, a new version number / BTC address will be attributed to this modified BIP.
when consuseus appears to have been reached, devs are free to fork( soft or hard ) the software despite any disagreement they may still have internally ( this is in fact always possible, it would simply be more socially acceptable to fork to something the network is in full agreement with even tho some devs don't like it. )
to encourage consensus building, BIPs with the lowest approval rating would be periodically knocked off, and all its votes setback to undecided. included the possibility of knocking off "none of the BIPs are acceptable, therefore there should be no change" in which case it would become clear that SOME KIND of change is deemed necessary by all those voting.
August 24, 2015, 10:04:42 AM
"What's wrong with voting?
The OP is not proposing "voting" in the normal sense. He is proposing that we simply make it very easy for node operators to download either BIP101, BIP100, 1-MB, etc. If, for example, the majority of the hash power gets on board with larger blocks, then that's what Bitcoin will become. Give more power to the node operators (rather than to the developers of a particular implementation of the protocol (Core)).
That's still a vote, what if the minority of the hash power don't want to use larger blocks? You are still forcing a change on them. And those minorities might command much larger stake in bitcoin ecosystem than you can imagine, they could easily destroy your majority fork with the flip of a pen
Please read this article again if you are interested
http://www.seedsforchange.org.uk/consensus
In this "voting system" there is no winner, it is simply informative, it actually jives with your Consensus Decision Making, the goal with be to get the network agreeing at 90%, first we might see 50/50 on 1MB vs 20MB then the devs make changes to there BIP say 8MB and get more of the network agreeing.
August 24, 2015, 09:37:22 AM
after chatting and thinking about it, I have edited OP, hopefully this addresses some concerns you all have.
August 24, 2015, 09:37:16 AM
To be honest it sounds like a "popularity contest" rather than a well thought out technical solution to a problem (this has been my thinking about this whole issue ever since XT embarked on the alarmist idea that Bitcoin is going to die and that they are going to fork by "convincing others" that they should follow them).
you don't think the most popular solution would tend to be the one which appears to be well thought out technical solution to the problem??
Sadly, no. Because the majority of humans is not always right, in fact, it's often quite the opposite.
the idea is that the devs offer viable BIPs with more or less the same amount of "correctness" but they are in disagreement as to which one to pick, and so they politly poll the nework to see where the hashing power / enocomc marjorty stand. in hopes that this allows them to make the best decision for everyone invloded
August 24, 2015, 07:51:08 AM
To be honest it sounds like a "popularity contest" rather than a well thought out technical solution to a problem (this has been my thinking about this whole issue ever since XT embarked on the alarmist idea that Bitcoin is going to die and that they are going to fork by "convincing others" that they should follow them).
you don't think the most popular solution would tend to be the one which appears to be well thought out technical solution to the problem??
Sadly, no. Because the majority of humans is not always right, in fact, it's often quite the opposite.
hero member
Activity: 560
Merit: 509
I prefer Zakir over Muhammed when mentioning me!
August 24, 2015, 07:14:20 AM
...
And please stop "developer centralization" concern trolling. Bitcoin XT is a one man show. If you sign up for this you are electing that Bitcoin development be headed by a notoriously controversial individual who has a rap sheet for being very pro-corporations and governments...
And please stop "developer centralization" concern trolling. Bitcoin XT is a one man show. If you sign up for this you are electing that Bitcoin development be headed by a notoriously controversial individual who has a rap sheet for being very pro-corporations and governments...
I support increasing the block size limit. Right now, showing support for XT seems to be the most efficient means of achieving that goal.
Longer term, I would like to see several implementations of the Bitcoin protocol controlled by different groups of developers. In other words, I'd like the square on the right here to have several smaller squares inside it (and no square [including Core] > 30%), thereby decentralizing development:
[ img width=800]https://i.imgur.com/VzqyqwR.gif[/img]
What in your opinion would be wrong with that longer-term goal of decentralizing development?
Many clients, each (hard)forking blockchain. How great would it be?!
August 24, 2015, 07:08:40 AM
once a version number achieves 90% of hashing power that would be considered the communities will miners will
FTFYhash power != community will
Exactly, there are many people who do not run nodes or mining but still greatly concerned about bitcoin's health since they use it daily.
I think at least the participants should have some level of involvement. It is difficult for someone who does not own any bitcoin to make any decision because he simply don't understand the whole thing
Use node to vote can be misleading, since you can create thousands of SPV nodes on virtual server. Hash power is more reliable but that excludes most of the participants (I guess winkelvoss twins do not own any hash power), and as 2013 fork showed, it can be manipulated by large pool owner
August 24, 2015, 02:47:04 AM
once a version number achieves 90% of hashing power that would be considered the communities will miners will
FTFYhash power != community will
Jump to: