Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 81E742DDF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 19 Mar 2019 00:22:34 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
	[185.70.40.136])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86A44608
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 19 Mar 2019 00:22:33 +0000 (UTC)
Date: Tue, 19 Mar 2019 00:22:25 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1552954951;
	bh=o6npnJuI308SWzUSv+T7p1L5ZcdYxrvNCnta0gaQ6QA=;
	h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
	From;
	b=vDzAiU3QUdc+/UOZJprEZBl2/vFsSGxlGJBqaGKamh+W19KwZmeoULb76FTetajNZ
	zPCjQarfGbmPA40kO7u/6yOo+eR4hhJVkYycR2E0CyX+NUtzQuj+NCFOxew4w4/gKF
	Wt48OB90GUhV1CZxv+Ey51bWXIWP9ecrBHoajwDM=
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
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 19 Mar 2019 02:02:18 +0000
Subject: Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an
	HTLB
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2019 00:22:34 -0000

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