2017-12-03-overview-and-logs-for-the-dev-meeting-held-on-2017-12-03.md 16.7 KB
Newer Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2017-12-03
summary: Discussion of open PRs and issues, Bulletproofs, Monero Research Lab, RNGs, 0MQ, and miscellaneous
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---

# Overview  

An overview can be found on [MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-12-03).  

# Logs  

**\<fluffypony>** 1. Greetings  
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting  
**\<fluffypony>** 3. Code + ticket discussion / Q & A  
**\<fluffypony>** 4. Any additional meeting items  
**\<fluffypony>** 5. Confirm next meeting date/time  
**\<fluffypony>** so 1. Greetings  
**\<fluffypony>** hi  
**\<ArticMine>** Hi  
**\<fluffypony>** luigi1111 (if you're back) / smooth / hyc / moneromooo etc.  
**\<moneromooo>** here  
**\<gingeropolous>** etc here  
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting  
**\<fluffypony>** lots of stuff  
**\<sarang>** MRL has working Java test code for complete multi-output bulletproofs  
**\<sarang>** It's being ported over to C++  
**\<moneromooo>** (not the multi output one)  
**\<sarang>** The Java part is complete  
**\<moneromooo>** Sorry, I meant just about the port ^\_^  
**\<sarang>** Discussions are ongoing about if/how the fee structure would be modified to prevent large-output txn DoS  
**\<fluffypony>** what's wrong with per-byte fees?  
**\<sarang>** You can load a txn with tons of outputs  
**\<sarang>** but verification is linear in the # of outputs  
**\<dEBRUYNE>** fluffypony: verification is linear, whilst size is log  
**\<dEBRUYNE>** basically  
**\<sarang>** So for low fees you can force the network to verify  
**\<fluffypony>** ah ok, makes sense  
**\<sarang>** So we need to incentivize the use of aggregate BPs while basically scaling the fee to the number of outputs etc.  
**\<sarang>** But things are looking good  
**\<sarang>** Verification is still quite efficient  
**\<sarang>** and with the multi-output setup, space savings are unreal  
**\<moneromooo>** In fact, the per byte fee needs to be done first, as per kB is way too coarse for this.  
**\<sarang>** Yeah a single output BP is about 704 bytes, while a 2-output BP is something like 768 bytes  
**\<sarang>** (including commitments)  
**\<sarang>** it's just too damn good  
**\<fluffypony>** nice  
**\<dEBRUYNE>** For clarification, a single output is currently \~ 6 kB, whereas a 2-output is \~ 12 kB  
**\<* hotoatmeal** was about to ask  
**\<sarang>** So we'll continue moving forward with porting and testing  
**\<manifest>** serhack here?  
**\<dEBRUYNE>** A typical Monero transaction has 2 ins + 2 outs  
**\<serhack>** yep manifest  
**\<manifest>** i was wondering who was the m8 that was gonna work on the go-library since i started on it myself a little bit swell  
**\<fluffypony>** dEBRUYNE: this would also be a major cost-saving for pool payments  
**\<fluffypony>** manifest: we're in a meeting  
**\<sarang>** For reference, the size of an M-output BP is 32\*(2\*log(64\*M)+9) bytes (this doesn't count the amount commitments)  
**\<sarang>** add 32 bytes for each of the M amount commitments if you want to include them  
**\<sarang>** (log is base 2)  
**\<rehrar>** manifest you can hop on mattermost.getmonero.org. Serhack is also there and you guys can PM and chat so as not to disrupt the meeting. Thanks. :)  
**\<ArticMine>** I have to give some thought to the fees to deal with  the verification issue  
**\<fluffypony>** ok so beyond BP is there anything else worth noting?  
**\<sarang>** We do require a power of 2 in the # of outputs  
**\<pigeons>** So sometimes you just create an additional change output, or how do you cause always a power of 2?  
**\<sarang>** We'll need to either pad with dummy outputs or split into power-of-2 proofs  
**\<ArticMine>** Split the change into two tx  
**\<pigeons>** OK  
**\<sarang>** The dummy output doesn't need to actually represent anything  
**\<sarang>** It just needs to be there for the proof  
**\<sarang>** It can be amount 0  
**\<ArticMine>** that will work also  
**\<sarang>** Anyway, that's my 3 cents  
**\<luigi1111>** Better to split  
**\<luigi1111>** Space is cheap gp  
**\<luigi1111>** Cpu is expensive\*  
**\<ArticMine>** We will have to price cpu  
**\<moneromooo>** There's a possible optimization for "filler" outs AIUI.  
**\<luigi1111>** Probably not as good as not using them :)  
**\<sarang>** There aren't any security proofs for a non-power-of-2 proof  
**\<moneromooo>** I was led to think it was not inherent in the scheme, though ?  
**\<sarang>** It is  
**\<moneromooo>** aw...  
**\<sarang>** At least for right now  
**\<sarang>** There's a recursive step that split arrays in half  
**\<ArticMine>** The issue I see is that the penalty only prices space  
**\<sarang>** The authors of the paper are looking into a generalization, but it doesn't exist yet  
**\<luigi1111>** That's interesting  
**\<fluffypony>** ok so  
**\<fluffypony>** anything else from the last two weeks worth noting?  
**\<sarang>** suraeNoether is completing review for multisig  
**\<sarang>** He is unable to be here today  
**\<Gdhhyfjjs467>** Has a code freeze date for the next for been set yet?  
**\<fluffypony>** Gdhhyfjjs467: yeah we'll be branching towards the end of the month  
**\<fluffypony>** assuming our comfort levels are ok  
**\<rehrar>** This was discussed briefly in MRL channel with the idea that if BPs are not too far off, would it be worth delaying the next hard fork by a couple months so it can be in?  
**\<dEBRUYNE>** The plan is to include multisig right?  
**\<dEBRUYNE>** \^ fluffypony  
**\<luigi1111>** Yes  
**\<fluffypony>** no need to delay the hard fork  
**\<luigi1111>** I don't think the upcoming fork does anything useful though  
**\<luigi1111>** So there's that  
**\<fluffypony>** if BP is ready it'll go into the Sept fork  
**\<dEBRUYNE>** Should we fork if there's nothing to fork for?  
**\<luigi1111>** Who knows ^\_^  
**\<fluffypony>** luigi1111: consistency, then  
**\<fluffypony>** well, that's what we committed to with the fork schedule  
**\<fluffypony>** "even if it's just bumping the block version number"  
**\<dEBRUYNE>** Sure, but didn't we also discuss slowing things down once the ecosystem got bigger?  
**\<moneromooo>** We did not commit to an exact fork schedule.  
**\<luigi1111>** And who is this we :)  
**\<moneromooo>** I, at least, did not :P  
**\<hotoatmeal>** does the wallet release schedule track the protocol fork schedule exactly?  
**\<hotoatmeal>** or do they have different cadences  
**\<moneromooo>** The wallet needs to update for a fairly large subset of consensus changes.  
**\<pigeons>** the wallet-cli and wallet-rpc are included with the daemon release that supports the fork  
**\<moneromooo>** So it's convenient to release at the same time.  
**\<fluffypony>** dEBRUYNE: I don't think we're at a point where we can go to annual  
**\<moneromooo>** Besides, the wallet and daemon rely on the same libs.  
**\<rehrar>** Isn't ZMQ also in the new release? Or has that been there for a while now?  
**\<fluffypony>** yes ZMQ is in the new release  
**\<moneromooo>** There's some of it in, but some of it's still missing.  
**\<pigeons>** there is some support for zmq over rpc, and more is comming, like tx/block notify and some changes to the existing zmq rpc  
**\<pigeons>** \*rpc over zmq  
**\<hotoatmeal>** moneromooo: yeah, mainly thinking about when I need to spend time to get those two memwipe patches (and the third I haven't written yet) reviewed/merged  
**\<pigeons>** the notify is what the people i hear from are waiting for, and tewinget told me a few weeks ago he's got the basics worked out  
**\<rehrar>** Are we still waiting on him for stuff?  
**\<moneromooo>** There's a patch waiting on changes IIRC.  
**\<moneromooo>** (for 0mq)  
**\<rehrar>** *sigh* tewinget, can you please get this stuff done? Seriously.  
**\<moneromooo>** Especially as I think some of the large pool speedups were lost.  
**\<moneromooo>** (not 100% sure)  
**\<hotoatmeal>** is there a way to detect that the network has forked, and your client hasn't gone with it?  
**\<moneromooo>** Kinda.  
**\<hotoatmeal>** my local daemon got left behind on the last one, because I forgot to update  
**\<fluffypony>** you can make an educated guess  
**\<hotoatmeal>** cue colorful headscratching  
**\<moneromooo>** Current daemon should moan if it sees blocks with a higher version than what it knows about.  
**\<fluffypony>** and there's auto-update records that notify  
**\<moneromooo>** The block verison thing is a bit vulnerable to someone mining a bad block on purpose to make you think there's been a fork though.  
**\<fluffypony>** yeah  
**\<moneromooo>** Losing 10 monero in the process or whatever it is :)  
**\<fluffypony>** ok let's move it along, then  
**\<fluffypony>** 3. Code + ticket discussion / Q & A  
**\<fluffypony>** are there any issues that could do with some input / resolution?  
**\<moneromooo>** The handful of oldest ones.  
**\<moneromooo>** The PRNG one.  
**\<moneromooo>** ones.  
**\<moneromooo>** For multisig, I think it's pretty much ready to go in, stoffu's done a lot of careful reviewing.  
**\<fluffypony>** ok - what's the blocker on switching to the Bitcoin one?  
**\<hotoatmeal>** moneromooo: what still needs doing / deciding on your part of the memwipe ones, and how can I help there?  
**\<moneromooo>** Mainly deciding whether we want to, or not.  
**\<moneromooo>** And bitcoin has two RNGs, the one I ported, and one that's closer to what we have. so there's the possibility of entropy attrition using only the "good" one.  
**\<moneromooo>** hotoatmeal: the only thing left IIRC was switching from std::vector\<char> to std::unique\_ptr\<char[]> and I feel more confident getting it right with vector.  
**\<moneromooo>** Other than that, nothing I think.  
**\<fluffypony>** moneromooo: by "good" one you mean the ported one?  
**\<moneromooo>** That can be done later by someoine who's familiar with how the refcounting works with operators though.  
**\<moneromooo>** Yes. The one that uses getrandom, etc.  
**\<fluffypony>** ok so I think if they haven't hit entropy attrition problems over the past few years it's unlikely we will - thoughts?  
**\<moneromooo>** Let me rephrase:  
**\<moneromooo>** Bitcoin has two RNGs: a good one using HW, and a... hmmm, less good ? one similar to our keccak based one  
**\<moneromooo>** Using the keccak based one does not deplete entropy nearly as fast as using the good one. Monero can use a lot of entropy (eg, range proofs).  
**\<moneromooo>** Therefore, I'm wondering whether using the good one all the time is worse than not.  
**\<hotoatmeal>** moneromooo: ok, I'll pick up the vector vs unique\_ptr part of that later this month  
**\<moneromooo>** Thanks  
**\<fluffypony>** ok so what if we used the good one for critical stuff like privkey generation  
**\<fluffypony>** and output selection  
**\<hotoatmeal>** and if you give me some pointers, can look at whatever that refcounted operators thing is in Jan  
**\<fluffypony>** and the stream one for range proofs  
**\<moneromooo>** Well, if I knew that, I'd know the answer to my question, since they're opposites.  
**\<moneromooo>** Anyway, to go back to multisig, I tihnk it's good to go now. If you haven't yet reviewed it, and want to do so, do so now.  
**\* hotoatmeal** drops out  
**\<fluffypony>** ok  
**\<fluffypony>** 4. Any additional meeting items  
**\<moneromooo>** When do we want bulletproofs on testnet ?  
**\<dEBRUYNE>** Tomorrow!  
**\<fluffypony>** hah hah  
**\<moneromooo>** A day may be a bit short to get people to update in time.  
**\<fluffypony>** are we going to wait for the multi output stuff?  
**\<sarang>** I think we should  
**\<moneromooo>** Not sure. This is not quite finished (multiple of 2 requirement), and has a non trivial impact on fees.  
**\<sarang>** Hrmm true, the fee thing  
**\<sarang>** :/  
**\<moneromooo>** And I'd really, really like to get smaller txes double plus quick.  
**\<fluffypony>** ok so how would this work  
**\<ArticMine>** A lot of people do  
**\<sarang>** In case it's relevant, every single-output proof is still a valid multiproof  
**\<moneromooo>** That's nice.  
**\<sarang>** (provided we define the Gi and Hi in the same order)  
**\<sarang>** (not sure if my extended code addressed that, will check)  
**\<moneromooo>** So, no clear votes for or against. Except me ^\_^ so that's 100% of expressed votes :P  
**\* sarang** checks the math on that  
**\<fluffypony>** moneromooo: I asked how it would work  
**\<moneromooo>** The fork ? I imagine similar to rct. Allow bulletproofs at fork f, optionally disallow borromean at f+1.  
**\<moneromooo>** (the code currently does not do that second part)  
**\<moneromooo>** That might become a bit more complicated if we start allowing aggregated proofs at f+1.  
**\<moneromooo>** But not very much.  
**\<dEBRUYNE>** so moneromooo, you'd like to start with single output right? And then eventually switch to multioutput  
**\<moneromooo>** Yes.  
**\<rehrar>** Sorry if this was answered, but is there an ETA on multioutput port from Java?  
**\<moneromooo>** No. It doesn't appear to be a lot of work though.  
**\<fluffypony>** so then txs with more than 1 output would use borromean?  
**\<moneromooo>** No. They'd use two bulletproofs.  
**\<sarang>** yup  
**\<rehrar>** Which is still a savings.  
**\<sarang>** Still great space savings  
**\<sarang>** And no DoS issues  
**\<dEBRUYNE>** 2 bulletproofs is 1.3 kb give or take right?  
**\<fluffypony>** ok  
**\<dEBRUYNE>** And we can keep our current fee structure  
**\<sarang>** dEBRUYNE: yes  
**\<moneromooo>** Most of it, in fact. Txes are ~2.2 kB.  
**\<rehrar>** I think that's worth it. And then it can be enhanced even further with multioutput later. But the immediate savings would be appreciated.  
**\<rehrar>** And gives time for the fee dislogue  
**\<fluffypony>** and what's our confidence level like in this? like is it March-fork-worthy?  
**\<rehrar>** Dialogue\*  
**\<moneromooo>** Well, we can know better if we fork in a couple days on testnet :)  
**\<ArticMine>** I have an idea on the fee issue  
**\<rehrar>** It can be deployed to testnet asap no.  
**\<rehrar>** ?  
**\<moneromooo>** That's what I'm asking about, yes.  
**\<fluffypony>** could we fork testnet this coming weekend?  
**\<moneromooo>** Works for me. Gives time for review.  
**\<rehrar>** Exciting!  
**\<sarang>** Yes and the code should definitely be reviewed by others  
**\<endogenic>** who?  
**\<endogenic>** if you had your pick  
**\<JollyMort[m]>** could someone do me a favor and send me the log of this channel from 2017-04-18?  
**\<sarang>** Ideally andytoshi since he's a paper author  
**\<moneromooo>** If I had my pick...  
**\<sarang>** suraeNoether  
**\<fluffypony>** Satoshi  
**\<endogenic>** fluffypony: on it  
**\<sarang>** Someone who digs the maths  
**\<Gdhhyfjjs467>** So Evan duffield?  
**\<dEBRUYNE>** luigi1111 I guess  
**\<endogenic>** vtnerd hyc fyi  
**\<moneromooo>** Oh yeah, luigi1111 is a good one.  
**\<rehrar>** Let's just get all hands on deck for this?  
**\<endogenic>** ok that means you too rehrar  
**\<Gdhhyfjjs467>** Lol jk. I like andytoshi idea  
**\<sarang>** I'm sure we'll find additional optimizations... I know for a fact my implementation of scalar operations into vectors could be refactored  
**\<rehrar>** I will understand none of it, but I'll look at it and either nod approvingly or cringe based on a coin toss.  
**\<sarang>** but I didn't in Java in order to keep it clean and understandable  
**\<endogenic>** i move to instate rehrar as new RNG  
**\<moneromooo>** The slice op ? Yes, but I don't think it takes much time compared to the muls.  
**\<sarang>** Random Nod Generator?  
**\<sarang>** Well and operations involving many vector ops could run a single loop per element, instead of per operation  
**\<sarang>** but they're generally fast and it makes things clean  
**\<sarang>** I'm not a huge fan of sacrificing clarity for a tiny speedup  
**\<sarang>** I'd like to chat with moneromooo post-meeting about our basepoint selection, to ease the transition into multiproofs later  
**\<sarang>** For those who want to compare code to paper, this is the paper: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf  
**\<moneromooo>** I pushed the patch as 2883 if people want to start reviewing ^\_^  
**\<rehrar>** Can I make a Reddit post calling devs to review it?  
**\<moneromooo>** Reddit.. devs ?  
**\<dEBRUYNE>** \^ that lol  
**\<rehrar>** :P nvm then  
**\<dEBRUYNE>** The people able to review it will be watching Github  
**\<endogenic>** rehrar: answer is in the question :P  
**\<fluffypony>** oh  
**\<fluffypony>** I guess meeting ~done  
**\<fluffypony>** 5. Confirm next meeting date/time  
**\<fluffypony>** Sunday the 17th