Node n is the first to make a kernel so I don’t know what you mean here…
Note that my reply was to my suggestion that mixnodes could make a single joint kernel:
I just realized there’s an even more obvious solution and I believe a better one. Mixnodes add their partial excess when going forward and they sign the total excess and adjust the offset when going backwards. Why is this better? Because we have a single kernel with the same guarantee as with M kernels (no undo attack if 1 is honest)
Unfortunately, what I suggested back then seems to have the problem with key cancellation that I’m mentioning now. If every node creates its own kernel, there is no such issue.
I don’t see how keys could be cancelled, since each mixnode’s partial sig is needed to relate the inputs and outputs.
1 Like
Ugh, I think I have made a mistake in my calculations and you’re right that the equation would not verify if the last node cancelled a key or many. If it cancelled a key of node 2, the private key that node 2 proved through the partial sig would need to have been contributed to the offset by node 2, but it has not been added there and ends up missing in this case (I think). I need to think about this a bit more…
Thank you very much for working on this. Where are the updates posted?
Sounds like the best side on the Wendy’s menu.
1 Like
“Widespread use of the protocol would leave the transaction graph mostly obscured.”
For that it need to be mandatory default private at the base protocol layer.
PERIOD!!!
1 Like
But what about server? If it will be single endpoint it can be a problem, another case if it will act like p2p server, so everyone can launch copy and sync it.
Yes, I see it as next development stage while we have no serverless payjoin implementation.
Possibly we can use these crates, I found them very useful: GitHub - cyphernet-dao/rust-netservices: P2P network service crates (alternative to rust-microservices).
Dr. Maxim Orlovsky is developing smart-contracts based on MimbleWimble tech for Bitcoin (called RGB), but there is no single word about MW and CA concept by Polestra surprisingly…
2 Likes
As far as I know, it’s not based on Mimblewimble, but rather on an idea from Peter Todd called single use seals.
1 Like
They wrote it with typo 
Forked grin_secp256k1zkp so:
“Amounts are confidential with Pedersen commitments and Bulletproofs, combining best from Liquid & Grin/Mimblewimble”
Also this:
“Mimblewimble-style Pedersen commitment aggregation & history cut-through better privacy concept for the future”
1 Like
I’m confused. I thought RBG was based on single use seals which has nothing to do with Mimblewimble. Bulletproofs themselves have nothing to do with MW, they’re just a way of proving v in a Pedersen commitment which happens to be used in confidential transactions including MW. I still don’t think RBG has much to do with MW tbh, but maybe I’m misunderstanding things.
1 Like
That’s only a discussion item (under section “Other”) on the Agenda of a 2020-09-30 RGB developer call. Hardly evidence that “Maxim Orlovsky is developing smart-contracts based on MimbleWimble tech”.
Monero and Zcash also use Pedersen commitments and rangeproofs. And probably also mentioned Mimblewimble in one of their developer calls. That doesn’t make them “based on MimbleWimble tech” either…
2 Likes
What is the threat level if a user does not use CoinSwap? There is obviously a lower amount of privacy. But what exactly is the threat? What can be deduced about this? And is it acceptable for the average citizen that doesn’t have a target on their back?
And also is there a threat of using CoinSwap? The need to have a whole alternative fee market to incentivize coinswap server operators? What if the coordinating server goes down? What if it’s a small pool of coins, it becomes pointless and a waste of money?
Maxim confirmed they don’t use mimblewimble:
Single-use-seals is the way preventing double spend and it has nothing to do with mimblewimble. But RGB uses confidential transactions - namely pedersen commitments + bulletproofs - to hide amounts in the client-side validated data - and this is different.
Regarding coinswap usage, it’s up to the user to decide if they want to coinswap or not. The decision can be seen as similar to a coinjoin on Bitcoin with the difference that the user doesn’t need to interact or know who is going to participate because you simply send your own coinswap to the server and never see any other information until the transaction is constructed.
1 Like