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 tx
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 pos
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 fanci
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 overhead at all
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
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 publ
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 blockchai
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
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 didn't involve hashing th
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 knowl
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 the key,
>
> Can you
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 able to solve the discret
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 to quantum
> > attacks
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 apparent-script monoculture for privacy
>
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 specifi
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 done
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 was,
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 description of the idea. It
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
Thanks Greg!
I'd be hesitant to deploy a MAST proposal without this clever application of
pay-to-contract-hash now! Looks like the overhead over a more-naive MAST
construction is rather trivial, too!
Matt
On January 23, 2018 12:30:06 AM UTC, Gregory Maxwell via bitcoin-dev
wrote:
>Interest i
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 anonymit
Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main
areas: efficiency and privacy. Efficiency because unexecuted forks of
a script can avoid ever hitting the chain, and privacy because hiding
unexecuted code leaves scripts indistinguishable to the extent that
their only differenc
22 matches
Mail list logo
