Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB
Good morning Alistair, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ 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 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' 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 > 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 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] 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 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 ``, `[HASHOP]`, `` 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 ` [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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB
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 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 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 > > > > 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB
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' 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 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 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB
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 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 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Pre BIP: Solving for spam and other abuse with an HTLB
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 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
