Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E744A11D6 for ; Wed, 28 Feb 2018 04:34:42 +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 1CFF7CF for ; Wed, 28 Feb 2018 04:34:41 +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 BD0AF14C0B9 for ; Wed, 28 Feb 2018 13:34:40 +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; 28 Feb 2018 13:34:40 +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 AFA494C072 for ; Wed, 28 Feb 2018 13:34:40 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) Received: from gw27.oz.hdemail.jp (ip-10-126-140-29.ap-northeast-1.compute.internal [10.126.140.29]) by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id A403214C0B9 for ; Wed, 28 Feb 2018 13:34:40 +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 gw27.oz.hdemail.jp (Postfix) with ESMTP id 49C34148C146 for ; Wed, 28 Feb 2018 13:34:40 +0900 (JST) X-Received: by mail-qt0-f200.google.com with SMTP id h21so1021024qtm.22 for ; Tue, 27 Feb 2018 20:34:40 -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:content-transfer-encoding; bh=YEtsbiQr+Fd9QyyHpemKTqdRr0NENnrhdhzmxtQWcAA=; b=gpxvq61uZbaNgBUlcJYPxNGJR+ctWI1T42uYI1IBzXiwj9BmJr16nzYD4eQeMMyquF PtlQ9jPysTiqHVBL7IIIo2CTxRX/D0uHIlzcEpjtpznCILmihvKpnnK9xwQ+Pbio1MK7 yd/dFiLfXMt9D/hcB8AWbEHvRifEUTpDdUEUDJmqwD84gw7bIsOZIM2EbqzCjjpsUQVa by9KNui3YqgEofojfdRy0yWUU9Pp48nexHJXJPfGHnMxm0kakKJsiFUsNaHIStdAx8Js 30ZIC90CqlSImS78Q0QL6qQ4rs6hps5XtrtvER4AzDqqqMs02zBkBbyyt/FG/OENqRwA YsAw== X-Gm-Message-State: APf1xPAoffxbQkETHCYGXku9IahkmOGlkR8JA5DtkdbDAWlNF6SJwpYx RGmj8P8uBI8b6lFnxLJakeMIWEe1NN4KrquTPpvq9KNJV+5hoU9lpBDk8MKjYhJog7egkpySuwn 7wqDFTzuFM98VjL0qxOVsFrNz88f+K52MzkJ9ZFybufV9BPn1TuU5PAOlPuNG8eWBSZvAlG/8S6 LpmWXJnTZc6LwxMcFx87cgf9m8lctD82qxPEyNeje/sO9kHfDr3I8DQBb3TbfZsJZlWI9uVk0jf AwO6BhRCY3XGCW1ORYZ6f9dv8GRVaK85oh/rfrUxpT9WcWxfRp0qZ3/EhWNsyyVn12x/MonWt7S TgVCANaZ28p7lYprjJC30TWCSdg= X-Received: by 10.55.21.16 with SMTP id f16mr19219466qkh.252.1519792478697; Tue, 27 Feb 2018 20:34:38 -0800 (PST) X-Google-Smtp-Source: AG47ELtOm4sKD8tkYtP+xIMJzWzJWxZ1eoAy6y80YznULSeo+Rso9t6dmKEK7Py1brF2V1ozAknjIMr2EG51+aF/zd8= X-Received: by 10.55.21.16 with SMTP id f16mr19219450qkh.252.1519792478396; Tue, 27 Feb 2018 20:34:38 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.12.176.3 with HTTP; Tue, 27 Feb 2018 20:34:18 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?44Ki44Or44Og44CA44Kr44O844Or44Oo44OP44Oz?= Date: Wed, 28 Feb 2018 04:34:18 +0000 Message-ID: To: Bitcoin Protocol Discussion 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: Wed, 28 Feb 2018 14:20:36 +0000 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 04:34:43 -0000 A few p.s.'es: 1. Graftroot probably breaks this (someone could just sign the time-locked output with a script that has no time-lock). 2. Address reuse of discarded privkeys would be a problem. A way to alleviate might be that freezing includes a send to a new address and the privkeys for that new one are discarded instead. One extra transaction, but reduces the risk of accidentally throwing away `donations4mybook` vanity keys. -Kalle. On Wed, Feb 28, 2018 at 3:47 AM, =E3=82=A2=E3=83=AB=E3=83=A0=E3=80=80=E3=82= =AB=E3=83=BC=E3=83=AB=E3=83=A8=E3=83=8F=E3=83=B3 wrote: > With the recent trend of physically robbing people for bitcoin (or > other cryptocurrencies), I thought it would be beneficial to introduce > a standard for locking up a portion of your bitcoin in a simple > 'gotta-wait-awhile' system. > > The idea is to simply create a transaction spending a set of UTXOs to > a P2SH address with an OP_CSV attached to it, and then throw away the > private keys. > > To spend the bitcoin, you would have to broadcast the transaction and > wait the given amount of time, then use the new txout. > > There are several ways to shoot yourself in the foot trying to do this > manually, but e.g. Bitcoin Core could handle this in a fairly > straightforward manner by introducing two new commands, which I call > freeze and unfreeze: > > bitcoin-cli freeze [amount OR array of txid+vout objects] [days, default = 1] > > E.g. bitcoin-cli freeze 10 5 > E.g. bitcoin-cli freeze ["abc123:1", "def346:0"] 3 > > The unfreeze command would by default list all freezes: > > bitcoin-cli unfreeze > txid days status > bcd123 5 frozen > dca999 3 frozen > > including the txid would broadcast the unfreeze and status would > become 'thawing' until the amount becomes available: > > bitcoin-cli unfreeze bcd123 > > bitcoin-cli unfreeze > txid days status > bcd123 5 thawing > dca999 3 frozen > > The benefit of this is that it becomes physically impossible for you > to spend the coins until you thaw them, and if this becomes standard > enough, it should disincentivize potential robbers as it would be > expected that you keep most of your assets locked up. They could of > course hold you hostage until the period is over, which may be worse, > but I think that kind of operation would be substantially more > difficult than a simply rob-and-run. > > The drawback is that you have to broadcast a transaction in order to > spend the content, and you cannot bump the fee so the transaction > could get stuck in a high-fee situation. > > -Kalle.