From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AC5E9F9F for ; Wed, 28 Feb 2018 23:36:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com [209.85.216.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 16955E7 for ; Wed, 28 Feb 2018 23:36:07 +0000 (UTC) Received: by mail-qt0-f181.google.com with SMTP id z14so5338748qti.2 for ; Wed, 28 Feb 2018 15:36:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=37J98srGwsFQesRBuBhmx057vi1uFvrTDxgb50wGVBg=; b=TDxIrC/L6J05Ii11B1sZj78ASpiIRtQWLonnoD31JAwgqp+4ZgqxDeBP25VmeAPD93 tUjsiuhW+d+xDfUIbcRndZO56vxkKofjRdr+SbPkFTAUyp8nM7ilycjDX79ueo63RdK3 uMCMFgILvBszmfCEGPEMnNEz4t26BdES8C3KDO1m5gYxQOHkifkqOViu3BaZrk+/bZu7 LjrNYibvtIOtzpgYeZfceI1O0p2rg8q0TIxBKpUkZ/iVdrqhznSUXPcSqZzblCtJE4rq 3G2Xe2/msDIXJ/ZhRqa/z2U+JlnXYMr/MzsqKjMh5mxs8X2KNMETMI4UPci5a4gigYum Jprw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=37J98srGwsFQesRBuBhmx057vi1uFvrTDxgb50wGVBg=; b=YRWBO8WTqrs4JgBNUJQKEc845lDgBSVj2Q32E/65G7Co+EwUp7BglB6zz7t9LnLzZt BqSX9qbCV1RLKfreFsza0WowKUp4OHI83ggnrvhJ3ySeYDSiVdbR2xgYvFrZuFRB9eau RWcS1jEDaZ/+WPa980bIZdT9KT4vORN2MqV5FqlPr3hpVzjPrkbYohI7r7QtyBpgjHXL 0fq7kwVXNKF6tBCcUInUL2P6D+CC0LElFw9tnsRD6lf5IeWobazgMlpiK+TH+IWrWDa+ npaqCJ4LusQ//h57esQaF/Xw/bFxMf0x324uyTlePtCgBjzG/lGczEdERParGa0NNVAi OrTQ== X-Gm-Message-State: APf1xPAzBPSZI02TEAVCy0jirrYbsG6FGSe75VG7QzgyEnbwOahl50Lq YGFeg+C6v8FGWaV5Dt95NM2hZCn0dtYgb3/yqpA= X-Google-Smtp-Source: AG47ELudtKxA562hnqhj6hqufLlCA55L/qP3xLaWB30WMO20WY6N+tQ6zd+vQoMpQCiNT9AIhouZTTfgja1nKFRCHDU= X-Received: by 10.200.0.209 with SMTP id d17mr27270126qtg.336.1519860966108; Wed, 28 Feb 2018 15:36:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.149.243 with HTTP; Wed, 28 Feb 2018 15:36:05 -0800 (PST) Reply-To: adam@cypherspace.org In-Reply-To: <20180228223044.GA31415@erisian.com.au> References: <20180228223044.GA31415@erisian.com.au> From: Adam Back Date: Thu, 1 Mar 2018 00:36:05 +0100 Message-ID: To: Anthony Towns , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: =?UTF-8?B?44Ki44Or44OgIOOCq+ODvOODq+ODqOODj+ODsw==?= Subject: Re: [bitcoin-dev] Simple lock/unlock mechanism X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 23:36:07 -0000 Coincidentally I had thought of something similar to what Kalle posted about a kind of software only time-lock vault, and described the idea to a few people off-list. Re. Root incompatibility, if the key is deleted (as it must be) then a delegated signature can not be made that bypasses the CSV timeout restriction, so Root should not be incompatible with this. I think it would be disadvantageous to mark keys as Rootable vs not in a sighash sense, because then that is another privacy/fungibility loss eroding the uniformity advantage of Root when the delegate is not used. One drawback is deleting keys may itself be a bit difficult to assure with HD wallet seeds setup-time backup model. As Anthony described I think, a simpler though less robust model would be to have a third party refuse to co-sign until a pre-arranged time, and this would have the advantage of not requiring two on-chain transactions. With bulletproofs and CT rangeproofs / general ECDL ZKPS there is the possibility to prove things about the private key, or hidden attributes of a public key in zero-knowledge. Kind of what we want is to place private key covenants, where we have to prove that they are met without disclosing them. For example there is a hidden CSV and it is met OR there is no hidden CSV so it is not applicable. Adam On 28 February 2018 at 23:30, Anthony Towns via bitcoin-dev wrote: > On Wed, Feb 28, 2018 at 04:34:18AM +0000, =E3=82=A2=E3=83=AB=E3=83=A0 =E3= =82=AB=E3=83=BC=E3=83=AB=E3=83=A8=E3=83=8F=E3=83=B3 via bitcoin-dev wrote: >> 1. Graftroot probably breaks this (someone could just sign the >> time-locked output with a script that has no time-lock). > > Making the graftroot key be a 2-of-2 muSig with an independent third part= y > that commits to only signing CLTV scripts could avoid this. Making it > 3-of-3 or 5-of-5 could be even better if you can find multiple independen= t > services that will do it. > > Cheers, > aj > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev