mimblewimble team mailing list archive

[Andrew Poelstra <apoelstra@xxxxxxxxxxxxxx>]

On Tue, Mar 07, 2017 at 02:18:53PM -0500, John Tromp wrote:
> > He also suggested the locktime should be cancellable and extendable by having
> > the would-be recipient reveal a key to the sender, but we didn't work out all
> > the details. If this works then we should be able to get the effect of a
> > relative lock-time, having indefinitely-open lightning channels, and so forth.
> > Exciting times.
> >
> > Therefore I revise my proposal again, to remove the explicit locktime, and
> > have only the fee.
> 
> "I send the coins to a 3-of-3 multisig: my key, his key, and a third
> key that I generate with some RSA timelock puzzle. Then I give him the
> corresponding pubkey and SNARK-prove to him that the privkey is a
> solution to the timelock puzzle."
> 
> This seems like quite a bit of complexity. What extra security
> assumptions are we relying on here?

"We", meaning public validators, are relying on no assumptions at all.

The people constructing the locktimes are depending on the security of the
zero-knowledge proof (which could be as simple as just hashes being random
oracles) and the security of the timelock puzzles (RSA problem being hard).

> I don't see the downside of simply requiring a locktime on every kernel...
> 

Extra identifying data which miners can identify and censor, additional data
being stored in the chain forever, additional validation cost for users who
aren't involved in the contract, permanent complexity of adding specific
contract enforcement logic to consensus code.

-- 
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