path: root/88/7a8cd50fcceca696317d9e1bff34ef19240d4e

Return-Path: <kimjuan.chan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 727242B6E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Oct 2018 04:26:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com
	[209.85.221.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 502406FB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Oct 2018 04:26:48 +0000 (UTC)
Received: by mail-wr1-f44.google.com with SMTP id l6-v6so27534735wrt.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Oct 2018 21:26:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:from:date:message-id:subject:to;
	bh=Mb9Tk96jI7p7mNNATzoLQxeB0CH6AtB5Ujh1ppoCx3M=;
	b=bfcc0UbefnqTtjHcHAoeiOoJ9WqokXGn5BHMxOpttgOw2V3gmsc6DNIM5kskNQyYMX
	6JXzsFNt7iFNF0Jag+R+uKHQpQFNyaGQ+ghcemAHYiJTwDxB7TXqw5IoqWbuab7WEsZd
	24Y8VlW3Kpw8HqTcK6EBbA+8Lj+nMZihyEgiq4JLTpwlPqVHI4cg4Zh/Timj1PL32QcV
	LEvXzQ5hDftakGkPBPU6SH5kU1NofXNohQ3LPLnuU+X2uOoeDVuqGU0HlAcIuQnxK91M
	Deup5hqpej6cWDQhmwg74feUvQsCbqESBuxYDYQqsusSjDHRHvcLS6cDjn37GYhOs0DP
	5BKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
	bh=Mb9Tk96jI7p7mNNATzoLQxeB0CH6AtB5Ujh1ppoCx3M=;
	b=H/r4shOf0zQKn+chTRrgfnIc7lli3bhObErdQxBsu1puV8661WVOuB0yF3OeQZzQDZ
	2afpys/8JHujiucfxqu+maS4qM5b8qzxSmm/SkEzXZJkhZaW2JxY+xti5MlpU/w8Kojp
	JDYruiXKcYjBeAwTN4P+/fcbz3oExVDconTXAvM0+ZNu4kiolh4HADWjynSTlMAA04DN
	8l/CJIDxemH7wLUo2Hd705JCaOzQru9Idsn/+jbNc22vUfaieanA6YYOAAyOtRFIGTCM
	wniFhwykpXgYzGwtUHGEz/ixKtstRrl58PimUS9/NCP71I3Jp6gtFKE+klgFIc+oU+sN
	9/mA==
X-Gm-Message-State: ABuFfogivYEmtd/3AMrWeUrC65upQwqoyx96XUaASDUGXVU3TuKA8AKi
	Vx/CgwJd6FIpx19t1IoWoDu/Nc7PEoUp6x9kbvaTu+Ml
X-Google-Smtp-Source: ACcGV61AtnJR1LZnsxXZVv9uSysGGeLhmbm5Dafi27A/IZZEwP+SrJg455yIhOxttTNTuAo1CWaMmxZbK6Y90PhNAM0=
X-Received: by 2002:adf:a387:: with SMTP id l7-v6mr23474558wrb.1.1539750406550;
	Tue, 16 Oct 2018 21:26:46 -0700 (PDT)
MIME-Version: 1.0
From: kim juan <kimjuan.chan@gmail.com>
Date: Wed, 17 Oct 2018 12:26:34 +0800
Message-ID: <CAAKtTCt1_MTh38Bsft6_V65cLBcxHOrvsXR8yen_Ag1AgWtxcw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="0000000000000678fc0578651476"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	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, 17 Oct 2018 04:39:06 +0000
Subject: [bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY
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, 17 Oct 2018 04:26:49 -0000

--0000000000000678fc0578651476
Content-Type: text/plain; charset="UTF-8"

Discussing the possibility of a new opcode (OP_CHECKTXOUTSCRIPTHASHVERIFY)
for the Bitcoin scripting system that allows a transaction output to be
only spendable in a predefined manner.

*Brief Description*

Bitcoin transactions have a txoutScript (scriptPubKey) field for each
output.
txoutScriptHash=Hash160(txoutScript)

*Word*: OP_CHECKTXOUTSCRIPTHASHVERIFY
*Opcode*: 184 (OP_NOP9)
*Input*: x
*Output*: x / fail*
*Description*:
Marks transaction as invalid if txoutScriptHash is not equal to top stack
item and value of txoutScript is not equal to OP_HASH160
ThisRedeemScriptHash OP_EQUAL*.


** Not entirely certain here, always have this impression new opcode has to
"NOP or fail" to ensure it can be implemented. As a result, the item may
also has to be dropped explicitly.*** So that change can be sent back to
the this redeem script. There are challenges to generalize this as a script
hash cause of some cyclic reference. Not sure if cyclic is the correct
term, ie: A = hash (B's hash) and B = hash (A's hash) is impossible.*

*Sample use case*

Acme has an ordinary key pair and a secure key pair. The ordinary key pair
is assumed to be in a less secure environment.  The private key of the
secure key pair will never ever expose itself until the moment it needs to
revoke transaction of the ordinary key pair.

redeemScript:
  IF
    2 <Acme's pubkey> <securePubkey> 2 CHECKMULTISIG
  ELSE
    <txoutScriptHash> CHECKTXOUTSCRIPTHASHVERIFY DROP <Acme's pubkey>
CHECKSIG
  ENDIF

The only ways to spend its outputs from this ThisRedeemScript is to forward
it to NextRedeemScript. Even if the original key pair is compromised, the
attacker can only spend it this way and has to publish the transaction.

tx1:
  scriptSig: <sig> <pubKey> 0
  scriptPubKey: HASH160 <Hash160(NextRedeemScript)> EQUAL

tx2: //if there is change
  scriptSig: <sig> <Acme's pubKey>
  scriptPubKey: HASH160 ThisRedeemScriptHash EQUAL

NextRedeemScript is time locked. Acme is able to monitor for unauthorized
transactions and react within the sequence-defined duration. The
combination of 2 key pair as one multisig can spend the output immediately
regardless of the timelock.

NextRedeemScript:
  IF
    2 <Acme's pubkey> <securePubkey> 2 CHECKMULTISIG
  ELSE
    "12h" CHECKSEQUENCEVERIFY DROP <Acme's pubkey> CHECKSIG
  ENDIF

After 12 hours, Acme is can spend the output as normal.

tx:
  scriptSig: <sig> <pubkey> 0
  scriptPubKey: DUP HASH160 <recipient's pubkeyHash> EQUALVERIFY CHECKSIG

*Description*

CSV and CTLV already laid the groundwork for retroactive invalidation,
showcased in innovative protocols such as HTLC of lightning network.

As illustrated from the sample use case, there are other classes of
problems that may requires retroactive invalidation in different and
less-interactive way from channels. Most of those problems require a
primitive opcode to influence how the output can be spent.

If the use case works as expected, attacks will be *less* rewarding. There
are still other attack vectors if Acme's original key pair is compromised,
i.e;

> The attacker can drain the output as transaction fees.
There could be ways to reduce that risk, but do not intent to add
complexity to a request. This additional depth of defense is an improvement
to deter attacks especially if an attack is costly to pull.

> After 12 hours, it may be still possible for attacker to submit
transactions in concurrent or ahead of Acme.
Acme should submit the transaction before the 12 hours and leave it in
mempool, waiting for nSequence to elapse. Attacker's transaction submitted
after it *should be(?)* rejected by the network. Attacker's transaction
submitted before it will be caught by the monitoring function. Even if the
above assumption is misguided, the use-case is still useful if transactions
have value smaller quantity than total, that limits loss to only the
transaction's value. At the same time, that reveals the fact that the key
pair is compromised and the further preventive actions can be carried out
using the secure key pair.

Possible privacy concern: The use case demonstrated change to be sent back
to self (there may be related concern such as wrongly configured digital
signature). The use case assumed P2SH is exceptional case, kind of like
multisignature wallets, for custodians like e-commerce merchants, exchanges.

--0000000000000678fc0578651476
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p style=3D"box-sizing:border-box;margin-top:0px;margin-bo=
ttom:16px"><font color=3D"#24292e" style=3D"font-family:arial,helvetica,san=
s-serif">Discussing the possibility of a new opcode (</font><font color=3D"=
#24292e" face=3D"monospace, monospace">OP_CHECKTXOUTSCRIPTHASHVERIFY</font>=
<font color=3D"#24292e" style=3D"font-family:arial,helvetica,sans-serif">) =
for the Bitcoin scripting system that allows a transaction output to be onl=
y spendable in a predefined manner.<br></font><br><b><font size=3D"4">Brief=
 Description</font></b><br><br><font color=3D"#24292e" style=3D"font-family=
:arial,helvetica,sans-serif">Bitcoin transactions have a=C2=A0</font><font =
color=3D"#24292e" face=3D"monospace, monospace">txoutScript</font><font col=
or=3D"#24292e" style=3D"font-family:arial,helvetica,sans-serif">=C2=A0(</fo=
nt><font color=3D"#24292e" face=3D"monospace, monospace">scriptPubKey</font=
><font color=3D"#24292e"><font face=3D"arial, helvetica, sans-serif">) fiel=
d for each output.<br></font><font face=3D"monospace, monospace">txoutScrip=
tHash=3D</font></font><span style=3D"background-color:rgb(248,249,250);font=
-family:monospace,monospace">Hash160(txoutScript)</span><font face=3D"arial=
, helvetica, sans-serif"><br></font></p><p style=3D"box-sizing:border-box;m=
argin-top:0px;margin-bottom:16px"><span style=3D"font-family:arial,helvetic=
a,sans-serif;background-color:rgb(248,249,250)"><b>Word</b>:=C2=A0</span><s=
pan style=3D"background-color:rgb(248,249,250)"><font face=3D"monospace, mo=
nospace">OP_CHECKTXOUTSCRIPTHASHVERIFY</font><br><font face=3D"arial, helve=
tica, sans-serif"><b>Opcode</b>:=C2=A0</font><font face=3D"monospace, monos=
pace">184 (OP_NOP9)</font><br></span><span style=3D"background-color:rgb(24=
8,249,250)"><font face=3D"arial, helvetica, sans-serif"><b>Input</b>:=C2=A0=
</font><font face=3D"monospace, monospace">x</font></span><span style=3D"fo=
nt-family:arial,helvetica,sans-serif;background-color:rgb(248,249,250)"><br=
><b>Output</b>:</span><span style=3D"font-family:arial,helvetica,sans-serif=
;background-color:rgb(248,249,250)">=C2=A0</span><span style=3D"background-=
color:rgb(248,249,250)"><font face=3D"monospace, monospace">x / fail*</font=
><br></span><span style=3D"font-family:arial,helvetica,sans-serif;backgroun=
d-color:rgb(248,249,250)"><b>Description</b>:<br>Marks transaction as inval=
id if=C2=A0</span><span style=3D"background-color:rgb(248,249,250)"><font f=
ace=3D"monospace, monospace">txoutScriptHash</font></span><span style=3D"fo=
nt-family:arial,helvetica,sans-serif;background-color:rgb(248,249,250)">=C2=
=A0is not equal to top stack item and value of=C2=A0</span><span style=3D"b=
ackground-color:rgb(248,249,250)"><font face=3D"monospace, monospace">txout=
Script</font></span><span style=3D"font-family:arial,helvetica,sans-serif;b=
ackground-color:rgb(248,249,250)">=C2=A0is not equal to=C2=A0</span><span s=
tyle=3D"color:rgb(26,26,26)"><font face=3D"monospace, monospace">OP_HASH160=
 ThisRedeemScriptHash OP_EQUAL</font></span><span style=3D"font-family:aria=
l,helvetica,sans-serif;color:rgb(26,26,26)">*.</span></p><p style=3D"box-si=
zing:border-box;margin-top:0px;margin-bottom:16px"><font face=3D"arial, hel=
vetica, sans-serif" size=3D"1"><i><span style=3D"background-color:rgb(248,2=
49,250)">* Not entirely certain here, always have this impression new opcod=
e has to &quot;</span><span style=3D"background-color:rgb(248,249,250)">NOP=
 or fail&quot; to ensure it can be implemented</span><span style=3D"backgro=
und-color:rgb(248,249,250)">. As a result,=C2=A0</span><span style=3D"backg=
round-color:rgb(248,249,250)">t</span><span style=3D"background-color:rgb(2=
48,249,250)">he item may also has to be dropped explicitly</span><span styl=
e=3D"background-color:rgb(248,249,250)">.<br></span></i><i>* So that change=
 can be sent back to the this redeem script. There are challenges to genera=
lize this as a script hash cause of some cyclic reference. Not sure if cycl=
ic is the correct term, ie: A =3D hash (B&#39;s hash) and B =3D hash (A&#39=
;s hash) is impossible.</i></font></p><p style=3D"box-sizing:border-box;mar=
gin-top:0px;margin-bottom:16px"><span style=3D"color:rgb(36,41,46)"><b><fon=
t size=3D"4">Sample use case</font></b></span></p><p style=3D"box-sizing:bo=
rder-box;margin-top:0px;margin-bottom:16px"><span style=3D"color:rgb(36,41,=
46)">Acme has an ordinary key pair and a secure key pair.=C2=A0</span><span=
 style=3D"color:rgb(36,41,46)">The ordinary key pair is assumed to be in a =
less secure environment.=C2=A0=C2=A0</span><span style=3D"color:rgb(36,41,4=
6)">The private key of the secure key pair will never ever expose itself un=
til the moment it needs to revoke transaction of the ordinary key pair.<br>=
</span></p><p style=3D"box-sizing:border-box;margin-top:0px;margin-bottom:1=
6px"><span style=3D"font-family:monospace,monospace;color:rgb(26,26,26)">re=
deemScript:<br>=C2=A0=C2=A0</span><span style=3D"color:rgb(36,41,46);font-f=
amily:monospace,monospace">IF<br></span><span style=3D"font-family:monospac=
e,monospace;color:rgb(36,41,46)">=C2=A0 =C2=A0 2=C2=A0</span><span style=3D=
"font-family:monospace,monospace;color:rgb(26,26,26)">&lt;Acme&#39;s pubkey=
&gt;=C2=A0</span><span style=3D"font-family:monospace,monospace;color:rgb(2=
6,26,26)">&lt;securePubkey&gt; 2</span><span style=3D"font-family:monospace=
,monospace;color:rgb(26,26,26)">=C2=A0</span><span style=3D"font-family:mon=
ospace,monospace;color:rgb(26,26,26)">CHECKMULTISIG<br></span><span style=
=3D"font-family:monospace,monospace;color:rgb(26,26,26)">=C2=A0 ELSE<br>=C2=
=A0 =C2=A0 &lt;txoutScriptHash&gt;=C2=A0</span><span style=3D"font-family:m=
onospace,monospace;background-color:rgb(248,249,250)">CHECKTXOUTSCRIPTHASHV=
ERIFY=C2=A0</span><font color=3D"#000000" style=3D"font-family:monospace,mo=
nospace"><span style=3D"white-space:pre-wrap;background-color:rgb(248,249,2=
50)">DROP </span></font><span style=3D"color:rgb(26,26,26);font-family:mono=
space,monospace">&lt;Acme&#39;s pubkey&gt;=C2=A0</span><span style=3D"color=
:rgb(26,26,26);font-family:monospace,monospace">CHECKSIG<br>=C2=A0 ENDIF</s=
pan><br></p><p style=3D"box-sizing:border-box;margin-top:0px;margin-bottom:=
16px"><span style=3D"color:rgb(36,41,46)">The only ways to spend its output=
s from this=C2=A0<font face=3D"monospace, monospace">ThisRedeemScript</font=
>=C2=A0is to forward it to=C2=A0<font face=3D"monospace, monospace">NextRed=
eemScript</font>.=C2=A0</span><span style=3D"color:rgb(36,41,46)">Even if t=
he original key pair is</span><span style=3D"color:rgb(36,41,46)">=C2=A0com=
promised, the attacker can only spend it this way and has to publish the tr=
ansaction.</span></p><p style=3D"box-sizing:border-box;margin-top:0px;margi=
n-bottom:16px"><font face=3D"monospace, monospace">tx1:<br><span style=3D"b=
ackground-color:rgb(248,249,250)">=C2=A0 scriptSig: &lt;sig&gt; &lt;pubKey&=
gt; 0<br></span></font><font color=3D"#1a1a1a"><font face=3D"monospace, mon=
ospace">=C2=A0 scriptPubKey:=C2=A0</font></font><span style=3D"color:rgb(26=
,26,26)"><font face=3D"monospace, monospace">HASH160 &lt;Hash160(NextRedeem=
Script)&gt; EQUAL<br><br></font></span><font face=3D"monospace, monospace">=
tx2: //if there is change<br><span style=3D"background-color:rgb(248,249,25=
0)">=C2=A0 scriptSig: &lt;sig&gt; &lt;Acme&#39;s pubKey&gt;<br></span></fon=
t><font color=3D"#1a1a1a"><font face=3D"monospace, monospace">=C2=A0 script=
PubKey:=C2=A0</font></font><span style=3D"color:rgb(26,26,26)"><font face=
=3D"monospace, monospace">HASH160=C2=A0</font></span><span style=3D"color:r=
gb(26,26,26);font-family:monospace,monospace">ThisRedeemScriptHash</span><s=
pan style=3D"color:rgb(26,26,26)"><font face=3D"monospace, monospace">=C2=
=A0EQUAL<br></font></span><span style=3D"color:rgb(26,26,26)"><font face=3D=
"monospace, monospace"><br></font></span><font face=3D"monospace, monospace=
" style=3D"color:rgb(36,41,46)">NextRedeemScript</font><span style=3D"color=
:rgb(36,41,46)">=C2=A0is time locked. Acme is able to monitor for=C2=A0</sp=
an><span style=3D"color:rgb(36,41,46)">unauthorized transactions</span><spa=
n style=3D"color:rgb(36,41,46)">=C2=A0and react within the sequence-defined=
 duration. The combination of 2 key pair as one multisig can spend the outp=
ut immediately regardless of the timelock.</span></p><p style=3D"box-sizing=
:border-box;margin-top:0px;margin-bottom:16px"><span style=3D"font-family:m=
onospace,monospace;color:rgb(26,26,26)">NextRedeemScript</span><span style=
=3D"font-family:monospace,monospace"><font color=3D"#1a1a1a">:<br></font></=
span><span style=3D"color:rgb(36,41,46);font-family:monospace,monospace">=
=C2=A0 IF<br></span><span style=3D"font-family:monospace,monospace;color:rg=
b(36,41,46)">=C2=A0 =C2=A0 2=C2=A0</span><span style=3D"font-family:monospa=
ce,monospace;color:rgb(26,26,26)">&lt;Acme&#39;s pubkey&gt;=C2=A0</span><sp=
an style=3D"font-family:monospace,monospace;color:rgb(26,26,26)">&lt;secure=
Pubkey&gt; 2</span><span style=3D"font-family:monospace,monospace;color:rgb=
(26,26,26)">=C2=A0</span><span style=3D"font-family:monospace,monospace;col=
or:rgb(26,26,26)">CHECKMULTISIG<br></span><span style=3D"color:rgb(26,26,26=
);font-family:monospace,monospace">=C2=A0 ELSE<br></span><span style=3D"fon=
t-family:monospace,monospace;color:rgb(26,26,26)">=C2=A0 =C2=A0=C2=A0</span=
><font color=3D"#1a1a1a" style=3D"font-family:monospace,monospace">&quot;12=
h&quot; CHECKSEQUENCEVERIFY DROP=C2=A0</font><span style=3D"font-family:mon=
ospace,monospace;color:rgb(26,26,26)">&lt;Acme&#39;s pubkey&gt;=C2=A0</span=
><span style=3D"font-family:monospace,monospace;color:rgb(26,26,26)">CHECKS=
IG<br></span><span style=3D"color:rgb(26,26,26);font-family:monospace,monos=
pace">=C2=A0 ENDIF</span></p><p style=3D"box-sizing:border-box;margin-top:0=
px;margin-bottom:16px"><span style=3D"color:rgb(36,41,46)">After 12 hours, =
Acme is can spend the output as normal.</span><br></p><p style=3D"box-sizin=
g:border-box;margin-top:0px;margin-bottom:16px"><font face=3D"monospace, mo=
nospace">tx:<br><span style=3D"background-color:rgb(248,249,250)">=C2=A0 sc=
riptSig: &lt;sig&gt; &lt;pubkey&gt; 0<br></span></font><font color=3D"#1a1a=
1a"><font face=3D"monospace, monospace">=C2=A0 scriptPubKey:=C2=A0</font></=
font><span style=3D"background-color:rgb(248,249,250);color:rgb(0,0,0);font=
-family:monospace,courier;font-size:14px;white-space:pre-wrap">DUP HASH160 =
&lt;recipient&#39;s pubkeyHash&gt; EQUALVERIFY CHECKSIG</span></p><p style=
=3D"box-sizing:border-box;margin-top:0px;margin-bottom:16px"><b style=3D"co=
lor:rgb(36,41,46);font-size:large;font-family:arial,helvetica,sans-serif">D=
escription</b></p><p style=3D"box-sizing:border-box;margin-top:0px;margin-b=
ottom:16px;color:rgb(36,41,46)"><span style=3D"color:rgb(34,34,34);font-fam=
ily:arial,helvetica,sans-serif">CSV and CTLV already laid the groundwork fo=
r r</span><span style=3D"color:rgb(34,34,34);font-family:arial,helvetica,sa=
ns-serif">etroactive invalidation, showcased in innovative protocols such a=
s HTLC of lightning network.<br><br>As illustrated from the sample use case=
, t</span><span style=3D"font-family:arial,helvetica,sans-serif;color:rgb(3=
4,34,34)">here are other classes of problems that may requires retroactive =
invalidation in different</span><span style=3D"color:rgb(34,34,34);font-fam=
ily:arial,helvetica,sans-serif">=C2=A0and less-interactive way from channel=
s. Most of those problems require a primitive opcode to influence how the o=
utput can be spent.</span></p><p style=3D"box-sizing:border-box;margin-top:=
0px;margin-bottom:16px;color:rgb(36,41,46)">If the use case works as expect=
ed, attacks will be=C2=A0<i>less</i>=C2=A0rewarding. There are still other =
attack vectors if Acme&#39;s original key pair is compromised, i.e;<br><br>=
&gt; The attacker can drain the output as transaction fees.<br>There could =
be ways to reduce that risk, but do not intent to add complexity to a reque=
st. This additional depth of defense is an improvement to deter attacks esp=
ecially if an attack is costly to pull.<br><br>&gt; After 12 hours, it may =
be still possible for attacker to submit transactions in concurrent or ahea=
d of Acme.<br>Acme should submit the transaction before the 12 hours and le=
ave it=C2=A0<span style=3D"color:rgb(36,39,41);font-family:Arial,&quot;Helv=
etica Neue&quot;,Helvetica,sans-serif">in mempool, waiting for nSequence to=
 elapse.</span>=C2=A0Attacker&#39;s transaction submitted after it=C2=A0<i>=
should be(?)</i><span style=3D"color:rgb(36,39,41);font-family:Arial,&quot;=
Helvetica Neue&quot;,Helvetica,sans-serif">=C2=A0rejected by the network. A=
ttacker&#39;s transaction submitted before it will be caught by the monitor=
ing function. Even if the above assumption is misguided, the use-case is st=
ill useful if transactions have value smaller quantity than total, that lim=
its loss to only the transaction&#39;s value. At the same time, that reveal=
s the fact that the key pair is compromised and the further preventive acti=
ons can be carried out using the secure key pair.</span></p><p style=3D"box=
-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46)">P=
ossible privacy concern: The use case demonstrated change to be sent back t=
o self (there may be related concern such as wrongly configured digital sig=
nature). The use case assumed P2SH is exceptional case, kind of like multis=
ignature wallets, for custodians like e-commerce merchants, exchanges.</p><=
/div>

--0000000000000678fc0578651476--