mimblewimble team mailing list archive

[Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>]

32 bytes per transaction, plus witness data (signature and sometimes hash/locktime) is nowhere near Bitcoin's size.

Having said this, the scaling is still linear in the number of transactions, yes.



Andrew



On Wed, Jan 25, 2017 at 04:16:58PM -0500, Ignotus Peverell wrote:
> The range proofs are subject to cut-through and may be optimizable. The transaction kernels (r.i.p. excess value) aren't and as they increase in size, make scalability look a lot closer to bitcoin and potentially worse.
> 
> - Igno
> 
> 
> 
> -------- Original Message --------
> Subject: Re: [Mimblewimble] Hash preimages, ZKCPs, atomic swaps and HTLC's
> Local Time: January 24, 2017 7:52 AM
> UTC Time: January 24, 2017 3:52 PM
> From: apoelstra@xxxxxxxxxxxxxx
> To: Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>
> mimblewimble@xxxxxxxxxxxxxxxxxxx <mimblewimble@xxxxxxxxxxxxxxxxxxx>
> 
> On Mon, Jan 23, 2017 at 06:31:09PM -0500, Ignotus Peverell wrote:
> > A tangential concern of mine is also the fact that those signatures need to be kept in the chain forever, in some form of another. While sinking signatures as formulated in your (Andrew Poelstra) paper can be problematic, I think the general concept is interesting. And the more information we add to the signed message, the more difficult aggregation will be.
> >
> 
> Any information immediately makes it impossible to aggregate a la sinking signatures, with any signature scheme I'm aware of.
> 
> > By only including fees in the message, I had some hopes that some summable signature scheme could still be formulated. A more complex composition is likely to make aggregation completely impossible.
> >
> 
> Even fees must be hashed before signing, eliminating any special structure they had.
> 
> > An alternative could be to add Schnorr partial signatures (or some equivalent) signing the empty string, paired with the soon-to-be-renamed excess value. The Schnorr signatures could be aggregated in each block or group thereof and the soon-to-be-renamed excess value could eventually be pruned. However there are a couple issues remaining with this approach (mainly detecting which excess value is safe to prune) so I'm not convinced it's viable either.
> >
> 
> We can't have Schnorr signatures that sign the empty string, I'd expect there are related-key attacks related to this. Even sinking signatures could not sign the empty string, they had to sign a maximum blockheight, which means that transactions can be invalidated by reorgs even without malicious behaviour. In effect everything is a coinbase transaction and needs to be locked for many blocks.
> 
> > I just want to make sure we're all aware of the trade-offs, especially when there's interference with our scalability, privacy or simplicity goals.
> >
> 
> I think aggressive signature aggregation like sinking signatures is a no-go for the above reasons. We lose all complex script ability and seriously hamper usability with this "max blockheight" business, and all we get is compression of the blockchain (already only 10-20Gb for a Bitcoin-equivalent chain even with this extra signature stuff) to near-nothing. The rangeproofs, which are still critical to the public verifiability of noninflation, remain at 100+Gb.
> 
> 
> Cheers
> Andrew
> 
> 
> --
> Andrew Poelstra
> Mathematics Department, Blockstream
> Email: apoelstra at wpsoftware.net
> Web: https://www.wpsoftware.net/andrew
> 
> "A goose alone, I suppose, can know the loneliness of geese
> who can never find their peace,
> whether north or south or west or east"
> --Joanna Newsom

-- 
Andrew Poelstra
Mathematics Department, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

"A goose alone, I suppose, can know the loneliness of geese
 who can never find their peace,
 whether north or south or west or east"
       --Joanna Newsom

Attachment: signature.asc
Description: PGP signature