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 3CF40DA6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Mar 2019 04:15:05 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
	[185.70.40.135])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 868CF2D5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 12 Mar 2019 04:15:04 +0000 (UTC)
Date: Tue, 12 Mar 2019 04:14:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1552364102;
	bh=/2Ao4s8aWtwkEx+vz84lvf0POnHaYahHbPTefU6CH2U=;
	h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
	From;
	b=shtRzbBVJzJ6qrZ5UloLIGsNiXv4N3qZBoRnKJN/QIXJp/ItPXyN0a8Ci4cPYsU47
	mFHZb9ESnSVOaceqBG9Zxecy+Bf1E4AYkb1CL2BfvY63cX+5H+J8xj7o4MmBBMI67L
	LGKF3jFzLlOTZdUZ0Jf2CR+oegg4g5sfC4a4Uujw=
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: <HT17PPZYL6SJ91sO2mrEmAZ6RaCoAPBSmF3cphDMx5bqjCFNgbfof5l-TfAS5RsfuyPEV_xUqyJDbfCONeefog8Tz3eLz4NhXGPDiKzTKHg=@protonmail.com>
In-Reply-To: <12139028.TiJ4v5RR02@dprfs-d5766>
References: <12139028.TiJ4v5RR02@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=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
	RCVD_IN_DNSWL_LOW, URI_NOVOWEL 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, 12 Mar 2019 05:45:26 +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, 12 Mar 2019 04:15:05 -0000

Good morning Alistair,

>     It won't have escaped notice that the HTLB script can be wholly writt=
en in an
>     HTLC script: 'HTLB over HTLC', however there are additional reasons t=
o
>     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 HTL=
C; 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, si=
nce 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 th=
ey 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 hav=
e a fixed participant set, and is effectively gotten "for free" with Taproo=
t (the requirement is the "Taproot assumption"), but is available now even =
without Taproot.

Regards,
ZmnSCPxj