Re: [bitcoin-dev] ANYPREVOUT in place of CTV

2022-05-03 Thread Swambo, Jacob via bitcoin-dev
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:

 OP_CHECKSIG  OP_CHECKSIGADD  OP_CHECKSIGADD 2 OP_EQUAL 
  OP_CHECKSIG

And they produce this witness:

 

The second participant can, for example, add a change output before signing. 
 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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] ANYPREVOUT in place of CTV

2022-04-29 Thread Swambo, Jacob via bitcoin-dev
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2020-06-22 Thread Swambo, Jacob via bitcoin-dev
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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev