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
Dear bitcoin-development,
One of the original reasons for the creation of this mailing list was because
the bitcoin.org forum was filled with this type of noise and this list was to
provide a medium for discussion of development topics. This entire SOPA thing
is off topic for this list. Might
Using commercial CAs to establish trust is a site local administrative policy..
Bitcoin and operating systems have no technical need to concern themselves with
this. It is a shame that the system has been abused by CAs paying off
operating system and web browser vendors but this is not the only
I think HTTPS, and more specifically x.509 PKI certs and CAs are generally a
good idea and (historical implementation bugs aside) the concept is technically
sound and secure. What is a bad idea (in my opinion) is to trust a software
vendor to decide who you should trust.. thus it is a bad idea
block based, there is no need to ever recalculate
the first half since the brute forcing value is in the second half of the
block..
This was the original prototype for the OpenCL miner without eliminating
redundant calculations and it shows the block1 and block2 calculations clearly.
http://he
I don't think that any kind of peer disconnection should be present in the
reference client implementation. This is a lot like using packet filters and
stateful firewalls - they are implemented based on local policy and they
require constant tweaking because they always cause problems when some
6 matches
Mail list logo
