On Fri, Sep 22, 2017 at 2:54 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> If the variable size increase is only a few bytes, then three
> possibilities arise:
>
> - one should allow signatures to be zero padded (to reach the maximum
> size) and abandon
There is no harm in the value being a maximum off by a few bytes.
> On Sep 22, 2017, at 2:54 PM, Sergio Demian Lerner
> wrote:
>
> If the variable size increase is only a few bytes, then three possibilities
> arise:
>
> - one should allow signatures to be zero padded (to reach the maximum siz
If the variable size increase is only a few bytes, then three possibilities
arise:
- one should allow signatures to be zero padded (to reach the maximum size)
and abandon strict DER encoding
- one should allow spare witness stack elements (to pad the size to match
the maximum size) and remove the
You generally know the witness size to within a few bytes right before signing.
Why would you not? You know the size of ECDSA signatures. You can be told the
size of a hash preimage by the other party. It takes some contriving to come up
with a scheme where one party has variable-length signatur
But generally before one signs a transaction one does not know the
signature size (which may be variable). One can only estimate the maximum
size.
On Fri, Sep 22, 2017 at 6:11 PM, Mark Friedenbach
wrote:
>
> On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner <
> sergio.d.ler...@gmail.com> wrote:
> On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner
> wrote:
>
>
>
> There are other solutions to this problem that could have been taken
> instead, such as committing to the number of items or maximum size of
> the stack as part of the sighash data, but cleanstack was the approach
> taken.
>
> There are other solutions to this problem that could have been taken
> instead, such as committing to the number of items or maximum size of
> the stack as part of the sighash data, but cleanstack was the approach
> taken.
The lack of signed maximum segwit stack size was one of the objections
> On 22 Sep 2017, at 12:33 AM, Luke Dashjr wrote:
>
> On Thursday 21 September 2017 8:02:42 AM Johnson Lau wrote:
>> I think it’s possible only if you spend more witness space to store the
>> (pubkey, message) pairs, so that old clients could understand the
>> aggregation produced by new clients
On Thursday 21 September 2017 8:02:42 AM Johnson Lau wrote:
> I think it’s possible only if you spend more witness space to store the
> (pubkey, message) pairs, so that old clients could understand the
> aggregation produced by new clients. But this completely defeats the
> purpose of doing aggrega
> On 21 Sep 2017, at 12:11 PM, Luke Dashjr wrote:
>
> On Wednesday 20 September 2017 5:13:04 AM Johnson Lau wrote:
>> 2. OP_RETURNTRUE does not work well with signature aggregation. Signature
>> aggregation will collect (pubkey, message) pairs in a tx, combine them,
>> and verify with one signat
On Wednesday 20 September 2017 5:13:04 AM Johnson Lau wrote:
> 2. OP_RETURNTRUE does not work well with signature aggregation. Signature
> aggregation will collect (pubkey, message) pairs in a tx, combine them,
> and verify with one signature. However, consider the following case:
>
> OP_RETURNTRU
> On 21 Sep 2017, at 3:29 AM, Mark Friedenbach wrote:
>
>
>> On Sep 19, 2017, at 10:13 PM, Johnson Lau wrote:
>>
>> If we don’t want this ugliness, we could use a new script version for every
>> new op code we add. In the new BIP114 (see link above), I suggest to move
>> the script version
> On Sep 19, 2017, at 10:13 PM, Johnson Lau wrote:
>
> If we don’t want this ugliness, we could use a new script version for every
> new op code we add. In the new BIP114 (see link above), I suggest to move the
> script version to the witness, which is cheaper.
To be clear, I don’t think it i
> On 19 Sep 2017, at 11:09 AM, Luke Dashjr via bitcoin-dev
> wrote:
>
> On Tuesday 19 September 2017 12:46:30 AM Mark Friedenbach via bitcoin-dev
> wrote:
>> After the main discussion session it was observed that tail-call semantics
>> could still be maintained if the alt stack is used for tra
> On Sep 18, 2017, at 8:09 PM, Luke Dashjr wrote:
>
> On Tuesday 19 September 2017 12:46:30 AM Mark Friedenbach via bitcoin-dev
> wrote:
>> After the main discussion session it was observed that tail-call semantics
>> could still be maintained if the alt stack is used for transferring
>> argume
On Tuesday 19 September 2017 12:46:30 AM Mark Friedenbach via bitcoin-dev
wrote:
> After the main discussion session it was observed that tail-call semantics
> could still be maintained if the alt stack is used for transferring
> arguments to the policy script.
Isn't this a bug in the cleanstack
16 matches
Mail list logo
