> On 9 Mar 2016, at 20:21, Bob McElrath wrote:
>
> Dave Hudson [d...@hashingit.com] wrote:
>> A damping-based design would seem like the obvious choice (I can think of a
>> few variations on a theme here, but most are found in the realms of control
>> theory
I think the biggest question here would be how would the difficulty retargeting
be changed? Without seeing the algorithm proposal it's difficult to assess the
impact that it would have, but my intuition is that this is likely to be
problematic.
Probabilistically the network sees surprisingly
On 7 Aug 2015, at 16:17, Ryan Butler via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
A raspberry pie 2 node on reasonable Internet connection with a reasonable
hard drive can run a node with 8 or 20mb blocks easily.
I'm curious as I've not seen any data on this subject. How
On 5 Aug 2015, at 15:15, Peter R pete...@gmx.com wrote:
Hi Dave,
Thank you for the feedback regarding my paper.
The paper is nicely done, but I'm concerned that there's a real problem with
equation 4. The orphan rate is not just a function of time; it's also a
function of the
On 4 Aug 2015, at 14:30, Gavin Andresen gavinandre...@gmail.com wrote:
On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org
mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
Fundamentally a block maker (pool or aggregation of pools) does
The paper is nicely done, but I'm concerned that there's a real problem with
equation 4. The orphan rate is not just a function of time; it's also a
function of the block maker's proportion of the network hash rate.
Fundamentally a block maker (pool or aggregation of pools) does not orphan its
On 30 Jul 2015, at 06:14, Tom Harding via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Another empirical fact also needs explaining. Why have average fees *as
measured in BTC* risen during the times of highest public interest in
bitcoin? This happened without block size