1 2015-12-21 01:10:49 <Iriez> Sipa: When you say "but I can only agree with merging it in Core if I'm convinced that there is no strong opposition to it from others.", could you please explain how you measure opposition? Im curious what consensus measuring mechanisms exist right now and how you utilize them to determine the level of consensus or opposition on issues.
  2 2015-12-21 01:11:01 <Iriez> And thank you.
  3 2015-12-21 01:16:08 <MarcoPon> Hi guys! May I ask one simple thing: how exactly are BIP numebers assigned? Case in point, how can I get a number for my Blockchain reference / explorarion one? https://github.com/bitcoin/bips/pull/202 - I see new BIPS (about block size) keep coming up... did I just have to choose one?
  4 2015-12-21 01:18:56 <belcher> MarcoPon i think its just a random number
  5 2015-12-21 01:19:14 <belcher> you ask the maintainer of the bip repos and they assign you a number
  6 2015-12-21 01:21:06 <MarcoPon> well, I sent a message to Greg Maxwell weeks ago (I even followed his suggestion on the mailing list to temporary name a BIP with the nickname), and the pull it's marked as "Need number assignment", but that doesn't exactly seems to work, so to speak! :)
  7 2015-12-21 01:21:21 <MarcoPon> -- is marked
  8 2015-12-21 02:07:41 <btcdrak> MarcoPon: First submit the BIP text as a PR, and then it can be assigned a number, Until then please name it bip-yourname-shorttitle
  9 2015-12-21 03:43:59 <kanzure> rusty: we need to mass re-enable modbits
 10 2015-12-21 03:46:19 <btcdrak> rusty: kanzure: please
 11 2015-12-21 03:47:00 <btcdrak> in fact, now that jgarzik has recused himself of moderation, someone else needs the administrator password.
 12 2015-12-21 16:13:15 <Quent1> wumpus are you going to merge https://github.com/bitcoin/bitcoin/pull/7219 ?
 13 2015-12-21 18:41:20 <Iriez> Were any of the core dev's approached by the linux foundation to partner for their blockchain initiative? I see IBM and R3 have both agreed to submit their codebase, which is pretty darn cool.
 14 2015-12-21 18:46:34 <mrkent> Does anyone know how this works? https://webbtc.com/script/4a5b82bd3a390aa58a17e346a79c61db3ab4ab6a0653f66490abfe29387fd95f:5
 15 2015-12-21 18:47:12 <sipa> Iriez: i was not
 16 2015-12-21 18:54:42 <jgarzik> Iriez, no
 17 2015-12-21 18:54:57 <jgarzik> Iriez, it is R3 trying to jump over bitcoin, be "more open source"
 18 2015-12-21 18:57:09 <jgarzik> Iriez, R3 marketing is jumped out of the gate very early trying to marginalize bitcoin as "cypherpunks not wanting to interface with banks or governments" http://www.ofnumbers.com/2015/09/29/designing-a-global-fabric-for-finance-g3f/
 19 2015-12-21 19:04:08 <netg> was to be expected
 20 2015-12-21 19:46:46 <Iriez> jgarzik: thank you for the response and I see your post on reddit too :)
 21 2015-12-21 19:47:09 <Iriez> Sipa: When you say "but I can only agree with merging it in Core if I'm convinced that there is no strong opposition to it from others.", could you please explain how you measure opposition? Im curious what consensus measuring mechanisms exist right now and how you utilize them to determine the level of consensus or opposition on issues.
 22 2015-12-21 19:47:38 <sipa> Iriez: i'd say months of discussion are a sign that it's a controversial subject at least
 23 2015-12-21 19:48:04 <sipa> i don't think there exist formal ways of measuring it, but it's in the best interest of the maintainers of software to make that judgement call
 24 2015-12-21 19:48:13 <Iriez> sipa: While I would agree with your logic, that unfortunately does not provide transparency to the users.
 25 2015-12-21 19:48:25 <sipa> to not force a potentially divisive choice on the economy
 26 2015-12-21 19:48:52 <Iriez> I was thinking that there needs to be more clear metrics that can be analyzed by the public/users, so that we can leverage 'real' consensus as opposed to perception based on individuals.
 27 2015-12-21 19:48:56 <sipa> in my view, we should never assume a hardfork can succeed... it can be proposed, but we need an extremely high bar of consensus to adopt it into software
 28 2015-12-21 19:49:33 <adam3us> Iriez: this is good http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011457.html
 29 2015-12-21 19:50:06 <adam3us> Iriez: and this https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md
 30 2015-12-21 19:50:20 <Iriez> sipa: Has there been a recent vote amongst maintainers of the software regarding a blocksize upgrade? It seems to me that most are in favor now, but its difficult to determine without a specific vote taken.
 31 2015-12-21 19:50:31 <Iriez> adam3us: I've read those posts and can only agree with their contents.
 32 2015-12-21 19:50:45 <adam3us> Iriez: and https://en.bitcoin.it/wiki/BIP_0001
 33 2015-12-21 19:50:57 <Iriez> However I would like to be more specific on this issue since there is a large disconnect between developers and community members.
 34 2015-12-21 19:51:11 <Iriez> If I could only fit my brain inside your guys brains for 5 minutes... :)
 35 2015-12-21 19:51:23 <adam3us> Iriez: the IETF post was pretty long and interesting on consensus process
 36 2015-12-21 19:51:45 <sipa> Iriez: we can't force people what software to run; we can choose what software we find worthwhile working on
 37 2015-12-21 19:51:52 <Iriez> adam3us: I know, I read it when it was posted a few months back, and I loved it when I read it.
 38 2015-12-21 19:52:05 <Iriez> sipa: I am not trying to debate any theory with you, only asking about metrics and how they are measured.
 39 2015-12-21 19:52:18 <Iriez> I understand your position quite clearly, I read the devlists daily :)
 40 2015-12-21 19:52:23 <sipa> ok!
 41 2015-12-21 19:52:37 <Iriez> Has there been a recent vote amongst maintainers of the software regarding a blocksize upgrade? It seems to me that most are in favor now, but its difficult to determine without a specific vote taken.
 42 2015-12-21 19:52:56 <Iriez> I am just curious what the current stance is amongst the maintainers, aside from yourself.
 43 2015-12-21 19:53:05 <sipa> i think a majority are in favor of following greg maxwell's capacity increase plan now
 44 2015-12-21 19:55:12 <Iriez> Thank you for clarification on the issue. What I see too much is dissent regarding idea's, but not often enough the voicing of consensus on current approaches. This makes it appear to a outside user that there is disarray in the project, when instead there is just more noise than signal.
 45 2015-12-21 19:56:04 <sipa> Iriez: agree!
 46 2015-12-21 19:56:06 <adam3us> Iriez: that is an astute observation. symptom of "someones wrong on the internet" effect where debate triggers more debate. but saying "great i agree" is something that doesnt trigger as quick a reaction
 47 2015-12-21 19:56:18 <morcos> Iriez: there is very strong agreement on following the plan laid out in greg's email and not a HF at this point
 48 2015-12-21 19:59:28 <jgarzik> Unfortunately that is not the whole story.   A subset of dev consensus considers bitcoin's current economics not "healthy" and wishes to change bitcoin to a new economic policy that has "healthy" block space competition.   This economic policy change has not been proposed as a BIP - instead you merely need inaction on core block size to accomplish the shift in economy to what dev consensus considers "healthy"
 49 2015-12-21 19:59:53 <jgarzik> This new economic state is under-studied, and the ideas for how hard limits should behave in this new system are barely off the white board
 50 2015-12-21 20:00:29 <jgarzik> Sticking-with-1M core block size sharpens several existential risks
 51 2015-12-21 20:00:33 <adam3us> jgarzik: the roadmap is not inaction and proposes the same size increase ~2MB as BIP 102.
 52 2015-12-21 20:00:47 <jgarzik> adam3us, false - roadmap does not change core block size
 53 2015-12-21 20:00:49 <adam3us> jgarzik: obviously modulo deployment speed and uptake by wallets
 54 2015-12-21 20:01:28 <adam3us> jgarzik:  the effective block size and scale and scalability is what matters to users.
 55 2015-12-21 20:01:58 <jgarzik> core block size is the most economically constrained resource - it fills up at a faster rate
 56 2015-12-21 20:02:05 <morcos> jgarzik: I think we can agree there are areas of communication that need to be improved.  Core needs a more permanent mission statement of values and principles or something.
 57 2015-12-21 20:02:54 <jgarzik> morcos, if sticking-with-1M is the direction, it is at a minimum reasonable to (a) communicate that plan to users, and (b) alert them of the desire to change bitcoin's economics
 58 2015-12-21 20:04:43 <adam3us> jgarzik: you are making assumptions that you are not stating. factors include how quickly can a HF deploy & be activated vs a soft-fork, how much testing & dev time needed for each (both need work) and how quickly will wallets and companies upgrade. i think on balance the SW approach is better.
 59 2015-12-21 20:05:26 <adam3us> jgarzik: the change economics call is in question because that depends on your assumptions of the above factors.
 60 2015-12-21 20:06:09 <brg444> jgarzik I presume an alternative involving a increase in the blocksize would include a similar statement to "alert users that Core has chosen to continue subsidize transactions" ?
 61 2015-12-21 20:06:36 <Iriez> As a user, I must state that jgarzik has a valid point in that everyone is absolutely confused on what the actual plan is. For example, you have all stated rough consensus on gmaxwell's proposal, which if I am not mistaken states "I propose we work immediately towards the segwit 4MB block soft-fork which increases capacity and scalability". To the layman, this sounds like you are going
 62 2015-12-21 20:06:36 <Iriez> to HF to a 4mb cap. Yet, it seems to me that what is really being said is "we wish to SF to SW which will give bitcoin a similar capacity increase as to be compared to a 4mb blocksize cap", which means no increase to the blocksize. Am I correct about the proposals intentions?
 63 2015-12-21 20:07:22 <sipa> i can agree with the argument that a hard fork is needed when there is an imminent threat that could hurt bitcoin's long term surival before its ecosystem can adapt to a limited block space behaviour
 64 2015-12-21 20:07:48 <sipa> but jgarzik makes it sound like the reason for a hard fork is avoiding economic change itself
 65 2015-12-21 20:08:17 <sipa> i don't think that sustainable and certainly a bad precedent
 66 2015-12-21 20:08:55 <adam3us> Iriez: do you agree that scale and scalability and time to availability of that scale is the primary objective?
 67 2015-12-21 20:09:34 <Iriez> adam3us: Absolutely. Yet I would like confirmation on the proposal's intentions since at its current wording its very murky.
 68 2015-12-21 20:09:35 <sipa> Iriez: it's approximately a 2x capacity increase (though it depends on the use case)
 69 2015-12-21 20:09:49 <sipa> Iriez: that needs clarification then!
 70 2015-12-21 20:09:58 <brg444> sipa I agree. We'd be left with a FED type situation where everyone is left wondering whether the next more is a rate increase or decrease. Central bank 2.0...
 71 2015-12-21 20:10:04 <brg444> next move*
 72 2015-12-21 20:10:17 <Iriez> sipa: Please understand I have watched your talk and read all of the devlist posts, I fully understand the intended capacity increase proposal with SW. But most users do not.
 73 2015-12-21 20:10:22 <adam3us> Iriez: yes the roadmap is proposing a soft-fork first. better doco needed.
 74 2015-12-21 20:12:01 <Iriez> statement that users need to be communicated with regarding the stance.
 75 2015-12-21 20:12:01 <Iriez> To layman, that is still not enough for understanding. I think it needs to be states also that the 1mb limit will remain the same. As a techophile/bitcoiner, I understand that when you say you intend to SF first, that means to leave the cap as is as that will require a hardfork to raise the limit. However the average user probably does not understand that. In this, I agree with garzik's
 76 2015-12-21 20:12:20 <Iriez> stated* (states lol)
 77 2015-12-21 20:13:00 <sipa> i think what needs to be communicated is that bitcoin core is a software project, and that its vision for bitcoin includes not deciding what its consensus rules are
 78 2015-12-21 20:13:05 <zookolaptop> It can be hard for devs, scientists, etc. to understand that the problem isn't the facts or the technical plans, the problem is the communication to the public.
 79 2015-12-21 20:13:17 <sipa> this may result in economic changes, but those are already happening
 80 2015-12-21 20:13:36 <Iriez> sipa: You do understand that currently you and the core dev's are holding the reins, right?
 81 2015-12-21 20:13:50 <sipa> Iriez: i am sure i have influence
 82 2015-12-21 20:13:56 <sipa> i hope i am not in control
 83 2015-12-21 20:14:06 <zookolaptop> sigh
 84 2015-12-21 20:14:44 <Iriez> We can discuss theory of the power of the users, etc. But if miners have delegated their power to you to make decisions, as they stated at HK, then it does appear that the core maintainers right now have a large pool of the power when it comes to decisions on direction of the project
 85 2015-12-21 20:15:01 <zookolaptop> There's a conflation happening between "I/we oppose a certain change because I/we think it wouldn't be a good idea technically" and "I/we have no authority or right to make changes".
 86 2015-12-21 20:15:05 <zookolaptop> Those are entirely different.
 87 2015-12-21 20:15:14 <silvaedium> The core maintainers and the core devs have all of the power. Ins't that the meaning of the word "core"?
 88 2015-12-21 20:15:28 <silvaedium> It all depends on what the goal of Bitcoin is
 89 2015-12-21 20:15:35 <Iriez> I think whats important here is to recognize that. To understand that despite your philosophy, that the current situation is unevenly distributed when it comes to power.
 90 2015-12-21 20:15:37 <morcos> Iriez: Well luckily there is a very large group of developers who are all in broad agreement.  We just need to communicate it better ala zooko's laptop
 91 2015-12-21 20:15:51 <Iriez> morcos: I agree with this statement :)
 92 2015-12-21 20:15:55 <silvaedium> Both parties, the party who thinks technically, and the party that thinks authoritiarianly, should both have a concencus towards bitcoins overall goal
 93 2015-12-21 20:16:09 <silvaedium> That way they can "mesh" better.
 94 2015-12-21 20:16:36 <adam3us> Iriez: coders are not always awesome doco writers. i expect help would not be turned down in that area (hint)!
 95 2015-12-21 20:17:08 <adam3us> Iriez: your feedback on the lack of clarity is useful to motivate people to improve it.
 96 2015-12-21 20:17:23 <Iriez> sipa: I think we can both agree that having too much power granted to the maintainers is a problem. I agree with your philosophy in regards to this, and would also agree that too much consolidated power will mean that bitcoin has failed.
 97 2015-12-21 20:17:42 <sipa> Iriez: yes...
 98 2015-12-21 20:18:20 <zookolaptop> The confusion that is happening is that a lot of users, and >= 90% of all the mining power, are waiting on "the core devs" to make decisions, and, IIUC, the core devs (or at least some of them!?) think that they don't have that right or responsibility.
 99 2015-12-21 20:18:40 <Iriez> But in order to correct a issue, we must first recognize the reality so that we can seek to correct corse. Right now the majority of miners have said "We want the core dev's to figure it out". Between the core dev's and the miners, I would state that is the majority of decision making power. Users have a economic incentive to listen to both parties to make the best decision
100 2015-12-21 20:18:46 <zookolaptop> And jgarzik is eloquently pointing out that if you do have that right and responsibility, then not making a decision is making a decision.
101 2015-12-21 20:18:48 <Iriez> haha, me and zooko are typing the same things.
102 2015-12-21 20:19:35 <zookolaptop> So, if you're one of "the core devs" -- whoever that is -- and you think that you don't have the right or responsibility to make modifications to the Bitcoin consensus algorithm,
103 2015-12-21 20:19:55 <zookolaptop> then I claim that you now have the right and responsibility to explain that to the users and miners, who are waiting for you to exercise it.
104 2015-12-21 20:20:17 <sipa> zookolaptop: agree!
105 2015-12-21 20:20:22 <Iriez> Double agree.
106 2015-12-21 20:20:24 <adam3us> i think there is a difference between improving bitcoin in a backwards compatible opt-in way.
107 2015-12-21 20:20:40 <adam3us> and proposing a hard-fork. i think the point is for a hard-fork the entire community must opt-in
108 2015-12-21 20:20:57 <silvaedium> Honestly what you should be focusing on is the usage case for Bitcoin. While decentralization makes Bitcoin appealing as a means of transferring wealth without government interevention, you need to focus on appealing to those that need that goal to increase adoption.
109 2015-12-21 20:21:08 <zookolaptop> adam3us: that is a reasonable stance (although I disagree with it).
110 2015-12-21 20:21:19 <zookolaptop> adam3us: but, the point here is that the miners and the community do *not* understand that.
111 2015-12-21 20:21:28 <zookolaptop> So if you want that to be the way it is, you'd better Get Explaining.
112 2015-12-21 20:21:29 <adam3us> zookolaptop: elaborate (why disagree)
113 2015-12-21 20:21:33 <zookolaptop> No.
114 2015-12-21 20:21:38 <adam3us> zookolaptop: yes doco sucks. hopeful someone will fix
115 2015-12-21 20:21:39 <zookolaptop> Because my opinion on the way it should be isn't important.
116 2015-12-21 20:21:54 <silvaedium> Be it focusing on the wealthy who as part of a capital flight need to move their funds out of the US, or underground markets, the decentralization of Bitcoin means that the developers wont be held liabile for Bitcoin's featuers
117 2015-12-21 20:21:54 <zookolaptop> What's important is the mismatch between the way it is in the minds of users and miners and the way it is in the minds of devs.
118 2015-12-21 20:21:58 <adam3us> zookolaptop: no disagreement that more info and doco is needed.
119 2015-12-21 20:22:00 <Iriez> So, if we can agree on that issue of communication of consensus and responsibilities, then we can agree that this issue is (probably) circular. I can tell you what precisely will happen when maintainers vocally state "we will not make consensus rules" .....the community will go "well who should?
120 2015-12-21 20:22:21 <zookolaptop> Yep.
121 2015-12-21 20:22:22 <silvaedium> Look at all of this bullshit talk.
122 2015-12-21 20:22:24 <Iriez> and most likely will maintain the most educated people and best suited to make consensus decisions are the maintainers.
123 2015-12-21 20:22:24 <silvaedium> It's amazing.
124 2015-12-21 20:22:36 <silvaedium> Plow the sable!
125 2015-12-21 20:22:54 <Iriez> And then here we are again, at the same situation :)
126 2015-12-21 20:23:00 <adam3us> Iriez: so the way that could work is the devs propose a hard-fork and ask the wider community if they think it is a good idea. if its clear that its nearly unanimous that sounds like a good way forward.
127 2015-12-21 20:23:00 <silvaedium> My pleasure :-)
128 2015-12-21 20:23:37 <Iriez> adam3us: I think concrete proposals are absolutely needed to ascertain consensus, but the critical question is how do we *measure* consensus?
129 2015-12-21 20:23:46 <brg444> adam3us +1. I think a reasonable, backward compatible, proposal that everyone can get behind is certainly one step toward stitching back together the community so that we are able to move forward as unit if ever the need for a hardfork presents itself
130 2015-12-21 20:23:59 <silvaedium> Bitcoin is becoming too Fuzzy
131 2015-12-21 20:24:05 <silvaedium> In both administration and application
132 2015-12-21 20:24:12 <silvaedium> There is a lot of effort that goes into this
133 2015-12-21 20:24:16 <silvaedium> Quit.,
134 2015-12-21 20:24:37 <silvaedium> There needs to be day-to-day real world non abstract usage cases.
135 2015-12-21 20:24:56 <silvaedium> Yesa
136 2015-12-21 20:25:08 <zookolaptop> adam3us: I went to Hong Kong and saw a panel which was allegedly 90% of the current hashpower.
137 2015-12-21 20:25:26 <zookolaptop> Many questions were asked of the panel (9 members) about making changes to Bitcoin protocol.
138 2015-12-21 20:25:40 <zookolaptop> The answers were consistent, and repeated multiple times: the miners want "the core devs" to decide, and then they will do whatever the core devs tell them to do.
139 2015-12-21 20:26:02 <silvaedium> Who is in control of the core devs?
140 2015-12-21 20:26:03 <silvaedium> Turtles.
141 2015-12-21 20:26:18 <zookolaptop> I'm not saying that "the core devs" have to take that power and exercise it. But I am saying that if they do not, they are leaving the vast majority of users hanging, because those users are expecting them to do so.
142 2015-12-21 20:26:28 <zookolaptop> So perhaps they ought to explain what they are doing/not doing to those people.
143 2015-12-21 20:26:32 <sipa> so, better communication is needed
144 2015-12-21 20:26:35 <sipa> i completely agree there
145 2015-12-21 20:27:16 <Iriez> sipa: can you at least confirm that you understand the majority of hashing power has given their vote to the maintainers?
146 2015-12-21 20:27:18 <silvaedium> This still doesn't mean anything with regards to concerete changes that should be made.
147 2015-12-21 20:27:27 <sipa> yes
148 2015-12-21 20:27:32 <Iriez> silvaedium: baby steps my friend.
149 2015-12-21 20:27:37 <Iriez> Ok, thank you sipa.
150 2015-12-21 20:27:52 <Iriez> So, then you recognize that you and the maintainers have a unevenly distribution of power right now ?
151 2015-12-21 20:28:02 <silvaedium> At a high enough resolution baby steps seem like leaps, and lower they seem like a blur.
152 2015-12-21 20:28:10 <silvaedium> Focus on the end result and work backwards.
153 2015-12-21 20:28:23 <silvaedium> Discover the goals, make changes to approach that goal.
154 2015-12-21 20:28:26 <sipa> only when we agree
155 2015-12-21 20:28:31 <zookolaptop> So I think what is happening is that either the core devs as a group do not understand that the miners have given their vote to them, or they do not wish to exercise that power. But I'm not sure.
156 2015-12-21 20:28:38 <silvaedium> Then correct the cause of the disagreement or change the system to allow agreement.
157 2015-12-21 20:29:03 <silvaedium> All of this massive amount of text to communicate such simple ideas is excessive and a waste of effort.
158 2015-12-21 20:29:05 <Iriez> sipa: I see your perspective. You are solid on your stance that taking action is excercising power and not taking action is not excercising power.
159 2015-12-21 20:29:27 <adam3us> zookolaptop: that is what the roadmap was intended to convey - a proposed roadmap and first step: seg-wit first
160 2015-12-21 20:29:31 <silvaedium> Miners are like "Oh shit let the core devs decide" the core devs are like "Bitch we only care about technical stuff that wont increase adoption" the executive is like "core devs get your shit in gear, we need to make bitcoin money"
161 2015-12-21 20:29:38 <zookolaptop> adam3us: what roadmap do you mean?
162 2015-12-21 20:29:40 <adam3us> zookolaptop: help with doco accepted
163 2015-12-21 20:29:53 <adam3us> zookolaptop: aha. see the locatiability of the roadmap also failed
164 2015-12-21 20:30:01 <sipa> Iriez: i am acknowledging that i have influence; and i am intending to use that influence to explain why us exercising the (alleged) power to hardfork is a bad idea
165 2015-12-21 20:30:06 <zookolaptop> adam3us: yeah, I'm unaware of this roadmap...
166 2015-12-21 20:30:10 <sipa> Iriez: and apparently we're not doing a good job at that
167 2015-12-21 20:30:19 <sipa> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
168 2015-12-21 20:30:22 <sipa> zookolaptop: ^
169 2015-12-21 20:30:38 <zookolaptop> Okay, before I load this URL, let me just tell you what I'm going to look for first.
170 2015-12-21 20:30:46 <zookolaptop> The most important thing in this is going to be the authority and identity of the writers.
171 2015-12-21 20:30:47 <silvaedium> NEVER HARDFORK
172 2015-12-21 20:30:56 <Iriez> sipa: if a blind woman is standing in the street and you see someone is driving erradically, headed straight for her and you know, for a undeniable fact, that you can pull her out of the way.....does allowing the car to hit her remove you of moral responsibility? Does your lack of action change the fact that she got killed because you did not step in and pull her out of harms way?
173 2015-12-21 20:30:58 <silvaedium> Do absolutely NOTHING to separate the userbase.
174 2015-12-21 20:31:00 <zookolaptop> If it says "This is from sipa", that's one thing. If it says "This is the core devs" speaking, that's another.
175 2015-12-21 20:31:09 <zookolaptop> Ah yes, I've read this.
176 2015-12-21 20:31:13 <zookolaptop> It is from gmaxwell.
177 2015-12-21 20:31:15 <Iriez> I apologize for the 'what if', but I believe this excercise can help one understand their position of authority regardless of action vs inaction.
178 2015-12-21 20:31:18 <silvaedium> This isn't a moral argument
179 2015-12-21 20:31:21 <silvaedium> That's ridiculous
180 2015-12-21 20:31:35 <brg444> zookolaptop here's is the "coredev" part:https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165
181 2015-12-21 20:31:42 <sipa> Iriez: if i was convinced bitcoin was heading for a disaster and the only way out was a hardfork, i would call for the community to support a hardfork proposal
182 2015-12-21 20:31:59 <silvaedium> But it's not
183 2015-12-21 20:31:59 <sipa> Iriez: i however do not consider the fear of economic change a disaster
184 2015-12-21 20:32:03 <Iriez> I agree that the situation we are headed for is not a disaster.
185 2015-12-21 20:32:09 <Iriez> Yes, we both agree there.
186 2015-12-21 20:32:18 <silvaedium> Bitcoin is not headed for a hardfork unless there is a technical issue wishing to cause such a hardfork
187 2015-12-21 20:32:37 <silvaedium> Devs need ideagrams
188 2015-12-21 20:32:50 <morcos> zookolaptop: The communication is bad, but the "core devs" have made a decision.
189 2015-12-21 20:32:58 <zookolaptop> brg444: ah! Thanks.
190 2015-12-21 20:33:06 <zookolaptop> morcos: you mean https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165 ?
191 2015-12-21 20:33:09 <morcos> It turned out to be remarkably easy becasue almost all of them agree with Greg's roadmap
192 2015-12-21 20:33:09 <silvaedium> The core devs are devs, they aren't people who understand anything beyond the technical
193 2015-12-21 20:33:12 <morcos> Yes
194 2015-12-21 20:33:15 <silvaedium> They code
195 2015-12-21 20:33:17 <silvaedium> That's all
196 2015-12-21 20:33:23 <morcos> And Greg's roadmap clearly does not include a HF at this point
197 2015-12-21 20:33:44 <silvaedium> Thank you for yor. Service ice.
198 2015-12-21 20:33:47 <silvaedium> cioa
199 2015-12-21 20:34:05 <Iriez> What the core maintainers need is a team of pysch, sociology and communications experts to help them :P
200 2015-12-21 20:34:23 <JeromeLegoupil> morcos I don't think communication is so bad, considering how tricky it is to communicate on something that hasn't reached yet consensus
201 2015-12-21 20:34:27 <Iriez> This reminds me of politics and how we only elect politicians who are certified in law
202 2015-12-21 20:34:36 <Iriez> and not scientists, doctors, laborers, etc :)
203 2015-12-21 20:34:38 <adam3us> Iriez: even a doco writer would be a start.
204 2015-12-21 20:34:46 <Iriez> +1
205 2015-12-21 20:35:02 <Iriez> adam3us: I think a team of doco writers would be beneficial, not a indivdidual
206 2015-12-21 20:35:17 <silvaedium> Iriez
207 2015-12-21 20:35:19 <silvaedium> Horridation
208 2015-12-21 20:35:44 <JeromeLegoupil> morcos also there has been important previous communication. Don't forget : https://bitcoinmagazine.com/articles/open-letter-bitcoin-community-developers-1441146317
209 2015-12-21 20:36:27 <silvaedium> You're still talking about docs with the OTC wiki isn't even functional?
210 2015-12-21 20:36:33 <silvaedium> Do you even understand the problem, hear?
211 2015-12-21 20:36:57 <Iriez> zookolaptop: that pull/1165 ....is that stating approval for gmaxwell's proposal? Even that im confused on because there is not a link or any statement of what the capacity increase actually is
212 2015-12-21 20:37:28 <sipa> Iriez: it links to greg's post
213 2015-12-21 20:37:48 <silvaedium> Bitcoin needs to get it's priorities straight and work on a system for dynamically updating it's priorities based upon the current goal. Not talk in abstraction and future plans while the main wiki that appeals to it's primary audiance isn't functional.
214 2015-12-21 20:37:52 <silvaedium> https://wiki.bitcoin-otc.com/wiki/Main_Page
215 2015-12-21 20:37:53 <silvaedium> Down
216 2015-12-21 20:37:54 <silvaedium> Fix it
217 2015-12-21 20:37:56 <silvaedium> Nao.
218 2015-12-21 20:38:11 <Iriez> oops! sorry, you are correct I see it at the bottom now
219 2015-12-21 20:38:21 <instagibbs> silvaedium, cut it out. It's ok to bundle your thoughts.
220 2015-12-21 20:38:24 <adam3us> see also this data on transaction volume trends and blocksize and demand elasticity http://rusty.ozlabs.org/?p=500 hopefully he'll update it
221 2015-12-21 20:38:57 <brg444> silvaedium AFAIK that's not the official wiki
222 2015-12-21 20:39:11 <brg444> silvaedium see the "-otc" part?
223 2015-12-21 20:39:14 <Iriez> sipa: do you feel it would be appropriate to state that the core maintainers wish for a fee market to develop?
224 2015-12-21 20:39:40 <Iriez> Or, at the least, that the consequences of not raising a blocksize will likely result in a fee market?
225 2015-12-21 20:39:41 <brg444> Iriez sorry to interject but don't you feel like a fee market is not already developing?
226 2015-12-21 20:39:46 <sipa> Iriez: i wish for an ecosystem that can deal with the reality of a limited block size
227 2015-12-21 20:39:58 <instagibbs> Iriez, Minimal Viable Consensus(MVC)
228 2015-12-21 20:40:05 <instagibbs> :P
229 2015-12-21 20:40:20 <Iriez> bgr444: Im not debating, only trying to probe for clear communications.
230 2015-12-21 20:40:38 <Iriez> but to answer your question, yes, the recent restriction of block space has started a fee market development.
231 2015-12-21 20:41:42 <silvaedium> https://www.youtube.com/watch?v=YuOBzWF0Aws&feature=youtu.be&t=19 <-- Relevant
232 2015-12-21 20:41:49 <brg444> that's my feeling as well. I'm unconfortable with referring to such things as some sort of "event"
233 2015-12-21 20:42:04 <zookolaptop> Iriez: yes, https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165 is stating support for gmaxwell's proposal. Yes, it fails to communicate that very well. :-(
234 2015-12-21 20:42:28 <sipa> zookolaptop: fails to communicate what very well?
235 2015-12-21 20:42:30 <zookolaptop> Sorry, let me be more specific -- it fails to make that clear to someone who doesn't have as much context and doesn't spend as much time reading.
236 2015-12-21 20:42:33 <adam3us> Iriez: see http://rusty.ozlabs.org/?p=500 for data about block size with graphs
237 2015-12-21 20:42:59 <zookolaptop> sipa: https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165 does not communicate its intent to a very wide audience.
238 2015-12-21 20:43:36 <Iriez> sipa: there's one thing that does bother me about using SW as a capacity increase that I've not really seen fully addressed. Perhaps you could help me. I understand the theoretical capacity increase, most of it which is seen in P2SH. But for regular transactions, it does not seem to offer much of a increase. Since the majority of the network is using non-P2SH transactions, wouldn't
239 2015-12-21 20:43:36 <Iriez> there not be much of a increase to system capacity considering this? Would not the system need to evolve with time, more P2SH transactions to exist befroe the capacity increase becomes more of a reality, less of a theory?
240 2015-12-21 20:44:06 <Iriez> zookolaptop: Thank you.
241 2015-12-21 20:44:09 <adam3us> Iriez: wallets will need to upgrade to benefit
242 2015-12-21 20:44:25 <sipa> Iriez: i ran a simulation on the existing bitcoin blockchain, and computed exactly what its size and virtual size under SW would be if all transactions were converted to segwit
243 2015-12-21 20:44:42 <sipa> Iriez: that is under the assumption that every wallet would have used segwit transactions from the start
244 2015-12-21 20:44:47 <morcos> zookolaptop: my thinking is that it doesn't need to.  it wil be important to be able to answer to a wider audience, what does this mean for us?  and we should work on that.  but right now its just fundamentally important to show that the developer community is united and has a plan
245 2015-12-21 20:44:53 <morcos> so we can stop going in circles
246 2015-12-21 20:44:54 <sipa> Iriez: it gives a 1.75x capacity factor in that case
247 2015-12-21 20:45:10 <Iriez> sipa, so essentially in laymans terms it would be a blocksize raise to 1.75mb
248 2015-12-21 20:45:22 <sipa> Iriez: yup
249 2015-12-21 20:45:23 <Iriez> I know thats not the correct way to look at it, b ut its the way most laymen will understand.
250 2015-12-21 20:45:34 <sipa> though there are many other benefits on the side
251 2015-12-21 20:45:57 <Iriez> I understand its compression (or perhaps reallocation) and not a raising of size.
252 2015-12-21 20:46:07 <zookolaptop> morcos: I think I agree about what's important. I *think* that I think that https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165 doesn't communicate about what's important to a wide audience.
253 2015-12-21 20:46:10 <sipa> oh no, it absolutely is raising the size :)
254 2015-12-21 20:46:20 <sipa> just in a backward compatible way
255 2015-12-21 20:46:26 <sipa> but i consider the size increase a side effect
256 2015-12-21 20:46:50 <Iriez> You are saying that blocks can be 1.75mb with SW?
257 2015-12-21 20:47:03 <sipa> yes
258 2015-12-21 20:47:04 <adam3us> Iriez: effective block size yes
259 2015-12-21 20:47:06 <Iriez> Or, rather, over 1mb?
260 2015-12-21 20:47:09 <sipa> yes
261 2015-12-21 20:47:17 <brg444> adam3us it'd be nice if major wallet providers would collaborate early on during the transition so that we're able to squeeze as much juice as possible out of the SW update when it does get implemented. I understand Gavin was sort-of defacto proxy for communication with industry.
262 2015-12-21 20:47:17 <sipa> it is a block size increase proposal, period
263 2015-12-21 20:47:47 <Iriez> Hrm, see, now I've been following this whole thing since day one, and even i did not understand that :/
264 2015-12-21 20:47:59 <adam3us> Iriez: with later improvements it should be able to get even more tps as well eg by soft-forking schnorr sigs into the easier upgradeability added by seg-wit
265 2015-12-21 20:48:11 <morcos> zookolaptop: well its going to be a process.  but at the start, at least for the developers, its something to keep us focused
266 2015-12-21 20:48:26 <sipa> Iriez: the trick is that the witness part is invisible to old nodes, and thus outside of the view of the old 1 mb block size limit
267 2015-12-21 20:48:42 <Iriez> That speaks poorly to the users. While im not a developer, im atleast 18 years in IT and a strong tech background, I could not ascertain that fact from all the discussions had.
268 2015-12-21 20:48:42 <sipa> Iriez: so all we need to do is make sure the excluding-witness part remains under 1 mb
269 2015-12-21 20:48:50 <Iriez> Is there a theoretical hard limit? Is that what the 4mb is?
270 2015-12-21 20:48:54 <sipa> yup
271 2015-12-21 20:49:00 <Iriez> Ok, fully clarified then :)
272 2015-12-21 20:49:16 <sipa> new blocksize is defined as part_without_witness + witness*0.25
273 2015-12-21 20:49:25 <sipa> that new block size remains limited to 1 MiB
274 2015-12-21 20:49:30 <sipa> eh, 1 MB
275 2015-12-21 20:49:56 <Iriez> So basically, its like SW is a whole new block space, combined with the old block space (layman)
276 2015-12-21 20:50:29 <morcos> Iriez: thats exactly how i'd describe it
277 2015-12-21 20:50:57 <sipa> Iriez: i felt i didn't have the time to properly explain in HK, due to time pressure at that point in the talk :)
278 2015-12-21 20:51:04 <brg444> isn't it more like a rearrangement of block size content so that we can fit more in the same space...?
279 2015-12-21 20:51:10 <sipa> brg444: nope
280 2015-12-21 20:51:32 <sipa> brg444: we just move some of the block content to a place where it isn't yet counted
281 2015-12-21 20:51:45 <Iriez> Sometimes info diagrams are essential
282 2015-12-21 20:51:47 <brg444> ah right.
283 2015-12-21 20:51:49 <sipa> (and where it is also effectively cheaper to the ecosystem, due to better prunability)
284 2015-12-21 20:51:51 <Iriez> I think in the case of SW, this is one of those scenario's.
285 2015-12-21 20:51:59 <AaronvanW> sipa: why does jl2012 expect only +-1.25MB block size?
286 2015-12-21 20:52:07 <Iriez> If we had a visualization of blocksize, it would help users understand it.
287 2015-12-21 20:52:14 <AaronvanW> https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg03116.html
288 2015-12-21 20:52:16 <brg444> maybe we ought to hire Peter R for that, he makes nice drawings :)
289 2015-12-21 20:52:23 <Iriez> lol
290 2015-12-21 20:52:28 <Iriez> I somehow think that wont happen.
291 2015-12-21 20:52:41 <instagibbs> just take something from his paper without attribution, im sure he wont mind
292 2015-12-21 20:52:47 <AaronvanW> where does this difference between 1.25 and 1.75 come from?
293 2015-12-21 20:53:26 <sipa> AaronvanW: he makes an assumption that not everyone will upgrade, which is certainly true
294 2015-12-21 20:53:41 <sipa> AaronvanW: but i like to see it from the other side: exactly the people who upgrade do get the advantage
295 2015-12-21 20:53:49 <Eliel_> so, short term he's right, long term, not so much.
296 2015-12-21 20:53:56 <AaronvanW> sipa: oh is that the only difference?
297 2015-12-21 20:54:30 <Eliel_> fee pressure will convince more people into using SW transactions.
298 2015-12-21 20:54:36 <sipa> AaronvanW: even if i'm the only wallet user in the world who starts using SW, i do get this 1.75x capacity increase for myself (as in: i will be able to do 1.75 times as many transactions as others for the same cost)
299 2015-12-21 20:55:08 <Iriez> sipa: do you feel that restriction on blockspace could be alliveated if 3rd party services (wallet providers, exchanes etc) upgrade and make it mandatory to switch to SW tx's ?
300 2015-12-21 20:55:10 <AaronvanW> righyt
301 2015-12-21 20:55:39 <sipa> Iriez: what restriction?
302 2015-12-21 20:55:44 <brg444> Iriez It's kind of a no brainer for them since they have to pay less fees
303 2015-12-21 20:55:57 <Iriez> sipa: if blockspace is getting full
304 2015-12-21 20:56:09 <Iriez> this is assuming SW is live.
305 2015-12-21 20:56:42 <Iriez> Sorry for asking a simple question, but im trying to black and white the situation with simplicity for understanding.
306 2015-12-21 20:56:58 <sipa> Iriez: blockspace is supply and demand; i think it will inevitably grow to fill up
307 2015-12-21 20:57:18 <sipa> Iriez: if the block size limit would have been 2 MB from the start, average blocks would be much larger already, IMHO
308 2015-12-21 20:57:28 <sipa> (i have no evidence for that, just my view)
309 2015-12-21 20:57:59 <Iriez> Yes, I understand, what I was just asking is if you believed that there would be a reaction by the community if blockspace starts filling up. If there is a large percentage of people not converted to SW tx's on the PSP's, wallet providers, exchanges etc
310 2015-12-21 20:58:23 <Iriez> Do you feel that they would convert to SW to help allievate pressure
311 2015-12-21 20:58:29 <adam3us> sipa: i think it is not an unreasonable claim because there are many more transactions offchain than onchain. maybe > 90% are offchain. the decision to go offchain or onchain is itself an economic decision.
312 2015-12-21 20:59:16 <Iriez> Or perhaps, do you feel that users would put pressure on these companies to convert to SW tx's to help allievate pressure.
313 2015-12-21 20:59:19 <sipa> Iriez: if existing payment mechanisms fill up the chain with no-witness txn, then new ones can pop up that undercut their fee rates by using SW :)
314 2015-12-21 20:59:34 <Iriez> Yes, so there is a economic incentive, so it is likely.
315 2015-12-21 20:59:35 <adam3us> Iriez: there are a number of wallets with large user bases, and hosted wallets with large user bases. if they upgraded all at once it may move the bulk in one go.
316 2015-12-21 20:59:47 <Iriez> adam3us: my thoughts too.
317 2015-12-21 21:00:04 <adam3us> Iriez: and paritcularly on the hosted side thats easier in a sense because it's a backend upgrade
318 2015-12-21 21:00:09 <Iriez> I am just trying to grasp policy decision making process and how it effects the wider economy.
319 2015-12-21 21:00:27 <Iriez> I dont think like these guys do, so its essential to understand it :)
320 2015-12-21 21:01:07 <Iriez> adam3us: yes, im thinking the blockchain.info's, coinbases, etc. p2p will come slower but surely over time.
321 2015-12-21 21:02:05 <Iriez> sipa: but SW does not decrease fee per tx, it just allows more to fill into the tx, yes?
322 2015-12-21 21:02:40 <Iriez> this would help with services that combine lots of inputs/outputs into one tx, but not for joe blow making a single tx, right?
323 2015-12-21 21:02:53 <sipa> Iriez: under fee pressure conditions, the economically optimal strategy for miners is to maximize fee per virtual size
324 2015-12-21 21:02:54 <brg444> Iriez why slower? as you've said they already have an economic incentive to do so. it'd be wise for them to move forward ASAP
325 2015-12-21 21:03:08 <sipa> Iriez: virtual size of a sw transaction is lower than that of an equivalent normal transaction
326 2015-12-21 21:03:46 <Iriez> brg444: a server who can upgrade and upgrade a million users wallets at once is a lot faster than p2p propagation. Think localized software wallets vs hosted wallets.
327 2015-12-21 21:03:57 <moa> brg444: " It's kind of a no brainer for them since they have to pay less fees" <--- here is the key insight into the incentive why/when fullnodes will consent to run larger blocksizes
328 2015-12-21 21:04:14 <Iriez> sipa: when you say virtual size, you mean in the mempool?
329 2015-12-21 21:04:25 <moa> when fees get larger enough for their OWN transactions, they will run larger blocks
330 2015-12-21 21:04:31 <brg444> Iriez ah sorry I read that wrong, didn't see the "p2p" part
331 2015-12-21 21:04:39 <brg444> I agree 100%
332 2015-12-21 21:04:41 <adam3us> Iriez: no its a concept to prevent wasteful use of the seg-witness data
333 2015-12-21 21:04:43 <sipa> Iriez: no, i mean the base_size + witness_size * 0.25 formula
334 2015-12-21 21:04:52 <Iriez> ah, ok.
335 2015-12-21 21:07:12 <Iriez> My technical questions have been fully clarified, but unfortunately the issue of consensus mechanisms still feels at a stand still. Is there any plans among the maintainers to clarify this stance in a attempt to push it into light? Its very much heavy on the communities mind.
336 2015-12-21 21:07:58 <Iriez> It seems that sipa at least feels its not the maintainers job to come up with consensus mechanisms. Is this what other maintainers feel too?
337 2015-12-21 21:08:54 <sipa> Iriez: well, it's a soft fork; it doesn't require all software to agree to it
338 2015-12-21 21:09:02 <sipa> Iriez: a majority of hashrate is enough
339 2015-12-21 21:09:34 <moa> Iriez: https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165 this is what developer consensus looks like ... what is it you do not understand about the "mechanism"?
340 2015-12-21 21:09:57 <moa> it sounds like you want an explanation of the social engineering of an open source project ?
341 2015-12-21 21:11:18 <Iriez> moa: sipa has stated that it is not the maintainers job to create consensus mechanisms. The community (I feel, from my observations) feels differently on the subject. Since its such a critical subject, I felt the need to provide more clarity to the issue.
342 2015-12-21 21:11:21 <brg444> very happy to see Cory Fields in there, I always wondered how he managed to stay outside of the whole debate all this time.
343 2015-12-21 21:12:11 <instagibbs> brg444, he's smarter ;)
344 2015-12-21 21:12:20 <Iriez> moa: when a core maintainer hinges his decision on 'consensus' but then has no real clear metric of what 'consensus' is, then i see that as a severe problem.
345 2015-12-21 21:12:30 <brg444> instagibbs I guess so!
346 2015-12-21 21:12:30 <Iriez> Not the problem being with sipa, but being with the tools at hand.
347 2015-12-21 21:12:59 <Iriez> The issue is circular and always circles back to the core maintainers.
348 2015-12-21 21:13:09 <brg444> Iriez Consensus metric seems very clear to me: what rules are being enforced by network peers
349 2015-12-21 21:13:26 <Iriez> thats consensus on current running software, not proposed changes
350 2015-12-21 21:13:33 <Iriez> We were discussing making changes based on consensus.
351 2015-12-21 21:13:34 <adam3us> Iriez: i thought it was clear in case of a hard-fork a proposal would be made and to try to get wide ecosystem views.
352 2015-12-21 21:13:46 <Iriez> adam3us: and how is that achieved?
353 2015-12-21 21:13:52 <instagibbs> Iriez, if there was some ungameable metric it would probably be in the consensus protocol itself. There are none.
354 2015-12-21 21:15:26 <Iriez> developers are very conservative by nature, and need to be convinced of consensus before implementing changes, yet there are no tools to widely measure consenses of proposed changes. This leads to stagnation.
355 2015-12-21 21:15:51 <Iriez> If the users really are the ones with power, then surely their vote matters.
356 2015-12-21 21:16:21 <AdrianG> Iriez: clearly its just going to be bitcoin business vs bitcoin miners.
357 2015-12-21 21:16:24 <Iriez> (please dont ramble about voting via which softare to use, i understand that, im talkikng proposals, not current)
358 2015-12-21 21:16:54 <AdrianG> somehow im almost certain small end users aren't even in consideration.
359 2015-12-21 21:17:08 <brg444> AdrianG define small
360 2015-12-21 21:17:11 <moa> Iriez: it's not really that mysterious, the 'metric' is the same as it was since satoshi started publishing code ... if enough peers are copying your code, building on it and ultimately running it.
361 2015-12-21 21:17:35 <Iriez> moa: you are forgetting the power that the core maintainers currently yield.
362 2015-12-21 21:17:44 <Iriez> What they propose, via code, is what ultimately gets run
363 2015-12-21 21:17:56 <Iriez> If you disagree with this statement you are ignoring the current reality of the system.
364 2015-12-21 21:18:01 <moa> they have only as much power as people who follow them ...
365 2015-12-21 21:18:08 <Iriez> The majority hashpower has given their vote to the maintainers.
366 2015-12-21 21:18:17 <jcorgan> this is starting to get circular
367 2015-12-21 21:18:20 <Iriez> That means that what the maintainers decide is what will be ran.
368 2015-12-21 21:18:31 <Iriez> Starting? It has been, which is what i've been saying the whole time. The issue is circular.
369 2015-12-21 21:18:38 <Iriez> It always comes back to the maintainers.
370 2015-12-21 21:18:39 <jcorgan> no, this discussion is
371 2015-12-21 21:19:03 <AdrianG> moa: in the end its miners who matter most, because they are the ones securing the network.
372 2015-12-21 21:19:15 <Iriez> Correct. The issue is too. And will remain so until the core maintainers clarify the situation.
373 2015-12-21 21:19:21 <AdrianG> why would anyone prefer a less secure network? it would have to be a dramatic change.
374 2015-12-21 21:19:28 <Iriez> AdrianG gets it :)
375 2015-12-21 21:19:48 <brg444> AdrianG do you think miners are interested in mining worthless coins?
376 2015-12-21 21:20:04 <AdrianG> brg444: are you interesed in security-less network?
377 2015-12-21 21:20:17 <AdrianG> or miner-less network, rather.
378 2015-12-21 21:20:18 <moa> i think the discussion has gone outside development into 'social attacks' and the the thicket there #bitcoin-dev -> #bitcoin-discuss
379 2015-12-21 21:20:45 <Iriez> moa: You are correct I believe.
380 2015-12-21 21:21:55 <AdrianG> social attacks?
381 2015-12-21 21:22:11 <Iriez> I dont agree with social attacks, but I believe it is no longer technical discussion.
382 2015-12-21 21:22:53 <brg444> Agreed too. Moved the discussion to #bitcoin if you care to pursue it AdrianG
383 2015-12-21 21:23:35 <Iriez> If it does not involve maintainers, im not interested :)
384 2015-12-21 21:24:09 <AdrianG> they aren't interested in what you have to say either, it seems, Iriez.
385 2015-12-21 21:24:30 <brg444> maintainers are a red herring ;)
386 2015-12-21 21:42:31 <Iriez> Is there any interest in allowing nodes the capability to vote on BIP's? Similar to the way we previously voted for BIP's on blocksize, but allowing nodes to vote? Would this be a interesting metric that could help determine users consensus on the issues? I only ask because I am a alturistic node operator.
387 2015-12-21 21:43:41 <instagibbs> Iriez, spooling up thousands of fakes nodes is easy. You'd need proof-of-stake voting or something similar. It's been discussed a decent amount.
388 2015-12-21 21:44:55 <Iriez> instagibbs: My thought process is that nodes could implement a identifying signature that could be verified with a function(s) within the node. That way you could determine if the node is real or just a spoofed proxy.
389 2015-12-21 21:45:37 <Iriez> For example, if I asked a node for a random piece of data only the node could have, with a identifier flag, the node could respond with that piece of data plus the identifier flag.
390 2015-12-21 21:47:12 <Iriez> If 1000 nodes respond with the same signature, then you would count those 1000 votes as 1.
391 2015-12-21 21:47:21 <instagibbs> Why would they not just have 1000 different sigs...
392 2015-12-21 21:47:39 <instagibbs> s/sigs/keys/g
393 2015-12-21 21:47:39 <Iriez> Because thats what the random piece of data requested for was.
394 2015-12-21 21:48:05 <instagibbs> How does that prove identity
395 2015-12-21 21:48:25 <instagibbs> ok this might be #bitcoin material if you wanna continue
396 2015-12-21 21:48:41 <Iriez> np, I'll think it through more first, perhaps this is more game-able than I thought :)
397 2015-12-21 21:48:51 <instagibbs> search for proof-of-storage
398 2015-12-21 21:49:32 <Iriez> thank you, I will!
399 2015-12-21 21:50:27 <instagibbs> cheers
400 2015-12-21 22:19:25 <btcdrak> In case anyone missed it https://bitcoin.org/en/bitcoin-core/capacity-increases