Re: [Bitcoin-development] Remove Us Please
You're only strengthening Gigas' point about the mailing list by posting derisive emails. Take your nonconstructive comments elsewhere. - Jameson On Fri, Jun 19, 2015 at 4:01 PM, Brian Hoffman brianchoff...@gmail.com wrote: damn he was just on the verge of solving the underlaying problem with Bitcoin and you interrupted his focus. On Jun 19, 2015, at 3:55 PM, John Bodeen john-bod...@uiowa.edu wrote: from their website, humorous bits highlighted *October 14, 2014 *In latest Hiatus new, the company has taken on yet another crazy project but this one is going to benefit the world in which it entered not long ago. The company had done a lot of research on crypto currencies, built one for itself, for testing purposes (GigasCorpCoin) and found the underlaying problem of Bitcoin and was poised to solve it. Company execs decided 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 for this secret and upcoming project. On Fri, Jun 19, 2015 at 10:34 AM, Jameson Lopp jameson.l...@gmail.com wrote: 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 this email from your list, you are now interfering with official company business. Thanks -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Remove Us Please
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 this email from your list, you are now interfering with official company business. Thanks -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Request for comments on hybrid PoW/PoS enhancement for Bitcoin
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 inventory, thus offering to send the block that 'endorses' as valid. Because there is an incentive to include endorsers, there is an incentive to broadcast mined blocks as soon as possible. - I'd say that this is already the case due to the incentive for a miner's block to get propagated around the network first. My first question would be whether or not your proposal would include a change to how nodes propagate new blocks. At the moment, a node that hears about a second valid block at the tip of the chain will ignore it and not propagate it to its peers. Wouldn't your proposal necessitate a change to this logic so that blocks with 'better' endorsements get propagated even if they are received after non-endorsed or lesser-endorsed blocks? I'd also be interested to know more how endorsements would be limited (fairly) to only a subset of nodes. I'm a bit fuzzy on the endorsement timing. You're saying that a miner will add endorsement payouts in their block based upon nodes that endorsed the previous block? Which means they're paying nodes to endorse a block that they probably didn't even mine? Or would a miner only include payouts to endorsers for the last block that they mined that was accepted by the network? - Jameson On Mon, Feb 23, 2015 at 2:27 PM, Chris Page pag...@gmail.com wrote: I'm soliciting feedback on an idea to will improve security, increase the number of full nodes, and provide more avenues for bitcoin distribution. The idea is still in its infancy, but I need constructive feedback before I take this further, or decide to abandon the idea. In particular, my ego is in check and I'm ready to be made a fool, but in turn, I'll be that much better educated, so fair trade! Here is the high-level overview: 1) A new block B0 is mined and broadcast as usual 2) Full nodes verify block B0. A subset of these nodes broadcast a new endorsement message endorsing the block as valid, and preferred. 3) Miners, now assembling and beginning mining a new block (B1), add endorsements of B0 to B1's coinbase transaction, sharing the block reward with endorsers of B0. As proposed, the idea of Block Endorsement requires a new message, but fits into current structures. Here some details about each of the steps above, and what it buys us: 1) The mining of block B0: No changes to current process or format. Blocks are mined and broadcast as they are today. 2) Only a subset of nodes are eligible to endorse a block, and hence, only a subset are eligible for an endorsement reward. We restrict to avoid a flood of endorsement messages by every node following the announcement of each new block. An endorsement message needs to identify exactly one block at a specific height that it is endorsing. It needs to include a payout address that meets certain validation criteria relative to the block it is endorsing. A valid payout address will include some proof of stake (PoS), whether that be that it has a 1+ bitcoin balance, some age weighted balance, or something else is TBD. The reason for PoS is that it should not be the case that a subversive miner could easily fabricate a valid endorsement payout address. The other requirement is that the tail bits of a valid endorsement payout address, when masked (size of mask TBD) need to match the trailing bits of the hash of the block it is validating. This directly ties endorsements to a specific block, and makes it computationally inexpensive to verify/relay, or drop invalid endorsement messages. The combination of PoS and mask will restrict the number of valid addresses. There are no restrictions on which endorsements a miner can include, as long as they are valid. As part of new block validation, full nodes would need to do all that they do now, but they would also need to validate endorsements included in the coinbase transaction. 3) Miners consider whether to include endorsement payouts as part of their coinbase transaction. They need not do so, but by including endorsements, they significantly increase the likelihood that their block will be selected. CHANGE TO BEST CHAIN SELECTION Block Endorsement requires a change to the best chain selection algorithm to encourage miners to include endorsement payouts. Because there is an incentive to include endorsers, there is an incentive to broadcast mined blocks as soon as possible. For the purpose of best chain selection, a block should get a significant bonus to its work (10%) for each valid endorsement payout included in a block's valid coinbase transaction. How many endorsements should be permitted is a design parameter which is in play, but let's assume that up to
Re: [Bitcoin-development] Running a full node
-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://statoshi.info/#/dashboard/file/default.json?panelId=1fullscreen - - Jameson On 11/08/2014 12:44 PM, Melvin Carvalho wrote: On 8 November 2014 16:28, Daniel F nanot...@gmail.com wrote: But I'd like to know what storage, RAM and bandwidth resources are needed. I guess that the problem is not the CPU. Hi Francis, Here are some rough guidelines for you, based on the statistics from my node: disk usage: about 30GB currently for the blockchain data. It'll only keep growing from here, but relatively slowly. There's some statistics on this site: https://blockchain.info/charts/blocks-size It may be reasonable to assume 10GB growth a year. When I was running a full node I gave it a disk of 50GB. cpu usage: pretty much nothing, after you have synced the blockchain. ram usage: after it runs for a few months, my node gets up to using 1.5 GB of ram or so. bandwidth usage: my node averages about 500GB of traffic per month, most of it outgoing. Hope that gives you a rough idea of what you can expect for running full node. Best, Daniel -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUXo9XAAoJEIch3FSFNiDcl20H/0/MrFt0SfR5G5S0m4sLMUdP 5/sveDnVjCBBmcoCKvH3XKchT7fVA6C4N1+dUYDJhlOaZhXegdY3saHdIP/sFzkF 38JBdoqWm4IysAC9gmtn/jRSrxh0wC780zVcLe2EgI7n+1ZOOqCaud28gX+ukoq5 dsU/B8bPEZ/2E7WbaXRcJJGqPdP03H2VXEkKxTWacBYFGVd6RhP9ieFHS3TyctNb A0g02l1OmymnSSP6ze32ne+G4RgPdbvYhevW8vay1P4ATgBSnB2sitawRXJjsxMy +d4Fqg+xYRMx3l8lamb7OLSi9rMe6GNEKyML4/Gu24JPSjlmQLXRJE/aS3oMyZc= =zXHK -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Abusive and broken bitcoin seeders
-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 sends out, the volume is also low. This graph has 'inv' and 'tx' sent messages for comparison. http://i.imgur.com/keyitsS.png Now, these are just message volume and not actual resource usage, but I have a feeling that 'getaddr' requests are not resource intensive since it shouldn't be reading from disk. I could look into adding timing metrics around these requests if you think it could be useful. - - Jameson On 07/31/2014 06:37 AM, Mike Hearn wrote: I suspect it is something that is going to have to be dealt with in the future (I just don't know how yet). The web has managed to survive despite constant fast crawls being the norm for the past 10 years or so. I wouldn't worry too much about this unless you can prove that a big chunk of your nodes resources are going to answering ver queries. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT2j2lAAoJEIch3FSFNiDcWqIH/i0W21cYFHyQZItSkyHezBER ExjudrLuXvTuRc/9b1OG7lJpK7IEYpCn0xXHGP3gv8gihq6lVEdZCFMXGWxU+eDv ECXppTTCUkofUjVInbU91eagXeRzK0UTbTrp2++hfLQIAv99B8mgSdoEcopP42Fd G197p/273lAPGVmNF31YPUcIbrhj0IzsiR1QaEEf1FEelaJ7MmU7YsUFUglajTqk 6+Uzcr6RcwLKAWVFAOA6VOeVwAMOQMwsniUAx6bYbqvgSHzRTllDDWW5rTaKh9+O rIhA3LvHpLh37xqTs6EvJb2Kn823e4Ax4Eoz3wqVvAyjNqWHRPjlXdXentHFN4Q= =R+Z1 -END PGP SIGNATURE- -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] statoshi.info is now live
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks; I've received several suggestions for other metrics to collect that I hope to implement soon, but you're right in that tracking per-peer pings is a different type of metric than what I'm currently collecting. I actually noted the lack of pong messages in a post I made a few weeks ago: http://coinchomp.com/2014/04/27/peeking-hood-running-bitcoin-node/ Once I added metrics for sent messages, it validated my theory: my node has never sent a single ping request to a peer and thus has never received a pong message. I can't even add sent pings or received pongs to this chart because they don't exist in my graphite instance. http://statoshi.info:8080/render/?width=1548height=883_salt=1400066995.622target=stats.message.received.pingtarget=stats.message.sent.ponglineMode=connectedbgcolor=00fgcolor=FF I guess my question regarding ping stats is how useful that information would be - it seems to me that if we are trying to quantify the cohesiveness of the network, we should instead be observing the message propagation times. Though that's outside the scope of my project; there are other people who are doing just that. http://bitcoinstats.com/network/propagation/ Jameson On 05/13/2014 01:48 PM, Josh Lehan wrote: I agree, it looks very slick. Well done. While on the subject of connected peers, what about the idea of adding the ping time from this node to other peers? The problem with fitting that information into the current design is that the graphs seem to be comprised of overall statistics for this node, not per-peer statistics that can vary between peers (such as ping time). If a line were to be added to a graph to represent each peer's ping time, the number of lines (statistics) on the graph would have to vary in real time as peers are added or removed, which would be a challenge. I earlier added the ping feature to bitcoind, and it works to measure the ping time, however this feature is on-demand: it won't ping other nodes unless requested. So, something would have to send the ping RPC command on a regular schedule, to ensure the graph is updated with new information. Also, there is currently no support for overlapping pings (although that would be easy to add), so if a peer is slow enough to not respond at all to the first ping request, and a second ping request goes out in the meantime, any late response from the first ping request would then be discarded. Great graphs, and these are just brainstorms for future ideas :) Josh Lehan Sent from my iPad On May 13, 2014, at 4:43, Wladimir laa...@gmail.com wrote: Hello Jameson, 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 and threw a nicer interface on top of it. http://statoshi.info Must say it looks very nice. One comment about the graphs: in the 'connected peers' chart you visualize some larger quantities (especially knownAddresses) and some very small ones (peer.(dis)connect). This makes the latter invisible due to scale. Some random stats may be useful as well: - Number of connected peers that are SPV clients or full nodes (NODE_NETWORK) - Current block height (so that it's possible to detect stuck nodes) - Number of transactions in mempool - Number of transactions in UTXO set - Maybe some fee statistics, https://github.com/bitcoin/bitcoin/pull/3959 would be useful here - Number of orphan blocks/orphan transactions Wladimir -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTc1XIAAoJEIch3FSFNiDcrygH/A+cDzLdNNwdiT2oGjpfYO/A fxlqSHqzGdTJQuTRgjxAOp9RrFGhGYT4Qz6TJ3qzSVAILyM3FYELxgm3B6TqDWi2 hc0FTFbVO3ys1Otza9r5r/6W0xGIkJaDRghoFlxd1jUCmuPyqK541pHjvX8MPAfm zYWCb5U2dU0MAzkV8vClQNMy5lMN3RulCm3lZPvetjnQXfhf2e36Pl5MFOsuqzcp PeZnuXHhxGT6BbVOoEnPRQiH7h0jmDqBV66nJaeUaLVvsg6urfo/HaUmDXuto0tF r7O779o138mLTofVxCwFvxYxilYDhS9S8L2uZc8ILt+SAZA3XQIM5okJYLd6I6A= =cJCd -END PGP SIGNATURE- -- Accelerate Dev Cycles with Automated Cross-Browser Testing
[Bitcoin-development] statoshi.info is now live
-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 raw Graphite stats at http://statoshi.info:8080/ If there are any metrics that you think would be helpful for development or monitoring purposes, just let me know and I'll take a shot at adding them. Jameson -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJTb6/qAAoJEIch3FSFNiDceR4H/jHchii5offrnQRsRcA7o4bh EEeL7ln9ID2FtqpL5wEjFtYq7nXL/8+o1BY7MOULo4SMpQIi0aY3ehNkPUCX3XKh U0F1ZZpkjMpI8BbIqBFwspNAE7bFh8vmRW9/IhWXf3VY8TmgVhZnbMmzxvcw7DwI kb1pgXZOEKCwmMvxBoWdmwDogvZvNPIThoQ9InY+qaGQut3lvrrSQMR7jYXxTY/9 Rebnny5c15KUrM3xwRPJvFHlbFE8F5a6ue9uwGq/STK73/iDqXksJNFnpzk3fnGc AryWmleHFfttfsb1kb991BFn2RCaKWvGBNUnq5dD/cCZIBwu3F16j65JAxboF94= =Xe+e -END PGP SIGNATURE- -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Announcing the Statoshi fork
-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/2014/05/07/announcing-statoshi-realtime-bitcoin-node-statistics/ https://jlopp.github.io/statoshi/ Feedback is appreciated! - - Jameson -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTaoWSAAoJEIch3FSFNiDclLoH/0CXPTum6B2cfoNsacihHuS9 9wt50sOgghttS3J/kloP315ijY7p2HSmhvqL2G/DWYh5Vx0f6gTaUAokQ8H6x4EV 3/pdZG+9a6eegpCtgr+IgphgPSEufzct/Mp7pKTAbH0G61toOM5ZfIgdL2X/2tpx 4TjOmjhZRHuglzsM9934EjezIsR7l2vaRQB0r1LPGSgWmDSKTTb2uK7xvD1zg0tz QXb0hl7A6rw1xZwmw3i+PujshJCbjVh8QrFT55GYi05yYdBsS6BAG46F5D8Uvn+M FnCBLdRfWrTzQXIxoLrtBmM1JXOJKdMhmG0p2mwzwXEGR7MR2suS/+Bb7iHJTpA= =iNNR -END PGP SIGNATURE- -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcing the Statoshi fork
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The next logical step may be for us to offer a public instance of these graphs; I'd be happy to work with you to set one up. I agree that it would be awesome to offer these types of stats with the installer; unfortunately the route I've taken has dependencies on several other other pieces of software to do all the heavy lifting of stats aggregation and chart rendering. I'm assuming that you would not want to build any of that processing into Bitcoin Core itself; would you be opposed to packaging other software along with the installer? - - 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 that outputs statistics to StatsD. I hope that some of you will find this interesting and potentially useful. http://coinchomp.com/2014/05/07/announcing-statoshi-realtime-bitcoin-node-statistics/ https://jlopp.github.io/statoshi/ Feedback is appreciated! Ooh nice graphs! We were coincidentally talking about showing stats from a node on a local web site on the #bitcoin-dev IRC a few days ago. At some point, if we're going to offer Bitcoin Core node-only installers, it'd be nice to include something like this so the user can keep an eye on their node(s). Wladimir -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTapAsAAoJEIch3FSFNiDcyMEIAIds0yo9zeWcqNqGZ+UNltoH hNt8NhYOgL/6WNeLVYdRmCrrdNn/KMSLcAZmOQ0U+W/qL3xh1RB59o3BcBnW05Yr ZxY5ajKKq+oz70ShMNUkVnzFSStMhH9fKnolrF0mgSx4CU9e0YTx/LBc/u9ulypO QNZydiiegwvTFjMxHItgU5xo/wzySazmyxN9x3Gls98vDfSjE3Rt/DTqAwHleD3t SlIu4RU2iPpAW/6MgfWqAw+CrbZ2NNKp7a7+0gsUlbdDP1h6WEvoae5sUzRmvLB3 rHMmRoRvTl4Hl1bG7CKyM4D3piBkpDf/nMqnAAFNYkocS5xVpHM1WrTMDAmkSLk= =/TPp -END PGP SIGNATURE- -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcing the Statoshi 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 designed for - sampling small amounts of stats from high volume systems. There would be an issue of trust, however - StatsD was also only really designed to be run inside of highly secure infrastructure where you trust all of the machines that are talking to it. - - Jameson On 05/07/2014 03:50 PM, Mike Hearn wrote: Really nice! We definitely need to put together a team who really cares about the operations side of the network and this is a fantastic start. It'd be nice if you didn't assume knowledge of what statsd is out of the box. Given the name I'd assumed it was a small UNIX daemon but it seems it's actually a Javascript thingy? It looks like putting together a monitored bitcoind setup can be quite a lot of work. I wonder if there are ways to simplify it. For example, would it make sense for someone to run a community statsd and graphite instance, so we can get aggregate statistics across many nodes and the node operators don't have to set everything up themselves? Does that make any sense? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTapDsAAoJEIch3FSFNiDcqNMIAKbliLXVJ+CovCB+etqwCYfD oTs0uxEIZvnGSzqn6i3z4tgzF7kbnpVThiHpG2MO2BytasGzfr+FsDLFpvkkvx0Q yffa1J5uB5QhY/POwg6GCN4DEmy8tbd+I5rSTKg1m/JuXZV2B4TFgr6GF+t+gBNT O2TTIngcl77XbGDF2XKOZSAHaIFx2KjdZNg5lfInVxDeA1dDzlU/vmEB37fx80EH IzD7FTllLp5qhlwYxaQTVxXmbjy+pXbtArYsVSRgoscgJI3DDKpxQj3uzjxouEHv 27QkhuS2dzFioQhLPcnz/PtcCkE1l0aDNf6n7OiJ3lGygQ0+AKZHpyuvFujpSY8= =QCYI -END PGP SIGNATURE- -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Announcing the Statoshi fork
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The charts are generated on-demand by Graphite, which is a Django app. I will note that one reason I chose StatsD is because it sends the stats via UDP rather than TCP, which is a non-blocking operation. I didn't want the sending of stats to affect 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; unfortunately the route I've taken has dependencies on several other other pieces of software to do all the heavy lifting of stats aggregation and chart rendering. I'm assuming that you would not want to build any of that processing into Bitcoin Core itself; would you be opposed to packaging other software along with the installer? Depends on just how much stuff it is. The idea is primarily to have an installer for running a (wallet-less) node as an OS background service. Having some statistics available would be worth some extra download size, otherwise it would be pretty much invisible. We'd already decided that we would need something like Python for the stats service. Implementing things like web services in C++ is just not realistic given the time constraints and the great already-written code that is out there. As an optional tool it should be external, not part of bitcoind itself. I suppose the chart rendering happens client-side? In that case the web service just has to collect and provide the data, and serve static html/js files. Wladimir -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTapj5AAoJEIch3FSFNiDcofAIALHi7XgQi8pf75btujaeBsX3 nniRD0yZIkoAvPlvFLiKQGE8TH+VR8Sb9fQACzmajYx1yjD0gN4xvkJXbI+pkeP5 L8ZryhqxL5qCh/OI4+fkWlsp5Nwx89QvUepdXXdc/AQGQJIEMceiZOLDcjbk29Yb vCsyJL5yhzM9BM0cImuvrOBPtF3/L6DbgHP8OLD2LHRl4paJ1UDtfYCx3HVO9wp8 ZWq1oCaFyoYmUyx8GTUzbLjh9sOgaq43GKYec/kQSLmFxhhMF0dGNDMiwD/xz1i7 LIswjlEKHZYOWWL3SMQg3pLlOTzGH4mHg++BAyrtzZ5CHlc1rjsPSk2d2Df/8Zc= =GFu9 -END PGP SIGNATURE- -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
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 think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. I haven't seen anybody arguing that it is. Bitcoin is the elegant embodiment of /artificially contrived/ mathematical rules, which just so happen to be very useful in their current configuration :-P Nobody is saying those rules are immutable. Just that it isn't sensible to undermine them by introducing imprecise and unpredictable elements like human politics. As an end-user of Bitcoin, the whole possible value of a set of mathematical rules has become completely trashed by the imprecise and unpredictable behavior of buyers and sellers. If the rules are not responsive to real human needs, bitcoin is worthless as a long-term store of value because **my idea of value** changes over time. This implies, in my mind, an absolutely requirement to attempt to gather some useful signal from the human political noise. How do you determine what that signal is, so you can **change the rules** and the mathematics so it makes more sense? You've got to deal with politics, one way or another. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
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 my thoughts last month: http://coinchomp.com/2014/03/19/bitcoin-nodes-many-enough/ I have begun working on my node monitoring project and will post updates if it results in me gaining any new insights about the network. - Jameson On 04/07/2014 07:34 AM, Mike Hearn wrote: At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and still falling: http://getaddr.bitnodes.io/dashboard/chart/?days=60 I know all the reasons why people *might* stop running a node (uses too much disk space, bandwidth, lost interest etc). But does anyone have any idea how we might get more insight into what's really going on? It'd be convenient if the subVer contained the operating system, as then we could tell if the bleed was mostly from desktops/laptops (Windows/Mac), which would be expected, or from virtual servers (Linux), which would be more concerning. When you set up a Tor node, you can add your email address to the config file and the Tor project sends you emails from time to time about things you should know about. If we did the same, we could have a little exit survey: if your node disappears for long enough, we could email the operator and ask why they stopped. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
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 / timing out because their requests cannot be handled by the nodes? For all I know, the network would run just fine on 100 nodes. But not knowing really irks me as an engineer. - Jameson -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
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 gmaxw...@gmail.com wrote: FWIW, A few months before that we had even less than 8500 by the bitnodes count. Gah, accidentally send I wanted to continue here that it was less than 8500 and had been falling pretty consistently for months, basically since the bitcoin.org change. Unfortunately it looks like the old bitnodes.io data isn't available anymore, so I'm going off my memory here. The Bitnodes counts have always been somewhat higher than my or sipa's node counts too, fwiw. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
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: On Mon, Apr 7, 2014 at 8:45 AM, Justus Ranvier justusranv...@gmail.com wrote: 1. The resource requirements of a full node are moving beyond the capabilities of casual users. This isn't inherently a problem - after all most people don't grow their own food, tailor their own clothes, or keep blacksmith tools handy in to forge their own horseshoes either. Right now running a full node consumes about $1 in disk space non-reoccurring and costs a couple cents in power per month. This isn't to say things are all ducky. But if you're going to say the resource requirements are beyond the capabilities of casual users I'm afraid I'm going to have to say: citation needed. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
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 10, 2014 at 8:30 AM, Troy Benjegerdes ho...@hozed.org wrote: Name me one single person with commit access to the bitcoin github repository who is *independent* of any venture capital or other 'investment' connections. I am, unless you count the fact that I own some Bitcoin and some mining hardware as 'investment' connections (and that case your comments are worthless). (By not naming anyone else I don't mean to imply there are no others, but I don't want to speak for anyone else. Nor would I necessarily expect the other part(ies|y) to step forward, since this mostly appears to be an invitation to step up and be attacked.) Thank you. I also appreciate your commentary[1], and willingness to list your investment position. What I'm concerned about are people who have signed non-disclosure agreements or who's salary/equity/whatever depend on people who are experts at manipulating markets to take naive investors money. Independent is also a state of mind as much as it is about financial connections. What pisses me off here is that a huge amount of wealth just changed hands based on MtGox's press release, and it stinks of insider trading. I still maintain the best outcome would be for MtGox to AGPLv3 release their code, and then those of us that understand it would be able to have a public technical discussion about how to fix it, and MtGox would still maintain their intellectual property ownership position. This, however, cuts off a significant revenue stream for people who take money making market bets 5 minutes before the information goes public, so I expect the likelyhood of such an outbreak of sanity is quite low. [1] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/ DISCLAIMER: I have a significant emotional investment in copyleft/viral copyright development models, and I expect to take a lot of money charging people to write code I give away for free. I also occasionally make money from cryptocurrency mining, but only when I can sell it in functional and transparent markets. -- Androidtrade; apps run on BlackBerryreg;10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Androi apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Popularity based mining (variable block reward)
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 and everybody node would be free to do so. Each network node would determine the popularity on its own depending on various factors (coin valuation/exchange rate, number of transactions and many others) and basically come up with its own block reward value. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Monetary Authority for Bitcoin
To piggyback on Jeff, Any proposal that is going to add reliance upon data from third parties outside of the Bitcoin network itself is likely going to be rejected outright. This opens far too many potential vulnerabilities. The exchanges that are kept track of could be hard coded into Bitcoin 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 Software, Inc On 12/09/2013 06:10 PM, Jeff Garzik wrote: On Mon, Dec 9, 2013 at 7:23 PM, Ryan Carboni ryan.jc...@gmail.com wrote: It is not a violation of the trust of those holding the currency. Many people bought Bitcoin in the hopes that it's value in the relation of other currencies will increase, not because there's a fixed money supply. The majority of people using Bitcoin as a currency in exchange for real goods are using the exchanges. Your proposal has been met with widespread laughter. Were I not ill with the flu, mockery would ensue as well. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
The conversations that spawned from this paper have been fascinating to read, but I have a problem with the conclusions. To quote the paper: The Bitcoin ecosystem is open to manipulation, and potential takeover, by miners seeking to maximize their rewards. This paper presented Selfish-Mine, a mining strategy that enables pools of colluding miners that adopt it to earn revenues in excess of their mining power. Higher revenues can lead new rational miners to join sel sh miner pools, leading to a collapse of the decentralized currency. Please explain to me why any rational miner would collude to earn slightly higher short term profits at the expense of then wiping out the value of all their bitcoins in the long term. Also, if you felt that this vulnerability is an immediate danger to the Bitcoin network, why publish the vulnerability publicly rather than first disclosing 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: this means that anytime a bug is found in Bitcoin protocol, chances are that it would take a lot more time to get fixed Correct. There is significant potential that a fix can create other problems... and any major mistake could instantly destroy $2 billion worth of value. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
