Core Devs : can you share your thoughts about all BIPs on this website ?
21 messages, 19 to 22 Aug 2015. Started by Nicolas Dorier.
Nicolas Dorier (5), Btc Drak (4), Peter Todd (3), Yifu Guo (2), Oliver Egginger (2), Will Madden (2), Eric Lombrozo, Greg Maxwell, +1 more
I created a small website which show a chart of your approvals about various BIPs (which you must fill by yourself with a signed pgp message)
For each BIP, you can fill if you approve or not, and give comments. (HTML accepted, so you can link stuff you your posts)
It would help the community a lot, so I hope you will do it ! I'm open to add other important devs, big miners, or other proposal that I missed.
Please, respond on BTC Talk or github. (I don't read the mailing anymore because of the spam :( )
Link : http://bipsxdevs.azurewebsites.net/ BtcTalk Topic : https://bitcointalk.org/index.php?topic=1156164 Github : https://github.com/NicolasDorier/BIPxDevs
I was looking at this site recently and it's not very clear that by clicking the name you get their opinion. I would make that a separate column stated, Technical Opinion.
I think you need to include more of the developers/technical people, Adam Back, Mark Friedenback, Jorge Timons, (all of who are core developers). You need Peter Todd is a core dev btw, as is thebluematt.
You need other experts, I would include Nick Szabo, Meni Rosenfeld, Charlie Lee might be a good one. You should get the pools on there too.
You're missing Mike Hearn of course.
My key is 0xE5D138F5E73A1AF2
On Wed, Aug 19, 2015 at 5:57 AM, Nicolas Dorier via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (22 lines)
> I created a small website which show a chart of your approvals about various > BIPs (which you must fill by yourself with a signed pgp message) > > For each BIP, you can fill if you approve or not, and give comments. (HTML > accepted, so you can link stuff you your posts) > > It would help the community a lot, so I hope you will do it ! > I'm open to add other important devs, big miners, or other proposal that I > missed. > > Please, respond on BTC Talk or github. (I don't read the mailing anymore > because of the spam :( ) > > Link : http://bipsxdevs.azurewebsites.net/ > BtcTalk Topic : https://bitcointalk.org/index.php?topic=1156164 > Github : https://github.com/NicolasDorier/BIPxDevs > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Thanks, btcdrak, I just added the column and you in the list. (looks nicer)
What I am calling "core devs" in the website is only "commit access people", should I rename this group ? I just want a way to improve readability of the website by grouping, I am open to all subjection on different way of grouping.
I'm good for adding Mike Hearn, Adam Back, Mark Friedenback, Jorge Timons, Nick Szabo, Meni Rosenfeld, Charlee Lee.
If some of you are reading this list, please send me your PGP public key. For the others, any idea where I can hunt their PGP public keys ?
On Fri, Aug 21, 2015 at 12:10 PM, Btc Drak <btcdrak@gmail•com> wrote:
Quoted text (46 lines)
> I was looking at this site recently and it's not very clear that by > clicking the name you get their opinion. I would make that a separate > column stated, Technical Opinion. > > I think you need to include more of the developers/technical people, > Adam Back, Mark Friedenback, Jorge Timons, (all of who are core > developers). You need > Peter Todd is a core dev btw, as is thebluematt. > > You need other experts, I would include Nick Szabo, Meni Rosenfeld, > Charlie Lee might be a good one. You should get the pools on there > too. > > You're missing Mike Hearn of course. > > My key is 0xE5D138F5E73A1AF2 > > > On Wed, Aug 19, 2015 at 5:57 AM, Nicolas Dorier via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> wrote: > > I created a small website which show a chart of your approvals about > various > > BIPs (which you must fill by yourself with a signed pgp message) > > > > For each BIP, you can fill if you approve or not, and give comments. > (HTML > > accepted, so you can link stuff you your posts) > > > > It would help the community a lot, so I hope you will do it ! > > I'm open to add other important devs, big miners, or other proposal that > I > > missed. > > > > Please, respond on BTC Talk or github. (I don't read the mailing anymore > > because of the spam :( ) > > > > Link : http://bipsxdevs.azurewebsites.net/ > > BtcTalk Topic : https://bitcointalk.org/index.php?topic=1156164 > > Github : https://github.com/NicolasDorier/BIPxDevs > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > >
I think everyone who has contributed any commits to the Bitcoin Core project should have a say in this.
Quoted text (60 lines)
> On Aug 20, 2015, at 8:38 PM, Nicolas Dorier via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > Thanks, btcdrak, I just added the column and you in the list. (looks nicer) > > What I am calling "core devs" in the website is only "commit access people", should I rename this group ? > I just want a way to improve readability of the website by grouping, I am open to all subjection on different way of grouping. > > I'm good for adding Mike Hearn, Adam Back, Mark Friedenback, Jorge Timons, Nick Szabo, Meni Rosenfeld, Charlee Lee. > > If some of you are reading this list, please send me your PGP public key. > For the others, any idea where I can hunt their PGP public keys ? > > On Fri, Aug 21, 2015 at 12:10 PM, Btc Drak <btcdrak@gmail•com <mailto:btcdrak@gmail.com>> wrote: > I was looking at this site recently and it's not very clear that by > clicking the name you get their opinion. I would make that a separate > column stated, Technical Opinion. > > I think you need to include more of the developers/technical people, > Adam Back, Mark Friedenback, Jorge Timons, (all of who are core > developers). You need > Peter Todd is a core dev btw, as is thebluematt. > > You need other experts, I would include Nick Szabo, Meni Rosenfeld, > Charlie Lee might be a good one. You should get the pools on there > too. > > You're missing Mike Hearn of course. > > My key is 0xE5D138F5E73A1AF2 > > > On Wed, Aug 19, 2015 at 5:57 AM, Nicolas Dorier via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > I created a small website which show a chart of your approvals about various > > BIPs (which you must fill by yourself with a signed pgp message) > > > > For each BIP, you can fill if you approve or not, and give comments. (HTML > > accepted, so you can link stuff you your posts) > > > > It would help the community a lot, so I hope you will do it ! > > I'm open to add other important devs, big miners, or other proposal that I > > missed. > > > > Please, respond on BTC Talk or github. (I don't read the mailing anymore > > because of the spam :( ) > > > > Link : http://bipsxdevs.azurewebsites.net/ <http://bipsxdevs.azurewebsites.net/> > > BtcTalk Topic : https://bitcointalk.org/index.php?topic=1156164 <https://bitcointalk.org/index.php?topic=1156164> > > Github : https://github.com/NicolasDorier/BIPxDevs <https://github.com/NicolasDorier/BIPxDevs> > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org <mailto:bitcoin-dev@lists.linuxfoundation.org> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
I'm not against it (mostly active committers as you are), my challenge is getting the PGP keys scattered all over the place. If you want put your thoughts, then let me know you pgp.
On Fri, Aug 21, 2015 at 12:45 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
Quoted text (76 lines)
> I think everyone who has contributed any commits to the Bitcoin Core > project should have a say in this. > > > On Aug 20, 2015, at 8:38 PM, Nicolas Dorier via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > > Thanks, btcdrak, I just added the column and you in the list. (looks nicer) > > What I am calling "core devs" in the website is only "commit access > people", should I rename this group ? > I just want a way to improve readability of the website by grouping, I am > open to all subjection on different way of grouping. > > I'm good for adding Mike Hearn, Adam Back, Mark Friedenback, Jorge Timons, > Nick Szabo, Meni Rosenfeld, Charlee Lee. > > If some of you are reading this list, please send me your PGP public key. > For the others, any idea where I can hunt their PGP public keys ? > > On Fri, Aug 21, 2015 at 12:10 PM, Btc Drak <btcdrak@gmail•com> wrote: > >> I was looking at this site recently and it's not very clear that by >> clicking the name you get their opinion. I would make that a separate >> column stated, Technical Opinion. >> >> I think you need to include more of the developers/technical people, >> Adam Back, Mark Friedenback, Jorge Timons, (all of who are core >> developers). You need >> Peter Todd is a core dev btw, as is thebluematt. >> >> You need other experts, I would include Nick Szabo, Meni Rosenfeld, >> Charlie Lee might be a good one. You should get the pools on there >> too. >> >> You're missing Mike Hearn of course. >> >> My key is 0xE5D138F5E73A1AF2 >> >> >> On Wed, Aug 19, 2015 at 5:57 AM, Nicolas Dorier via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation•org> wrote: >> > I created a small website which show a chart of your approvals about >> various >> > BIPs (which you must fill by yourself with a signed pgp message) >> > >> > For each BIP, you can fill if you approve or not, and give comments. >> (HTML >> > accepted, so you can link stuff you your posts) >> > >> > It would help the community a lot, so I hope you will do it ! >> > I'm open to add other important devs, big miners, or other proposal >> that I >> > missed. >> > >> > Please, respond on BTC Talk or github. (I don't read the mailing anymore >> > because of the spam :( ) >> > >> > Link : http://bipsxdevs.azurewebsites.net/ >> > BtcTalk Topic : https://bitcointalk.org/index.php?topic=1156164 >> > Github : https://github.com/NicolasDorier/BIPxDevs >> > >> > _______________________________________________ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists•linuxfoundation•org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > >
On Wed, Aug 19, 2015 at 4:57 AM, Nicolas Dorier via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (7 lines)
> I created a small website which show a chart of your approvals about various > BIPs (which you must fill by yourself with a signed pgp message) > For each BIP, you can fill if you approve or not, and give comments. (HTML > accepted, so you can link stuff you your posts) > It would help the community a lot, so I hope you will do it ! > I'm open to add other important devs, big miners, or other proposal that I > missed.
I think this is a bit well, sad, at the moment-- a basic principle in sound decision making is that one should try to withhold judgement until after the analysis and options are laid out to avoid prematurely laying down "battle lines" which then they're socially and politically committed to a particular answer.
There are several other BIPs in the works right now that aren't out there yet, as well (as presumably) new insight from the workshop. It would be a shame if these things would be for naught because of being decided prematurely.
Decision making is not the goal of this site, it is only a way to see various pros and cons of various devs on various proposals in a single place. This is for the community to have a coherent view about what you are talking about now spread into reddit/mailing/forums.
If you did not analyzed a proposal yet, you don't have to fill out your opinion veto or approval. It is only to show what you would you "approve" and what you would "veto", after your analysis. Then point out all the discussions in the opinion section that lead you to your conclusion.
You can change edit your position as you progress into your analysis and as new BIP get redacted. I'm eager to include the new proposals.
On Fri, Aug 21, 2015 at 1:45 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
Quoted text (26 lines)
> On Wed, Aug 19, 2015 at 4:57 AM, Nicolas Dorier via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> wrote: > > I created a small website which show a chart of your approvals about > various > > BIPs (which you must fill by yourself with a signed pgp message) > > For each BIP, you can fill if you approve or not, and give comments. > (HTML > > accepted, so you can link stuff you your posts) > > It would help the community a lot, so I hope you will do it ! > > I'm open to add other important devs, big miners, or other proposal that > I > > missed. > > > I think this is a bit well, sad, at the moment-- a basic principle in > sound decision making is that one should try to withhold judgement > until after the analysis and options are laid out to avoid prematurely > laying down "battle lines" which then they're socially and politically > committed to a particular answer. > > > There are several other BIPs in the works right now that aren't out > there yet, as well (as presumably) new insight from the workshop. It > would be a shame if these things would be for naught because of being > decided prematurely. >
On Fri, Aug 21, 2015 at 6:10 AM, Nicolas Dorier via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (16 lines)
> Decision making is not the goal of this site, it is only a way to see > various pros and cons of various devs on various proposals in a single > place. > This is for the community to have a coherent view about what you are talking > about now spread into reddit/mailing/forums. > > If you did not analyzed a proposal yet, you don't have to fill out your > opinion veto or approval. > It is only to show what you would you "approve" and what you would "veto", > after your analysis. > Then point out all the discussions in the opinion section that lead you to > your conclusion. > > You can change edit your position as you progress into your analysis and as > new BIP get redacted. > I'm eager to include the new proposals.
The most important part that developers should complete is the "Technical Opinion" column section where they can explain their general worldview, what their concerns are, how those concerns would be alleviated. If one is undecided or does not have enough information regarding each BIP then dont fill it out. That also helps signal the level of consensus for a proposal.
As it stands at the moment, it's almost impossible to direct someone at the opinion of a specific developer other than hunting down a few gems scattered to the four corners of the universe. I tried recently and it was simply impossible. At least with this system, specific BIPs aside, we can easily see the view of each developer. I think most of us can comment on BIP101 since the BIP appears non-negotiable.
The XT faction are easily winning the media war by obscuring rational debate by high signal to noise ratio. Nicolas' solution means the most important views expressed by each heavyweight will not get lost and serve as a good reference point for everyone, including the media.
The site could be extended to include major stakeholders too like major service providers (think exchanges, wallet providers etc) and mining pools.
On 20 August 2015 21:45:23 GMT-07:00, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (11 lines)
>I think this is a bit well, sad, at the moment-- a basic principle in >sound decision making is that one should try to withhold judgement >until after the analysis and options are laid out to avoid prematurely >laying down "battle lines" which then they're socially and politically >committed to a particular answer. > > >There are several other BIPs in the works right now that aren't out >there yet, as well (as presumably) new insight from the workshop. It >would be a shame if these things would be for naught because of being >decided prematurely.
I'll second that, which is why I've mostly not commented on whether or not particular proposals are good ideas, except in the case where they're obviously broken due to reasons other than the blocksize itself. For instance both of Garzik's proposals and Andresen's BIP101 have serious flaws regardless of your thoughts on the blocksize, which is why I've commented on them. Wuille's OTOH is implemented well, which is why I have not commented about it.
What might be valuable is to ask devs to explain what their threat models are, what should be at the root of their thinking about the blocksize.
On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (1 line)
> What might be valuable is to ask devs to explain what their threat models are, what should be at the root of their thinking about the blocksize.
That's exactly what the "Technical Opinion" column is for.
On 21 August 2015 02:09:06 GMT-07:00, Btc Drak via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (3 lines)
>The site could be extended to include major stakeholders too like >major service providers (think exchanges, wallet providers etc) and >mining pools.
Given the strong consensus that blockchains simply don't scale well - even Andersen describes a blocksize increase as "kicking then can down the road" - it'd be good to ask service providers what their long term plans for growth are.
On 21 August 2015 02:31:51 GMT-07:00, Btc Drak <btcdrak@gmail•com> wrote:
Quoted text (7 lines)
>On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev ><bitcoin-dev@lists•linuxfoundation•org> wrote: >> What might be valuable is to ask devs to explain what their threat >models are, what should be at the root of their thinking about the >blocksize. > >That's exactly what the "Technical Opinion" column is for.
What if could be used for; theres value in being more explicit.
I like the intend of this attempt to bring more clarity to the blocksize debate, however it would be more help to make this a information site about the current outstanding BIPs and summarize their differences rather than voting mechanism. (ofcourse the author of the BIPs would "vote" for their own proposals.)
It would be good to include supporting and counter statements regards to these BIPs on the site. in addition to highlight certain things like pools in china have voiced their opinion that increase should happen, and 8mb is something they are comfortable with, which is not directly related to a single BIP, but never the less relevant in this discussion.
On Fri, Aug 21, 2015 at 5:35 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (32 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > On 21 August 2015 02:31:51 GMT-07:00, Btc Drak <btcdrak@gmail•com> wrote: > >On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev > ><bitcoin-dev@lists•linuxfoundation•org> wrote: > >> What might be valuable is to ask devs to explain what their threat > >models are, what should be at the root of their thinking about the > >blocksize. > > > >That's exactly what the "Technical Opinion" column is for. > > What if could be used for; theres value in being more explicit. > -----BEGIN PGP SIGNATURE----- > > iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV1vDG > AAoJEMCF8hzn9Lncz4MIAIMtLLA4q7KJiwrYrpjFWme1ys9iyPZiADJGQWG3qKlH > Q4pEcwWt69jfTUCjLYfegsDW4eEMarejs568iSF70hvGB4OPWrYK3YiM1cWlWtDD > seN3G/4dJjehL7h1Nz+/OTjTlePkguHctRlJTavel8sI7fg356iMJc1Ggm5Q1ZFl > CLrivr/CEO7Qk9Uo5ewhnwConKjLygSyv67SSaMJW7pZB06uTX6M3lk11c/RB/C6 > JKPqxkvOmNIX9U8S/G3Y2pYf3/up72IhP0Ugp31iOsz629B2WvEsDYu/0SP61+oZ > za9HrP2g8OsxVq6SUD3MukmbRVKklvcnro4vk5sOlYI= > =Jfl+ > -----END PGP SIGNATURE----- > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (12 lines)
> I like the intend of this attempt to bring more clarity to the blocksize > debate, however it would be more help to make this a information site about > the current outstanding BIPs and summarize their differences rather than > voting mechanism. > (ofcourse the author of the BIPs would "vote" for their own proposals.) > > It would be good to include supporting and counter statements regards to > these BIPs on the site. > in addition to highlight certain things like pools in china have voiced > their opinion that increase should happen, and 8mb is something they are > comfortable with, which is not directly related to a single BIP, but never > the less relevant in this discussion.
I was rather surprised by the tweet from AntPool[1] today saying that they support big blocks and would be prepared to upgrade to XT. Pools have stated that they are willing to increase to a maximum of 8MB, but upgrading to XT puts them on a schedule towards 8GB which is clearly not what they have agreed to.
Do you have any insights into what's going on there?
Also do you have any insight into what Chinese pools would accept as a compromise in terms of raising the blocksize limit?
Drak
[1] https://twitter.com/JihanWu/status/633288343338381314
accordingly to public release[1], They.
1. agreed that blocksize increase is needed. 2. opposed original 20mb, suggest 8mb instead as it is more technically reasonable. 3. do not want blocksize to change in the "short term future" ( direct translation. ) and in the document states. "after discussion we are in agreement that the blocksize should be within the ball park of 8mb for the short term future."
They have no explicitly rejected or supported the other components of BIP101. It's my opinion that as long as the change is < 8mb. they'll take it.
I don't believe in trying to predict the future, on adoption, technology growth, nor geopolitics. I think it matters very little which BIP we need up deploying, as long as all the attack vectors are covered, especially for the dynamically adjustable ones.
One thing is for sure though, not increasing the blocksize is not an option.
we can't predict the future, in the mean time, Hardfork Responsibly™.
On Fri, Aug 21, 2015 at 7:28 AM, Btc Drak <btcdrak@gmail•com> wrote:
Quoted text (32 lines)
> On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> wrote: > > I like the intend of this attempt to bring more clarity to the blocksize > > debate, however it would be more help to make this a information site > about > > the current outstanding BIPs and summarize their differences rather than > > voting mechanism. > > (ofcourse the author of the BIPs would "vote" for their own proposals.) > > > > It would be good to include supporting and counter statements regards to > > these BIPs on the site. > > in addition to highlight certain things like pools in china have voiced > > their opinion that increase should happen, and 8mb is something they are > > comfortable with, which is not directly related to a single BIP, but > never > > the less relevant in this discussion. > > I was rather surprised by the tweet from AntPool[1] today saying that > they support big blocks and would be prepared to upgrade to XT. Pools > have stated that they are willing to increase to a maximum of 8MB, but > upgrading to XT puts them on a schedule towards 8GB which is clearly > not what they have agreed to. > > Do you have any insights into what's going on there? > > Also do you have any insight into what Chinese pools would accept as a > compromise in terms of raising the blocksize limit? > > Drak > > [1] https://twitter.com/JihanWu/status/633288343338381314 >
Yifu Guo via bitcoin-dev:
Quoted text (1 line)
> One thing is for sure though, not increasing the blocksize is not an option.
Why not? The blocksize increase eliminates the pressure to seek durable solutions. But it will turn out differently. Other than we all think.
I really can not imagine that a 20-year plan will be successful. At one point we like to clear away the auto-increase. I think that is the only thing for sure at the moment.
I hope that the current protocol and blockchain will be continued. Perhaps with fewer people. That would settles the matter for the time being. ;)
- oliver
Keeping the block size at 1mb restricts the number of active users of bitcoin to around 100,000 people transacting twice a day on blockchain.
BItcoin is a protocol. Protocols are successful because of their network effect. Capping the block size freezes bitcoin’s network effect, limits users and prevents new users from joining (which will cut demand to exchange bitcoin) and also freeze the economic incentive to mine, because it will hurt the price.
Keeping the 1MB cap in place is horrible for the health of bitcoin. It’s good for competing protocols that want a chance to “catch up”.
Freezing bitcoin’s growth for any meaningful length of time will threaten its position as the leading cryptocurrency. Reasonable, controlled growth is a good thing. BIP101 should be rolled into core as soon as feasible.
Quoted text (21 lines)
> On Aug 21, 2015, at 7:18 AM, Oliver Egginger via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: > > Yifu Guo via bitcoin-dev: >> One thing is for sure though, not increasing the blocksize is not an option. > > Why not? The blocksize increase eliminates the pressure to seek durable > solutions. But it will turn out differently. Other than we all think. > > I really can not imagine that a 20-year plan will be successful. At one > point we like to clear away the auto-increase. I think that is the only > thing for sure at the moment. > > I hope that the current protocol and blockchain will be continued. > Perhaps with fewer people. That would settles the matter for the time > being. ;) > > - oliver > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
My UX skills are lacking a bit. You can edit all your thoughts about each BIP, HTML is accepted, so you can link to other posts you made somewhere else. When you click on a cell in the grid, it forward you to the page that the dev edited for this BIP.
This website is not only to say "approve", "disapprove", nor is it about a formal process for reaching agreement. This is a tool, a portal, which educates people, and permit you to link all of your thoughts about the various BIP and show it to others.
With the opinions browse able from the same website, you will notice in a gleam as soon as one of those proposal reach consensus. (I think SIPA's BIP has a chance to do so, but nobody knows it yet) Sadly, the most controversial is a BIP, the noisier it is, at the expense of those which are not. (like sipa's one).
It irritates me a lot that the debate in public mind is "XT or not" / "Bigger blocks or not", when in reality there is lots of different proposals that might also reach consensus but are lost in the noise. I will add any BIP that at least one voter approve and want to push forward. I plan to add merchants/wallet providers/mining pools later.
On Fri, Aug 21, 2015 at 6:35 PM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (28 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > On 21 August 2015 02:31:51 GMT-07:00, Btc Drak <btcdrak@gmail•com> wrote: > >On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev > ><bitcoin-dev@lists•linuxfoundation•org> wrote: > >> What might be valuable is to ask devs to explain what their threat > >models are, what should be at the root of their thinking about the > >blocksize. > > > >That's exactly what the "Technical Opinion" column is for. > > What if could be used for; theres value in being more explicit. > -----BEGIN PGP SIGNATURE----- > > iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV1vDG > AAoJEMCF8hzn9Lncz4MIAIMtLLA4q7KJiwrYrpjFWme1ys9iyPZiADJGQWG3qKlH > Q4pEcwWt69jfTUCjLYfegsDW4eEMarejs568iSF70hvGB4OPWrYK3YiM1cWlWtDD > seN3G/4dJjehL7h1Nz+/OTjTlePkguHctRlJTavel8sI7fg356iMJc1Ggm5Q1ZFl > CLrivr/CEO7Qk9Uo5ewhnwConKjLygSyv67SSaMJW7pZB06uTX6M3lk11c/RB/C6 > JKPqxkvOmNIX9U8S/G3Y2pYf3/up72IhP0Ugp31iOsz629B2WvEsDYu/0SP61+oZ > za9HrP2g8OsxVq6SUD3MukmbRVKklvcnro4vk5sOlYI= > =Jfl+ > -----END PGP SIGNATURE----- > >
Am 21.08.2015 um 15:34 schrieb Will Madden:
Quoted text (2 lines)
> Keeping the block size at 1mb restricts the number of active users of bitcoin to around 100,000 people transacting twice a day on blockchain. > BItcoin is a protocol. Protocols are successful because of their network effect. Capping the block size freezes bitcoin’s network effect, limits users and prevents new users from joining (which will cut demand to exchange bitcoin) and also freeze the economic incentive to mine, because it will hurt the price.
As a protocol Bitcoin could support millions of full nodes. What you talking about is the number of shareholders. But these are poorly determined by the block size. The number of shareholders is determined by many parameter but manly by the decreasing-supply algorithm. Which "was chosen because it approximates the rate at which commodities like gold are mined". See: https://en.bitcoin.it/wiki/Controlled_supply
While the decreasing-supply algorithm of Bitcoin has many advantage it's very hard to believe that the block chain will ever reach mass adoption. Even after 6 years, hardly anyone owns Bitcoins. Like Gold Bitcoin is distributed in large blocks to a few. Exceptions prove the rule. In the last 6 years the 1MB limit has been sufficient. I don't think that we will hit the 8MB limit in the next 6 years, except for stress tests and spam.
Quoted text (2 lines)
> Freezing bitcoin’s growth for any meaningful length of time will > threaten its position as the leading cryptocurrency.
I don't think that a relative tight block size could harm Bitcoin middle-term. Only experienced users penetrate the block chain directly. They know what they are doing and deal with problems. When space for transactions starts to become scarce and the fees rise too much, the developers have enough time to make a change. It would then also not so controversial. A matter of a few days or weeks. Especially if all necessary preparations have already been taken.
But I know that my opinion is very different from other claims. However, reliable people share some more fatalism as I'm currently find in some parts of the the Bitcoin community. Fear is a very bad adviser and can make a genius stupid.
- oliver
I’m replying all just because my point was changed in your response.
Quoted text (6 lines)
> As a protocol Bitcoin could support millions of full nodes. What you > talking about is the number of shareholders. But these are poorly > determined by the block size. The number of shareholders is determined > by many parameter but manly by the decreasing-supply algorithm. Which > "was chosen because it approximates the rate at which commodities like > gold are mined". See: https://en.bitcoin.it/wiki/Controlled_supply
I am not talking about "shareholders” who own bitcoin, or the supply of bitcoin at all. I’m talking about active users of bitcoin. I don’t care if they send 10,000 BTC, or .01 BTC, usage is adoption. Putting a 1MB cap on block size caps transaction volume, which by definition blocks adoption and use.
Quoted text (7 lines)
> While the decreasing-supply algorithm of Bitcoin has many advantage it's > very hard to believe that the block chain will ever reach mass adoption. > Even after 6 years, hardly anyone owns Bitcoins. Like Gold Bitcoin is > distributed in large blocks to a few. Exceptions prove the rule. In the > last 6 years the 1MB limit has been sufficient. I don't think that we > will hit the 8MB limit in the next 6 years, except for stress tests and > spam.
You can think what you like, but I find your position on this specious. You don’t know if we will hit that limit in the next 6 years. All it takes is one moderately successful application and we could be hitting that limit with very little warning. It could be open bazaar, or something else. Stating that “even after 6 years, hardly anyone owns Bitcoins.” as a justification that it will stay small doesn’t hold water either in terms of common sense or when looking at other standards evolving through history. TCP/IP was declared as a standard by the US Military in 1982 and became a public standard in 1985. Normal people didn’t start using TCP/IP until much later, when Mark Andreessen created the Mosaic internet browser, the precursor to Netscape. It was released in 1993. Widespread use didn’t really kick in until the second half of that decade. The reference bitcoin client was released in January 2009. So it’s basically 1988 for bitcoin, if we use the internet as a proxy - one way to look at it. The telephone even took 50 years to become widespread.
Quoted text (7 lines)
> I don't think that a relative tight block size could harm Bitcoin > middle-term. Only experienced users penetrate the block chain directly. > They know what they are doing and deal with problems. When space for > transactions starts to become scarce and the fees rise too much, the > developers have enough time to make a change. It would then also not so > controversial. A matter of a few days or weeks. Especially if all > necessary preparations have already been taken.
This is insane. You actually believe this? Capping the block size at 1MB doesn’t just cause fees to rise. It caps transactions that can be performed. This caps the number of users who can access bitcoin, directly cuts demand, which kills the price, which kills the mining, and BAM Rome falls. Only experienced users can “penetrate’ the block chain directly? Seriously? You download a software application, or sign up for a web wallet, buy some bitcoin on an exchange or have a friend send you some, and send it. Try bread wallet. My mom can do it. She is in her 70’s and couldn’t program a VCR 20 years ago.
I am just going to stop here. I really hope you change the way you are looking at bitcoin. This is not what it was meant to be, and if it ever becomes this, I’m not going to be interested in it.
Quoted text (39 lines)
> On Aug 21, 2015, at 11:31 AM, Oliver Egginger <bitcoin@olivere•de> wrote: > > Am 21.08.2015 um 15:34 schrieb Will Madden: >> Keeping the block size at 1mb restricts the number of active users of bitcoin to around 100,000 people transacting twice a day on blockchain. >> BItcoin is a protocol. Protocols are successful because of their network effect. Capping the block size freezes bitcoin’s network effect, limits users and prevents new users from joining (which will cut demand to exchange bitcoin) and also freeze the economic incentive to mine, because it will hurt the price. > > As a protocol Bitcoin could support millions of full nodes. What you > talking about is the number of shareholders. But these are poorly > determined by the block size. The number of shareholders is determined > by many parameter but manly by the decreasing-supply algorithm. Which > "was chosen because it approximates the rate at which commodities like > gold are mined". See: https://en.bitcoin.it/wiki/Controlled_supply > > While the decreasing-supply algorithm of Bitcoin has many advantage it's > very hard to believe that the block chain will ever reach mass adoption. > Even after 6 years, hardly anyone owns Bitcoins. Like Gold Bitcoin is > distributed in large blocks to a few. Exceptions prove the rule. In the > last 6 years the 1MB limit has been sufficient. I don't think that we > will hit the 8MB limit in the next 6 years, except for stress tests and > spam. > >> Freezing bitcoin’s growth for any meaningful length of time will >> threaten its position as the leading cryptocurrency. > > I don't think that a relative tight block size could harm Bitcoin > middle-term. Only experienced users penetrate the block chain directly. > They know what they are doing and deal with problems. When space for > transactions starts to become scarce and the fees rise too much, the > developers have enough time to make a change. It would then also not so > controversial. A matter of a few days or weeks. Especially if all > necessary preparations have already been taken. > > But I know that my opinion is very different from other claims. However, > reliable people share some more fatalism as I'm currently find in some > parts of the the Bitcoin community. Fear is a very bad adviser and can > make a genius stupid. > > - oliver >
Bitcoin will be neutered and die if the big Chinese mining pools utilize XT.
Specifically the text of @JihanWu's tweet was,
"I support increasing the block size. @BITMAINtech 's AntPool will be prepared to switch to XT, IF we see majority has switched."
Since there are many people who are supportive of increasing the block size, but have spend much time calling attention to the many problems of XT (which I need not repeat again here), it is odd that Jihan Wu would see a need to suggest that AntPool will be prepared to switch to XT at a time when there has not yet been time for fully assessing other proposals; not all proposals have gone through a voting process, nor have even people had a chance yet to attend upcoming workshops on the subject which are partially or wholly intended for development of consensus ( one example being the upcoming one in Montreal, but I think this is not the only one https://scalingbitcoin.org/montreal2015/ ). See also Pindar Wong's post on this list regarding the Montreal workshop : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/0101 35.html
This is also a good time to remember again some of the pressures being placed by the state on Chinese internet-based businesses. These pressures have increased, as has been recently discussed on this list, here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/0098 61.html
Take a good read of these issues (linked to above) relating to Chinese mining and the influence of the Chinese state, and it becomes clear how the state pressures might cause Chinese miners to adopt XT in light of:
Hearn's disabling Tor in XT https://lists.torproject.org/pipermail/tor-dev/2014-July/007167.html http://cointelegraph.com/news/115153/bitcoin-xt-fork-can-blacklist-tor-e xits-may-reveal-users-ip-addresses Hearn's move to support blacklisting https://www.reddit.com/r/Bitcoin/comments/1qmbtu/mike_hearn_chair_of_the _bitcoin_foundations_law/
A recent post that sums it up pretty well: http://qntra.net/2015/08/collected-notes-on-the-xt-client-and-xtcoin-for k/
I encourage people still reading this list to:
- - Not use XT - - Work to develop consensus on an alternative that increases block size (e.g. BIP 100) - - Attend a conference if you can such as the one which is coming up in Montreal https://scalingbitcoin.org/montreal2015/ and if you go there as a developer / engineer / miner, AGREE ON SOMETHING (other than XT) - - Visualize different proposals and votes on them so people can see what is happening - - Please see also (how end users can deal with this situation) at: https://bitcointalk.org/index.php?topic=1157545.msg12189776 and contribute to the discussion if you like
Thank you.
On 08/21/2015 04:28 AM, Btc Drak via bitcoin-dev wrote:
Quoted text (33 lines)
> On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> wrote: >> I like the intend of this attempt to bring more clarity to the >> blocksize debate, however it would be more help to make this a >> information site about the current outstanding BIPs and summarize >> their differences rather than voting mechanism. (ofcourse the >> author of the BIPs would "vote" for their own proposals.) >> >> It would be good to include supporting and counter statements >> regards to these BIPs on the site. in addition to highlight >> certain things like pools in china have voiced their opinion that >> increase should happen, and 8mb is something they are comfortable >> with, which is not directly related to a single BIP, but never >> the less relevant in this discussion. > > I was rather surprised by the tweet from AntPool[1] today saying > that they support big blocks and would be prepared to upgrade to > XT. Pools have stated that they are willing to increase to a > maximum of 8MB, but upgrading to XT puts them on a schedule towards > 8GB which is clearly not what they have agreed to. > > Do you have any insights into what's going on there? > > Also do you have any insight into what Chinese pools would accept > as a compromise in terms of raising the blocksize limit? > > Drak > > [1] https://twitter.com/JihanWu/status/633288343338381314 > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
- -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn