Re: [Mimblewimble] Compact blocks

2017-04-27 Thread John Tromp
dear Igno, > BIP152 introduced a good solution by introducing short transaction ids > (which we can generalize to inputs/outputs/kernels): > > https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#Short_transaction_IDs > > It does force a full re-hashing of the pool on each block but siph

Re: [Mimblewimble] Compact blocks

2017-04-27 Thread Ignotus Peverell
re optimization right now. Bitcoin doesn't have such a thing and just plain ban on misbehavior seems to work well enough so far. - Igno Original Message ---- Subject: Re: [Mimblewimble] Compact blocks Local Time: March 4, 2017 4:20 PM UTC Time: March 5, 2017 12:20

Re: [Mimblewimble] Compact blocks

2017-03-07 Thread Ignotus Peverell
I'm fine with 2 Merkle trees. Seems like there won't be much that's non-witness in the kernel though. - Igno P.S. Loving all the mailing list activity today :) Original Message -------- Subject: Re: [Mimblewimble] Compact blocks Local Time: March 7, 2017 11:24 AM UT

Re: [Mimblewimble] Compact blocks

2017-03-07 Thread Myrtle Warren
It should be sufficient for the output and its rangeproof to be separately committed to the chain to prevent ambiguity. Committing to rangeproofs, which are witness data and can be ignored (at a trust tradeoff), will reduce flexibility. This is a good point. I'm not opposed to the rangeproof an

Re: [Mimblewimble] Compact blocks

2017-03-07 Thread Merope Riddle
From: moaningmyr...@protonmail.com It should be sufficient for the output and its rangeproof to be separately committed to the chain to prevent ambiguity. Committing to rangeproofs, which are witness data and can be ignored (at a trust tradeoff), will reduce flexibility. This is a good point.

Re: [Mimblewimble] Compact blocks

2017-03-07 Thread Merope Riddle
Myrtle Warren said: > As far as I can tell, the specific construction of the output hash's preimage > has not been determined. If we move forward with this mechanism, it becomes > critically important that the hash covers the range proof itself. A situation > where the hash resolves ambiguously

Re: [Mimblewimble] Compact blocks

2017-03-06 Thread Myrtle Warren
Definitely a fan of compact blocks to mitigate some impact of a faster block time. A few random thoughts below: On range proof validation: Doing all we can to reduce duplicate range proof transmission seems like a big win. I prefer the amended version in the last email to the original proposal.

Re: [Mimblewimble] Compact blocks

2017-03-04 Thread Ignotus Peverell
of collisions with a pool of 100,000 elements would still be less than 0.0003%. 4 bytes would likely be too small, a transaction pool of the same size would have 69% of collisions. - Igno Original Message ----l Subject: Re: [Mimblewimble] Compact blocks Local Time: March 3, 2

Re: [Mimblewimble] Compact blocks

2017-03-03 Thread John Tromp
dear Igno, > That is, the receiver will look up how many kernel she has matching the hint. > If 0 or more than 1, it will query peers for a list of all known > matching kernels. Uhm, that should be: ask the sending peer to expand the hint to a full kernel. regards, -John -- Mailing list: https

Re: [Mimblewimble] Compact blocks

2017-03-03 Thread John Tromp
dear Igno, >> The second largest piece of data is composed of the transaction kernels >> (~100 bytes each). We can't fully avoid sending those as they're not >> "anchored" on anything, like the range proof is anchored on an output. >> However we could send a shortened version of their hash. In thi

Re: [Mimblewimble] Compact blocks

2017-03-01 Thread Ignotus Peverell
ead of the empty string) and include it in the kernel. - Igno Original Message Subject: Re: [Mimblewimble] Compact blocks Local Time: March 1, 2017 2:37 PM UTC Time: March 1, 2017 10:37 PM From: john.tr...@gmail.com To: Ignotus Peverell , mimblewimble@lists.launchpad.net dear I

Re: [Mimblewimble] Compact blocks

2017-03-01 Thread John Tromp
dear Igno, > In this discussion, I'm only interested in the size of a block when sent > across the wire during propagation. It's desirable in this context to have > small block sizes (in bytes) so that blocks can traverse the network quickly > without causing too much additional traffic. As most n