ed it would be a good investment to launch its own 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
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 remov
The overlapping consensus mechanisms between the Core Developers, the
miners, the block chain based businesses, and the end users make it such
that the very definition of Bitcoin is not just what any single one of
those groups comes to a consensus about. We must ALL be in consensus about
just what
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
invent
-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
http://s
Great work, Pieter. I've been spooling up several nodes per week lately and can
testify that stalled downloads during initial syncing are a pain. I usually
forgo bootstrapping on VPSes because I don't want to have to adjust the disk
space allocation.
With headers-first I'm saturating my home ca
-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 se
> Great graphs, and these are just brainstorms for future ideas :)
>
> Josh Lehan
>
> Sent from my iPad
>
>> On May 13, 2014, at 4:43, Wladimir wrote:
>>
>> Hello Jameson,
>>
>>> On Sun, May 11, 2014 at 7:14 PM, Jameson Lopp
>>> wr
-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 r
ffect 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 wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> I agree that it would be awesome to offer these types of stats with
-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 designe
h the installer?
- - Jameson
On 05/07/2014 03:46 PM, Wladimir wrote:
> On Wed, May 7, 2014 at 9:12 PM, Jameson Lopp wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> In order to gain more insight into what messages and requests a node is
>> processin
-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.
http://coinchomp.com/2
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:
>>>
Looks like Matt just pushed out new builds to the Ubuntu PPA, so this issue
should resolve itself shortly.
- Jameson
On 04/19/2014 05:39 PM, patrick wrote:
> The alert system filters based on the clients version number.
>
> The ubuntu bitcoin ppa is dynamically linked to openssl unlike the
> b
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:
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 wrote
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 /
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
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:
>&g
"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
&
tcoin
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
closing 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
> wrot
23 matches
Mail list logo
