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
1
DAC PLAY / Blockchain forked?
« on: October 02, 2016, 07:42:51 pm »
Is the blockchain forked? I seem to have been on a fork with ~43% participation the last few days that I can't get off of. Not sure if it is the main chain and 50 delegates have dropped out or if I'm stuck on a chain with just less than half of the delegates...

Anyone knows what's up?

2
For those that don't know the bts_tools package, the best description can probably be given with screenshots (a picture is worth a thousand words!): http://bts-tools.readthedocs.org/en/latest/monitor.html#screenshots

-------------------------------------

A bit later than what I originally hoped for, here comes the bts_tools package ported to support graphene clients, in this case BitShares 2.0.

Given the new asynchronous model of communication via websockets, I had to refactor more than originally planned, but the bulk of it is now done, and I learnt quite a great deal in the process (wanted to look into async programming in python for some time now, and this was the perfect occasion!). Thanks go to Xeroc for writing his python-graphenelib module, that was extremely helpful in getting me bootstrapped and understanding how it all worked.

Please bear in mind that there are probably still a few things not working, or not working properly. The basic functionality is there, though:
 - cpu/ram/network connections graph
 - feeds publishing, using either a time interval (as before) or a time slot (as currently setup in the telegram chat)
 - some other plugins: wallet_state, voted_in, online, network_connections

notably missing:
 - detection of blocks missed

So for the non-faint of heart that don't mind a few quirks, you can install the tools as usual with:

Code: [Select]
$ pip3 install bts_tools
and you should get version >= 0.3. The documentation, although not updated yet, should still mostly apply to everything: http://bts-tools.readthedocs.org/

What you can do then:
 - bts2 build [tag]: builds the latest version, or a given version
 - bts2 run: runs the witness client
 - bts2 run_cli: runs the cli wallet
 - bts2 monitor: launch the monitoring tools

Things to watch out for in this release:
 - the config file is still sensitive, ie: you need to configure everything properly, there is very little checking. The default config.yaml file comes with the minimum required fields you need to configure to get something working, edit at will. If you had a previous config.yaml file, it is highly recommended to delete it beforehand.
 - in particular, you need to setup correctly an api_access.json file (as described here: https://github.com/BitShares/bitshares-2#accessing-restricted-apis - the saltpass.py script can be found here: https://github.com/BitShares/bitshares-2/blob/bitshares/programs%2Fwitness_node%2Fsaltpass.py) and configure your config.ini file to use it. This is needed to get access to restricted APIs of the client such as the network one.

What I plan to do next is to iron out the support, port the remaining monitoring plugins and stabilize the code base. Support for Muse clients should also come very soon :)

Let me know what you think!

3
DevShares / DevShares forked...
« on: March 18, 2015, 12:44:21 pm »
It looks like all the init delegates went on their own fork, leaving all the others on a minority fork... See http://dvs.bitsharesblocks.com/

How do we solve this? Should the init delegates sort it out themselves or do we (the other delegates) have to do something to get back on the fork from the init delegates?

4
DevShares / Attack on DevShares / client misbehaving?
« on: March 10, 2015, 03:46:30 pm »
Since yesterday morning, 2015-03-09 at about 07:40 UTC, my DVS delegate's CPU usage has been spiking, with a client that seems to be connecting / disconnecting a lot:



This is still going on as of today. This also happens when I run a DevShares client on my laptop, so is not restricted to my delegates. see the last 5 minutes on my laptop (no wallet open):



Is this an attack / spamming of the DevShares network? More likely, could it be some client on the network that is misbehaving (hinted at by the deconnection/reconnection)?

I have this IP that comes up in the client a lot:
Code: [Select]
Peer 46.10.205.0:32123 disconnected us: You offered us a block that we reject as invalid

Can anyone shed a light on what could be happening here?

5
There is currently an attack that is possible on the BitShares network where an attacker could:
 - use timing of block propagations to discover which are the IP addresses of delegates
 - use a DDoS attack on those delegates to take them down

This has been described more in details in this thread

This can be easily thwarted by "hiding" the delegates and making sure that it is not possible to identify the source of a newly signed block. To this end, I propose the following solution:

http://digitalgaia.io/backbone.html

tl;dr: hide the delegates behind some public relay nodes. In this way, it looks like that all blocks originate from the backbone and it is not possible to know who signed them. At first I would like to have 2 nodes in the US, 2 in Europe and 2 in Asia.


How to make it happen?

Just vote for my delegate, btstools.digitalgaia (30% payrate), and as soon as it gets elected I will buy some VPS instances for the backbone nodes and start working on setting them up, as well as developing the software required to manage those nodes.

Note that I would also set up seed nodes / chain servers, which can make initial sync to the network faster, as well as allowing nodes to get on the correct chain in case of a fork (by syncing with a chain server that's on the main fork, you also get on the main fork).


Criticism

Although a good start, this is not a perfect solution (yet!):

- Whoever runs the backbone nodes can perform the same attack on the delegates (although it is now limited to the person running the backbone nodes, instead of basically anyone simply connected to the network).

- The backbone itself can be DDoS'ed. In this case:
 - if delegates are only connected to the backbone, and the entire backbone falls, then they don't have connections anymore to the network. This can be mitigated by delegates starting to connect to normal nodes when they see that the backbone starts falling.
 - the delegates can also maintain their own set of relays instead of trusting the backbone's operator. This is more work (and more money spent on VPS), but you don't need to trust anyone else than yourself. Being able to run the software developed for the backbone would be a great help here, so even though a delegate doesn't plan on using the backbone, he could still benefit from it being developed.


Why you should trust me

I already am the author of the bts_tools python package (GitHub, BitSharesTalk), which help delegates monitor their own running instance, and I'd like to expand the functionality of the tools so as to also be able to manage a group of nodes or specialized instances of nodes in the BitShares network. In particular, I'd like them to be able to manage a configuration of seed nodes + backbone nodes as described previously.


Is this going to be a cost for the blockchain forever?

For now, I request a 30% delegate, as this would cover the cost of the VPS instances and my time for developing the software and maintaining the backbone.

Assuming that the backbone is running and fully operational, the following can happen in the future:

 - I further investigate ways to make the backbone itself completely DDoS resistant, and/or try to make it autonomous and able to replace fallen nodes automatically with nodes provided by trusted members of the community. If this is achievable, and the backbone can self-sustain itself, then my delegate's position would not be required anymore.

 - Instead of being paid as a delegate, I can monetize the backbone service by asking delegates wanting to use it to pay me directly for the service, as well as other ways of securing a delegate that I might come up with. Initially, I think that making it available for everyone is beneficial for the entire network, though, hence the delegate's position.


Conclusion

I'd like to be elected as a 30% paid delegate to implement a solution for DDoS protection for delegates, and potentially investigate more avenues in order to enhance the security of the BitShares network.

I'd also be interested to hear feedback on whether people think that the backbone is an interesting and effective solution to the DDoS problem, and if not, what could be done instead.

6
Stakeholder Proposals / Tutorial about running a delegate
« on: January 23, 2015, 02:40:48 pm »
Hi all,

(tl;dr: tutorial is at: http://bts-tools.readthedocs.org/en/latest/howto.html)

I completed the first version of the tutorial I had planned to write for some time on running a delegate.

The tutorial starts from scratch, and guides you in installing Debian on a VPS, installing the BTS Tools I developed, and then using them to build, run and monitor the BitShares client. Hopefully it is clear enough, and I hope this will motivate more people to look into the BTS Tools.

Tutorial can be found at: http://bts-tools.readthedocs.org/en/latest/howto.html

Note also that this is a first version, it is not 100% complete (but mostly), and any comments/suggestions for improvements are welcome.

I have also started to write more doc in general for the tools (not only the tutorial) but this is still very much a work in progress. Doc is at: http://bts-tools.readthedocs.org/

Please remember to also vote for my delegate: btstools.digitalgaia, it still needs ~5% to get voted in. For a 30%-only delegate this gets you:
 - continued development and funding of the BTS Tools (https://bitsharestalk.org/index.php?topic=12534)
 - more documentation like this one
 - 6 seed nodes/chain servers (2 US, 2 Europe, 2 Asia) for the BitShares and the DevShares network

Hope you like it!

7
DevShares / PSA: DevShares 0.6.0 has been released
« on: January 20, 2015, 01:16:20 pm »
and upgrade should be done in less than 7 hours now!...

@Vikram: did you forget to post it in the announcement thread or is it a trick to check who's reading the forum daily? :P

8
General Discussion / BitShares RPC proxy
« on: January 10, 2015, 09:07:37 pm »
Hi all,

I'd like to announce a new tool that I developed which is a simple RPC proxy to the BitShares client that implements more fine-grained access control. This allows for instance to give a user only access to the "info" and "about" method, while another has access to the full functionality of the wallet, etc..

The source code and documentation (Readme) can be found here: https://github.com/wackou/bts_proxy

Please consider voting for my delegate btstools.digitalgaia if you like it and would like to see more of those tools, I still need your votes :D

9
DevShares / Does DevShares wallet_import_private_key work?
« on: January 08, 2015, 02:13:31 pm »
I tried importing my BTS private keys, however out of the 3 I tried, only 1 gave me some DVS (and less than expected)...

Is there a way to check allocation or the genesis block for which addresses should have some funds?

I also tried to importing some PTS keys (that donated to AGS), which did not fail, and no funds there either... Maybe I'm doing something wrong?

10
Stakeholder Proposals / Slate for btstools.digitalgaia
« on: January 08, 2015, 12:06:21 pm »
tl;dr: slate can be seen here: http://www.bitsharesblocks.com/delegate/slate?name=btstools.digitalgaia

Hi all,

I finally got around to putting together a delegate slate of people that I feel should be voted in order to best benefit the BitShares ecosystem. Thanks Xeroc and Fuzz for pushing this issue, I believe it is a very important one. Without further ado, here's the slate (scroll down to see full list):

Code: [Select]
delegate: btstools.digitalgaia
slate:
    # core developers, all at 100% payrate
    - dev0.nikolai                 # Toast (Nikolai Mushegian)
    - stan.delegate.xeldal         # Stan (Stan Larimer)
    - bm.payroll.riverhead         # Bytemaster (Daniel Larimer)
    - jcalfee1-developer-team.helper.liondani  # James Calfee
    - dev0.theoretical             # Theoretical (formerly: drltc)
    - dev-trial.misc.nikolai       # Toast budget for new dev trials
    - valzav.payroll.testz         # Valentine (Valzav)
    - delegate-dev1.btsnow         # Dan Notestein
    - delegate-dev2.btsnow         # Eric Frias
    - delegate-dev3.btsnow         # Gregorsz
    - delegate-dev4.btsnow         # Gandalf-The-Grey
    - dev.nathanhourt.com          # Nathan Hourt
    - developer.vikram             # Vikram Rajkumar

    # 3rd-party developers (forum id specified when different from delegate)
    - del0.cass                    # 100%  https://bitsharestalk.org/index.php?topic=11753
    - dev.bitsharesblocks          # 100%  https://bitsharestalk.org/index.php?topic=11272 (id: svk)
    - btstools.digitalgaia         #  30%  https://bitsharestalk.org/index.php?topic=12534 (id: wackou)
    - backbone.riverhead           #  10%  https://bitsharestalk.org/index.php?topic=10861
    - dev-metaexchange.monsterer   # 100%  https://bitsharestalk.org/index.php?topic=12317
    - dev.sidhujag                 # 100%  https://bitsharestalk.org/index.php?topic=12027
    - elmato                       # 100%  https://bitsharestalk.org/index.php?topic=12494
    - tradebts.gulu                # 100%  https://bitsharestalk.org/index.php?topic=13457
    - dacx.baozou                  # 100%  https://bitsharestalk.org/index.php?topic=13428
    - dev-pc.bitcube               # 100%  https://bitsharestalk.org/index.php?topic=13995 (id: pc, cube)
    - minebitshares-reloaded       # 100%  https://bitsharestalk.org/index.php?topic=14887 (id: nethyb)  |  seed node: euseednode.minebitshares.com, auseednode.minebitshares.com

    # marketing initiatives
    - marketing.methodx            # 100%  https://bitsharestalk.org/index.php?topic=11663
    - argentina-marketing.matt608  # 100%  https://bitsharestalk.org/index.php?topic=11847
    - media.bitscape               # 100%  https://bitsharestalk.org/index.php?topic=12833
    - delegate.rgcrypto            # 100%  http://rgcrypto.wordpress.com/2015/01/05/announcement/
    - market.cn.group101           # 100%  https://bitsharestalk.org/index.php?topic=13226
    - delegate.verbaltech          # 100%  https://bitsharestalk.org/index.php?topic=13837
    - www.bts-hk                   # 100%  https://bitsharestalk.org/index.php?topic=13724
    - sollywood.sollars-com        # 100%  https://bitsharestalk.org/index.php?topic=13900
    - delegate.dposhub-org         # 100%  https://bitsharestalk.org/index.php?topic=15832
    - delegate.kencode             # 100%  https://bitsharestalk.org/index.php?topic=16072

    # other / special purpose delegates
    - fuzzy.beyondbitcoin          # 100%  https://bitsharestalk.org/index.php?topic=13485
    - fund.bitsharesbreakout       # 100%  https://bitsharestalk.org/index.php?topic=13500
    - del.fav                      #  80%  https://bitsharestalk.org/index.php?topic=15094

    # active "standard" delegates  (3% payrate)
    - delegate.xeroc
    - delegate.liondani     # seed node: 185.25.22.21:1776  |  chain server: 185.25.22.21:1375
    - mr.agsexplorer        # id: boombastic  |  seed node: 180.153.142.120:1777
    - delegate.baozi        # id: alt         |  seed node: 106.185.26.162:1776
    - immortal.bitdelegate  # id: emski       |  seed node: seed.bitdelegate.org:42577
    - dele-puppy            # id: puppies     |  seed node: 95.85.33.16:8764
    - cny.bts500            # id: heyD
    - btsx.chinesecommunity # id: ripplexiaoshan
    - delegate.cgafeng
    - testz
    - delegate.xeldal
    - delegate.coolspeed
    - maqifrnswa
    - spartako
    - emski.bitdelegate
    - dpos.crazybit
    - delegate.webber
    - calabiyau
    - kokojie
    - bdnoble
    - bitcoiners
    - delegate1.john-galt
    - delegate-clayop

    # standby newcomers producing feeds and up-to-date (payrate 3%)
    # (getting these voted in is good for decentralization)
    - delegate.robrigo
    - moon.warlock       # id: davidpbrown
    - delegate-1.lafona  # 1% payrate
    - delegate-mdj       # 2% payrate (id: mdj)
    - delegate.ihashfury # seed nodes and chain servers: https://bitsharestalk.org/index.php?topic=12856.0
    - triox-delegate     # id: triox

I hope I did not forget anyone, if so, please let me know via PM. Another thing I'd like to point out, is that this slate as shown here is in the yaml format (similar to json, but less "visual noise") and can be published if you have the bts_tools installed directly with the following command:

Code: [Select]
$ bts publish_slate slate.yaml

You can find some documentation on how to publish your own slate with the bts_tools here: http://bts-tools.readthedocs.org/en/latest/cmdline.html#publishing-a-slate

11
General Discussion / RPC calls access control
« on: December 30, 2014, 08:52:16 pm »
There's a thought (and a question) I had a while back, but that came back to mind today as I was thinking about all the things that could be built upon the BitShares platform (happens to me a lot :P), and which is the following:

would it be a lot of work to implement some sort of access control to the RPC calls to the client?

I originally had this question when using a small RPC proxy to the client to be able to do some Ajax calls from a webpage, however I didn't feel very comfortable that this proxy had unrestricted access to my client (which was also running my delegate at the time).

There are also the tools that I'm working on, which (understandably so) people don't necessarily feel comfortable running (unless properly reviewed before) as it could easily steal their private keys if having access to an unlocked wallet.

Something like that would be nice in the config.json file

Code: [Select]
"rpc": {
    "enable": true,
    "users": [
        {
            "rpc_user": "web_client",
            "rpc_password": "password1",
            "rpc_methods_allowed": ["get_info", "about", "blockchain_get_blocks"],
        },
        {
            "rpc_user": "bts_tools",
            "rpc_password": "password2",
            "rpc_methods_allowed": ["get_info", "blockchain_get_delegate_slot_records", "wallet_publish_feeds"],
        }
    ],
    "httpd_endpoint": "127.0.0.1:5678",
}

maybe also having the "rpc_methods_forbidden" property would be nice, which would allow things like:

Code: [Select]
"rpc_methods_allowed": ["*"],
"rpc_methods_forbidden": ["wallet_dump_private_key"]

although it's generally better to always whitelist instead of blacklisting methods, so we could probably do with only "rpc_methods_allowed" at the beginning.

I know that there are other priorities right now in the development of the wallet, but if this is not too much work, I think it'd be very nice to have (probably this also could help for integration in gateways, as it would allow to have a python/php/... interface to the client which has limited access to what the client can do)

12
DevShares / Is DevShares officially launched?
« on: December 23, 2014, 12:37:06 pm »
or is it still in development? (whatever that means ::) inception... :P)

In particular, my question is: what is the official place to get the source code from?
- continuously from the develop branch
- from the devshares branch
- only from the -dev tags

Thanks!

13
Stakeholder Proposals / Delegate btstools.digitalgaia: proposal and updates
« on: December 21, 2014, 12:58:35 pm »
delegate name: btstools.digitalgaia (Standby | 7.45% votes)  (http://bitsharesblocks.com/delegates/delegate?name=btstools.digitalgaia)
pay rate: 30%
hangout: https://bitsharestalk.org/index.php?topic=12106.msg163527#msg163527
specs: 2-core xeon, 4GB RAM, 100Mb/s symmetric, location: FR (hosted at https://www.gandi.net)

seed node: seed01.digitalgaia.io:1776  (46.226.109.66:1776)
chain server: seed01.digitalgaia.io:1375  (46.226.109.66:1375)

bts_tools source code: https://github.com/wackou/bts_tools
last published version: 0.2.4  (https://pypi.python.org/pypi/bts_tools)
updates: see last posts in this thread for current updates, official changelog for released versions can be found here: https://github.com/wackou/bts_tools/blob/master/HISTORY.rst



Hi all,

Having learned about Protoshares about a year ago now, I have since then been fascinated by the DAC concept and BitShares in general, which is why I decided to run as delegate since the launch of BitShares (and the dry runs before that), and have been developing some tools in order to maintain my delegate easily. This has been open source since the beginning and the source code can be found here: https://github.com/wackou/bts_tools

What the tools do is that they automate a lot of the tedious tasks needed to properly maintain a delegate, such as building a new version, publishing feeds, not forgetting to update the info of your delegate with the version after an upgrade, monitoring of network connections, etc... and will send you an alert by email or iOS push notifications whenever the client crashes or starts missing blocks.

I have created a 30% paid delegate to fund my development of the tools, and further participate in the BitShares ecosystem (eg: I already provide a seed node too, but would like to provide chain nodes, write howtos about setting up a new node, etc.)


Mission

My mission is to enhance the security, stability and overall reliability of the BitShares platform, by making it easier to run a delegate properly, and enforcing good practices. I also have some ideas about making the network more resilient to defects, lack of connectivity and/or directed attacks which I would like to explore if given the opportunity.

These 2 main avenues of development can currently be seen on my delegate website:


Short-term roadmap

The roadmap I plan to follow for the short term future is to go on developing the bts_tools, fix bugs and implement feature requests that can be seen in the github issues tracker: https://github.com/wackou/bts_tools/issues

Mainly, I would like the tools to be ultra-reliable (what good is a monitoring tool if it crashes?) and start implementing what is needed in order to monitor specialized nodes (eg: seed nodes, chain nodes, backbone nodes) instead of just delegate nodes.

As for network health, I also pledge to set up and maintain 2 seed nodes / chain nodes in each major geographical region (US, Europe, Asia) for a total of 6 nodes for as long as I am voted in.


Long-term roadmap

In the long term, I plan to continue maintaining the delegate tools and make it easy for delegate to perform their duties easily (by writing tutorials, etc.).

Once we know that all delegates are operating in a stable way, I would also like to try to investigate what could be done at higher level in order to ensure that the network functions properly (for instance, I firmly believe that it would be beneficial for the network if it could be ensured that it acts as a small-world network), and would like to build incentives for nodes to coordinate in order to guarantee that, or provide myself nodes that would do that.


About me

My name is Nicolas Wack, and I have been developing in C++ for the last 15 years doing mostly audio analysis (main project of fame: http://essentia.upf.edu/, source at: https://github.com/MTG/essentia) and python for the last 10 years or so, doing a bit of everything (main projects: https://github.com/wackou/guessit (active) and https://github.com/wackou/smewt (retired, for lack of time))
You can see some of my projects on my GitHub account (https://github.com/wackou), as I am a fervent believer in open source and free software as a better way of developing software.

14
General Discussion / Delegate slate publishing for non-delegates
« on: December 14, 2014, 01:05:18 pm »
I was talking with Fuzz recently and he mentioned his desire to publish a slate of delegates, however he doesn't have a delegate himself to do that and asked me whether I could help him figure it out. Preferably, this should be possible to integrate into the mumble chatroom so people could just click on a link there. After giving it a little bit of thought, I came up with those potential solutions:

  • the dev team enhances the current bts:// url scheme to allow multiple delegates at once

    At the moment, one can create a link bts://<delegate-name>/approve, which will open the GUI wallet and approve the delegate whose name is in the link. That only works for one delegate at a time, though, but probably it would be very easy to extend this to something like bts://approve-slate/delegate1&delegate2&delegate3&delegate4

    PROS:
     - easy, barely no setup required
     - no delegate required either

    CONS:
     - approves all the delegate at the time of clicking, but doesn't change approval if Fuzz updates his slate later

  • Fuzz gets a delegate, only to publish a slate (ie: doesn't try to get elected)

    This would be the more "standard" way of doing it

    PROS:
     - uses standard delegate slate publishing methods
     - he can update his slate, and people that have him approved will vote for the updated slate

    CONS:
     - people need to use "vote as recommended" (not the default option)
     - people need to have him approved in their wallets, which means there's a risk that he ends up becoming an active delegate

  • This message from Toast:

    https://bitsharestalk.org/index.php?topic=12020.msg158784#msg158784

    But I'm not sure I really understand what this entails (this probably sounds like the best solution in the long-term, though)

Any other ideas/thoughts about what would be the best way to do this?

I believe that this would go a long way towards solving voter apathy, and surely there are some low-hanging fruits that can be picked to ensure that it is as easy as possible for people wanting to publish a slate to do so, and for shareholders that trust a community figure to just "follow" their votes.

15
!!! This thread is now retired, please use the new one for new posts: https://bitsharestalk.org/index.php?topic=12534.0 !!!

Hi all,

My name is Nicolas Wack, and I have been developing in C++ for the last 15 years and python for the last 10 years or so.
You can see some of my projects on my GitHub account (https://github.com/wackou), as I am a fervent believer in open source and free software as a better way of developing software.

Having learned about Protoshares about a year ago now, I have since then been fascinated by the DAC concept and BitShares in general, which is why I decided to run as delegate since the launch of BitShares (and the dry runs before that), and have been developing some tools in order to maintain my delegate easily. This has been open source since the beginning and the source code can be found here: https://github.com/wackou/bts_tools

What the tools do is that they automate a lot of the tedious tasks needed to properly maintain a delegate, such as building a new version, publishing feeds, not forgetting to update the info of your delegate with the version after an upgrade, monitoring of network connections, etc... and will send you an alert by email or iOS push notifications whenever the client crashes or starts missing blocks.

I would like to run a new paid delegate to fund my development of the tools, and further participate in the BitShares ecosystem (eg: I already provide a seed node too, but would like to provide chain nodes, write howtos about setting up a new node, etc.)


Mission

My mission is to enhance the security, stability and overall reliability of the BitShares platform, by making it easier to run a delegate properly, and enforcing good practices. I also have some ideas about making the network more resilient to defects, lack of connectivity and/or directed attacks which I would like to explore if given the opportunity.

These 2 main avenues of development can currently be seen in my previous delegates website:

Now that it is possible to have delegates with a higher pay, I think it makes sense to have a single delegate operating on both these issues with a combined payrate rather than 2 separate ones. Making the network stronger would also now involve multiple delegates getting together and gathering their resources (seed nodes, chain nodes, etc.) rather than me running dozens of them from a single delegate pay.


Short-term roadmap

The roadmap I plan to follow for the short term future is to go on developing the bts_tools, fix bugs and implement feature requests that can be seen in the github issues tracker: https://github.com/wackou/bts_tools/issues

Mainly, I would like the tools to be ultra-reliable (what good is a monitoring tool if it crashes?) and start implementing what is needed in order to monitor specialized nodes (eg: seed nodes, backbone nodes) instead of just delegate nodes.

I do also hereby welcome people in this forum to preferably report bugs/issues/feature requests directly on github as it makes it easier to track what needs to be done.


Long-term roadmap

In the long term, I plan to continue maintaining the delegate tools and make it easy for delegate to perform their duties easily (by writing tutorials, etc.).

Once we know that all delegates are operating in a stable way, I would also like to try to investigate what could be done at higher level in order to ensure that the network functions properly (for instance, I firmly believe that it would be beneficial for the network if it could be ensured that it acts as a small-world network), and would like to build incentives for nodes to coordinate in order to guarantee that, or provide myself nodes that would do that.

This long-term roadmap is still a bit vague (mostly, it's what's described in my previous backbone delegate proposal), but I plan to refine it continuously by updating this post and/or the delegate website.


Closing words

I am currently thinking of running this delegate at a 30% pay rate, as I foresee to only be able to work 5-10 hours/week on it for the coming months, and do not think it would be fair to ask the same as bytemaster, toast, svk, cass, etc. I am of course open to publicly burning some of it in the future if BitShares market cap rises a lot (pretty sure it will ;)) and if the community wants me to
do so.

Before registering the delegate though, I would like to test the water and see whether 30% at current rate seems an adequate pay rate for the value I propose to bring to the ecosystem, so please use the poll at the top of this thread to give your opinion. I will most likely create the delegate in the next few days according to the outcome of the poll.

Thank you for reading this far!

EDIT: changed desired pay rate from 50% to 30% as it seems people think it's more fair
EDIT2: this thread will soon be retired for a new one without the poll (visual noise)

Pages: [1] 2