Alistair Mann [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-17 📝 Original message:This update collects ...
📅 Original date posted:2019-03-17
📝 Original message: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
📝 Original message: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