public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Alistair Mann <al@pectw.net>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB
Date: Tue, 19 Mar 2019 00:22:25 +0000	[thread overview]
Message-ID: <l4BUfzuidK4XBlGw5eVQI5ZTL5I8i_UurXFU4IwrORvTJjhPjA9B3HLUw7MctfL0rk2r-wfSantKTPkNqX9vaN97vpthNrYC73mgDYm3iMM=@protonmail.com> (raw)
In-Reply-To: <2800869.rK7t1eu9ik@dprfs-d5766>

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


      reply	other threads:[~2019-03-19  0:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-11 16:01 [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB Alistair Mann
2019-03-12  4:14 ` ZmnSCPxj
2019-03-17 16:11   ` Alistair Mann
2019-03-18  4:22     ` ZmnSCPxj
2019-03-17 20:27 ` Alistair Mann
2019-03-19  0:22   ` ZmnSCPxj [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='l4BUfzuidK4XBlGw5eVQI5ZTL5I8i_UurXFU4IwrORvTJjhPjA9B3HLUw7MctfL0rk2r-wfSantKTPkNqX9vaN97vpthNrYC73mgDYm3iMM=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=al@pectw.net \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox