Restarting Development on BIP-199

k26dr commented at 10:04 pm on March 23, 2025: none

Please describe the feature you’d like to see added.

Hi, I’d like to restart development on BIP-199: https://en.bitcoin.it/wiki/BIP_0199

It was previously started as [PR #7601](https://github.com/bitcoin/bitcoin/pull/7601) which was then abandoned.

Is there any interest in getting this implemented? If so, I can start a PR and begin contributing.

BIP-199 was never fully implemented in Bitcoin Core.

Describe the solution you’d like

I’d like to use pay-to-public key addresses to implement the feature so that the full script is on-chain. Otherwise, we would run into the problem of how to store the script, which contains refund and redeem addresses + a hash that would need to be stored on disk somewhere.

Describe any alternatives you’ve considered

Using Segwit witness scripts to generate the HTLC. I believe this would be the an inferior implementation because the full script would then have to be stored on disk. Loss of this data would lead to loss of ability for the refunder to claim a refund of the contract.

Please leave any additional context

I am the author of the NPM library for BIP-199: ( https://www.npmjs.com/package/bip-199 ), so I have some experience with this feature.

k26dr added the label Feature on Mar 23, 2025

sipa commented at 10:10 pm on March 23, 2025: member

I’d like to use pay-to-public key addresses to implement the feature so that the full script is on-chain.

If it’s a pay-to-pubkey address, it’s not an HTLC policy.

Otherwise, we would run into the problem of how to store the script, which contains refund and redeem addresses + a hash that would need to be stored on disk somewhere.

This is inevitable for any realistic protocol. Even BIP199 and #7601 used P2SH, which prevented the script from being on-chain before spending.

k26dr commented at 10:18 pm on March 23, 2025: none

Pay-to-public key would just stick the script on-chain, no? @sipa

sipa commented at 10:18 pm on March 23, 2025: member

Well, yes, but it would be a pay-to-pubkey script, not an HTLC script?

k26dr commented at 10:21 pm on March 23, 2025: none

As I understand it, this is an HTLC script:

0 OP_IF
1     [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>            
2 OP_ELSE
3     <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
4 OP_ENDIF
5 OP_EQUALVERIFY
6 OP_CHECKSIG

and if this was put on-chain as a pay-to-pubkey script it would still work without breaking consensus.

If this is true, I’m cool with that. @sipa

k26dr commented at 10:23 pm on March 23, 2025: none

If P2WSH is the preferred implementation, I’m cool with that too. I’m just trying to understand why pay-to-pubkey script would be an issue.

k26dr commented at 10:26 pm on March 23, 2025: none

The NPM implementation uses P2WSH, so I’m not unfamiliar with that methodology. I just ran into the issue that if you lose the witness script, you lose the ability to claim the HTLC.

sipa commented at 10:35 pm on March 23, 2025: member

“Pay to pubkey” (P2PK) means a <pubkey> OP_CHECKSIG script, nothing else. I think what you mean is what I’d call a “bare HTLC script”, i.e., putting the script you give above directly in the scriptPubKey?

Terminology aside, this is problematic for several reasons:

There exist no addresses for HTLC scripts (BIP199 or otherwise), you’d need to introduce a new address format for this to work or nobody can send to it. Previous experience shows that this is a multi-year process, at least (even the BIP350 address format introduced in 2020, for taproot which activated in 2021, is not universally accepted). FWIW, there is no address for P2PK either.
An address for such scripts would need to be enormous (storing at least 3 hashes, plus a timeout value). My rough guess is ~166 characters for a base32-style address like BIP173/BIP350?
Using such scripts is non-standard. Even ignoring that senders cannot use them, transactions paying to them just won’t relay across the network. This can be changed of course, but that again is a slow process.
It’s expensive for senders. Since they need to put the full script in the crediting transaction, they need to pay for the on-chain bytes that consumes. For this reason, basically nothing non-trivial has used bare scripts (besides P2PK and P2PKH), moving to P2SH, P2WSH, or P2TR instead, which move this cost to the receiver - the one who cares about the properties of complex script in the first place - by revealing it at spending time. With P2TR, the script can even be broken up into multiple branches, so that only the used one needs to be revealed and paid for.

In real applications where HTLCs are used (like Lightning), I believe the problem with data storage is (partially) addressed by deriving the keys/preimages deterministically, though I’m not an expert on this.

In any case, for P2WSH or P2TR, there is no need for any of this. With the introduction of miniscript descriptors (BIP 387), Bitcoin Core should be able to sign for any of these scripts already.

k26dr commented at 10:40 pm on March 23, 2025: none

Ok fair enough. If a future BIP takes care of this, I’ll close the issue. Thanks for the explanation.

k26dr closed this on Mar 23, 2025

Restarting Development on BIP-199 #32126

Please describe the feature you’d like to see added.

Is your feature related to a problem, if so please describe it.

Describe the solution you’d like

Describe any alternatives you’ve considered

Please leave any additional context