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: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AD735CD3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Aug 2019 03:03:15 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5367F829
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Aug 2019 03:03:14 +0000 (UTC)
Date: Thu, 08 Aug 2019 03:03:04 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1565233391;
bh=QLvyBG2WGxvveyxhxCvZwA1KoE/PdVF3WkvCTL2cLco=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=l3LuxCMgBdp0i5LP/PBVAO3j2Ij6zwOqcTdWTn8x5nx0ooweV3vyGf26hyTqRbJfW
GuaFoLZCb99QfrXcFuu8r5F2y67b/WbxQF2SxIlJXmEi4cwh0iq5YytXZWRFwbJJkb
3S6yO87R07EAbW5MyGdJpzp4hU+zPDly8NW1AuWU=
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <xAXfAdir4XrXKbi1j7Jnpmr70WJQQ_iuGUHRjHJZ3bXMETO7Sf1w40Zr6Rvy8BLmheoaQewjzyLMVZKpUU7h1sHtuHOOocBaw8fzHiapfd4=@protonmail.com>
In-Reply-To: <CAKzdR-q3nnWggUz7aE0p1ts8KsWVigznjuJpR1SNzKNXs+GmiA@mail.gmail.com>
References: <CABaSBawe_oF_zoso2RQBX+7OWDoCwC7T2MeKSX9fYRUQaY_xmg@mail.gmail.com>
<CABaSBawQhC5EDbyc8c0rk1JxjF2NJBn+mb6tPgvTwkNXOPcSGg@mail.gmail.com>
<CABLeJxTE09d3ujndAhrxiVwBmXkdxyUM9QfKTE69QQcNDbr5Qg@mail.gmail.com>
<CAKzdR-q3nnWggUz7aE0p1ts8KsWVigznjuJpR1SNzKNXs+GmiA@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback
mechanisms
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: Thu, 08 Aug 2019 03:03:15 -0000
Good morning Sergio,
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Thursday, August 8, 2019 10:09 AM, Sergio Demian Lerner via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Seems to be comparable to the proposed "Tick Method" from 2013:
> https://bitcointalk.org/index.php?topic=3D307211.msg3308565#msg3308565=
=C2=A0
>
> However I remember that someone told me the tick method had a flaw..
Maybe the use of `SIGHASH_NONE` for both inputs of the TxOut transactions?
Also txid malleability.
The first can be fixed by not using `SIGHASH_NONE` for one of the inputs an=
d requiring a hot privkey to sign with that.
The second can be fixed by using SegWit outputs.
Regards,
ZmnSCPxj
> =C2=A0
>
> On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev <bitcoin-de=
v@lists.linuxfoundation.org> wrote:
>
> > Does revaulting vault up with the same keys, or new ones?
> >
> > Are they new derivation paths on the same key?
> >
> > Would love some expanded explanation on how you=E2=80=99re proposing th=
is would work.
> >
> > Thanks,
> > Dustin
> >
> > On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev <bitcoin-de=
v@lists.linuxfoundation.org> wrote:
> >
> > > Hi,
> > >
> > > One of the biggest problems with the vault scheme (besides all of the
> > > setup data that has to be stored for a long time) is an attacker that
> > > silently steals the hot wallet private key and waits for the vault's
> > > owner to make a delayed-spend transaction to initiate a withdrawal
> > > from the vault. If the user was unaware of the theft of the key, then
> > > the attacker could steal the funds after the delay period.
> > >
> > > To mitigate this, it is important to choose a stipend or withdrawal
> > > amount per withdrawal period like x% of the funds. This limits the
> > > total stolen funds to x% because once the funds are stolen the user
> > > would know their hot key is compromised, and the user would know to
> > > instead use one of the other clawback paths during all of the future
> > > withdrawal delay periods instead of letting the delay timeout all the
> > > way to the (stolen) default/hot key.
> > >
> > > The reason why a loss limiter is the way to go is because there's
> > > currently no way (that I am aware of, without an upgrade) to force an
> > > attacker to reveal his key on the blockchain while also forcing the
> > > attacker to use a timelock before the key can spend the coins. I am
> > > curious about what the smallest least invasive soft-fork would be for
> > > enabling this kind of timelock. There are so many covenant proposals
> > > at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY,
> > > ....). Or there's crazy things like a fork that enables a transaction
> > > mode where the (timelock...) script of the first output is
> > > automatically prefixed to any of the other scripts on any of the othe=
r
> > > outputs when an input tries to spend in the future. A thief could add
> > > his key to a new output on the transaction and try to spend (just lik=
e
> > > a user would with a fresh/rotated key), but the OP_CSV would be
> > > automatically added to his script to implement the public observation
> > > delay window.
> > >
> > > Also, there was other previous work that I was only informed about
> > > today after posting my proposal, so I should mention these as related
> > > work:
> > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February=
/015793.html
> > > https://blog.oleganza.com/post/163955782228/how-segwit-makes-security=
-better
> > > https://www.youtube.com/watch?v=3DdiNxp3ZTquo
> > > https://bitcointalk.org/index.php?topic=3D5111656
> > >
> > > - Bryan
> > > http://heybryan.org/
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
