Hi everyone:
We would like to share a paper and website for CVE-2018-17145 that was
found in mid-2018.
There was an easily exploitable uncontrolled memory resource consumption
denial-of-service vulnerability that existed in the peer-to-peer network
code of three implementations of Bitcoin and sev
On 5/5/20 5:31 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
> Hi Antoine,
>
>> Even with cheaper, more efficient protocols like BIP 157, you may have a
>> huge discrepancy between what is asked and what is offered. Assuming 10M
>> light clients [0] each of them consuming ~100MB/month for filters/
On 5/6/20 9:07 PM, Keagan McClelland wrote:
> I think that one of the solutions here is to have light clients choose
> their full node tethers explicitly. Even if you think it is unrealistic to
> have everyone run their own node (fwiw, I don’t), there is still a trust
> model where you can pick yo
On 5/8/20 1:01 PM, Keagan McClelland wrote:
>> The RPC interface in Bitcoin Core, and others, is not great for this
>> because it exposes a lot of functionality that isn't necessary and
>> introduces risks.
> This is actually somewhat my point. If the RPC interface was good for this
> and *didn't*
On 10/15/19 8:50 AM, Joachim Strömbergson wrote:
> [...] to generate much longer chain with superslow timestamp increase (~5
> blocks in 1 second) without increasing difficulty (i.e. staying at min.
> diff.). [...]
> In that case, it would take about 7 minutes of block time secon
On 10/12/19 1:46 PM, Tier Nolan via bitcoin-dev wrote:
> On Sat, Oct 12, 2019 at 6:56 PM Joachim Strömbergson
> wrote:
>> On different note, one of the problems that I haven't seen mentioned here
>> yet is the timewarp attack. It is relevant to some of the proposed
>> solutions. It should be pos
On 10/15/19 12:20 AM, Joachim Strömbergson wrote:
>>> [...] to generate much longer chain with superslow timestamp increase (~5
>>> blocks in 1 second) without increasing difficulty (i.e. staying at min.
>>> diff.). [...]
>> In that case, it would take about 7 minutes of block time seconds for
>
On 10/12/19 10:56 AM, Joachim Strömbergson via bitcoin-dev wrote:
> [...] First you provide proof of your best block height via coinbase [...]
So I don't think you can use the height in the coinbase for that
purpose, as it's not possible to validate it without the previous
headers. That's common
On 10/12/19 9:27 AM, Tier Nolan via bitcoin-dev wrote:
> [...]
>
> I think parallel downloading would be better than focusing on one peer
> initially. Otherwise, a dishonest peer can slowly send their headers to
> prevent moving to parallel mode.
>
> [...]
As implemented, there is a timeout for
On 10/4/19 1:20 AM, David A. Harding wrote:
> On Thu, Oct 03, 2019 at 05:38:36PM -0700, Braydon Fuller via bitcoin-dev
> wrote:
>> This paper describes a solution [to DoS attacks] that does not
>> require enabling or maintaining checkpoints and provides improved security.
>
On 10/4/19 4:31 PM, Tier Nolan via bitcoin-dev wrote
> [..] At root, the requirement is that peers can prove their total chain POW.
> [...]
Indeed, it's currently necessary to receive all of the chain headers to
determine. It would be interesting to have a succinct chainwork proof
for all cases.
On 10/4/19 1:20 AM, David A. Harding wrote:
> On Thu, Oct 03, 2019 at 05:38:36PM -0700, Braydon Fuller via bitcoin-dev
> wrote:
>> This paper describes a solution [to DoS attacks] that does not
>> require enabling or maintaining checkpoints and provides improved security.
>
Hi everyone,
We would like to share a paper for broad discussion, it is titled
"Bitcoin Chain Width Expansion Denial-of-Service Attacks".
>From the abstract: The attacks leverage unprotected resources for a
denial-of-service by filling the disk and exhausting the CPU with
unnecessary header and b
13 matches
Mail list logo
