0

I'm currently working on implementing a modified version of Hash Time Locked Contracts (HTLC) in Bitcoin and would greatly appreciate any guidance or best practices from the community.

Objective: I aim to modify the standard HTLC to simplify the creation process. In my modified HTLC:

  1. The creator of the HTLC does not need to specify a hash lock initially.
  2. The creator specifies a party (which can be nullable) who will later add the hash lock to the pre-HTLC.
  3. Only the creator of the pre-HTLC and the specified party can add the hash lock.

Questions:

  1. Feasibility: Can this modification be implemented within the current Bitcoin scripting capabilities? Are there any inherent limitations I should be aware of?
  2. Security Considerations: What potential security risks should I consider with this modification? How can I mitigate these risks?
Improve this question
6
  • Am I understanding right that you are trying to create an output which will execute differently based on someone else’s input after it was created? Commented Jun 25, 2024 at 13:40
  • @Murch let me explain more detailed.in simple HTLC when Alice and Bob want to change assets,at first Alice creates HTLC struct and lock funds for Bob with inputs (hashlock,BobAddr,timelock,amount,etc).In modified version I want Alice to create preHTLC struct for Bob with inputs (3rdParty,BobAddr,timelock,amount,etc),after it 3rdParty comes and converts preHTLC creating new struct HTLC with preHTLC data and adds hashlock. Afters this step everything goes as in simple HTLC protocol. Commented Jun 25, 2024 at 13:48
  • Are you aware of PSBTs? Commented Jun 25, 2024 at 18:54
  • unfortunately,no Commented Jun 26, 2024 at 9:11
  • I have done some research,but I still cant understand will it match to the described architecture.Particularly that 3rdParty can be nullable,will work PSBT for it. Commented Jun 26, 2024 at 9:18

1 Answer 1

Reset to default
0

You cannot broadcast an incomplete transaction and have another user modify it later, because an incomplete transaction is not valid and invalid transactions do not propagate on the network.

You could share an incomplete transaction out-of-band, e.g. on a message board, via a Partially signed Bitcoin transaction (PSBT) iff the inputs and outputs of the transaction creator are sufficient to enforce their expected outcome by using a SIGHASH_SINGLE | SIGHASH_ANYONECANPAY construction. The second participant would then be able to fill in the remaining inputs and outputs to achieve their intended outcome in addition.

However, if you want two participants to both have input on one output script, your protocol will require at least one round trip, as the original transaction creator cannot sign off on an incomplete output script, and therefore either the second participant would have the ability to unilaterally determine that output or the transaction would have to go back to the creator after the second participant adds their modification.

I must admit that I don’t fully understand what you are trying to achieve, and therefore may be missing a workaround or trick, but the above should cover the general situation. Your problem reminds me of how inscription market places use PSBTs to offer NFTs for sale, and if you are not familiar, it might be interesting to study that approach.

If you generally want to better understand how HTLCs work, you may want to take a look at Elle Mouton’s excellent HTLC Deep Dive, her other blog posts may also be interesting in the context of your line of inquiry.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.