On Sep 12, 2017, at 1:55 AM, Johnson Lau wrote:
> This is ugly and actually broken, as different script path may
> require different number of stack items, so you don't know how many
> OP_TOALTSTACK do you need. Easier to just use a new witness version
DEPTH makes this relatively easy to do. Jus
On Tue, Sep 12, 2017 at 4:49 AM, Sergio Demian Lerner via bitcoin-dev
wrote:
> It also implies that some times a researcher works hard to investigate a
> vulnerability and later he finds out it was previously reported. It also
> means that the researcher cannot report to alt-coins which have a dif
On Tue, Sep 12, 2017 at 3:37 AM, Anthony Towns via bitcoin-dev
wrote:
> If you can't pick even a small group that's trustworthy
No.
> I find it hard to imagine bitcoin's still obscure enough that people
> aren't tracking git commit logs to use them as inspiration for attacks
For embargoed fixes
It would be a good starting point if the current policy could be
clarified, so everyone is on the same page, and there is no confusion.
On 09/11/2017 09:49 PM, Sergio Demian Lerner via bitcoin-dev wrote:
> Historically people have published vulnerabilities in Bitcoin only after
>>80% of the nodes
a remote code execution, will be patched
> immediately (without disclosing the actual problem) and all participants
> will be notified asap. This is no different from any other open source
> project. An example of this case was the OpenSSL Heartbleed vulnerability
> that affe
> On 8 Sep 2017, at 4:04 AM, Mark Friedenbach via bitcoin-dev
> wrote:
>
> If I understand the revised attack description correctly, then there
> is a small window in which the attacker can create a script less than
> 55 bytes in length, where nearly all of the first 32 bytes are
> selected by
Historically people have published vulnerabilities in Bitcoin only after
>80% of the nodes have upgraded. This seems to be the general (but not
publicly stated) policy. If you're a core developer and you know better,
please correct me.
This means that:
- a critical vulnerability, like a remote co
On 09.09.2017 16:08, shiva sitamraju via bitcoin-dev wrote:
> Hi,
>
> I understand the motivation of adding the birthdate field. However, not
> very comfortable with having this in the public key serialization. There
> are privacy implication of both the birthday field and having the complete
>
> On 12 Sep 2017, at 10:03 AM, Mark Friedenbach wrote:
>
> My apologies for a delay in responding to emails on this list; I have
> been fighting a cold.
>
> (Also my apologies to Johnson Lau, as I forgot to forward this to the list.)
>
> On Sep 8, 2017, at 2:21 AM, Johnson Lau wrote:
>
>> Ta
