Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

Good morning Greg, I am probably being exceedingly naive, but I would like to compare Taproot to a generalization of funding transactions. For instance, CoinSwapCS: 1. It uses an HTLC in an off-chain transaction, and a funding transaction TX0 whose output is a "simple" 2-of-2. 2. The HTLC

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

Gah, please no. I see no material reason why cross-input signature aggregation shouldn't have the signatures in the first n-1 inputs replaced with something like a single-byte push where a signature is required to indicate aggregation, and the combined signature in the last input at whatever

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Tue, Jan 23, 2018 at 1:44 AM, Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Jan 23, 2018 at 12:30:06AM +, Gregory Maxwell via bitcoin-dev > wrote: > > One point that comes up while talking about merkelized scripts is can > > we go about making

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Tue, Jan 23, 2018 at 12:30 AM, Gregory Maxwell wrote: > It turns out, however, that there is no need to make a trade-off. The > special case of a top level "threshold-signature OR > arbitrary-conditions" can be made indistinguishable from a normal > one-party signature, with no

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

Den 25 jan. 2018 00:22 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: I think you misread my second proposal. The first step is not only to publish the hash but to publish a *pair* consisting of the hash and the transaction. If the attacker changes the transaction

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Wed, 2018-01-24 at 19:51 +0100, Natanael wrote: > > That's not the type of attack I'm imagining. Both versions of your > scheme are essentially equivalent in terms of this attack. > > Intended steps: > 1: You publish a hash commitment. > 2: The hash ends up in the blockchain. > 3: You

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

Den 24 jan. 2018 16:38 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: Okay, I think my proposal was wrong... This looks better (feel free to break again): 1. Commit (H(classic_pk, tx), tx) to the blockchain, wait until confirmed 2. Reveal classic_pk in the

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Wed, 2018-01-24 at 13:51 +0100, Natanael via bitcoin-dev wrote: > Sidenote: There's a risk here with interception, insertion of a new > commitment and getting the new transaction into the blockchain first. > However, I would suggest a mining policy here were two known > conflicting transactions

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

Den 23 jan. 2018 23:45 skrev "Gregory Maxwell via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: On Tue, Jan 23, 2018 at 10:22 PM, Anthony Towns wrote: > Hmm, at least people can choose not to reuse addresses currently -- > if everyone were using taproot and that

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Wed, 2018-01-24 at 01:52 +, Andrew Poelstra via bitcoin-dev wrote: > > > They are. But I don't believe that is relevant; the attacker would > > simply steal the coins on spend. > > > Then the system would need to be hardforked to allow spending through > a > quantum-resistant ZKP of

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Tue, Jan 23, 2018 at 10:45:06PM +, Gregory Maxwell via bitcoin-dev wrote: > On Tue, Jan 23, 2018 at 10:22 PM, Anthony Towns wrote: > > Hmm, at least people can choose not to reuse addresses currently -- > > if everyone were using taproot and that didn't involve hashing

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Tue, Jan 23, 2018 at 10:22 PM, Anthony Towns wrote: > Hmm, at least people can choose not to reuse addresses currently -- > if everyone were using taproot and that didn't involve hashing the key, Can you show me a model of quantum computation that is conjectured to be

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Tue, Jan 23, 2018 at 01:15:38PM +, Gregory Maxwell wrote: > On Tue, Jan 23, 2018 at 6:44 AM, Anthony Towns wrote: > > Is this really intended as paying directly to a pubkey, instead of a > > pubkey hash? > > If so, isn't that a step backwards with regard to resistance

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Tue, Jan 23, 2018 at 9:23 PM, Matt Corallo via bitcoin-dev wrote: > The issue with that approach without support for the privacy-encouraging > wrapper proposed by Greg here is that it encourages adoption halfway and > destroys a lot of the value of the

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

The issue with that approach without support for the privacy-encouraging wrapper proposed by Greg here is that it encourages adoption halfway and destroys a lot of the value of the apparent-script monoculture for privacy preservation. Greg's proposal here doesn't change the format of any

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

Interesting parallels to current Elements sidechain peg-in functionality. User tweaks the watchmen(BTC holder) pubkey using P2CH, committing to a script that is used on the *sidechain side* as spending authorization for that bitcoin output rather than mainnet. I think composing the two can be

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

I had the opposite response in private, which I will share here. As recently as Jan 9th feedback on BIP 117 was shared on this list by Pieter Wuille and others suggesting we adopt native MAST template instead of the user programmable combination of BIPs 116 and 117. Part of my response then

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Tue, Jan 23, 2018 at 6:44 AM, Anthony Towns wrote: > Is this really intended as paying directly to a pubkey, instead of a > pubkey hash? > > If so, isn't that a step backwards with regard to resistance to quantum > attacks against ECC? You're reading too much into a

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

On Tue, Jan 23, 2018 at 12:30:06AM +, Gregory Maxwell via bitcoin-dev wrote: > One point that comes up while talking about merkelized scripts is can > we go about making fancier contract use cases as indistinguishable as > possible from the most common and boring payments. > Now we tweak C to

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

This sounds like a useful idea for improving the privacy of coinswap. Traditionally coinswap mixing had an anonymity set related to the number of multisig transactions being used on the blockchain. With the new tech of Schnorr, MAST and now this Taproot, with sufficient adoption coinswap's