On Mon, Sep 11, 2017 at 10:37 PM, Anthony Towns via bitcoin-dev
wrote:
> All of those things seem like they'd help not just altcoins but bitcoin
> investors/traders too, so it's not even a trade-off between classes of
> bitcoin core users. And if in the end various altcoins aren't able to
> keep
On Mon, Sep 11, 2017 at 10:43:52AM -0700, Daniel Stadulis wrote:
> I think it's relevant to treat different bug severity levels with different
> response plans.
That makes sense.
For comparison, Monero defines a response process that has three levels
and varies the response for each:
] a. H
On Mon, Sep 11, 2017 at 07:34:33AM -0400, Alex Morcos wrote:
> I don't think I know the right answer here, but I will point out two things
> that make this a little more complicated.
> 1 - There are lots of altcoin developers and while I'm sure the majority would
> greatly appreciate the disclosure
On Mon, Sep 11, 2017 at 9:03 PM, Mark Friedenbach via bitcoin-dev
wrote:
> I believe you meant "unclean stack," and you are correct. This was
> also pointed out last tuesday by a participant at the in-person
> CoreDev meetup where the idea was presented.
http://diyhpl.us/wiki/transcripts/bitcoin-
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:
> Tail-call execution semantics require "unclean stake" , i.e. final
> stake wi
Coincidentally, the kind of Merkle tree that Mark describes in his
proposal is exactly the one that we use at Stampery.
The Stampery BTA whitepaper[1] includes pseudocode for many of the
algorithms outlined by this proposal, including fast-SHA256, the tree
building process and the inclusion provin
On Mon, Sep 11, 2017 at 5:43 PM, Daniel Stadulis via bitcoin-dev
wrote:
> I think it's relevant to treat different bug severity levels with different
> response plans.
>
> E.g.
> Compromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability)
> Compromising UTXO state (In CVE-2013-3220, bloc
I think it's relevant to treat different bug severity levels with different
response plans.
E.g.
Compromising UTXO custody (In CVE-2010-5141, OP_RETURN vulnerability)
Compromising UTXO state (In CVE-2013-3220, blockchain split due to Berkeley
DB -> LevelDB upgrade, CVE-2010-5139 Overflow bug, unsc
I don't think I know the right answer here, but I will point out two things
that make this a little more complicated.
1 - There are lots of altcoin developers and while I'm sure the majority
would greatly appreciate the disclosure and would behave responsibly with
the information, I don't know whe
