2019-06-16-logs-for-the-dev-meeting-held-on-2019-06-16.md 13.3 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
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2019-06-16
summary: Development status, Code & ticket discussion, payment ID, CLSAG, and miscellaneous
tags: [dev diaries, core, crypto]
author: el00ruobuob / rehrar
---

# Logs  

**\<rehrar>** Meeting time! Who all is here?  
**\<rbrunner>** Hi all  
**\<hyc>** hey  
**\<fullmetalScience>** Hi  
**\<dEBRUYNE>** Here  
**\<rehrar>** 2. Brief review of what's been completed since the previous meeting  
**\<hyc>** v0.14.1.0 is out in the world  
**\<rbrunner>** CLI so far, yes ...  
**\<rehrar>** so I hear. And I even hear deterministic builds are doing their thing ok  
**\<jtgrassie>** hi  
**\<hyc>** they are being deterministic now, yes  
**\<dEBRUYNE>** Some small improvements still for deterministic builds, but I'd argue it was a excellent first round :P  
**\<rehrar>** nothing left to be done on the CLI front then for this little release?  
**\<rehrar>** but then also, looking to the next release, what's going on, do we know?  
**\<rehrar>** for 0.15  
**\<rbrunner>** little release is actually a pretty big release  
**\<rbrunner>** feature-wise  
**\<hyc>** there may be a few small bug reports for v0.14.1. might want a v0.14.1.1  
**\<dEBRUYNE>** I think the intention was to release it way earlier this time, because we can already add all the consensus changes early on  
**\<dEBRUYNE>** Unless CLSAG is also going to go in I guess  
**\<moneromooo>** It'll depend on whether it gets a review I think.  
**\<hyc>** Is 0.15 the October release?  
**\<moneromooo>** (in time)  
**\<rehrar>** sarang suraeNoether, can you speak to the potential timeline of review for CLSAG?  
**\<dEBRUYNE>** hyc: Yeah  
**\<rehrar>** dsc\_ selsta dEBRUYNE anything from GUI?  
**\<dEBRUYNE>** hyc: So we have about four months left I guess  
**\<dEBRUYNE>** GUI v0.14.1.0 has been tagged and fluffypony is working on the builds  
**\<hyc>** so when are we expecting to freeze 0.15 ?  
**\<dEBRUYNE>** rehrar: Some new stuff for the GUI:  
**\<dEBRUYNE>** - White theme  
**\<dEBRUYNE>** - Addressbook redesign  
**\<dEBRUYNE>** - History redesign  
**\<dEBRUYNE>** - Trezor and Ledger Nano X support  
**\<dEBRUYNE>** - Fiat price conversion  
**\<dEBRUYNE>** - macOS fullscreen support  
**\<dEBRUYNE>** Also an update checker + Hindi translation  
**\<dEBRUYNE>** And xiphon did a lot of work on improving the communication between the (integrated) daemon and the GUI  
**\<rehrar>** oooooh. Looks juicy. thanks dEBRUYNE  
**\<rehrar>** so it'll be faster?  
**\<dEBRUYNE>** hyc: I guess that is going to depend on whether we want to add CLSAG. If not, we could do a first 0.15 release after RandomX has been merged (e.g. in August)  
**\<dEBRUYNE>** And then another point release a month before the fork  
**\<dEBRUYNE>** rehrar: Yes and less 'laggy'  
**\<moneromooo>** Does someone want to review the share-rpc (pay for RPC service) branch ? :)  
**\<moneromooo>** It goes well with a CPU friendly PoW...  
**\<hyc>** I may take a look after I get back from konferenco  
**\<rehrar>** I assume we don't have any core team here?  
**\<moneromooo>** \\o/  
**\<rehrar>** but if not, we can still kind of talk about Payment ID stuff  
**\<dEBRUYNE>** Btw moneromooo, you already coded up a rough implementation of CLSAG right?  
**\<rehrar>** which is number 4.  
**\<moneromooo>** Yes.  
**\<moneromooo>** Well, sarang did, and I plugged it in.  
**\<dEBRUYNE>** rehrar: That's kind of my fault, I forgot to ping them in advance (I did earlier today, but probably too late :/)  
**\<dEBRUYNE>** Anyway, we can still discuss it, as there is plenty of opinions on the meta ticket  
**\<hyc>** rough? is it something you'd deploy for real, and what we'd submit to auditors to review?  
**\<moneromooo>** Both, assuming the review passes.  
**\<hyc>** ok  
**\<dEBRUYNE>** hyc: With 'rough' I kind of meant that, as far as I could see, it wasn't fully finished yet  
**\<moneromooo>** If you have suggestions for changes, go for it.  
**\<dEBRUYNE>** moneromooo: I just thought it wasn't fully finished yet, if it is I stand corrected :-P  
**\<moneromooo>** Well, I don't know what you've seen before, but AFAIK it is finished now, unless comments.  
**\<rehrar>** alright, let's discuss the whole PID thing then, if we can, with the people represented here giving their opinions as well.  
**\<dEBRUYNE>** I see, thanks for clarifying  
**\<rehrar>** dEBRUYNE: is correct that actually  many of core had made their opinions known on the meta discussion  
**\<rehrar>** can you link that real fast dEBRUYNE ?  
**\<moneromooo>** Did any exchange/merchant switch from long payment ids since... half a year ago, say ?  
**\<dEBRUYNE>** I think some smaller ones did, but the big ones (Bittrex, Bitfinex, Binance) did not  
**\<dEBRUYNE>** rehrar: sure  
**\<dEBRUYNE>** smooth: https://github.com/monero-project/meta/issues/356#issuecomment-500187077 & https://github.com/monero-project/meta/issues/356#issuecomment-501168062  
**\<dEBRUYNE>** binaryFate: https://github.com/monero-project/meta/issues/356#issuecomment-499968785  
**\<rehrar>** at the end of the thread in particular, ArticMine brings up his revised opinion about potentially looking at removing tx\_extra  
**\<dEBRUYNE>** ArticMine: https://github.com/monero-project/meta/issues/356#issuecomment-501347185  
**\<ErCiccione[m]>** some big ones like kraken already use subadresses moneromooo, iirc  somebody as a list of the status of some exhanges and services  
**\<dEBRUYNE>** https://github.com/monero-project/meta/issues/356#issuecomment-499936642 & https://github.com/monero-project/meta/issues/356#issuecomment-499948904  
**\<rbrunner>** Yeah, but it would be interesting to see whether somebody \*switched\*  
**\<ErCiccione[m]>** maybe sgp\_?  
**\<dEBRUYNE>** rehrar: As far as I can see, people don't like temporary banning payment IDs by parsing tx\_extra  
**\<dEBRUYNE>** As it is essentially a slippery slope  
**\<dEBRUYNE>** So that leaves us with (i) Phase them out by removing all support from the official software or (ii) banning the tx\_extra field entirely  
**\<rehrar>** dEBRUYNE: agreed. I see that reflected as well.  
**\<rehrar>** yes ^  
**\<sgp\_>** I had a list in January, not sure if it is up-to-date anymore  
**\<rehrar>** can I ask people to give opinions on the above two options presented by dEBRUYNE?  
**\<dEBRUYNE>** rbrunner: The announcement has only been up for 10 days though  
**\<rehrar>** I particularly want to hear arguments for or against removing tx\_extra  
**\<rbrunner>** dEBRUYNE: Yes, saw it, but we make noises a lot longer :)  
**\<sgp\_>** rehrar: I have personally head some arguments against removing tx\_extra from legacy financial services  
**\<dEBRUYNE>** The arguments for are, for example, (i) a clean and definitive way to phase out long payment IDs and (ii) improves fungibility  
**\<sgp\_>** Zcash has an encrypted memo field that they use to claim support for many traditional remittance services  
**\<rehrar>** dEBRUYNE: I think (ii) is kind of massive, given that's our shtick  
**\<dEBRUYNE>** moneromooo: I vaguely remember you working on some kind of encrypted memo field too, is that correct?  
**\<sgp\_>** ftr I only support parsing for current payment ID behavior to force services to switch. I am not for the removal of tx\_extra in its entirety  
**\<dsc\_>** \< rehrar> dsc\_ selsta dEBRUYNE anything from GUI? \<== Past 4 days been working on development related tooling to support QML development, this is unrelated to my CCS  
**\<moneromooo>** I have a partial patch for this somewhere. I stopped because it's a bit chicken and egg since you need tx tx key to decrypt the rest and I was not sure what to do yet.  
**\<rbrunner>** Likewise. Erasing tx\_extra completey is going overboard somehow for me  
**\<rehrar>** sgp\_ rbrunner are there any other reasons for keeping it around?  
**\<sgp\_>** rehrar: mostly flexibility  
**\<dEBRUYNE>** sgp\_: How is that field used exactly in that context?  
**\<rehrar>** and is there a good reason why something like it can't be kept track of externally via third party, and why it needs to be on the base currency?  
**\<rbrunner>** Up to a point, it should be possible for the users of the currency to do like they want ... to a certain degree, with a single field  
**\<sgp\_>** See "what people will do with this" https://electriccoin.co/blog/encrypted-memo-field/  
**\<dEBRUYNE>** On the other hand, do we want to give people the ability to potentially hurt privacy of other participants on the network?  
**\<rbrunner>** And who knows, maybe one day we will have some emergency and want to put something in there ourselves. A currency with exactly zero flexibility ... I don't know  
**\<sgp\_>** When I was doing payment ID research back in January, someone specifically asked that tx\_extra remained for this flexibility  
**\<rehrar>** let me look at the dollar. Does the dollar have this field?  
**\<rbrunner>** Marking one's own txs is quite a small privacy risks for others, if you ask me  
**\<rehrar>** or are memos and stuff kept and integrated in dollar management software?  
**\<rbrunner>** Yes, bank transfers have something like a short memo, right?  
**\<sgp\_>** rehrar: I'm not an expert here, I'm just relaying some information to say the flexibility could be useful  
**\<rehrar>** rbrunner: sure, but that isn't built into the dollar bill itself  
**\<rehrar>** which is my point  
**\<rehrar>** is this necessary as a part of Monero itself? Or can monero management software be built to have these memos?  
**\<rehrar>** My initial thoughts are the latter  
**\<rbrunner>** Hmm, I think that comparison limps a little ..  
**\<sgp\_>** my personal opinion is that the flexibility shouldn't be removed unless there's a problem, and we should try to address that more head-on. If we already tried to kill payment IDs and they used a different format in tx\_extra, that would be one thing. But we're in a situation now where we are trying it for the first time and I think a simple parsing would be successful at making people switch over  
**\<rbrunner>** Uh, no, several incompatible memo transfer systems will crop up for sure  
**\<rbrunner>** Why not fill \*every\* tx\_extra with fake data, if that's such a problem?  
**\<rehrar>** hyc, dEBRUYNE, moneromooo? care to chime in at all?  
**\<moneromooo>** Not really.  
**\<sgp\_>** rbrunner: that's basically what zcash does with the encrypted memo field  
**\<moneromooo>** We've gone over that enough for me.  
**\<rbrunner>** Yes, and we now with the short payment ids, right?  
**\<hyc>** as a protocol guy I tend to favor having extensiblity  
**\<hyc>** there's certainly a risk of dumping tons of spam into the chain with a totally open-ended extention field  
**\<hyc>** might want to constrain it to "any individual tx\_extra can't be greater than N bytes" etc  
**\<moneromooo>** That could be made to weigh extra for the fee fwiw.  
**\<hyc>** N=512, 1024, dunno  
**\<rehrar>** isn't that what minergate does when they find a block or is that somethign different?  
**\<rehrar>** I recall somebody saying they add a bunch of weird data  
**\<moneromooo>** They did.  
**\<dEBRUYNE>** sgp\_: Lots of people are opposed to parsing though, I don't think that is going to find consensus  
**\<rehrar>** alright well, anything else to say on this topic?  
**\<rehrar>** we can continue in the issue  
**\<dEBRUYNE>** rehrar: In general I am kind of ambivalent, I think we can achieve a lot by removing all functionality from the software  
**\<sgp\_>** dEBRUYNE: I understand, I just personally think there is some middle ground that doesn't need to include full tx\_extra. I think we've exhausted this topic for now  
**\<dEBRUYNE>** Currently, we removed it, but it is easily to reenable  
**\<sgp\_>** \*full tx\_extra removal  
**\<luigi1111>** instead of command line, move to compile time  
**\<dEBRUYNE>** Next step could be that they need to add code theirselves for payment ID support  
**\<hyc>** VARIANT\_TAG(binary\_archive, cryptonote::tx\_extra\_merge\_mining\_tag, TX\_EXTRA\_MERGE\_MINING\_TAG);  
**\<rbrunner>** But the code would be missing at the people's systems, where the exchanges could not get it in again  
**\<hyc>** if tx\_extra is needed to support merge mining then removing it is kinda out of the question, no?  
**\<dEBRUYNE>** rbrunner: Yes, that as well  
**\<dEBRUYNE>** But there may be some third party wallets that retain support  
**\<rbrunner>** As long as they don't threaten to fork and come up with MoneroLPID (long payment id variant) ...  
**\<rehrar>** alright, let's go ahead and move along  
**\<rehrar>** there is also    discussion blocked out for this meeting  
**\<rehrar>** but we talked about it a bit, and I don't see any MRL people here  
**\<hyc>** seems like there are a lot of current valid uses for tx\_extra, so you can't remove it outright  
**\<rehrar>** still want to discuss, or table?  
**\<hyc>** CLSAG can wait for next meeting I think  
**\<rehrar>** ok  
**\<rehrar>** any additional items?  
**\<hyc>** surae is busy taking care of konferenco now anyway  
**\<rehrar>** code/ticket discussion?  
**\<moneromooo>** Anyone else than hyc wants to review share-rpc ? :)  
**\<moneromooo>** Or even use it as backend to add pay-for-downloading-torrents or whatever.  
**\<rehrar>** I lack the skills :)  
**\<rehrar>** \*:(  
**\<rehrar>** alright everyone, I think we can call it here  
**\<rehrar>** two weeks from now?  
**\<rehrar>** thanks for coming! have a good couple weeks.