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
|
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 CB6608DC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 06:04:35 +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 D37AB6C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 06:04:34 +0000 (UTC)
Date: Wed, 22 May 2019 06:04:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1558505072;
bh=B7HG4Zb+h+F2NgmpZz7xsvpJAsGTB5glTAT/596V/Rg=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=U39q3RQZSaY1WeK+rbhLGFs+K01P+MguwihvzmWEPWxJS9RvXd8K3wuS8dM7v6imr
vFgEfwkhMA8q/jUZJ23FnCX8EJBDJLt8l4Or+gqEoVAKTcCcAseYl7xBewYk4uBlQk
/p8MuUXw5lTwjPwJrbZ1dbCxh6BIGLV3JV4SNMzI=
To: Jeremy <jlrubin@mit.edu>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com>
In-Reply-To: <CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@mail.gmail.com>
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
<VU6YVz_dc9U4BhGd6WWNvYLS-DI1lBE14tpYdXEyIufTZ2OvqQfcWh6RVelCLWTQMWqiNsSf_AM3Pq2hzn3G62RIQwceLx54rRmD-zHCdNU=@protonmail.com>
<CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@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
X-Mailman-Approved-At: Wed, 22 May 2019 13:30:30 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY
proposal
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, 22 May 2019 06:04:35 -0000
Good morning,
Some more comments.
* I do not think CoinJoin is much improved by this opcode.
Typically, you would sign off only if one of the outputs of the CoinJoin =
transaction is yours, and this does not really improve this situation.
* Using this for congestion control increases blockchain usage by one TXO a=
nd one input, ending up with *more* bytes onchain, and a UTXO that will be =
removed later in (we hope) short time.
I do not know if this is a good idea, to increase congestion by making un=
necessary intermediate transaction outputs, at times when congestion is a p=
roblem.
* I cannot find a way to implement Decker-Russell-Osuntokun (or any offchai=
n update mechanism) on top of this opcode, so I cannot support replacing `S=
IGHASH_NOINPUT` with this opcode.
In particular, while the finite loop support by this opcode appears (at f=
irst glance) to be useable as the "stepper" for an offchain update mechanis=
m, I cannot find a good way to short-circuit the transaction chain without =
`SIGHASH_NOINPUT` anyway.
* Channel factories created by this opcode do not, by themselves, support u=
pdates to the channel structure.
But such simple "close only" channel factories can be done using n-of-n a=
nd a pre-signed offchain transaction (especially since the entities interes=
ted in the factory are known and enumerable, and thus can be induced to sig=
n in order to enter the factory).
More complex channel factories that can update the division of the factor=
y to channels cannot be done without a multiparty offchain update mechanism=
such as Decker-Wattenhofer or Decker-Russell-Osuntokun.
So, similarly to CoinJoin, I do not think it is much improved by this opc=
ode.
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 Wednesday, May 22, 2019 1:11 PM, Jeremy <jlrubin@mit.edu> wrote:
> Morning,
>
> Yes, in general, Bitcoin does not do anything to prevent users from disca=
rding their keys.
>
> I don't think this will be fixed anytime soon.
>
> There are some protocols where, though, knowing that a key was once known=
to the recipients may make it legally valid to inflict a punitive measure =
(e.g., via HTLC), whereas if the key was never known that might be a breach=
of contract for the payment provider.
>
> Best,
>
> Jeremy
>
> On Tue, May 21, 2019 at 7:52 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> > Good morning Jeremy,
> >
> > >If a sender needs to know the recipient can remove the covenant before=
spending, they may request a signature of an challenge string from the rec=
ipients
> >
> > The recipients can always choose to destroy the privkey after providing=
the above signature.
> > Indeed, the recipients can always insist on not cooperating to sign usi=
ng the taproot branch and thus force spending via the `OP_CHECKOUTPUTSHASHV=
ERIFY`.
> >
> > Regards,
> > ZmnSCPxj
|
