On Tue, Jan 31, 2012 at 12:17 AM, Gregory Maxwell wrote:
> On Mon, Jan 30, 2012 at 11:33 PM, Michael Hendricks wrote:
>> address manager point to the attacker. If a client has 8 connections
>> to the network, a Sybil attack would succeed 1.7% of the time.
>
> Meh, careful not to mixup addrman cr
On Tue, Jan 31, 2012 at 12:17 AM, Gregory Maxwell wrote:
> On Mon, Jan 30, 2012 at 11:33 PM, Michael Hendricks wrote:
>> address manager point to the attacker. If a client has 8 connections
>> to the network, a Sybil attack would succeed 1.7% of the time.
>
> Meh, careful not to mixup addrman cr
We split IRC among all those channels to handle the load when there were 60k
clients.. the ideal thing would be some kind of dynamic sizing, and this
applies to the number of outbound connections and transaction relaying logic
too.. the same values that work for 1k clients don't work as well for
On 01/30/2012 11:33 PM, Michael Hendricks wrote:
> On Mon, Jan 30, 2012 at 7:05 PM, Gavin Andresen
> wrote:
>> Given the randomness in Pieter's design, that seems extremely unlikely
>> / difficult to do. Is it possible to do a back-of-the-envelope
>> calculation to figure out what percentage of n
> I think it's important that we have more mechanisms then just DNS and
> hardcoded seednodes.
> This is important because the mechanisms we have are all pretty
> subject to blocking. Now— before you say it— Bitcoin isn't intended to
> be blocking resistant (combine it with Tor and Tor anti-censors
On Mon, Jan 30, 2012 at 11:33 PM, Michael Hendricks wrote:
> address manager point to the attacker. If a client has 8 connections
> to the network, a Sybil attack would succeed 1.7% of the time.
Meh, careful not to mixup addrman created issues with preexisting ones
simply related to the number o
On Mon, Jan 30, 2012 at 7:05 PM, Gavin Andresen wrote:
> Given the randomness in Pieter's design, that seems extremely unlikely
> / difficult to do. Is it possible to do a back-of-the-envelope
> calculation to figure out what percentage of nodes on the network an
> attacker would have to control t
On Mon, Jan 30, 2012 at 9:05 PM, Gavin Andresen wrote:
> I've also been wondering if it is time to remove the IRC bootstrapping
> mechanism; it would remove a fair bit of code and we'd stop getting
> reports that various ISPs tag bitcoin as malware. When testing the
> list of built-in bootstrappi
On Monday, January 30, 2012 9:05:49 PM Gavin Andresen wrote:
> I've also been wondering if it is time to remove the IRC bootstrapping
> mechanism; it would remove a fair bit of code and we'd stop getting
> reports that various ISPs tag bitcoin as malware. When testing the
> list of built-in bootst
> Cool design. It seems resilient to many attacks. A Sybil attack
> coming from a large botnet (which controls addresses in many ranges)
> can still fill all buckets in both tables, I think. As far as I can
> tell, that wasn't possible with the old design.
Given the randomness in Pieter's desig
On Sun, Jan 29, 2012 at 7:31 PM, Pieter Wuille wrote:
> wanting to move to IPv6 support in the Satoshi bitcoin client
> somewhere in the future, the way IP addresses were managed is not
> really possible anymore. Right now, basically all addresses ever seen
> are kept - both on-disk and in-memory,
On Sunday, January 29, 2012 9:31:02 PM Pieter Wuille wrote:
> The implementation is available in pull request 787
> (https://github.com/bitcoin/bitcoin/pull/787), but there is certainly
> need for testing, and room for improvements. Test reports, comments,
> constructive criticism, suggestions and
Hello all,
wanting to move to IPv6 support in the Satoshi bitcoin client
somewhere in the future, the way IP addresses were managed is not
really possible anymore. Right now, basically all addresses ever seen
are kept - both on-disk and in-memory, and sorted on last-seen time
with some randomizati
13 matches
Mail list logo
