ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-12 📝 Original message:Good morning Alistair, > ...
📅 Original date posted:2019-03-12
📝 Original message:Good morning Alistair,
> It won't have escaped notice that the HTLB script can be wholly written in an
> HTLC script: 'HTLB over HTLC', however there are additional reasons to
> consider HTLB for a separate BIP:
I believe there is indeed an important usecase for HTLB over HTLC, which is to improve the anonymity set.
An HTLB over HTLC would be indistinguishable onchain from other uses of HTLC; assuming that HTLCs have other uses, this is a (small?) plus to privacy.
Note that the redundant <digest> would have to be given by Alice to Bob, since using a standardized one will also reveal use of HTLB over HTLC instead of hiding it among other HTLC UTXOs.
Another thing to improve privacy would be to apply the Funding Transaction pattern: https://zmnscpxj.github.io/offchain/generalized.html
In such a case, Alice would prepare two transactions, one which pays to a 2-of-2, and another which spends that 2-of-2 and pays to an HTLB (over HTLC).
Alice would provide the second transaction to Bob, who must return a valid signature for that transaction, then place the first transaction onchain.
Then the protocol resumes as normal.
If Alice and Bob both agree that the bond can be returned to Alice, then they recreate the second transaction as a normal spend from 2-of-2 to a flat P2PKH of Alice (or whatever address Alice desires), obscuring that HTLB was used at all.
The Funding Transaction Pattern is applicable to all constructions that have a fixed participant set, and is effectively gotten "for free" with Taproot (the requirement is the "Taproot assumption"), but is available now even without Taproot.
Regards,
ZmnSCPxj
📝 Original message:Good morning Alistair,
> It won't have escaped notice that the HTLB script can be wholly written in an
> HTLC script: 'HTLB over HTLC', however there are additional reasons to
> consider HTLB for a separate BIP:
I believe there is indeed an important usecase for HTLB over HTLC, which is to improve the anonymity set.
An HTLB over HTLC would be indistinguishable onchain from other uses of HTLC; assuming that HTLCs have other uses, this is a (small?) plus to privacy.
Note that the redundant <digest> would have to be given by Alice to Bob, since using a standardized one will also reveal use of HTLB over HTLC instead of hiding it among other HTLC UTXOs.
Another thing to improve privacy would be to apply the Funding Transaction pattern: https://zmnscpxj.github.io/offchain/generalized.html
In such a case, Alice would prepare two transactions, one which pays to a 2-of-2, and another which spends that 2-of-2 and pays to an HTLB (over HTLC).
Alice would provide the second transaction to Bob, who must return a valid signature for that transaction, then place the first transaction onchain.
Then the protocol resumes as normal.
If Alice and Bob both agree that the bond can be returned to Alice, then they recreate the second transaction as a normal spend from 2-of-2 to a flat P2PKH of Alice (or whatever address Alice desires), obscuring that HTLB was used at all.
The Funding Transaction Pattern is applicable to all constructions that have a fixed participant set, and is effectively gotten "for free" with Taproot (the requirement is the "Taproot assumption"), but is available now even without Taproot.
Regards,
ZmnSCPxj