Good morning Alistair,
Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, March 18, 2019 4:27 AM, Alistair Mann via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > This update collects community feedback on my HTLB Pre-BIP > > As reminder, I'm suggesting a BIP for a hitherto poorly supported class of > transactions: "Good Behaviour Bonds". > > 1. On this mailing list: > ZmnSCPxj notes HTLB over HTLC can improve privacy by obscuring whether a > transaction is, in fact, an HTLB or an HTLC. This requires that the > 'redundant' <digest> and [HASHOP] be not standardised. I intend to follow > that > > > advice. > > 2. On Reddit at http://tinyurl.com/yxdketdo: > /u/almkglor nudges me to consider if Bob could immediately fail the HTLB to > Alice's benefit. I believe he could with something like this script: > OP_IF > OP_DUP OP_HASH160 <seller pubkey hash> > OP_ELSE > OP_IF > [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <buyer pubkey hash> > > OP_ELSE > <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash> > > OP_ENDIF > > > OP_ENDIF > OP_EQUALVERIFY > OP_CHECKSIG > The second OP_IF is new and would mean Bob can give Alice a [HASHOP] and > <digest> that allows her to immediately redeem the funds. I will be modifying > > the proof-of-concept code to investigate and prove this change. The above is at odds with my suggestion to transport HTLBs over HTLCs. BIP-199 already exists and defines a standard template for HTLC contracts. OP_IF [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash> OP_ELSE <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash> OP_ENDIF OP_EQUALVERIFY OP_CHECKSIG To use the above contract as HTLB: 1. Alice is the "buyer". 2. Bob is the "seller". 3. The preimage of `<digest>` is generated by Alice and given by Alice to Bob. I observe that an "early return to Alice" can be implemented by Bob, by taking the first branch, but sending the money back to an address Alice controls. Since Bob is the one who will decide whether to take the money (i.e. Alice is wasting Bob precious time and resource) or return to Alice (i.e. Alice sent the message in good faith), this decision can be made by Bob entirely without any input from Alice. So the overall flow of the messages would be: 1. Alice sends preimage of `<digest>`, `[HASHOP]`, `<num>` and a new address that Alice controls (for purpose of "early return"). 2. Alice makes transaction to the above HTLC pattern. 3. Bob has until `<num> [HASHOP]` to decide: 3.1. To claim the money for itself by taking the first branch and sending to a new address that Bob controls. 3.2. To return the money to Alice by taking the first branch and sending to the address Alice gave. 4. If Bob has not decided at the timeout, Alice can get her money back by taking the second branch. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
