From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 81E742DDF for ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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' 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 > OP_ELSE > OP_IF > [HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160 > > OP_ELSE > [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 > > OP_ENDIF > > > OP_ENDIF > OP_EQUALVERIFY > OP_CHECKSIG > The second OP_IF is new and would mean Bob can give Alice a [HASHOP] and > 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] OP_EQUALVERIFY OP_DUP OP_HASH160 OP_ELSE [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 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 `` 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 ``, `[HASHOP]`, `` 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 ` [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