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
signature.asc
Description: PGP signature
-- Mailing list: https://launchpad.net/~mimblewimble Post to : mimblewimble@lists.launchpad.net Unsubscribe : https://launchpad.net/~mimblewimble More help : https://help.launchpad.net/ListHelp
