Grin: serialize various slate elements as hex (and not arrays of ints)
I wonder how feasible/realistic it would be to update the wallet slate serialization before mainnet to serialize the various bytes slices as hex rather than arrays of integers?
Could we potentially do this as a v2 of the slate format?
{
"amount": 4206000000,
"height": 77907,
"tx": {
"body": {
"outputs": [
{
"proof": [
82,
154,
122,
171,
25,
9,
93,
192,
208,
133,
80,
123,
178,
45,
170,
96,
89,
171,
96,
149,
138,
98,
168,
169,
200,
221,
236,
104,
131,
203,
104,
100,
40,
61,
199,
103,
51,
65,
230,
183,
244,
229,
253,
70,
224,
250,
182,
228,
30,
163,
248,
187,
255,
106,
196,
175,
167,
119,
237,
114,
210,
151,
250,
36,
12,
28,
57,
63,
88,
241,
127,
86,
238,
241,
191,
144,
48,
204,
45,
60,
158,
233,
75,
200,
81,
27,
69,
223,
242,
245,
219,
45,
42,
217,
152,
198,
20,
239,
253,
188,
38,
114,
180,
208,
84,
230,
119,
142,
109,
236,
249,
212,
5,
83,
125,
220,
61,
255,
96,
103,
41,
197,
152,
115,
172,
186,
83,
127,
173,
42,
52,
130,
150,
216,
158,
246,
162,
36,
255,
179,
216,
127,
168,
147,
152,
17,
122,
209,
63,
228,
8,
72,
101,
22,
28,
32,
181,
247,
211,
12,
133,
171,
208,
99,
53,
177,
63,
146,
61,
154,
238,
137,
237,
106,
66,
28,
23,
155,
229,
15,
96,
75,
142,
155,
86,
39,
84,
3,
140,
105,
245,
154,
81,
85,
60,
66,
23,
101,
181,
98,
132,
233,
126,
111,
213,
86,
45,
174,
100,
29,
22,
94,
155,
217,
228,
198,
128,
203,
207,
227,
140,
155,
91,
186,
94,
89,
242,
227,
156,
151,
124,
48,
18,
64,
101,
198,
156,
237,
24,
238,
97,
27,
85,
81,
170,
46,
149,
157,
11,
57,
84,
237,
153,
179,
57,
249,
104,
242,
66,
220,
67,
135,
212,
170,
177,
82,
31,
92,
99,
227,
117,
131,
102,
48,
84,
127,
148,
164,
147,
220,
134,
173,
116,
120,
112,
108,
251,
30,
163,
32,
189,
26,
106,
33,
105,
240,
125,
246,
178,
158,
229,
240,
134,
230,
185,
10,
139,
34,
14,
153,
117,
125,
143,
13,
87,
196,
55,
184,
35,
232,
79,
181,
244,
181,
70,
109,
73,
13,
94,
74,
103,
75,
244,
158,
198,
3,
5,
41,
68,
151,
35,
82,
231,
174,
85,
131,
15,
143,
194,
78,
221,
102,
110,
0,
0,
189,
44,
61,
195,
241,
151,
174,
214,
71,
179,
164,
170,
19,
186,
2,
233,
193,
118,
144,
38,
187,
96,
41,
23,
98,
0,
22,
223,
175,
76,
52,
170,
96,
190,
187,
191,
161,
88,
174,
204,
220,
151,
249,
64,
72,
52,
120,
114,
154,
236,
206,
65,
46,
86,
98,
26,
130,
225,
112,
35,
100,
193,
142,
114,
13,
228,
142,
183,
136,
253,
1,
35,
169,
206,
141,
184,
78,
91,
166,
247,
179,
190,
32,
85,
146,
218,
183,
30,
115,
15,
2,
9,
99,
249,
17,
94,
147,
30,
56,
70,
160,
232,
159,
86,
98,
61,
7,
216,
123,
95,
233,
48,
204,
3,
21,
151,
11,
23,
219,
163,
150,
2,
218,
183,
148,
10,
114,
230,
11,
46,
21,
170,
229,
92,
110,
69,
251,
5,
57,
111,
175,
121,
94,
105,
78,
15,
69,
194,
229,
156,
206,
9,
165,
198,
184,
98,
189,
195,
213,
68,
123,
214,
191,
223,
68,
168,
148,
233,
17,
69,
33,
155,
50,
135,
241,
254,
43,
233,
11,
192,
135,
218,
144,
193,
203,
84,
75,
239,
184,
114,
153,
22,
183,
145,
122,
80,
55,
43,
226,
159,
215,
207,
98,
24,
94,
17,
81,
39,
28,
19,
59,
218,
116,
122,
226,
125,
181,
211,
241,
73,
186,
219,
40,
248,
69,
194,
165,
229,
203,
218,
2,
28,
103,
36,
93,
232,
158,
54,
25,
204,
220,
77,
222,
142,
61,
56,
216,
143,
22,
158,
112,
63,
58,
212,
10,
25,
236,
246,
86,
76,
80,
97,
246,
227,
125,
52,
80,
254,
137,
198,
71,
198,
131,
95,
30,
189,
174,
68,
104,
115,
69,
247,
69,
74,
166,
193,
233,
196,
225,
114,
6,
43,
222,
150,
40,
197,
190,
195,
223,
97,
183,
169,
220,
222,
6,
92,
32,
248,
209,
52,
229,
94,
126,
222,
58,
218,
155,
130,
123,
203
],
"features": {
"bits": 0
},
"commit": [
8,
125,
22,
60,
46,
153,
125,
14,
137,
21,
218,
31,
129,
6,
202,
229,
12,
145,
8,
221,
152,
52,
248,
41,
221,
205,
151,
147,
196,
194,
24,
148,
74
]
}
],
"inputs": [
{
"commit": [
8,
0,
236,
80,
241,
29,
193,
36,
192,
88,
76,
63,
200,
163,
189,
35,
68,
155,
19,
58,
46,
100,
236,
16,
213,
99,
195,
160,
184,
154,
8,
179,
202
],
"features": {
"bits": 1
}
}
],
"kernels": [
{
"excess": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"features": {
"bits": 0
},
"fee": 8000000,
"lock_height": 77907,
"excess_sig": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
]
}
]
},
"offset": [
124,
12,
213,
170,
176,
116,
41,
252,
17,
143,
29,
152,
7,
73,
135,
90,
9,
125,
174,
70,
121,
220,
207,
19,
120,
52,
2,
165,
209,
31,
17,
110
]
},
"id": "219d1989-3e37-4dab-9223-36ae5d15cde9",
"num_participants": 2,
"participant_data": [
{
"public_blind_excess": [
2,
92,
250,
230,
61,
23,
128,
146,
9,
24,
194,
31,
10,
213,
48,
69,
154,
72,
235,
186,
25,
38,
183,
87,
88,
183,
96,
82,
63,
213,
11,
80,
107
],
"part_sig": null,
"message_sig": null,
"public_nonce": [
3,
225,
90,
31,
43,
220,
198,
217,
22,
83,
169,
163,
61,
210,
1,
202,
123,
65,
192,
192,
24,
121,
95,
15,
118,
93,
244,
223,
80,
88,
106,
240,
231
],
"id": 0,
"message": null
}
],
"fee": 8000000,
"lock_height": 77907
}
antiochp
All 14 comments
Yes, it's definitely possible, involves messing about with serde directives. I'd started at some point but decided to move on to something else. Can put it on the short list. I don't think we'd need to worry about backwards compatibility, just tell everyone to update before trying to send transactions.l
yeastplume
on 12 Dec 2018
Currently looking into this there is two ways to do it:
- At the slate levels. Implementing serialize/deserialize on
ParticipantData/Input/Outputsetc... - Implementing serialize/deserialize on
grin_secp256k1zkpstructs.
Second solution is cleaner imo. Thoughts?
quentinlesceller
on 12 Dec 2018
Second may be cleaner but we would want to be very careful that we're not touching any seemingly unrelated code like that - those structs are used everywhere.
First option may actually be preferable in terms of only wanting to affect the slate serialization.
antiochp
on 12 Dec 2018
Yeah that's what I'm thinking too. Maybe we should go with 1 so we don't break everything.
quentinlesceller
on 12 Dec 2018
Does it make sense to implement separate serialisation and deserialisation on every function that wants to interact with the data? To me, you would want as least some unified layer of abstraction to convert it into the more machine readable format.
Or, is changing it to hex a good idea in the first place? Presumably only humans will prefer to read it in as hex, which will surely make them the edge case? Is it better to just have any tools that display these items handle the serialisation to hex?
[e: thinking about it more makes me think that serialisation to hex is a good idea, it would make the developers life even worse if serialisation only happened before they saw it. I still feel an abstraction layer or altering grin_secp256k1zkp will be more maintainable.]
popey456963
on 16 Dec 2018
I'm looking at this from the perspective of the "slate" being the piece of data here and that there should be one consistent serialization format for the slate as a whole (its what we pass around internally in the wallet and between wallets).
Most of the time we serialize to/from a single binary format (see ser.rs in core for this).
But the slate is json and somewhat of a special case.
antiochp
on 16 Dec 2018
I could probably do option 1 over the weekend, seems more straightforward/ less headachy to me, any reason why not?
svechinsky
on 3 Jan 2019
@svechinsky We're only a a week or so away from releasing mainnet and introducing a serialization change may be overly risky at this stage.
antiochp
on 5 Jan 2019
Yes, seems like this can/should be introduced after mainnet release.
quentinlesceller
on 6 Jan 2019
could we change the milestone on the issue then?
AndrewSB
on 12 Jan 2019
@svechinsky thanks for #2436
And regarding to:
- Another PR for an optional Slate ID (and have to consider how this remains backwards compatible, given it would adds a field that doesn't exist in older clients)
- Another PR to handle the integration of new slate + backwards compatibility concerns there
Would you like to complete the mentioned 2 more PRs to complete this enhancement?
garyyu
on 30 Jan 2019
Yes I would got side tracked with some private issues hopefully but should
be able to complete them shortly
On Wed, Jan 30, 2019, 03:54 Gary Yu <[email protected] wrote:
@svechinsky https://github.com/svechinsky thanks for #2436
https://github.com/mimblewimble/grin/pull/2436
And regarding to:
- Another PR for an optional Slate ID (and have to consider how this
remains backwards compatible, given it would adds a field that doesn't
exist in older clients)- Another PR to handle the integration of new slate + backwards
compatibility concerns thereWould you like to complete the mentioned 2 more PRs to complete this
enhancement?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mimblewimble/grin/issues/2134#issuecomment-458780687,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATCAqyWF3tnkRJ88oJB9Y3xtTK3kBCWIks5vIPtdgaJpZM4ZOGhh
.
svechinsky
on 30 Jan 2019
So in regards to backward compatibility, any better way than serializing based on the slate version or lack of it?
svechinsky
on 30 Jan 2019
quentinlesceller
on 26 Mar 2019
Related issues
lehnberg
·
4Comments
black-phillip616
·
3Comments
antiochp
·
3Comments
antiochp
·
3Comments
garyyu
·
4Comments
Most helpful comment
Yeah that's what I'm thinking too. Maybe we should go with 1 so we don't break everything.