<p>The security implication of removing a checksig operation from the encumbrance script is that the coins can be stolen while in flight by anybody, and especially by miners.  Obviously, on testnet, only someone who's bored or interested enough to grab the coins will take the time to "attack" your transactions.</p>

<p>There's not much sense in listing and analyzing the vulnerabilities in your method.  Testnet coins are worthless and certainly nobody will take the time to brute-force sha256, or grind through a hash table to get them.</p>

<p>As for checksig-less scripts in general, there are indeed bots on mainnet that listen for such transactions being relayed and try to grab any coins.  It's probably easy enough to run the same bot on testnet.</p>

<p>In any case, if you want to avoid this scenario altogether, you can migrate your setup to regtest.</p>

CC BY-SA 4.0
2018-12-30T11:52:34.083Z
2018-12-30T11:52:34.083Z
arubi
<p>If I conduct an htlc transaction on testnet that does not include OP_CHECKSIG will it still cost an attacker more than (say) $10 in processing power or storage to subvert my tests?</p>

<p>Details: I'm tinkering with <a href="https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki" rel="nofollow noreferrer">BIP-0199 htlcs</a>, the last step of which is CHECKSIG. Now, bitcoind does not (<a href="https://github.com/bitcoin/bitcoin/pull/7601#issuecomment-339548311" rel="nofollow noreferrer">yet</a>) expose htlc functionality through RPC, so in order to tinker I've had to implement BIP-0199 via RPC requests myself. To date I've implemented everything I need up to the final CHECKSIG. I understand of Pieter Wuille <a href="https://bitcoin.stackexchange.com/a/72939">here</a> that I would need to implement the signing logic for CHECKSIG myself, which seems logical. However, I'm not interested in the role of CHECKSIG in a htlc as I believe it indistinguishable from the same opcode in any standard transaction so I propose to skip implementing it while my tinkering remains on testnet.</p>

<p>Obviously an htlc without CHECKSIG is not secure. For my purposes is it secure <em>enough</em>: Logically,<br>
1. While it remains on testnet, a successful attack obtains no more than testnet coins;<br>
2. The testnet coins that could be obtained are limited to the funds committed to the p2sh address;<br>
3. An attacker who somehow knew that a redeemscript did not contain CHECKSIG would still have to brute force a script whose sha256 hash matches that of the redeemscript in order to redeem funds;<br>
4. An attacker who sees the seller's redeemscript has to obtain matches for the digest and public key (perhaps through hash tables) and <em>still</em> has to get his copy of the transaction mined first in order to cheat the seller;<br>
5. An attacker seeing the buyer's transaction 'only' has to match on the public key then get his copy mined first to cheat the buyer;<br>
6. An attacker that's too slow to get mined first could nevertheless succeed by getting the block containing the transaction orphaned.</p>

<p>And so, an attack on an testnet hashed time-locked contract that does not include CHECKSIG will <em>still</em> require either processing power and/or storage space well in excess of $10. Is my reasoning sound, and if not, what have I missed?</p>

<security><testnet><cryptography><p2sh><hash-time-locked-contract>
Security implications of removing CHECKSIG in a test
Alistair Mann
# Security implications of removing CHECKSIG in a test

(Asked by: username_0 on 2018-12-30)

If I conduct an htlc transaction on testnet that does not include OP\_CHECKSIG will it still cost an attacker more than (say) $10 in processing power or storage to subvert my tests?

Details: I'm tinkering with [BIP-0199 htlcs](https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki), the last step of which is CHECKSIG. Now, bitcoind does not ([yet](https://github.com/bitcoin/bitcoin/pull/7601#issuecomment-339548311)) expose htlc functionality through RPC, so in order to tinker I've had to implement BIP-0199 via RPC requests myself. To date I've implemented everything I need up to the final CHECKSIG. I understand of Pieter Wuille [here](https://bitcoin.stackexchange.com/a/72939) that I would need to implement the signing logic for CHECKSIG myself, which seems logical. However, I'm not interested in the role of CHECKSIG in a htlc as I believe it indistinguishable from the same opcode in any standard transaction so I propose to skip implementing it while my tinkering remains on testnet.

Obviously an htlc without CHECKSIG is not secure. For my purposes is it secure *enough*: Logically,  
1. While it remains on testnet, a successful attack obtains no more than testnet coins;  
2. The testnet coins that could be obtained are limited to the funds committed to the p2sh address;  
3. An attacker who somehow knew that a redeemscript did not contain CHECKSIG would still have to brute force a script whose sha256 hash matches that of the redeemscript in order to redeem funds;  
4. An attacker who sees the seller's redeemscript has to obtain matches for the digest and public key (perhaps through hash tables) and *still* has to get his copy of the transaction mined first in order to cheat the seller;  
5. An attacker seeing the buyer's transaction 'only' has to match on the public key then get his copy mined first to cheat the buyer;  
6. An attacker that's too slow to get mined first could nevertheless succeed by getting the block containing the transaction orphaned.

And so, an attack on an testnet hashed time-locked contract that does not include CHECKSIG will *still* require either processing power and/or storage space well in excess of $10. Is my reasoning sound, and if not, what have I missed?

**Tags:** security, testnet, cryptography, p2sh, hash-time-locked-contract


---

## 1 answers

### Answer by username_1 on 2018-12-30. Score: 3 | Accepted answer

The security implication of removing a checksig operation from the encumbrance script is that the coins can be stolen while in flight by anybody, and especially by miners. Obviously, on testnet, only someone who's bored or interested enough to grab the coins will take the time to "attack" your transactions.

There's not much sense in listing and analyzing the vulnerabilities in your method. Testnet coins are worthless and certainly nobody will take the time to brute-force sha256, or grind through a hash table to get them.

As for checksig-less scripts in general, there are indeed bots on mainnet that listen for such transactions being relayed and try to grab any coins. It's probably easy enough to run the same bot on testnet.

In any case, if you want to avoid this scenario altogether, you can migrate your setup to regtest.


---

