On Mon, 16 Sep 2019 at 21:10, ZmnSCPxj via bitcoin-dev
wrote:
> ‐‐‐ Original Message ‐‐‐
> > I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for
> > segwit
> > v0 for compatibility reasons. Most wallets/exchanges/services now support
> > sending
> > to native segwit
Good morning Greg and John,
I am not as sanguine here; SegWit activation was already delayed relative to
commonly-broadcast expectations, yet many services *still* do not support
sending to SegWit v0 addresses even now.
On the other hand, the major benefit of taproot is the better privacy and
> I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for
segwit
v0 for compatibility reasons. Most wallets/exchanges/services now support
sending
to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption) and
that
will be even more true if Schnorr/Taproot activate in
On Fri, 9 Aug 2019 at 08:02, Elichai Turkel via bitcoin-dev
wrote:
>
> Hi,
Since the idea of implicitly even pubkeys has potentially more general
implications, I've started a separate thread [1] about that idea.
> I want to add to John Newbery's suggestion of using implicit even/odd only
>
Hi,
I want to add to John Newbery's suggestion of using implicit even/odd only
public keys and tweaked public keys in taproot and suggest the following:
If everything is implicit then the only reason for the first byte of the
control block(`c[0]`) is the tapscript leaf version.
I suggest that
Hmm? If I'm following what you mean, that's not the P2P rules, it's the
> Unserialize code, in particular:
>
> compat/assumptions.h:52:static_assert(sizeof(int) == 4, "32-bit int
> assumed");
>
> serialize.h:289:uint64_t ReadCompactSize(Stream& is)
>
> serialize.h-679-template typename V>
>
On Wed, Jun 26, 2019 at 08:08:01PM -0400, Russell O'Connor via bitcoin-dev
wrote:
> I have a comment about the 'input_index' of the transaction digest for taproot
> signatures. It is currently listed as 2 bytes. I think it would be better to
> expand that to 4 bytes.
FWIW, I think this would
I have a comment about the 'input_index' of the transaction digest for
taproot signatures. It is currently listed as 2 bytes. I think it would
be better to expand that to 4 bytes.
The two byte limit is derived from the block size / weight limit, which
limits the maximum size of a transaction,
On Wed, May 22, 2019 at 10:06 PM Pieter Wuille
wrote:
> On Tue, 21 May 2019 at 10:20, Russell O'Connor
> wrote:
> >
> > Regarding Tapscript, the specification calls for the final value of the
> stack being a single non-false value:
> >
> >> The tapscript is executed according to the rules in
On Tue, 21 May 2019 at 10:20, Russell O'Connor wrote:
>
> Regarding Tapscript, the specification calls for the final value of the stack
> being a single non-false value:
>
>> The tapscript is executed according to the rules in the following section,
>> with the initial stack as input
>> II.
Hi,
> A Taproot output is a SegWit output [...] with
> version number 1, and a 33-byte witness program whose first byte is 0 or
1.
Given a secret key k and public key P=(x,y), a signer with the knowledge of
k
can sign for -P=(x,p-y) since -k is the secret key for that point. Encoding
the
y
Regarding Tapscript, the specification calls for the final value of the
stack being a single non-false value:
The tapscript is executed according to the rules in the following section,
> with the initial stack as input
> II. If the execution results in anything but exactly one element on
>
Good morning list,
> > Can this "unknown discrete logarithm" be made provably unknown, so all
> > signers are assured of this property? Bonus points if the outside world
> > can't tell. The exact mechanism could be outside the scope of the BIP, but
> > knowing that it's possible is useful.
>
Good morning Johnson,
> > > Some way to sign an additional script (not committed to by the witness
> > > program) seems like it could be a trivial addition.
> >
> > It seems to me the annex can be used for this, by having it contain both
> > the script and the signature somehow concatenated.
>
>
>>
>> Some way to sign an additional script (not committed to by the witness
>> program) seems like it could be a trivial addition.
>
> It seems to me the annex can be used for this, by having it contain both the
> script and the signature somehow concatenated.
This is not possible since
On Monday 06 May 2019 20:17:09 Luke Dashjr via bitcoin-dev wrote:
> Some way to sign an additional script (not committed to by the witness
> program) seems like it could be a trivial addition.
This would be especially useful for things like OP_CHECKBLOCKATHEIGHT:
Good morning Sjors, sorry everyone for the double-posting...
> I believe this is the "hash to a point" technique.
>
> The scalar behind the above point cannot be known, unless either the hash
> function is broken, or ECDLP is broken.
> (perhaps a better cryptographer can give the proper
Good morning Sjors,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Wednesday, May 8, 2019 4:42 AM, Sjors Provoost via bitcoin-dev
wrote:
> Hey Pieter,
>
> I think this is a reasonable collection of changes that make sense in
> combination. Some initial feedback and
Good morning Luke,
> Is there any way to use the Taproot construct here while retaining external
> script limitations that the involved party(ies) cannot agree to override?
> For example, it is conceivable that one might wish to have an unconditional
> CLTV enforced in all circumstances.
Thanks for the comments so far!
I'm going to respond to some of the comments here. Things which I plan
to address with changes in the BIP I'll leave for later.
On Mon, 6 May 2019 at 13:17, Luke Dashjr wrote:
> Tagged hashes put the tagging at the start of the hash input. This means
>
On Mon, May 06, 2019 at 08:17:09PM +, Luke Dashjr via bitcoin-dev wrote:
> Some way to sign an additional script (not committed to by the witness
> program) seems like it could be a trivial addition.
Aside: if you want to commit to something extra *with* the witness
program, you could use
Hey Pieter,
I think this is a reasonable collection of changes that make sense in
combination. Some initial feedback and questions.
>From the BIP:
> If one or more of the spending conditions consist of just a single key (after
> aggregation),
> he most likely one should be made the internal
There are multiple references to "space savings", but no rationale for
treating "space" as something to save or even define. The costs are in CPU
time and I/O (which "space saving" doesn't necessarily reduce) and bandwidth
(which can often be reduced without "space saving" in commitments). The
Hello everyone,
Here are two BIP drafts that specify a proposal for a Taproot
softfork. A number of ideas are included:
* Taproot to make all outputs and cooperative spends indistinguishable
from eachother.
* Merkle branches to hide the unexecuted branches in scripts.
* Schnorr signatures enable
24 matches
Mail list logo
