summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorアルム カールヨハン <karl@dglab.com>2018-02-28 04:34:18 +0000
committerbitcoindev <bitcoindev@gnusha.org>2018-02-28 04:34:42 +0000
commitb9df5ece23fe0c51e76d9ddd7ce01307934bd0b1 (patch)
treec77ecf5f92ed9e63fcab831b28c59437994f0829
parentd15631ae9be546cd501dfba3d94e2cd2c800c591 (diff)
downloadpi-bitcoindev-b9df5ece23fe0c51e76d9ddd7ce01307934bd0b1.tar.gz
pi-bitcoindev-b9df5ece23fe0c51e76d9ddd7ce01307934bd0b1.zip
Re: [bitcoin-dev] Simple lock/unlock mechanism
-rw-r--r--e7/ba016021234d0bb9822d034315ba9bd5df31da159
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.
+