proofs of position and UTXO set commitments

> Interesting, thanks for the link. Seems we arrived at similar conclusions
> regarding the hash function, with similar frustrations with respect to
> blake2b/2s.
>
> Funny that it's also for the same merkle set application. We ended up with
> a Merkle Mountain Range [1] instead of a Patricia tree. The MMR is
> append-only and makes pruning easy, which works well for MimbleWimble. You
> can navigate down the MMR with just the position the element was inserted
> at, so we just keep a simple index for that. Memory layout is great as a
> lot of it is immutable and sit close together, although the current impl
> doesn't leverage that too well yet. Wonder if Bram looked at MMRs? Patricia
> trees may make more sense for Bitcoin though.
>
> Proof of positions are cool, might look at that some more in the near
> future, when we're less busy implementing everything else ;-)
>
>
> - Igno
>
> [1] https://github.com/ignopeverell/grin/blob/master/doc/merkle.md
>
> -------- Original Message --------
> Subject: Re: [Mimblewimble] Switch to Blake2
> Local Time: July 24, 2017 6:44 PM
> UTC Time: July 24, 2017 6:44 PM
> From: kanzure@gmail•com
> To: Ignotus Peverell <igno.peverell@protonmail•com>, Bram Cohen <
> bram@bittorrent•com>, Bryan Bishop <kanzure@gmail•com>
>
> On Fri, Jul 21, 2017 at 1:12 PM, Ignotus Peverell <
> igno.peverell@protonmail•com> wrote:
>
>> So I'm considering a switch to the Blake2 [3] hash function.
>>
>
> Bram recently made some comments about blake a few weeks ago:
> http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-07-
> 08-bram-cohen-merkle-sets/
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
>
>