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 ... 20 21 22 23 24 25 26 [27] 28 29 30 31 32 33
391
Such an exciting moment!  +5%

392
"Remember, remember, the fifth of November..."   ;D
Quite fitting for the 1st birthday of the release of ProtoShares!

I say 2014-11-05 at 17:00UTC

393
Initial connection to the network is much faster and it seems to use less cpu for me  +5%

394
also, since around 0.4 or 0.4.2 (not 100% sure) my delegate seems to have a really hard time acquiring connections at the beginning. Starts with the 7-8 seed nodes it gets at the very beginning, then stays there for quite a while. Sometimes it takes off, but sometimes it just drops. Was at 3 connections just a couple of minutes ago, when I have:
Code: [Select]
(unlocked) >>> network_get_advanced_node_parameters
{
  "peer_connection_retry_timeout": 30,
  "desired_number_of_connections": 100,
  "maximum_number_of_connections": 200
}

395
I've had two crashes in the last 4 hours.  First one didn't have gdb running,  Second crash bt is

Had a similar crash 2 days ago, and today another one kind of similar too: https://github.com/BitShares/bitshares_toolkit/issues/649

396
yes, seems like there was a bit of forking recently, got 4 missed blocks last night (got alerts), only to wake up with my delegate with no missed block since at least a couple of days, so somehow it got back on the correct branch (with the blocks properly produced ??? how is that even possible?...). I imagine bitmeat is still stuck on its fork...

397
Stakeholder Proposals / Re: 3.1 is looking good
« on: August 04, 2014, 02:18:31 pm »
same here, had no access to internet the whole weekend and came back to my delegate alive and kicking, with lots of connections  +5%

Before that, I had to restart it everyday or it would invariably lose all connections and stay half-dead. Great job 3I!

398
General Discussion / Re: Delegate Observations
« on: July 31, 2014, 11:43:05 am »
Great! Although that should probably just be a temporary solution until a better solution is found out, because:
 - people will accuse us of forming a cabal
 - this somehow centralizes the delegates, as 1 bad delegate could harvest the IPs of all the other ones easily, which would make it easy to DDOS a good part of them

I'm thinking having some types of nodes which are low-latency and non-peer-IP-forwarding to which delegates could connect which could act as a sort of backbone for instant and anonymous block broadcasting could be a good solution. I'm still not completely convinced, but I'll post something more detailed if I can get it clearer in my head.

399
General Discussion / Re: Delegate Observations
« on: July 31, 2014, 10:53:06 am »
I also got a seemingly strange one:

Code: [Select]
          97525
     3e9d0e1a61194b490a2b874f1133c85088cdda6f               wackou-delegate              0       166 2014-07-30T22:15:50         0     YES                  NO
     73c52ca0e0838712c8662d82c5cc301bad0d8071                        init72              0       166 2014-07-30T22:16:00         0     YES                 YES

seems like I was on time and everything (as is shown by latency=0, I also had a lot of connections at that time and this was an isolated event, subsequent blocks after this one were produced correctly), is it just that somehow init72 "decided" to not include my block? Could it be that my block didn't propagate in less than 10 seconds to that node? In that case, it would probably be a good idea to have a "backbone" of broadcasting nodes, delegates and/or proxy nodes for delegates not wanting to broadcast their IP. I remember seeing this idea somewhere, maybe this has to be done in order for delegate to not randomly miss block (when they in fact correctly produced it)

400
General Discussion / Re: Irregular block production by Delegate
« on: July 29, 2014, 07:29:07 pm »
Same for me, I'll try to track it down, too, but right now everything looks normal, so not sure why it happens...   ???
(ntp synchronized, currently 40+ connections, just missed one and then everything back to normal)

Is there a way to know the number of the missed block? The output of
Code: [Select]
blockchain_get_delegate_slot_records currently only lists the time, which is not very practical (would it be possible to add the block # to the output of it?)

401
BTSX7Uj7JMS1T1GcrbWmTHRjmfRz3DXuo5uaadTFaqh5fnXSMTFKox

402
General Discussion / Re: Delegates please Use Sub-Accounts
« on: July 24, 2014, 07:02:51 pm »
My old delegate "wackou-delegate" is now called "wackou.digitalgaia", collected fees will go towards developing the bitshares_delegate_tools.

I also now have "security.digitalgaia", fees will go towards funding a security audit of the codebase,
and "charity.digitalgaia", fees will go towards a charity somewhat aligned/related with bitshares, at the moment I'm thinking the EFF but there might be others in the future.

403
General Discussion / Re: delegate stopped producing blocks..!
« on: July 24, 2014, 06:09:46 pm »
on your screenshot it shows 7 connections, so maybe you dropped below 5 when it was your turn to produce a block? and then got back to more than 5, which would leave "no trace" of what happened.

404
General Discussion / Re: Delegate temporary absence
« on: July 23, 2014, 09:42:39 pm »
As a delegate should have a backup machine IMHO that should not be necessary as you can simply switch over to the backup machine by enabling/disabling block production.

 +5% Yes, it's a way how it's should be done. Probably at some point somebody will automate this task but even today it's can be done manually in 10 seconds.

what happens if a delegate has two machines running, each producing blocks as a form of redundancy? It will cause forks and race conditions, but how serious are those? (I know they can be serious, but would redundancy be a good or bad thing?)

The idea is to have N machines "ready", meaning properly synced (ie: head block is only a few seconds of age), at least 5 connections, NTP also in sync, wallet open and unlocked. All of them, except for one, should have their block production set to false, so that at a given time you only have a single one producing blocks.

Whenever you want to activate a backup machine, you should first make sure to deactivate your currently producing one (and preferably not too close to your allotted block production time) and then activate the one you want. As other people commented here, you should never produce 2 blocks at once, in case of doubt it is much better to miss a block than produce duplicates.

405
Excellent idea!! This is a great step towards "fixing" voter apathy, as I can imagine not so far away in the future that some delegates will be known for advancing network security, some for marketing, some for charity, and some other for diversity. People would definitely be more aware and willing to check one of those boxes (where each box would be a known delegate for his recommendations):

Code: [Select]
[ ] 100% network security
[ ] 100% marketing
[ ] 100% charity
[ ] 50% network, 50% marketing
[ ] 33% network, 33% marketing, 33% charity
etc.

than choosing a full slate of delegates.

bytemaster, the speed at which you find solutions to problems you encounter on the go is really impressive, first tapos, then dpos, now rdpos, and not even a year has gone by... hats off to you!

Pages: 1 ... 20 21 22 23 24 25 26 [27] 28 29 30 31 32 33