diff options
author | アルム カールヨハン <karl@dglab.com> | 2018-02-28 04:34:18 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2018-02-28 04:34:42 +0000 |
commit | b9df5ece23fe0c51e76d9ddd7ce01307934bd0b1 (patch) | |
tree | c77ecf5f92ed9e63fcab831b28c59437994f0829 | |
parent | d15631ae9be546cd501dfba3d94e2cd2c800c591 (diff) | |
download | pi-bitcoindev-b9df5ece23fe0c51e76d9ddd7ce01307934bd0b1.tar.gz pi-bitcoindev-b9df5ece23fe0c51e76d9ddd7ce01307934bd0b1.zip |
Re: [bitcoin-dev] Simple lock/unlock mechanism
-rw-r--r-- | e7/ba016021234d0bb9822d034315ba9bd5df31da | 159 |
1 files changed, 159 insertions, 0 deletions
diff --git a/e7/ba016021234d0bb9822d034315ba9bd5df31da b/e7/ba016021234d0bb9822d034315ba9bd5df31da new file mode 100644 index 000000000..a591e938a --- /dev/null +++ b/e7/ba016021234d0bb9822d034315ba9bd5df31da @@ -0,0 +1,159 @@ +Return-Path: <karljohan-alm@garage.co.jp> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id E744A11D6 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 28 Feb 2018 13:34:40 +0900 (JST) +X-Received: by mail-qt0-f200.google.com with SMTP id h21so1021024qtm.22 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CALJw2w4hKCAJY5U7Li82FbHHnXZKjcZ0Cw67V+=WxvknkY=Zxg@mail.gmail.com> +References: <CALJw2w4hKCAJY5U7Li82FbHHnXZKjcZ0Cw67V+=WxvknkY=Zxg@mail.gmail.com> +From: =?UTF-8?B?44Ki44Or44Og44CA44Kr44O844Or44Oo44OP44Oz?= <karl@dglab.com> +Date: Wed, 28 Feb 2018 04:34:18 +0000 +Message-ID: <CALJw2w7BQcMEHDa=mx6Gf_JQP603D_hpPq1YN5Em1cfsr4BDAw@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <karl@dglab.com> 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. + |