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
|
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 31254E46
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Dec 2018 11:47:45 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 22A71D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Dec 2018 11:47:43 +0000 (UTC)
Date: Mon, 24 Dec 2018 11:47:38 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1545652060;
bh=8miS8Yd9WGqd4iKxu1msm0Q5tnCshPfErBcmICCm/wk=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=tj58X/j/7O648NBYMRBLSMvat6AeFYFnHUX8QpAhEZp6faVEgZOMXlbitTS24dQxT
S6n43pIdV+xyGnzS7l9KCZiLEgkrQRI2XwJoLXIMjILdZNLn0GzZHrW8baxVO/t7IU
uoFmQUHZELXElpmub+HTwUvbD2MFlDW1mIYZlYtI=
To: Johnson Lau <jl2012@xbt.hk>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <B2h-WuZWvKKnCqz_qvciHFHf16SgY_63GAF_Y5KbsiJ_wRRoZMw-LBT6Beob9oYOzm9TMaeewJhZXqvPr7TizXOLBoOsOiKPQDyax4aefGY=@protonmail.com>
In-Reply-To: <CAABEECD-2B12-4852-A440-58809EB6BF56@xbt.hk>
References: <9F8C0789-48E9-448A-A239-DB4AFB902A00@xbt.hk>
<8z5NQkaOUo9z-wdBphQtZrxIf7OCtVQFvK3neMWvcRsngld5XJs-vt7CLuY46ZOp_pX8gEd92pMdkEkp8CUOMH9lUTw5ocWsbDPiaKdSa2I=@protonmail.com>
<34B38940-524D-42B9-8A67-6A62DCE04665@xbt.hk>
<KFCfNAmHhRvsDJs70UW3l4ssqBtdBrb8gYP5A3cN2hsTPrXVg7f5Yrt2LOo5V0QdAhhoooc3lllXxiiXSVt_28obYBl_XKAgEQkGg1kOj8I=@protonmail.com>
<CAABEECD-2B12-4852-A440-58809EB6BF56@xbt.hk>
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
X-Mailman-Approved-At: Mon, 24 Dec 2018 14:47:55 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging
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: Mon, 24 Dec 2018 11:47:45 -0000
Good morning Johnson,
Indeed, manual operation is risky.
However the intent is to reduce the requirements on commodity wallets in or=
der to integrate them into a combined onchain and offchain UI.
A boutique protocol would reduce the number of existing onchain wallets tha=
t could be integrated in such UI.
If we could make walletless offchain software in such method, *any* existin=
g wallet with an API to programmatically send arbitrary amount to arbitrary=
address can be integrated into such UI.
This could include hardware wallets.
Regards,
ZmnSCPxj
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 Sunday, December 23, 2018 12:56 AM, Johnson Lau <jl2012@xbt.hk> wrote:
> > On 22 Dec 2018, at 10:25 PM, ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
> > Good morning Johnson,
> >
> > > Generally speaking, I think walletless protocol is needed only when y=
ou want to rely a third party to open a offchain smart contract. It could b=
e coinswap, eltoo, or anything similar.
> >
> > I think a third party would be pointless in general, but then I am stro=
ngly against custodiality.
> > The idea is that you have some kind of hardware wallet or similar "some=
what cold" storage that you control yourself, and crate channels for your h=
ot offchain Lightning wallet, without adding more transactions from your so=
mewhat-cold storage to your hot offchain Lightning wallet on the blockchain=
.
> > Then you could feed a set of addresses to the hot offchain wallet (addr=
esses your somewhat-cold storage controls) so that when channels are closed=
, the funds go to your somwhat-cold storage.
> > I also doubt that any custodial service would want to mess around with =
deducting funds from what the user input as the desired payment. I have not=
seen a custodial service that does so (this is not a scientific study; I r=
arely use custodial services); custodial services will deduct more from you=
r balance than what you send, but will not modify what you send, and will p=
revent you from sending more than your balance minus the fees they charge f=
or sending onchain.
> > Even today, custodial services deducting from your sent value (rather t=
han the balance remaining after you send) would be problematic when interac=
ting with merchants (or their payment processors) accepting onchain payment=
s; the merchant would refuse to service a lower value than what it charges =
and it may be very technically difficult to recover such funds from the mer=
chant.
> > I expect such a custodial service would quickly lose users, but the wor=
ld surprises me often.
> > Regards,
> > ZmnSCPxj
>
> If the users are expected to manually operate a hardware wallet to fund t=
he channel, they might do stupid things like using 2 wallets to make 2 txs,=
thinking that they could combine the values this way; or =E2=80=9Crefillin=
g=E2=80=9D the offchain wallet with the address, as you suggested. While I =
appreciate the goal to separate the coin-selecting wallet with the offchain=
wallet, I am not sure if we should rely on users to do critical steps like=
entering the right value or not reusing the address. Especially, the setup=
address should be hidden from user=E2=80=99s view, so only a very few =
=E2=80=9Cintelligent advanced users" could try to refill the channel.
>
> If we don=E2=80=99t rely on the user as the bridge between the hardware w=
allet and the offchain wallet, we need a communication protocol between the=
m. With such protocol, there is no need to spend the setup TXO with NOINPUT=
.
|
