Nostr notes by Swambo, Jacob [ARCHIVE]

📅 Original date posted:2022-05-03 📝 Original message:Thanks ...

2023-06-07T23:08:55Z

In reply to nevent1q…aqzf
_________________________

📅 Original date posted:2022-05-03
📝 Original message:Thanks Darosior for your response.

I see now that APOAS (e.g. with ANYONECANPAY and/or SINGLE) and CTV (with less restrictive templates) fall prey to the same trade-off between flexibility and safety. So I retract my statement about that 'point in favour of OP_CTV'. It would be nice to by-pass the trade-off, but it seems to be unavoidable. That begs the question, why would we want to have a way to commit to less restrictive templates?

Firstly, I posit that if a transaction does not allow RBF, then it would be very difficult for an attacker to repackage parts of the transaction into a malicious alternative and rebroadcast it before it reaches the mempool of the majority of nodes, who would then reject the malicious alternative.

Secondly, some covenant-based applications aren't as critical as others, and it may well be acceptable to take the risk of using something like ANYONECANPAY|ALL even with RBF enabled.

Third, in a trusted multi-party context you can safely make use of flexible signature messages. Let's say there are 3 people and a UTXO with the following locking script as a single leaf in the tapscript:

<pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD <pk3> OP_CHECKSIGADD 2 OP_EQUAL <APOAS|SINGLE:signature_covenant_tx> <covenant_PK> OP_CHECKSIG

And they produce this witness:

<SINGLE:sig_1> <ALL:sig_2>

The second participant can, for example, add a change output before signing. <sig_1> is not sufficient and so can't be repackaged without the authorisation of participant 2.

The additional flexibility through composing APOAS with other SIGHASH modes, and the ability to re-bind covenant transactions to different UTXOs allows protocol designers to do more with APOAS covenants than with CTV covenants (as currently spec'd). I'm not yet convinced that BIP-118 is totally safe, but I think the debate recently is part of that maturation process and I'm glad for it.

Jacob Swambo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220503/0dcb6bd3/attachment.html>;

📅 Original date posted:2022-04-29 📝 Original message:Hi, ...

2023-06-07T23:08:06Z

In reply to nevent1q…cnsx
_________________________

📅 Original date posted:2022-04-29
📝 Original message:Hi,

While I agree with the arguments in favour of (optional ANYONECANPAY) APOAS in lieu of CTV in the short-term (given the additional benefit of enabling Eltoo), there's a point to add in favour of CTV (or similar) in the long-term beyond as an optimisation.

With APOAS-based covenants, the signature message algorithm is tied to both the covenant commitment and transaction validation. Coupling these things introduces a trade-off between safety and flexibility with covenant-based applications. E.g. the maximally safe and restricted covenant commits to all inputs and outputs of the transaction (using SIGHASH ALL). However, a less restricted covenant commits to, for example, a single input and a single output (using ANYONECANPAY|SINGLE) but opens itself up to attacks making use of transaction malleability and signature replay. If instead we separate the covenant commitment from the signatures to validate transactions (as with CTV and TXHASH + CHECKSIGFROMSTACK) then we by-pass this trade-off. The flexibility of additional templates with new CTV versions or with the TXHASH primitive seems to me to enable significantly more utility for covenant-based applications.

Best regards,

Jacob Swambo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220429/942ba6fa/attachment.html>;

📅 Original date posted:2020-06-22 📝 Original message:I am ...

2023-06-07T18:25:36Z

In reply to nevent1q…786h
_________________________

📅 Original date posted:2020-06-22
📝 Original message:I am building a solution for distributed, delegated pre-signed transactions (DDPST). This post introduces what DDPST are and why I think they are relevant for multiple applications. If you are working on application that can benefit from such a construction and want me to use your application in the proof of concept code, please reach out. All feedback is welcome on the concept in general.

Pre-signed transactions (PSTs) are utilized in numerous off-chain protocols including Lightning Network, non-custodial trading, Statechains, and custody protocols. PSTs are useful because they enable restricted access to funds and their custody can be *delegated* with limited risk. Compare this with the arbitrary control over funds that comes with access to the private keys. It is conceivable then that a broad class of applications would benefit from a mechanism to securely delegate PSTs. A mechanism to *distribute* custody of PSTs across multiple entities can act as a practical countermeasure for numerous attacks (e.g. denial-of-service, bribery, blackmail, etc.). Moreover, systems of accountability among the custodians, with proofs of correct and incorrect behaviour, form a foundation for engineering incentive structures that align with the objectives of the application at hand. Finally, distributed custody of PSTs could enable new trust models for the privacy of delegated PSTs using multi-party computation.

# Examples

Consider first the example of vault-custody protocols [1], where there is a requirement for a distributed network monitoring and response system to detect breeches and trigger a recovery process. It is critical to protect against denial-of-service (DoS) attacks that seek to compromise a monitoring node in order to force the custody operation into a recovery process. In this attack the adversary broadcasts the recovery transaction and reduces the accessibility of the wallet owner's funds. A method for distributing custody of the recovery transaction offers defence-in-depth, and a method for delegating custody enables outsourcing the monitor and response service (see Watchtower implementations currently under development [2,3]). A further improvement for the protection of PSTs, that comes from distributing custody, is that *proactive* security models can be instanciated such that successful attacks must occur in a limited time-frame [4].

Consider next the example of justice transactions in the current Lightning Network model. Here, it is critical that justice transactions are broadcast in a timely manner in response to detecting that either party is attempting to close the channel with a prior state. Attacks rely on disrupting the broadcast of the justice transaction through, for example, bribing the watchtower to wait. The watchtower can broadcast late and claim that it was an honest failure due to network issues. The victim has no recourse to punish the watchtower nor the malicious channel participant. If instead the justice transaction was distributed among a set of independent watchtowers, and an accountability system was in-place for their actions, a more robust incentive structure could be engineered. Moreover, distributing custody of the justice transaction can provide a new privacy mechanism for both operational security of a business but also to mitigate targeted attacks such as bribery.

Best regards,
Jacob

# References

[1] Jacob Swambo, Spencer Hommel, Bob McElrath, and Bryan Bishop. Custody Protocols Using Bitcoin Vaults. 2020. https://arxiv.org/abs/2005.11776

[2] The eye of satoshi - lightning watchtower. https://github.com/talaia-labs/python-teos

[3] Private altruist watchtowers. https://github.com/lightningnetwork/lnd/blob/master/docs/watchtower.md

[4] Ran Canetti, Rosario Gennaro, and Amir Herzberg. Proactive security: Long-term protection against break-ins. CryptoBytes, 3:1–8, 1997.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200622/68d835de/attachment.html>;