Re: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY
The problem with using ALL|ANYONECANPAY is that you cannot verify beforehand that the other inputs are the inputs you want added to the transaction. Some examples of bad things that could happen: * Coordinator adds its own inputs, you still get your outputs but effectively paid fees for no privacy gain * The inputs added could be paying at a lower fee rate than expected, causing the tx to take longer than what you paid for * Different input types or amount are added so you no longer have the same uniformity across the inputs * (if you care) An input from a sanctioned address is added, causing you to get "tainted" coins. This is the code in ln-vortex that verifies the psbt on the client side if you are curious https://github.com/ln-vortex/ln-vortex/blob/master/client/src/main/scala/com/lnvortex/client/VortexClient.scala#L616 Best, benthecarman From: bitcoin-dev on behalf of alicexbt via bitcoin-dev Sent: Monday, May 22, 2023 7:51 AM To: Bitcoin Protocol Discussion Subject: [bitcoin-dev] Coinjoin with less steps using ALL|ANYONECANPAY Hi Bitcoin Developers, I recently experimented with different sighash flags, PSBTs and realized ALL|ANYONECANPAY could be used to reduce some steps in coinjoin. Steps: - Register outputs. - One user creates a signed PSBT with 1 input, all registered outputs and ALL|ANYONECANPAY sighash flag. Other participants keep adding their inputs to PSBT. - Finalize and broadcast the transaction. Proof of Concept (Aice and Bob): https://gitlab.com/-/snippets/2542297 Tx: https://mempool.space/testnet/tx/c6dd626591dca7e25bbd516f01b23171eb0f2b623471fcf8e073c87c1179c492 I plan to use this in joinstr if there are no major drawbacks and it can even be implemented by other coinjoin implementations. /dev/fd0 floppy disk guy Sent with Proton Mail secure email. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Using OP_VAULT to improve DLCs
Hi list, After reading through James's OP_VAULT proposal this week, I had a realization that this can be used for more than a deep cold storage wallet. Instead of vaulting and unvaulting, we can just send to a OP_UNVAULT output. When using OP_UNVAULT if we set the `recovery-spk-hash` to a burn address (ie OP_RETURN ``) and the `delay-period` to `0` we can use it as a not-so simple covenant with the `unvault-target-hash` being set to whatever output restrictions you want to create. Given this we can recreate a lot of what CTV promises, one of my favorites being [Lloyd's improvement to DLCs](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html) (I recommend reading that first) A similiar construction could be done by creating a taproot tree similiar to LLoyd's construction with each leaf looking like: ` 0 OP_UNVAULT CHECKSIG` In the same as Lloyd's proposal: when the oracle(s) reveals their attestations either party can combine them to get the secret key corresponding to `CET_i` and spend the coins to the CET (whose `unvault-target-hash` hash is `CET-hash`) which distributes the funds according to the contract. ## Comparison Compared to the original CTV proposal, this should get all the same computational savings. However, it would use more blockchain space. The main downside I see is our final spending script will be slightly larger. Instead of just having ` OP_CTV` it will be replaced with ` 0 OP_UNVAULT` (34 bytes extra, not including the witness discount). However, this may be negligible in the case of a DLC with many outcomes as a lot of the input size will be coming from the control block. This also can always be skipped by doing a cooperative close of the DLC if the internal-key of the taproot tree can be spent using something like MuSig. I imagine a lot of the other applications for CTV can be recreated with OP_VAULT using this same trick. # Credits - Lloyd Fournier for the original proposal - James O'Beirne for the OP_VAULT proposal and giving me the idea to skip the intial OP_VAULT and just use OP_UNVAULT Best, benthecarman ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Anti-fee-sniping protection with nSequence in taproot transactions to improve privacy for off-chain protocols
> If nSequence is set it should apply only to the first input of the transaction, if it has multiple inputs. This could have complications with DLCs and dual funded lightning. In both protocols the ordering of the inputs is not know until both parties have revealed all of their inputs, and during the reveal the nSequence is given. If we want DLCs and dual funded lightning to be compatible it would be better to have it define it as “at least one of the inputs of the transaction” instead of “it should apply only to the first input of the transaction” benthecarman ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
