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
Hi,
Given today's presentation by Chris Jeffrey at the Breaking Bitcoin
conference, and the subsequent discussion around responsible disclosure
and industry practice, perhaps now would be a good time to discuss
"Bitcoin and CVEs" which has gone unanswered for 6 months.
Hi,
Are there are any vulnerabilities in Bitcoin which have been fixed but
not yet publicly disclosed? Is the following list of Bitcoin CVEs
up-to-date?
https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
There have been no new CVEs posted for almost three years, except for
> 1) The segregated witness discount is changed from 75% to 50%. The block
> size limit (ie transactions + witness/2) is set to 1.5MB. This gives a
> maximum block size of 3MB and a "network-upgraded" block size of roughly
> 2.1MB. This still significantly discounts script data which is kept out
>
Hi Pavel,
(my earlier email was moderated, so the list can only see it via your
reply),
Yes, an attacker could try and send malicious data to take advantage of
a compression library vulnerability... but is it that much worse than
existing attack vectors which might also result in denial of
Storage of UTXO data looks like an implementation detail and thus one
would have thought that the choice of database would not increase the
odds of consensus protocol failure.
Btcd, a full node implementation written in Go, already provides a
database interface which supports different backends:
Maybe grab some code from BIP101 ? It permits block messages > 2MB,
while retaining the current limit of 2 MB imposed on other network
messages. The 32 MB limit was patched a few months ago.
Links to code:
Hi Jeff,
Thoughts on this part of the proposal:
"Absent/invalid votes are counted as votes for the current hardLimit.
Out of range votes are counted as the nearest in-range value."
1. Why should an absent vote be considered a vote for the status quo? A
non-voter should have zero impact on the
I don't think this would work.
If the rule is that one user can only have one vote, how do you prevent
a user running multiple nodes?
Also, how do you verify that a node is indeed a fully validating node
with its own copy of the blockchain?
On 08/25/2015 01:37 PM, Peter Todd via bitcoin-dev
-0700, Simon Liu via bitcoin-dev wrote:
Olivier Janssens claims that one of your colleagues is asking for Gavin
to be removed from his position. Is this true?
https://www.reddit.com/r/Bitcoin/comments/3hksre/blockstream_employee_asking_to_remove_gavin_from/?sort=confidence
http
That's a good question.
An argument has been put forward that a larger block size would reduce
the security of the network, so does the converse hold?
On 08/07/2015 11:17 AM, jl2012 via bitcoin-dev wrote:
What if we reduce the block size to 0.125MB? That will allow 0.375tx/s.
If 3-24 sounds
Increasing the block size shouldn't be a problem for Chinese miners.
Five of the largest - F2Pool, Antpool, BW, BTCChina, Huobi - have
already signed a draft agreement indicating they are fine with an
increase to 8 MB: http://www.8btc.com/blocksize-increase-2
With regards to China's international
12 matches
Mail list logo
