Date: Tue, 19 Mar 2019 00:22:25 +0000
To: Alistair Mann <al@pectw.net>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <l4BUfzuidK4XBlGw5eVQI5ZTL5I8i_UurXFU4IwrORvTJjhPjA9B3HLUw7MctfL0rk2r-wfSantKTPkNqX9vaN97vpthNrYC73mgDYm3iMM=@protonmail.com>
In-Reply-To: <2800869.rK7t1eu9ik@dprfs-d5766>
References: <12139028.TiJ4v5RR02@dprfs-d5766> <2800869.rK7t1eu9ik@dprfs-d5766>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an
	HTLB
Precedence: list

Good morning Alistair,


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Monday, March 18, 2019 4:27 AM, Alistair Mann via bitcoin-dev <bitcoin-d=
ev@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 o=
f
> transactions: "Good Behaviour Bonds".
>
> 1.  On this mailing list:
>     ZmnSCPxj notes HTLB over HTLC can improve privacy by obscuring whethe=
r a
>     transaction is, in fact, an HTLB or an HTLC. This requires that the
>     'redundant' <digest> and [HASHOP] be not standardised. I intend to fo=
llow 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 modif=
ying
>
> 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 h=
ash>
    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 tak=
ing the first branch, but sending the money back to an address Alice contro=
ls.
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 s=
ent the message in good faith), this decision can be made by Bob entirely w=
ithout any input from Alice.

So the overall flow of the messages would be:

1.  Alice sends preimage of `<digest>`, `[HASHOP]`, `<num>` and a new addre=
ss 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 t=
o 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