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
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.
https://lists.linuxfoundati
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
CVE-2015
On 05/11/2016 02:01 PM, Matt Corallo via bitcoin-dev wrote:
> Indeed, I think the "ASICs are bad, because 1-CPU-1-vote" arguments
> mostly died out long ago, and, indeed, the goal that many making those
> arguments had of building "unoptimizeable" ASICs failed with them.
Discussion quietened down
> 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 servi
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:
https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_whic
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 r
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 wro
2015 at 10:22:32AM -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_g
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://pastebin.com/q2TT58Z5
> I find it quite notable that
There's also an interesting question posted over at Reddit - will
Lightning payment hubs be treated as money transmitters in the US?
https://www.reddit.com/r/bitcoin_uncensored/comments/3gjnmd/lightning_may_not_be_a_scaling_solution/
A payment hub operator working with brand name merchants like D
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 sound
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
Would a 1MB increase to 2MB, as outlined in BIP 102, be considered a
"modest" increase?
On 07/24/2015 07:09 AM, Adam Back via bitcoin-dev wrote:
> I am
> optimistic that within a year Bitcoin scaling and decentralisation
> will look much better with current active work on decentralisation,
> layer
Increasing the block size does not hinder research and development of
Lightning or other technologies.
On 07/23/2015 05:04 PM, Eric Lombrozo via bitcoin-dev wrote:
> I should also add that I think those who claim that fee pressure will
> scare away users and break the industry are *seriously* und
17 matches
Mail list logo
