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: [email protected] > To: Ignotus Peverell <[email protected]> > [email protected] <[email protected]> > > 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
signature.asc
Description: PGP signature
-- Mailing list: https://launchpad.net/~mimblewimble Post to : [email protected] Unsubscribe : https://launchpad.net/~mimblewimble More help : https://help.launchpad.net/ListHelp
