summaryrefslogtreecommitdiff
path: root/e7/ba016021234d0bb9822d034315ba9bd5df31da
blob: a591e938a67ceab785b864539695655d0675f909 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
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.