Hi all,
I've also been spending a few months coding upon the change's Pieter has
been making with the headersfirst8 pull request.
My code updates are also ready to test, and are available on github at
https://github.com/rebroad/bitcoin/ and the branch is
sipa-headersfirst8-patches.
I've made a
https://bitcointalk.org/index.php?topic=145066.0
The idea proposed in the above article seemed like an excellent idea. What
is holding this up from being implemented? Does someone need to code it, or
write a BIP first?
--
As part of a roadmap for block downloading, I think this may be a good time
to look into providing an HTTP/HTTPS protocol for block downloading - this
would also allow web proxies to cache blocks and thus make it more
accessible, as well as cater for resumeable downloads.
I was just thinking about the way block difficulty is calculated, and how
people may (in future) decide whether to mine or not.
Is it possible that when the difficulty is low, many will decide to mine,
producing blocks every 3 or 5 minutes, and then in 1 week, bitcoin will
increase the
Hi,
Looking at:
https://github.com/bitcoin/bitcoin/commit/3e52aaf2121d597ab1ed012b65e37f9cb5f2754e#src/main.cpp-P52
It appears that 8 months ago the code was changed to DoS(100) nodes sending
on txs that use individual txs as the coinbase. Does this mean txs that are
0 confirmed?
If so, then,
I recently was dabbling with AskFor() and changing the time waited from 2
minutes to 10 seconds (I think perhaps this value may change in future
versions when network tuning is implemented).
I noticed that, when used with the -limitfreerelay option that is causes
significant increase in traffic
Dear Bitcoin developers,
In brief, the proposal I have is to extend the protocol to allow
partial block download and upload. This is for people with
intermittent connectivity or restricted connectivity. e.g. my own
internet connection is quite slow, and my ISP routinely sends RSTs to
both sides
7 matches
Mail list logo
