it privately to the core developers? Apologies if you
did disclose it privately in the past; I've seen no mention of it.
--
Jameson Lopp
Software Engineer
Bronto Software
On 11/05/2013 01:58 PM, Jeff Garzik wrote:
On Tue, Nov 5, 2013 at 1:55 PM, Alessandro Parisi startit...@gmail.com
wrote
or the miner could choose, how this works is not something I'm
personally focused on.
Yeah... you can't just gloss over a little detail like that. There must
be consensus between the miners, otherwise a solved block will be
rejected by a miner's peers.
--
Jameson Lopp
Software Engineer
Bronto
no reliance on external data ... depending on various factors (coin
valuation/exchange rate
ಠ_ಠ
--
Jameson Lopp
Software Engineer
Bronto Software
On 12/10/2013 11:23 AM, Jan Kučera wrote:
Basically there would be no reliance on external data as the network itself
would decide on reward height
You have plenty of good points, but they are not relevant to this mailing list.
I suggest you take them elsewhere.
--
Jameson Lopp
Software Engineer
Bronto Software, Inc
On 02/10/2014 01:25 PM, Troy Benjegerdes wrote:
On Mon, Feb 10, 2014 at 08:45:03AM -0800, Gregory Maxwell wrote:
On Mon, Feb
I'm glad to see that I'm not the only one concerned about the consistent
dropping of nodes. Though I think that the fundamental question should be: how
many nodes do we really need? Obviously more is better, but it's difficult to
say how concerned we should be without more information. I posted
On 04/07/2014 08:26 AM, Pieter Wuille wrote:
In my opinion, the number of full nodes doesn't matter (as long as
it's enough to satisfy demand by other nodes).
I agree, but if we don't quantify demand then we are practically blind. What
is the plan? To wait until SPV clients start lagging /
The Bitnodes project updated their counting algorithm a month or so ago. It
used to be slower and less accurate - prior to their update, it was reporting
in excess of 100,000 nodes.
- Jameson
On 04/07/2014 09:53 AM, Gregory Maxwell wrote:
On Mon, Apr 7, 2014 at 6:50 AM, Gregory Maxwell
I would point to bandwidth as the most important issue to the casual user who
runs a node at home. Few casual users have the know-how to set up QoS rules and
thus become quite annoyed when their Internet connection is discernibly slowed.
- Jameson
On 04/07/2014 11:53 AM, Gregory Maxwell wrote:
Perhaps I missed it somewhere, but I don't recall it ever being a goal of
Bitcoin to act as a stable long-term store of value.
- Jameson
On 04/30/2014 01:06 PM, Troy Benjegerdes wrote:
On Wed, Apr 30, 2014 at 11:00:06PM +1000, Gareth Williams wrote:
On 30/04/14 00:13, Mike Hearn wrote:
I do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In order to gain more insight into what messages and requests a node is
processing, I've created a Bitcoin Core fork that outputs statistics to StatsD.
I hope that some of you will find this interesting and potentially useful.
?
- - Jameson
On 05/07/2014 03:46 PM, Wladimir wrote:
On Wed, May 7, 2014 at 9:12 PM, Jameson Lopp jameson.l...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In order to gain more insight into what messages and requests a node is
processing, I've created a Bitcoin Core fork
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I completely agree that this setup is far too difficult to reasonably expect
anyone to implement it. You're correct that we could run a single StatsD daemon
and have quite a few nodes sending statistics to it - this is really what
StatsD was
the node's performance.
- - Jameson
On 05/07/2014 04:18 PM, Wladimir wrote:
On Wed, May 7, 2014 at 9:57 PM, Jameson Lopp jameson.l...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I agree that it would be awesome to offer these types of stats with the
installer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since it seems unlikely that we'll be able to ship an integrated stats /
monitoring feature in the short term, I went ahead and set up a public Statoshi
instance and threw a nicer interface on top of it.
http://statoshi.info
You can also view the
,
On Sun, May 11, 2014 at 7:14 PM, Jameson Lopp jameson.l...@gmail.com
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since it seems unlikely that we'll be able to ship an integrated stats /
monitoring feature in the short term, I went ahead and set up a public
Statoshi instance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I may be able to provide some insight regarding request volume / abuse via my
public node at http://statoshi.info
My node receives a 'getaddr' request about every 50 seconds:
http://i.imgur.com/XEpnWfG.png
In terms of the 'addr' messages that it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I host charts of my node's system metrics at
http://statoshi.info/#/dashboard/db/system-metrics
Note that the CPU spikes are abnormal as I'm making automated RPC calls to
query the UTXO set.
My node's bandwidth usage chart can be found at
This is an interesting idea from the standpoint of trying to incentivize
people to run nodes, though from a high level it seems to just be adding
complexity to the current process by which nodes 'endorse' blocks. When a
node receives and validates a block it then informs its peers of the new
coin
and back it itself.
The company is currently in motion and will hire an expert to do some of
the coding by October 14, 2015. Company President refused to be
interviewed due to too much work that needs done for this secret and
upcoming project.
On Fri, Jun 19, 2015 at 10:34 AM, Jameson
You are free to remove yourself; the URL is at the bottom of every email:
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc.
corpor...@gigasgaming.com wrote:
This is no longer a mailing list, this is a chatroom.
Please remove
20 matches
Mail list logo
