From: kim juan <kimjuan.chan@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY
Date: Wed, 17 Oct 2018 12:26:34 +0800 [thread overview]
Message-ID: <CAAKtTCt1_MTh38Bsft6_V65cLBcxHOrvsXR8yen_Ag1AgWtxcw@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 4341 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 12637 bytes --]
next reply other threads:[~2018-10-17 4:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-17 4:26 kim juan [this message]
2018-10-17 5:17 ` ZmnSCPxj
2018-10-17 6:58 ` kim juan
2018-10-17 10:22 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAKtTCt1_MTh38Bsft6_V65cLBcxHOrvsXR8yen_Ag1AgWtxcw@mail.gmail.com \
--to=kimjuan.chan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox