[bitcoin-dev] Distributed Delegated Pre-Signed Transactions (DDPST)

[bitcoin-dev] Distributed Delegated Pre-Signed Transactions (DDPST)

[Swambo, Jacob]

[-- Attachment #1: Type: text/plain, Size: 3902 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 5649 bytes --]