[bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB

[bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB

[Alistair Mann]

Greetings all, 

I'm looking for thoughts on the BIPability of a relatively minor change, with 
an outsize benefit, with the provisional name 'Hashed Time-Locked Bond', HTLB 
for short.

The minor change is to implement HTLC without its digest element. The outsize 
benefit is to incentivise against spam and other abuse. In this post I'll 
introduce the script, motivation, a working proof-of-concept site, and then 
round out addressing the desirability of a BIP.

Implementation of HTLB:
The script takes the form: 

    OP_IF
        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

Notice that this is the script of BIP-0199 with '[HASHOP] <digest> 
OP_EQUALVERIFY' removed. 

A worked example. Alice is the buyer and Bob the seller. Alice knows that Bob 
is her father and that he doesn't know her new email address. She commits 
50,000 satoshis to the above script with a 24 hour timeout, then sends proof 
of that transaction along with an email reintroducing herself. Bob's MUA 
recognises that the bond is good and alerts him to the email from a strange 
sender: he knows that if he disagrees with the implicit assertion that he will 
want that email, he has 24 hours to redeem those funds at the sender's 
expense. He reads the email. Bob is incentivised not to redeem against his 
daughter though, and lets the timeout expire: Alice reclaims her funds. Carol 
did not bond at all, so her email was refused at the server. Dave's bond of 
100 satoshis was too small to pass Bob's minimum, so his email too was refused 
at the server. Erin guaranteed 50,000 satoshis each to reach Bob and ten 
thousand others with an email offering triple-glazed windows: she's now well 
on the way to losing them all.

Motivation: 
There is a transaction class we can identify as 'Good Behaviour Bonds' 
currently poorly served in Bitcoin*. Bail bonds and bar tabs are real world 
exemplars. Conceptually, Alice guarantees Bob she will do or be something for 
a fixed period: if she complies Bob refrains from redeeming her guarantee; if 
she does not comply Bob redeems some or all of it. It's inherent to the class 
that Alice is incentivised within the transaction to good behaviour outside 
it. Conversely, Bob is incentivised outside the transaction to good behaviour 
within it. 

In essence, Alice commits funds to a penalty in advance of a connection to 
Bob. Alice is incentivised by getting her funds back, Bob is incentivised by 
her - and others - continued patronage. 

This transaction class can protect any addressable resource. Alice can 
therefore guarantee Bob that:
1. Her email to him is not spam
2. Her telephone call to him is not a robocall
3. Her posts to his website are not flamebait.
In each case this is handled by extending the protocol concerned to detect for 
and change behaviour depending on Alice's proof of bond.

That Alice can guarantee her behaviour to addressable resources means she can 
also guarantee her behaviour to non-addressable resources. She could 
guarantee:
1. a group chat that she won't upload NSFW content
2. an IRC channel that she won't flood
3. a streamed multiplayer game that she won't swear over teamspeak.
This is accomplished by use of an addressable resource and an enforcement 
mechanism such as IRC's devoice command.

Alice can also guarantee her behaviour offline in much the same way. She can 
guarantee to:
1. a magistrate that she'll appear for trial by a given date (Bail bond/ 
Surety)
2. a houseowner that she'll cover costs incurred from cleaning up after her 
(Rental/Security deposit)
3. an innkeeper that she can pay for the drinks she's ordering (Bar tab)
That a transaction has been entered into online can be proved offline, so 
these can be accomplished by means of an online, addressable resource and an 
offline plaintext token.

Live site:

I have put up a live proof-of-concept at http://berewic.com. This protects a 
specific URL accessed through HTTP (the "demo page") whereby visitors who have 
posted bond on testnet3 get different content than those who have not posted 
bond, or whose bond has expired. This is accomplished through an experimental 
protocol where an agent with a hot wallet speaks for a credentialed user in a 
similar way to how SMTP speaks for an email's original sender. That protocol 
would seem to be outside the scope of the proposed BIP but I'm happy to 
elaborate if required.

A short video demonstrating live use of the HTLB is also posted there. 

BIP:

Name: "Hashed Time-Locked Bond" seems a reasonable name - the script is still 
hashed even if the digest is gone, and HTLB nicely scans like HTLC - 1.

It won't have escaped notice that the HTLB script can be wholly written in an 
HTLC script: 'HTLB over HTLC', however there are additional reasons to 
consider HTLB for a separate BIP:
1. Alternative implementations using HTLB over HTLC would need to standardise 
on what the redundant [HASHOP] and <digest> should be
2. Using HTLB over HTLC is inefficient as it compels unused storage and 
unnecessary processing
3. Amending or superceding BIP-0199 to recognise the digest element as 
optional creates backward compatibility issues
4. Recognising the motivation onchain would help inform second-layer solutions 
where HTLB would be even more useful (eg, I believe that HTLCs and HTLBs do 
not have analogues in the Lightning Network)
5. Wallet support. A limiting factor for the live site above has been the lack 
of wallet HTLC support to the point that the demo does not implement CHECKSIG. 
HTLC & HTLB signing would ideally take place in the wallet that must be 
present, and so a BIP would help bolster the case for, and inform anyone 
revisiting, PR7601.

Thoughts?

* The HTLB lives in the space somewhere near 
https://en.bitcoin.it/wiki/Fidelity_bonds and 
https://en.bitcoin.it/wiki/Contract#Example_1:_Providing_a_deposit. The former 
requires an unnecessary sacrifice, the latter does not allow for penalisation.

Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB

[ZmnSCPxj]

Good morning Alistair,

>     It won't have escaped notice that the HTLB script can be wholly written in an
>     HTLC script: 'HTLB over HTLC', however there are additional reasons to
>     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 HTLC; 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, since 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 they 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 have a fixed participant set, and is effectively gotten "for free" with Taproot (the requirement is the "Taproot assumption"), but is available now even without Taproot.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB

[Alistair Mann]

Many thanks for your thoughts, ZmnSCPxj.

> 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 HTLC; 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,
> since using a standardized one will also reveal use of HTLB over HTLC
> instead of hiding it among other HTLC UTXOs.

Both these are good observations and I'll act on them.
 
> Another thing to improve privacy would be to apply the Funding Transaction
> pattern: https://zmnscpxj.github.io/offchain/generalized.html
<snip>

I've not read of the FTP before; I welcome it, and take on board that it 
improves privacy by keeping a script offline. My first thought is that doesn't 
affect the suggested BIP, so my next update here won't include it. I recognise 
it would improve mainnet use of scripts though, so do expect to return to it.

Cheers,
-- 
Alistair Mann

Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB

[Alistair Mann]

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.

At https://twitter.com/ChristopherA/status/1105153022206722048
3. @mappum observes the HTLB idea is "like proof-of-stake". Such a succint 
comparison of HTLB with existing work is useful to me even though HTLB has 
nothing to do with mining and PoS consensus. I'll be investigating if the PoS 
penalty system has more that can inform this BIP.

I'm grateful to the above for their contributions, and also to the circa 60+ 
non-bot visitors to the berewic.com site: quiet interest is positive. 

Assuming no other major changes my next update will be a formal write-up for 
the BIP.

Cheers,
-- 
Alistair Mann

Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB

[ZmnSCPxj]

Funding Transaction Pattern is how I name it; I am unaware if this pattern has been named before.
I know gmax created Taproot precisely as an optimization of this pattern, so I presume he is aware of it, and might know a proper name for such.
It is massively ambiguous to call it "gmax technique" as that name could apply to many, many techniques.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 18, 2019 12:11 AM, Alistair Mann <al@pectw.net> wrote:

> Many thanks for your thoughts, ZmnSCPxj.
>
> > 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 HTLC; 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,
> > since using a standardized one will also reveal use of HTLB over HTLC
> > instead of hiding it among other HTLC UTXOs.
>
> Both these are good observations and I'll act on them.
>
> > Another thing to improve privacy would be to apply the Funding Transaction
> > pattern: https://zmnscpxj.github.io/offchain/generalized.html
>
> <snip>
>
> I've not read of the FTP before; I welcome it, and take on board that it
> improves privacy by keeping a script offline. My first thought is that doesn't
> affect the suggested BIP, so my next update here won't include it. I recognise
> it would improve mainnet use of scripts though, so do expect to return to it.
>
> Cheers,
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Alistair Mann

Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB

[ZmnSCPxj]

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