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
timization 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 AM
From:
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
UTC Time: March 7
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
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.
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
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, 2017 2:47 PM
UTC Time
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
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
9 matches
Mail list logo
