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 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
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
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
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.
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
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.
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
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
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
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
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
12 matches
Mail list logo