ivial currently as we know rJ from our wallet private keys
> and we can quickly check if the switch commit hash was generated by
> us.
>
> None of this is to say I disagree - just wanted to make sure these
> were both visible as well.
>
>
> — Antioch
>
> Sent with Pro
om) Secure Email.
> Original Message --------
> Subject: Re: [Mimblewimble] Hashed switch commitments
> Local Time: December 13, 2017 11:18 AM
> UTC Time: December 13, 2017 4:18 PM
> From: cry...@timruffing.de
> To: mimblewimble@lists.launchpad.net
>
> I need to resurrect this
On Thu, 2017-09-07 at 18:12 +, Andrew Poelstra wrote:
> It's true that people can put non-random things here which would be
> really
> bad for privacy. I don't think there's any efficiently-verifiable way
> to
> prevent that. Maybe requiring the data be a hash and requiring the
> preimage
> be
Maybe store it committed to the excess factors (via merkle tree, to allow one
excess to commit to multiple switch commitments)? Tx kernels are prunable, but
committed to each block, so we can have a merkle proof of inclusion in a
historical block to open the commitment.
Raw excess commitment E
Hiding important data inside the rangeproofs would force nodes to keep it
around.
The rangeproofs are otherwise purely witness data that non-archival nodes can
discard.
On Thu, Sep 07, 2017 at 01:33:14PM -0700, Oleg Andreev wrote:
> How about this (weird) idea:
>
> 1. Store `sha256(r*J)` inside
How about this (weird) idea:
1. Store `sha256(r*J)` inside one of the first 2 forged elements (corresponding
to the lowest bit of your number, assuming base-4 rangeproofs; for base-3 it
also works).
2. When you reveal it after PQ upgrade, you will destroy 1 bit of privacy in
your number,
On Thu, Sep 07, 2017 at 01:23:45PM -0400, Ignotus Peverell wrote:
> Hi,
>
> I wanted to pick that back up. I think it comes down to yet another tradeoff
> between privacy, security and convenience. To give back some context from
> Andrew's email:
>
> > Basically our outputs should consist of
7 matches
Mail list logo
