phyro

I believe https://forum.grin.mw/t/eliminating-finalize-step/7621/106 describes another way to produce payment proofs that are the same for both SRS/RSR flow. One of the differences is that the `s` part of the Schnorr...

> It uses the set of all participant's R_i, which takes more space. And it uses a nonstandard way of commiting to extra data (R * Hash instead of R...

I wonder if it would make sense having the invoice fields blinded by default. A payment proof can be thought of as an invoice proof and if it has a...

I agree, this is definitely not needed right now and if at any point we found a use case for it, we could always make a new 'version' of a...

The discussion [here](https://gist.github.com/phyro/cc0265cfc27d0405eefe63c490048265) made me think a bit about payment proofs in multiparty setting. I think we can have a uniform and relatively simple construction where we kill two birds...

@tromp I'm reading [Proof type Invoice](https://github.com/tromp/grin-rfcs/blob/early-payment-proofs/text/0000-early-payment-proofs.md#proof-type-invoice) and want to check my understanding. The steps for the invoice flow are: 1. The receiver signs the mentioned data and sends `(sig, msg)`...

Regarding the implementation of this, would it make sense to define the payment proof as \ where M is the message the receiver signs for the payment proof, sig(M, receiver_addr)...

> You should write (X - Xr) instead of Xs?! No, I meant Xs because in the definition I made above we remember the _sender_ partial signature which is then...

@marekyggdrasil I personally agree that a stackoverflow for Grin would be a good thing to have and would contribute to answers myself, but it seems like there was no activity...

I think it's best to plan this also for the scenario of full blocks. In this case, we'd need to have an option to define the cancel fee to define...