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 BDC13104A for ; Thu, 1 Mar 2018 05:12:19 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mo.garage.hdemail.jp (mo.garage.hdemail.jp [46.51.242.127]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 99264110 for ; Thu, 1 Mar 2018 05:12:18 +0000 (UTC) Received: from ip-10-217-1-36.ap-northeast-1.compute.internal (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-mf-postfix) with SMTP id 3AB4B14C0B9 for ; Thu, 1 Mar 2018 14:12:17 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from unknown (HELO mo.garage.hdemail.jp) (127.0.0.1) by 0 with SMTP; 1 Mar 2018 14:12:17 +0900 X-Received: from mo.garage.hdemail.jp (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-ma-postfix) with ESMTP id 05AAB4C072 for ; Thu, 1 Mar 2018 14:12:17 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) Received: from gw14.oz.hdemail.jp (ip-10-188-130-13.ap-northeast-1.compute.internal [10.188.130.13]) by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id 023A114C0C5 for ; Thu, 1 Mar 2018 14:12:17 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from mail-qt0-f200.google.com (lb05.oz.hdemail.jp [54.238.57.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw14.oz.hdemail.jp (Postfix) with ESMTP id 827D7148C064 for ; Thu, 1 Mar 2018 14:12:16 +0900 (JST) X-Received: by mail-qt0-f200.google.com with SMTP id h21so3872708qtm.22 for ; Wed, 28 Feb 2018 21:12:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8UrlrRQKp+ofkiSF0ibKyovB++SFD1+T3TeByGdaY7I=; b=bsJ0VNGpq9jekLZwr3pZ4JzFOyP1bENqsuDDjW6D4f7usTop8RHyduCgxmA7rKT/gz dQHplri/nxVFw4Kqs0SQsu7t8snTG7dr2Fa8R5dJJIh4abk6MOhZNpoPQU0mlvbk1plf JqyKbhqh6gF2hQwXs7gvfFr0B5cbtoxBwBI8ysbROghe98n3/KzrefWWkR1he7PbidyQ NWkMhilpMOgh7USJ5xdd3bMeI0+cV+7lrv2T0UT70w5s+X4c1L2gLC2aJxSS1AsgMFkI gpeJVsNFI+/IMLOAhM7/aF9mlCAf5J0aImzmhWeeHJfs0qw1t53+j4r1vMUHmQnkod2l iTRQ== X-Gm-Message-State: AElRT7E5uipRNygRAgb0TB+jMqqUiH+Tf+bRq29DTM8j2cjnu+1nlr1d 3ALOprMqz3c514xn7PaHo93qeG/TQqsVPqT32Cvookmb1PefktZBBhrCHBZ4jiggBCzbonS8cVU /xkJ438XkQY/1HqNcjG++8Z/DiVzigBrIXOC3tK/1PVVEr5c/gY+gdbAZwppJFHxM5UA/nmLcNr kaQkEK+ooT4pbXvxqULTxlfzDk5w5ntMjzQORzbqI+QLUXyAIIw0Z5OMrModbICzwxWusW7p+3d fsmr+5/oA5tgsuFB2nV2BtyO5XzePIBcPfBmx4KuehiiKPyUcmMQnPMC9gml7wGigZ4CkJtu6Nt y5/iFXJEBlFK3SdwB64wzywAKJ0= X-Received: by 10.55.97.66 with SMTP id v63mr889141qkb.266.1519881134940; Wed, 28 Feb 2018 21:12:14 -0800 (PST) X-Google-Smtp-Source: AG47ELsEFp2euCkYZH2cRqQ1PqQa/XGAQDvo1P++O2J1pRqVIONwQRLRyyg3g8BXoajC/rPcLro/N5ZMKcmprv3lYsc= X-Received: by 10.55.97.66 with SMTP id v63mr889122qkb.266.1519881134593; Wed, 28 Feb 2018 21:12:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.12.176.3 with HTTP; Wed, 28 Feb 2018 21:11:54 -0800 (PST) In-Reply-To: <20180228223044.GA31415@erisian.com.au> References: <20180228223044.GA31415@erisian.com.au> From: =?UTF-8?B?44Ki44Or44Og44CA44Kr44O844Or44Oo44OP44Oz?= Date: Thu, 1 Mar 2018 05:11:54 +0000 Message-ID: To: Anthony Towns Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 05 Mar 2018 13:27:57 +0000 Cc: Bitcoin Protocol Discussion 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: Thu, 01 Mar 2018 05:12:19 -0000 On Wed, Feb 28, 2018 at 10:30 PM, Anthony Towns 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. That kind of defeats the purpose. If you go through the trouble of doing that, you can just do multisig and skip the freezing part entirely. A robber would have to get you and the cosigner to sign in both cases, and the CLTV could be overridden with graftroot. On Wed, Feb 28, 2018 at 11:36 PM, Adam Back wrote: > 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. 1. Create TX1=3D(tx, sig) from UTXO A to p2sh B which has a CSV timelock. Discard privkey A. 2. After broadcasting TX1, you need privkey B to spend it. 3. Use graftroot and privkey B with a script without timelock to spend B. The robber can simply force you to execute step 3, since you have the privkey to B. > One drawback is deleting keys may itself be a bit difficult to assure > with HD wallet seeds setup-time backup model. That's a good point. Even more of a reason to include as part of 'freezing' a send to a new ephemeral key as 'initialization'. Sucks to pay triple fees though (freeze ephemeral + unfreeze + actual use). > 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. I was hoping there was a way for a person to simply lock-up the major portion of their coins easily. As a sidenote: a security firm (e.g. one that comes to your house when the alarm goes off) could have a service where seeing an unfreeze transaction which you have told them about without you giving a heads up beforehand is equal to alarm going off. -Kalle.