Guest User


a guest
Mar 13th, 2017
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 7.05 KB | None
  1. <BlueMatt> Hisham: bitcoin's consensus rules are not a development topic, and its best to keep irc channels on-topic so people can filter for what discussions they want to be involved in based on channels :)
  2. <BlueMatt> ehh, merging proposed consensus rules, that is
  3. <BlueMatt> given they have already been technically vetted (not sure anyone bothered to review the uasf code that was posted, but it looked trivial, soooo)
  4. <gmaxwell> Hisham: Sorry, I wasn't trying to be rude before-- just wanted you to know that asking to ask is not well recieved in chat generally. It is surprising to some people, but there are good reasons for it... and not a think unique at all to the bitcoin channels. :) Cheers.
  5. <Hisham> No problem Gregory, it's ok, I still like you guys :)
  6. <BlueMatt> Hisham: you might wish to read the blog post i linked you to, it tries to describe some of why "consensus" matters, ie why things like fork activation, while they might be proposed by devs, must be decided on by a large body of users, and why its important that those users try their damndest to only make changes when they are really uncontroversial
  7. <BlueMatt> not sure i did a good job, but i /tried/ to make those points :P
  8. <Hisham> Matt, what I want to discuss with all of you is, how me as Hisham can get consensus ?
  9. <Hisham> How you as a developers measure this ?
  10. <Hisham> Talk or reddit for example ?
  11. <belcher> educate yourself on the issues and talk to people, correct misinformation, explain why segwit is a good idea, etc
  12. <Hisham> Twitter ?
  13. <belcher> yes, all of those
  14. <BlueMatt> go to meetups, go talk to businesses, post about it on forums and reddit, email people asking for their opinions, etc, etc
  15. <BlueMatt> and twitter and wechat and.....
  16. <Hisham> It's not what I shall I do, I will try my best to do what you've recommended but what I'm asking now is, lets say we already have consensus for SegWit UASF, how will you as a developers will know that there are a hell lot of people in your back supporting you to get the SegWit UASF integrated into Bitcoin Core ?
  17. <Hisham> Hopefully it's more clear now.
  18. <Hisham> And to be more clear, I'm not aganist consensus "at all
  19. <Hisham> "
  20. <Hisham> It's a must and this is how Bitcoin works.
  21. <sipa> the kind of consensus needed depends on the failure mode
  22. <Hisham> May you elaborate more please ?
  23. <sipa> for certain types of changes, like SegWit's current proposal, the system only fails if a majority of miners signal they're ready, but in reality aren't, and at the same time there is not widespread adootion of segwit-conpatible software deployed in the network
  24. <sipa> UASF drops the miner signalling requirement, so it can fail under wider conditions
  25. <sipa> that makes it riskier, and thus we'd need a clearer signal from the community that it is the way forward
  26. <Hisham> Perfect.
  27. <Hisham> Stop here please and let me quote you.
  28. <Hisham> "clearer signal from the community that it is the way forward"
  29. <Hisham> How will you witness this ?
  30. <sipa> I'm not.
  31. <sipa> I'm not even saying UASF is a good or bad thing.
  32. <Hisham> I understand.
  33. <sipa> All I'm saying is that it is more complicated.
  34. <dgenr8> sipa: is a supermajority of mining signaling "yes" a necessary component of the "clear community signal"?
  35. <sipa> dgenr8: no
  36. <dgenr8> thank you
  37. <sipa> hashrate only represents mining readiness
  38. <Hisham> You are not getting my point still, with all respect, I'm not asking for your opinion because I understand that nobody is entitled to ask this.
  39. <Hisham> What I'm saying, you've said that Core developers need clearer signal from the community.
  40. <Hisham> I fully agree.
  41. <sipa> Hisham: i'm not answering your question because i'm not interested in doing politics
  42. <sipa> all i'm saying is why some changes are more complicated then others
  43. <sipa> based on their technical properties
  44. <BlueMatt> miners are users of the system, like anyone else, but for the purpose of consensus changes, are only users of the system, like anyone else :P
  45. <sipa> Hisham: if you're asking me under what conditions UASF would be merged into Core, you're asking the wrong question. You should ask under what conditions people would decide to run that version of Core. And to that, I don't know the answer.
  46. <Hisham> Well, I guess there is a lot of misunderstanding here, so to make clear because I'm not really getting it, telling me how consensus is being measured from Core developers is a question that can't be answered ?
  47. <sipa> Hisham: it shouldn't matter. Core is just a software project, and there are several forks
  48. <BlueMatt> Hisham: its a useless question, especially when you're talking about a 5-line patch
  49. <BlueMatt> the question is, when will people run such a version of a bitcoin full node
  50. <sipa> if Core developers would merge something crazy, i would hope that the community is smart enough to start running a fork that doesn't have craziness
  51. <dgenr8> that turns out to be difficult
  52. <sipa> of course, developers have influence
  53. <sipa> by the choices they make
  54. <BlueMatt> sipa: dont worry, if you merge something crazy I'll maintain a fork :P
  55. <Hisham> :D
  56. <sipa> but in an ideal world, maintainers don't matter - only users
  57. <Hisham> Sipa, we are in agreement by the way.
  58. <Hisham> But there is something that is still I'm missing.
  59. <Hisham> And please guys, no need to set up the exile for me.
  60. <Hisham> I'm not an enemy :D
  61. <sipa> UASF has a flag date. If we expect that before the flag date nearly the entire ecosystem will have adopted software that implements UASF with that flagdate, it is safe.
  62. <Hisham> Yes, I'm noob or rookie whatever, I just want to understand and help even a tiny bit :)
  63. <Hisham> How will they adopt the software if still the code in not merged into any Core version ?
  64. <jwinterm> what happens if expected outcome of expectation does not materialize?
  65. <jwinterm> just call the whole thing off?
  66. <Hisham> Sipa, there ?
  67. <sipa> Hisham: as i said, in an ideal world, maintainers don't matter, and users run software that is sane
  68. <sipa> Hisham: so in an ideal world, the coices that any given software project makes don't matter
  69. <sipa> we don't live in an ideal world, and in the real world there exists politics
  70. <sipa> which i'm not not going to participate in
  71. <dgenr8> BlueMatt once explained to me quite forcefully that there must only be one consensus implementation (absent some idealistic provable equivalence condition)
  72. <BlueMatt> dgenr8: luckily a carefully-constructed fork is pretty much quivalent :)
  73. <BlueMatt> dgenr8: and there is a big difference between "we're adding a new consensus rule by all agreeing to run it" and "we're gonna run 32 different clients and have 32 different consensus rules risking everyon's money and consensus for marginal gain"
  74. <dgenr8> And getting off your crazy treadmill isn't marginal gain.
  75. <BlueMatt> dgenr8: hmm?
  76. <BlueMatt> dgenr8: I would say that there is lots of value to be had by accessing consensus rules by different apis, yes, but that doesnt inherintly mean different implementations, and there is real risk to having many different implementations
  77. <BlueMatt> consider for a moment the history of different implementations in bitcoin.....its really not good
RAW Paste Data Copied