Slate V4 (Compact Slates) #49

yeastplume · 2020-04-06T13:01:30Z

DavidBurkett · 2020-04-06T14:23:13Z

text/0000-compact-slates.md

+//"tx": null,
+  "amt": "1000000000",
+  "fee": "8000000",
+  "hgt": "437088",


Did you figure out why this was needed? I don't believe it is, or at minimum, it can probably be optional

I don't think it's needed at all, so will try removing it.

DavidBurkett · 2020-04-06T14:26:42Z

It would probably be a good idea to specify the encoding used for pubkeys, commitments, and signatures.

ghost · 2020-04-07T16:37:21Z

As discussed in chat, we could use a slate stage field that denotes what kind of slate we are dealing with (invoice, send, receive, finalize etc). The wallet GUI could display one UI 'receive' slate interface and handle which endpoint to use behind the scenes. That would improve UX flow considerably for P2P transactions.

yeastplume · 2020-04-08T11:24:34Z

As discussed in chat, we could use a slate stage field that denotes what kind of slate we are dealing with (invoice, send, receive, finalize etc). The wallet GUI could display one UI 'receive' slate interface and handle which endpoint to use behind the scenes. That would improve UX flow considerably for P2P transactions.

Yes, I agree, and it will also remove a lot of awkwardness from code that tires to infer what state the slate is in. Going to add this field.

yeastplume · 2020-04-09T11:30:32Z

Added proposed stage (sta) field and description
Removed hgt field
Added more precise descriptions of hex string fields

i1skn · 2020-04-15T13:13:23Z

Great work on this one! I especially like sta field, because now I do:
https://github.com/i1skn/ironbelly/blob/d55bcb70c52e36815f9f2380396722e112248021/src/common/index.ts#L170-L177 to identify the stage of a slate and to have this info inside a slate is a good thing!

I have a small question, why do we need to pass fee in a slate?

Standard flow: fee can be added between S2 and S3, right?
Invoices flow: fee is unknown in I1 because payee can use different amount of inputs, right? So, fee could be calculated only between I2 and I3, right?

Probably, I'm missing something here...

i1skn · 2020-04-15T13:16:47Z

text/0000-compact-slates.md

+   * `excess` - Hex-String encoded short form public key on the secp256k1 curve representing the public blind excess for the participants inputs/outputs. The first party to add signature data must also generate and add a random kernel offset to this value.
+   * `part` - Hex-String encoded Aggregated (Schnorr) secp2561k signature represeting the participant's partial sig. May be omitted if the participant does not yet have enough data to create it
+   * `nonce` - The public key of the nonce chosen by the participant for their partial signature
+* `proof` - An optional payment proof requet that must be filled out by the recipient if requested (only valid for basic transaction flow). This contains:


typo: requet

yeastplume · 2020-04-16T11:32:44Z

Great work on this one! I especially like sta field, because now I do:
https://github.com/i1skn/ironbelly/blob/d55bcb70c52e36815f9f2380396722e112248021/src/common/index.ts#L170-L177 to identify the stage of a slate and to have this info inside a slate is a good thing!

I have a small question, why do we need to pass fee in a slate?

Standard flow: fee can be added between S2 and S3, right?

Invoices flow: fee is unknown in I1 because payee can use different amount of inputs, right? So, fee could be calculated only between I2 and I3, right?

Probably, I'm missing something here...

Fee needs to be included in the signature message, and needs to be specified by the person inserting the inputs, so it has to be specified at S1 and I2. It can be dropped at S2 since the originator knows it.

j01tz · 2020-04-20T17:02:19Z

Looks great overall @yeastplume, this definitely makes the material clear and digestible.

A quick question about the "return" slate in the basic workflow: can we (or do we already) prune the senders xs and nonce keys in sigs?

My (possibly naive) understanding is that to finish building the transaction the only additional signature data that the sender needs from the receiver is a partial schnorr signature, a commitment to their blinding factor (a new xs), and a commitment to the nonce from the partial signature.

yeastplume · 2020-04-24T14:26:55Z

Looks great overall @yeastplume, this definitely makes the material clear and digestible.

A quick question about the "return" slate in the basic workflow: can we (or do we already) prune the senders xs and nonce keys in sigs?

My (possibly naive) understanding is that to finish building the transaction the only additional signature data that the sender needs from the receiver is a partial schnorr signature, a commitment to their blinding factor (a new xs), and a commitment to the nonce from the partial signature.

That's correct, and no we're not currently pruning the sender's xs and nonce data on the return trip and probably should. Will amend

DavidBurkett · 2020-04-27T16:22:36Z

What will the flow look like for sending or receiving using a multisig wallet? Does this slate model work for that?

yeastplume · 2020-04-27T20:59:15Z

What will the flow look like for sending or receiving using a multisig wallet? Does this slate model work for that?

No, this is definitely optimized for a single sender/recipient workflow at the moment. For multisig, I'd anticipate adding a new set of status stages and another set of definitions as to what fields need to be present at each stage.

antiochp · 2020-04-28T15:46:24Z

We specify the following on the slate itself -

fee
lock_hgt

Fee makes sense but "lock height" is sort a hold over from legacy v1 (this defaults to 0 if not in use, but its not actually a field on a plain kernel, so we ignore it if 0).
It would be nice if we could specify a "kernel feature" along with associated feature specific fields.

This is related to "relative kernel locks" but a more general purpose approach here would make our live significantly easier when dealing with different kinds of kernels.

In slate.rs we do the following (basically map slate.lock_height==0 to plain kernel) -

	// Construct the appropriate kernel features based on our fee and lock_height.
	// If lock_height is 0 then its a plain kernel, otherwise its a height locked kernel.
	fn kernel_features(&self) -> KernelFeatures {
		match self.lock_height {
			0 => KernelFeatures::Plain { fee: self.fee },
			_ => KernelFeatures::HeightLocked {
				fee: self.fee,
				lock_height: self.lock_height,
			},
		}
	}

Ideally the slate contains enough information to fully represent a kernel feature.

yeastplume · 2020-04-29T15:44:01Z

We specify the following on the slate itself -

fee

lock_hgt

Fee makes sense but "lock height" is sort a hold over from legacy v1 (this defaults to 0 if not in use, but its not actually a field on a plain kernel, so we ignore it if 0).
It would be nice if we could specify a "kernel feature" along with associated feature specific fields.

This is related to "relative kernel locks" but a more general purpose approach here would make our live significantly easier when dealing with different kinds of kernels.

In slate.rs we do the following (basically map slate.lock_height==0 to plain kernel) -
	// Construct the appropriate kernel features based on our fee and lock_height.
	// If lock_height is 0 then its a plain kernel, otherwise its a height locked kernel.
	fn kernel_features(&self) -> KernelFeatures {
		match self.lock_height {
			0 => KernelFeatures::Plain { fee: self.fee },
			_ => KernelFeatures::HeightLocked {
				fee: self.fee,
				lock_height: self.lock_height,
			},
		}
	}
Ideally the slate contains enough information to fully represent a kernel feature.

How about something like this:

{
  "ver": "4:3",
  "id": "6f9c730a-1193-4123-948c-f6c1dc49e904",
  "sta": "S1",
  "amt": "60000000000",
  "fee": "4000000",
  "feats": {
    "feat" : 1,
    "lock_hgt": 3434,
  },
  "sigs": [
    {
      "xs": "AibJx7P1F3b+MYgAdk3mKkL6NhH/O2DZ65GLCSd5Ej0d",
      "nonce": "AuzSBEMitFkX2OiJSUToH4Fu/athEnsdQwDmBLBqdFiF"
    }
  ],
  "proof": {
    "saddr": "KvIz/vtzzNJdvh/p72ItytezxuU8N+OhrEsykmX3WAk=",
    "raddr": "GtKjKihZs4cbFe8UNgcPrXxXCBsYxOCvuyzsuH4RK44="
  }
}

feats.feat is the enumeration of the kernel feature
fee remains where it is (as it's likely to be universal)
If feats is not provided, the kernel is assumed to be plain (0).
feats is just a struct that contains all possible non-fee kernel feature arguments. It can be extended over-time with whatever args are needed for new features. Although the internal struct will contain all possible feature args, args not relevant to a feature can be left out of the serialization.

yeastplume · 2020-05-05T11:04:57Z

Updated with more generic approach to KernelFeatures arguments

quentinlesceller · 2020-05-07T13:24:38Z

In line with our governance process, this RFC can be considered being in Final Comment Period, with a disposition to merge in two weeks time, on May 21.

Please ensure any comments are made before then!

j01tz

Added a few small comments, great job with this overall 🚀

j01tz · 2020-05-17T20:48:12Z

text/0000-compact-slates.md

+  "ver": "4:3",
+  "id": "7haE++9ZScKLOqM2jvRsjA==",
+  "sta": "S2",
+  "sigs": [


I think we want to add new offset field here before sigs begins.

j01tz · 2020-05-17T20:50:39Z

text/0000-compact-slates.md

+#### Top-Level Slate Struct
+
+* The `version_info` struct is removed, and is replaced with `ver`, which has the format "[version]:[block header version]"
+* `id` becomes a short-form base-64 encoding of the UUID binary


Isn't the UUID hex encoded rather than base64?

Yes, as a matter of that this is no longer a change, remove that line

j01tz · 2020-05-17T20:52:42Z

text/0000-compact-slates.md

+
+This RFC is envasaged as a necessary first step for all slate-exchange possibilities that would benefit from compactness, e.g:
+
+* [Slate Serialization](https://github.com/j01tz/grin-rfcs/blob/slate-serialization/text/0000-slate-serialization.md)


Can replace slate-serialization and armored-slates here with slatepack

quentinlesceller

Big RFC :) A lot of work! Everything makes sense and really well written.
Few comments below. I think after they are addressed we can process with the merging.

RFC PR: https://github.com/mimblewimble/grin-rfcs/pull/49

And can you rename to 0012-compact-slates.md

text/0000-compact-slates.md

lehnberg · 2020-05-25T13:05:37Z

@quentinlesceller is the FCP period extended?

In line with our governance process, this RFC can be considered being in Final Comment Period, with a disposition to merge in two weeks time, on May 21.

Please ensure any comments are made before then!

text/0000-compact-slates.md

quentinlesceller · 2020-05-25T13:54:41Z

@lehnberg I was waiting for @yeastplume to address the comments above. After that we can merge it.

yeastplume · 2020-05-25T14:48:11Z

Thanks for reviewing, comments all addressed and rfc updated

text/0000-compact-slates.md

quentinlesceller · 2020-05-25T15:21:59Z

🎉 Wohooo! This RFC has now been merged! 🤸‍♀️
Tracking issue: mimblewimble/grin-wallet#317

yeastplume added 3 commits April 6, 2020 11:32

add first pass of RFC

baf6232

add motivation

27fecd2

Add community explanation

3e7777e

yeastplume mentioned this pull request Apr 6, 2020

Add support for sending compact slates mimblewimble/grin-wallet#366

Merged

DavidBurkett reviewed Apr 6, 2020

View reviewed changes

yeastplume added 2 commits April 9, 2020 10:22

start of changes based on feedback

f7d6fa7

add proposed stage field

1ae8a7c

fix sta description

13baf6d

lehnberg mentioned this pull request Apr 14, 2020

Release Planning: Grin v4.0.0 mimblewimble/grin-pm#248

Closed

yeastplume changed the title ~~[WIP] Compact Slates~~ Compact Slates Apr 15, 2020

i1skn reviewed Apr 15, 2020

View reviewed changes

split up changes definition, add transaction object changes

f021797

yeastplume added 2 commits April 16, 2020 12:33

merge ins and outs into coms

aef1488

fix version description

6c93838

yeastplume mentioned this pull request Apr 17, 2020

Conversions of node Transaction object into Slate's coms field mimblewimble/grin-wallet#382

Merged

yeastplume added 5 commits April 24, 2020 11:30

update changes, add binary definition

f694373

fix formatting

01d18ab

fix formatting

a886005

fix coms length

26c48dd

change title

85236ca

yeastplume changed the title ~~Compact Slates~~ Slate V4 (Compact Slates) Apr 24, 2020

removal of initiator's sig entry during I2 and S2

2c52636

lehnberg added the wallet dev Related to wallet dev team label May 4, 2020

yeastplume added 2 commits May 5, 2020 11:40

add offset field

c41d5f1

add optional kernel features fields

e653b8b

lehnberg assigned quentinlesceller May 5, 2020

quentinlesceller added the in FCP Currently in Final Comment Period label May 7, 2020

yeastplume mentioned this pull request May 11, 2020

Compact slate merge mimblewimble/grin-wallet#404

Merged

update to reflect changes to offset selection

200124f

j01tz approved these changes May 17, 2020

View reviewed changes

yeastplume added 2 commits May 18, 2020 10:19

fixes based on comments

cc04ab0

sp

c6c51db

quentinlesceller approved these changes May 21, 2020

View reviewed changes

quentinlesceller reviewed May 25, 2020

View reviewed changes

text/0000-compact-slates.md Outdated Show resolved Hide resolved

updates based on feedback

b02aaaa

quentinlesceller reviewed May 25, 2020

View reviewed changes

text/0000-compact-slates.md Outdated Show resolved Hide resolved

more updates based on feedback

c46fcca

quentinlesceller reviewed May 25, 2020

View reviewed changes

text/0000-compact-slates.md Outdated Show resolved Hide resolved

quentinlesceller added 2 commits May 25, 2020 11:14

Update RFC Number and merge preparation

2a96e8a

Fix tracking issue link

81511e6

quentinlesceller merged commit e6d4bff into mimblewimble:master May 25, 2020

quentinlesceller mentioned this pull request May 25, 2020

Tx-building: Compact slates mimblewimble/grin-wallet#317

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Slate V4 (Compact Slates) #49

Slate V4 (Compact Slates) #49

yeastplume commented Apr 6, 2020 •

edited by lehnberg

Loading

DavidBurkett Apr 6, 2020

yeastplume Apr 8, 2020

DavidBurkett commented Apr 6, 2020

ghost commented Apr 7, 2020

yeastplume commented Apr 8, 2020

yeastplume commented Apr 9, 2020

i1skn commented Apr 15, 2020 •

edited

Loading

i1skn Apr 15, 2020

yeastplume Apr 16, 2020

yeastplume commented Apr 16, 2020 •

edited

Loading

j01tz commented Apr 20, 2020 •

edited

Loading

yeastplume commented Apr 24, 2020

DavidBurkett commented Apr 27, 2020

yeastplume commented Apr 27, 2020

antiochp commented Apr 28, 2020 •

edited

Loading

yeastplume commented Apr 29, 2020 •

edited

Loading

yeastplume commented May 5, 2020

quentinlesceller commented May 7, 2020

j01tz left a comment

j01tz May 17, 2020

yeastplume May 18, 2020

j01tz May 17, 2020

yeastplume May 18, 2020

j01tz May 17, 2020

quentinlesceller left a comment

lehnberg commented May 25, 2020

quentinlesceller commented May 25, 2020

yeastplume commented May 25, 2020

quentinlesceller commented May 25, 2020


		This RFC is envasaged as a necessary first step for all slate-exchange possibilities that would benefit from compactness, e.g:

		* [Slate Serialization](https://github.com/j01tz/grin-rfcs/blob/slate-serialization/text/0000-slate-serialization.md)

Slate V4 (Compact Slates) #49

Slate V4 (Compact Slates) #49

Conversation

yeastplume commented Apr 6, 2020 • edited by lehnberg Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DavidBurkett commented Apr 6, 2020

ghost commented Apr 7, 2020

yeastplume commented Apr 8, 2020

yeastplume commented Apr 9, 2020

i1skn commented Apr 15, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yeastplume commented Apr 16, 2020 • edited Loading

j01tz commented Apr 20, 2020 • edited Loading

yeastplume commented Apr 24, 2020

DavidBurkett commented Apr 27, 2020

yeastplume commented Apr 27, 2020

antiochp commented Apr 28, 2020 • edited Loading

yeastplume commented Apr 29, 2020 • edited Loading

yeastplume commented May 5, 2020

quentinlesceller commented May 7, 2020

j01tz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

quentinlesceller left a comment

Choose a reason for hiding this comment

lehnberg commented May 25, 2020

quentinlesceller commented May 25, 2020

yeastplume commented May 25, 2020

quentinlesceller commented May 25, 2020

yeastplume commented Apr 6, 2020 •

edited by lehnberg

Loading

i1skn commented Apr 15, 2020 •

edited

Loading

yeastplume commented Apr 16, 2020 •

edited

Loading

j01tz commented Apr 20, 2020 •

edited

Loading

antiochp commented Apr 28, 2020 •

edited

Loading

yeastplume commented Apr 29, 2020 •

edited

Loading