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.


Messages - wackou

Pages: 1 ... 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 ... 33
331
General Discussion / Re: [URGENT] Delegates Please Upgrade to v0.4.26!
« on: December 12, 2014, 09:57:25 pm »
Quote from: wackou on December 12, 2014, 09:35:21 pm
However, when I run
Code: [Select]
blockchain_get_delegate_slot_records wackou-delegate it shows that my last block was from 2014-12-12T13:38:10
Sorry, my bad, that's because the default values are
Code: [Select]
blockchain_get_delegate_slot_records wackou-delegate -1000 10and as there were lots of missed blocks, -1000 went way past beyond the usual 10 blocks per delegate to show blocks until "now", so running
Code: [Select]
blockchain_get_delegate_slot_records wackou-delegate -1000 100does the trick. Sorry for the noise  :-[

332
General Discussion / Re: [URGENT] Delegates Please Upgrade to v0.4.26!
« on: December 12, 2014, 09:35:21 pm »
upgraded seed node and delegate to 0.4.26, and producing blocks. There is something weird, though:
I am pretty sure I just produced a block with wackou-delegate, it even came up on bitsharesblocks: http://bitsharesblocks.com/blocks/block?id=1247596

However, when I run
Code: [Select]
blockchain_get_delegate_slot_records wackou-delegate it shows that my last block was from 2014-12-12T13:38:10

What's even weirder, is that this list keeps being updated, but seems to lag ~8h behind the current time. I would have thought that this is a sync issue, or some background indexing, however both my delegate node and my seed node show the exact same list, and they are on different machines. I did follow the same upgrade pattern for both though (0.4.25-RC1 -> 0.4.25 -> 0.4.25-RC2 (resync blockchain) -> 0.4.26), so maybe that's the cause? I'm a bit confused as to what this could be given that my delegate is signing blocks correctly now...  ???

333
General Discussion / Re: Delegate Hangout #2 w/ Wackou --- 10 DEC 14 @ 3:00PM EST
« on: December 10, 2014, 07:15:33 pm »
bump

Happening in less than an hour now!

334
Stakeholder Proposals / Re: Delegate Proposal: del0.cass
« on: December 10, 2014, 06:49:45 pm »
 Congrats +5% You definitely deserve it!

335
Stakeholder Proposals / Re: avoiding delegate downtime while upgrading client
« on: December 09, 2014, 10:51:11 pm »
ah, and another thing: re-indexing takes up a lot of memory which is not necessarily freed afterwards (not sure there's a leak, but memory doesn't seem to get reclaimed by the OS), so I would recommend to exit the client after re-indexing and restart it immediately afterwards, RAM usage will look more "normal" then.

336
Stakeholder Proposals / Re: New delegate proposal: btstools.digitalgaia
« on: December 09, 2014, 08:46:34 pm »
If people haven't seen it on the main discussion forum, I'll be in a delegate hangout tomorrow, see: https://bitsharestalk.org/index.php?topic=12107.0

Looking forward to your questions!

337
Stakeholder Proposals / Re: avoiding delegate downtime while upgrading client
« on: December 08, 2014, 08:48:28 pm »
Quote from: monsterer on December 08, 2014, 05:02:34 pm
Hmm, I don't fancy re-indexing the DB on one build while the other is producing blocks, surely that's a recipe for disaster?

only if both are supposed to be producing blocks. The way I do it is what people mentioned before, but instead of locking/unlocking the wallet, I just "switch" them using
Code: [Select]
wallet_delegate_set_block_production ALL true or
Code: [Select]
wallet_delegate_set_block_production ALL false which is instantaneous, ie:

Code: [Select]
client 1: producing blocks, this is the client I want to upgrade (usually on a VPS)
run client 2, same version as client 1 (same wallet too, usually on my laptop). By default, it has block_production=false
# when there is time before next block production (use get_info['next_block_production_time'] on client 1 to know)
client 1: wallet_delegate_set_block_production ALL false
client 2: wallet_delegate_set_block_production ALL true
# now client 2 is producing, so basically you can do whatever you want with client 1, in particular
exit client 1
recompile client 1
run client 1, unlock it
# reindexing can indeed take some time, but is not a problem since last time you were running client 1 it had block_production=false,
# so it will still have it, so it can come fully online whenever it wants, you won't produce forks
# wait for another moment before next block production (same as before, but checking on client 2 now), then
client 1: wallet_delegate_set_block_production ALL true
client 2: wallet_delegate_set_block_production ALL false
# at this point, client 1 is upgraded and fully operational again, you can exit client 2 and relax after a smooth upgrade :)

This seems a bit contrived at first, but will feel very natural after a few times ;)

To check on the clients while upgrading, I use some python tools that I wrote specifically for that purpose, in particular I use this view:
https://raw.githubusercontent.com/wackou/bts_tools/master/bts_tools_screenshot2.png

In this screenshot, you can actually see that I run the client on localhost while recompiling on the server (remote host) and that now would be a bad time to switch, as there are only 39 seconds before my next scheduled block production.

You can get the tools here: https://github.com/wackou/bts_tools

338
Random Discussion / Re: BitGuardians
« on: December 08, 2014, 03:29:31 pm »
 +5% to the text and the picture

Enough of people complaining that our current world is fucked up (even though it might be), what we need is more people building a new one, where the values we hold dear are enshrined in the foundations of this new system we're building...

Quote from: Ben Mason on December 05, 2014, 05:54:44 pm
Satoshi’s blockchain invention has gifted us with the ability to resist corruption over time and therefore, the potential to become truly civilized.  For the first time in human history, the potential to transition peacefully from a system of abject horror to one of hope is a tantalizing reality.

So true, this is the key to building a new world that is fair and open while being strong enough to resist the attacks of the old one, when it will realize its time will soon be over...

339
Stakeholder Proposals / Re: New delegate proposal: btstools.digitalgaia
« on: December 04, 2014, 08:24:55 pm »
Thanks guys for the support! :)

340
Stakeholder Proposals / Re: New delegate proposal: btstools.digitalgaia
« on: December 03, 2014, 01:24:02 pm »
OK, so I went ahead and registered btstools.digitalgaia as a 30% delegate. Eagerly waiting for your votes now, thanks!

341
General Discussion / Re: publish feed price automatic(From BitSuperLab)
« on: December 02, 2014, 10:44:34 am »
Quote from: alt on December 02, 2014, 01:30:57 am
try to remove the try{} except {} , and see what's wrong
Code: [Select]
while True:
  try:
    fetch_price()
    display_price()
  except:
    logger.error("Warning: unknown error, can't fetch price")
  time.sleep(sample_timer)

Small tip: if you want to see what exception was raised, but still want to catch it, you can do it like so:
Code: [Select]
while True:
  try:
    fetch_price()
    display_price()
  except Exception as e:
    logger.error("Warning: unknown error, can't fetch price")
    logger.exception(e)
  time.sleep(sample_timer)
which will print the exception type, message and stack trace.

342
Stakeholder Proposals / Re: New delegate proposal: btstools.digitalgaia
« on: December 02, 2014, 10:39:45 am »
Quote from: Mysto on December 02, 2014, 01:25:25 am
We really need 1 website where we can browse delegates, click their names and have... [...]

I fully agree. I did something like that for my own delegates, the result of which can be seen here: http://digitalgaia.io/wackou.html
This is generated from this: https://github.com/wackou/digitalgaia/blob/master/wackou.html where you just have to fill in the delegate_name and mission blocks (note: this is the delegate that the new btstools.digitalgaia will replace).

I would be willing to host such a website, but delegates would have to submit pull requests to update their info, I'm not sure that is to the taste of everyone. Someone with better frontend skills could surely do better than that (eg: wordpress style), but unfortunately no one has stepped up to do it yet. I would say that that's clearly an open position for a paid delegate. I would not burden svk with this, I believe he already has enough on his plate with bitsharesblocks as it is, I think it's better to have a website dedicated to delegates campaigning, as the target group is not exactly the same as the one for bitsharesblocks (albeit with a big intersection between the two)

343
Stakeholder Proposals / Re: New delegate proposal: btstools.digitalgaia
« on: December 01, 2014, 09:22:19 pm »
I edited my post to set the desired pay rate to 30%, and also added a few more options with low pay-rate in the poll, including one where I keep my 3% delegate, in order to get more precise feedback.

As for the short-term roadmap, another thing I'm planning to do is to add support for building and monitoring Sparkle and DPoS-PTS clients (given that they're forked from BitShares mainline, I expect this to be available quite soon).

344
General Discussion / Re: Sparkle Alpha Test Network Live: Mining to be Honored in Real Network
« on: November 30, 2014, 02:57:11 pm »
stuck on block 6275 too... I imagine that's due to the fact that difficulty skyrocketed, right?

345
Stakeholder Proposals / Re: New delegate proposal: btstools.digitalgaia
« on: November 29, 2014, 06:08:37 pm »
well, given that the user group that the tools are targeted at are delegates, I was expecting them to read the github commits and see whether I had been slacking off or not. If needed, I could post updates here in the forum in a dedicated thread, or setup a blog, but as Cass mentioned, maintaining a blog is some work and would take some time off of the actual work that I'm proposing to do.

If the "facebook for delegates" would be up and running, maybe it would be a good idea to not only make it easy for delegates to publish their proposals/missions/etc., but also to publish reports of what they have been doing/plan to do. Food for thought for whoever will implement that...

edit: TEST EDIT, this is just to see whether it makes sense to have updates by editing a post, rather than posting a new one
edit2: again

Pages: 1 ... 16 17 18 19 20 21 22 [23] 24 25 26 27 28 29 30 ... 33

Page created in 0.201 seconds with 23 queries.