Ingo/Merope,
Not sure if you have seen this:
"Rolling UTXO set hashes"
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html
See the whole thread:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/thread.html
So it appears that potentially you can do additions and subtractions with
hashes!
Cheers,
Praxeology Guy
> -------- Original Message --------
> Subject: Re: [Mimblewimble] Treeless block and UTXO set validation
> Local Time: July 27, 2017 11:24 AM
> UTC Time: July 27, 2017 4:24 PM
> From: igno.pever...@protonmail.com
> To: Merope Riddle <merop...@protonmail.com>
> mimblewimble@lists.launchpad.net <mimblewimble@lists.launchpad.net>
>
> Yes, I realized it yesterday, was pondering on it some more before emailing
> yet again. I take it as a lesson to sit for a couple days on a new idea that
> seems too good before emailing :)
>
> And yes, protonmail is annoying that way, it detects the emails are from
> mailing lists but still spams them for not coming from a protonmail server...
>
> - Igno
>
>> -------- Original Message --------
>> Subject: Re: [Mimblewimble] Treeless block and UTXO set validation
>> Local Time: July 27, 2017 1:53 PM
>> UTC Time: July 27, 2017 1:53 PM
>> From: merop...@protonmail.com
>> To: Ignotus Peverell <igno.pever...@protonmail.com>
>> mimblewimble@lists.launchpad.net <mimblewimble@lists.launchpad.net>
>>
>> For some reason this message was sent to spam in Protonmail. May be why
>> there are so few replies.
>>
>> Sums are not sufficient to validate the UTXO set. Anybody who owns two
>> outputs summing to a commitment `C` can give a peer any pair of commitments
>> `C1` and `C2` with valid rangeproofs such that `C1 + C2 = C`, causing a
>> disagreement on the UTXO set and therefore a consensus failure.
>>
>> The same is true for inputs although the room for mutation is more limited
>> because there are only so many inputs to choose from.
>>
>> Same is true for kernels.
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>>> -------- Original Message --------
>>> Subject: [Mimblewimble] Treeless block and UTXO set validation
>>> Local Time: July 26, 2017 5:45 AM
>>> UTC Time: July 26, 2017 5:45 AM
>>> From: igno.pever...@protonmail.com
>>> To: mimblewimble@lists.launchpad.net <mimblewimble@lists.launchpad.net>
>>>
>>> Hi all,
>>>
>>> I think we could do without any type of Merkle tree, both in block headers
>>> and in the complete UTXO set (for sync). Please tell me if I'm wrong.
>>>
>>> A block is composed of the following information (ignoring header):
>>>
>>> - Outputs, with a commitment, range proof and a features bitset.
>>> - Inputs, which are just outputs commitments.
>>> - Kernels, with the excess value, its signature and the fee.
>>>
>>> The UTXO set necessary to sync-up a new node, assuming it has the header
>>> chain already, is composed of outputs (all unspents) and kernels (all of
>>> them) with same information as above.
>>>
>>> The purpose of putting some sort of Merkle tree root in a block header is
>>> to make it hard to mess with block data, as it would change the proof of
>>> work (also SPV but let's ignore that for a sec). Now lets get rid of all
>>> tree roots and just put 2 things in block headers: the sum of excess values
>>> over the whole block and the sum of excess values since genesis (summing
>>> all blocks). What can we mess with?
>>>
>>> - Output commitments can't be changed, wouldn't match the sums (both in
>>> block and total in UTXO set).
>>> - Output range proofs can't be changed, they would get invalidated with
>>> respect to their commitment.
>>> - Inputs can't be changed, would match the sum.
>>> - Kernel excess can't be changed, wouldn't match the sums (also both in
>>> block and total in UTXO set)
>>> - Kernel sig can't be changed, wouldn't validate with the excess as pubkey.
>>> - Kernel fee can't be changed, wouldn't validate with the sig.
>>>
>>> Only the feature bitsets could be potentially messed with, but right now
>>> they're only used to flag coinbase kernels and outputs and messing with
>>> that would also invalidate sums.
>>>
>>> The result would be that full nodes don't need to maintain any tree of any
>>> type, making it a lot simpler and saving a fair amount of space. Also when
>>> a new node wants to sync up, there's no tree to transfer and that process
>>> also get a fair amount simpler. If I'm right, I have to apologize to Merope
>>> for not seeing this earlier. And obviously we would lose some features, SPV
>>> would get harder and spent proofs, while still possible (I think), wouldn't
>>> be as elegant.
>>>
>>> - Igno
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
