onvenient way of identifying "our" outputs in the UTXO set for
>> wallet recovery.
>> This is trivial 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
is trivial 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 wit
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 thr
I need to resurrect this thread.
What's currently implemented in Grin [1] is
(vG + bH), BLAKE2(bJ),
where the hash is truncated to 160 bits.
Hashed switch commitments are supposed to give you two main properties:
1. Switch binding: even if you have unlimited computation power from
to
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, reveal
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 th
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 the pair
> vH + rG, sha256(rJ)
> where J is a new NUMS generator, G the standard
10 matches
Mail list logo
