Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - wackou

Pages: 1 [2]
16
Stakeholder Proposals / Understanding reason for fork
« on: November 25, 2014, 09:19:53 pm »
I just saw that the last fork in the blockchain was caused by my delegate (sorry :-[), but I really am at a loss as to why... My delegate has been running since 0.4.24 uninterrupted and did not miss a single beat, I am properly synchronized to ntp, have a healthy number of connections, etc.

I did look at some delegates that recently missed isolated blocks, and tried to look at the next and previous producing delegate to try to see a pattern (eg: a delegate not properly synchronized to ntp might produce its block early and ignore the one from the delegate just before him), but couldn't find any...

Any help understanding what happened?

Actually, is there a (general) method to do post-mortem analysis of why a block was missed, or a fork created? Best practices, etc?

Thanks for any tip/suggestion too.

17
Technical Support / Running multiple seed nodes on the same server
« on: November 10, 2014, 08:41:02 pm »
I was recently wondering whether it would be more beneficial for the network to run multiple seed nodes on a same server, connecting on different ports, or a single one with combined capacity, eg: is it better to have 2 nodes with 100 connections each, or 1 node with 200 connections?

I saw on the current list of seed nodes (https://github.com/BitShares/bitshares/blob/469cd826066b05d4399aaa081eccf783a776c0e6/libraries/client/include/bts/client/client.hpp#L70-L89) that there are some hosts with multiple instances running on the same IP, so someone must have thought that this was a good idea. Intuitively I would tend to say that a single combined node is better for the network, as it makes it more tightly connected, but I might be wrong. Also, a lot of connections between multiple processes might be duplicate, while the single node ensures distinct connections.

An argument in favor of multiple instances is to provide redundancy, but you can use something like http://supervisord.org/ to mitigate for crashes and restart the client automatically, and in the case you lose network connectivity you're no better off with multiple processes than with one.

Any opinions / arguments in favor of each solution?

18
Stakeholder Proposals / Announcing DigitalGaia delegates
« on: October 10, 2014, 08:50:31 am »
tl;dr delegate bids are described at http://digitalgaia.io


Hi all,

I have been a C++/Python linux developer for the last ~10 years, and more recently on OSX, which is why I started contributing to BitShares by doing the initial work for packaging Keyhotee on OSX, then fixed a few small things to be able to compile the bitshares toolkit natively using clang on OSX (instead of macports gcc), and participated in nearly all the dry runs. I am not so active on the forums (for lack of time, and knowledge about economics, although I'm learning ;) ) but I try to read and stay up-to-date as much as possible, as well as report bugs whenever I can on github.

As I started running a delegate since the launch of BitShares in July, I realized I needed some tools to be able to monitor my delegate easily, so I started to work on the bitshares_delegate_tools, which you can find here:

https://github.com/wackou/bitshares_delegate_tools

(there are a couple of screenshots on the github readme)
 
It then occurred to me that if each delegate were to be doing something more for BitShares, on top of running the delegate client, then this could become a fundamental feature of BitShares DACs as it would create an entire ecosystem of competent, dedicated and diverse set of people, all working towards the same goal of enhancing the network. I believe that creativity comes as sparks of ideas, from diverse and unexpected places in the world, when unfettered minds dream of making a better world :)

This is why I'd like to present the concept of Digital Gaia, where I propose 2 delegate bids:
- wackou.digitalgaia, which is used to fund my development of the bitshares_delegate_tools
- backbone.digitalgaia, which is used to fund specialized nodes useful for the health of the network

The website describing the delegate bids more in details can be found at http://digitalgaia.io

Hoping you like what I'm proposing, and thank you for reading (and voting for me!)

Cheers,

Wackou.

19
Hi all,

after having worked on my monitoring tools for the BitShares client for the last couple of months, I feel
that it has now reached a level where it can be useful for other people, and that I don't feel ashamed to
show it to the public  :)

It is obviously far from perfect, and there are still features missing, but understand that this is a
work in progress, and I am very open to comments, suggestions, critics, and pull requests of course ;)

It is written in python, the github link is here: https://github.com/wackou/bitshares_delegate_tools

and although there is no downloadable release yet, it shouldn't be too much work to release it on pypi
(this means for now that a fully proper installation (ie: wsgi behind a webserver) requires a bit of python
experience, but it isn't too hard either)

Let me know what you think,

Cheers,

Wackou.

PS: it doesn't support BitShares DNS yet but work is underway

Pages: 1 [2]