'freeworm' looked up a withdraw for me giving me a transaction id.   I don't see this in my account, nor do I see my "Account Key" in the transaction.  Is there anyway to figure out what the registered account name is from this transaction?

>> blockchain_get_transaction 651b36f9

With the possibility for delegate-operators to have as many delegates as they want don't we have delegation voting (= your voting power is distributed among all the delegates you vote for) and not real approval voting effectively?

For example (with approval voting): I want to have the full effect of my voting stake, so I have to vote for 101 delegates. If I only know and trust 5 delegates then I would have to vote for 25 delegates of each of the 5 delegate operators.
This would be the same as distributing your vote among 5 delegates if we had delegation voting.

On the other side approval voting gives the shareholder, that is not educated that his vote only has the full effect when he votes for 101 delegates, the impression that he is supposed to vote only for a few delegates. He doesn't see a reasons to vote for 20 delegates (as he doesn't know the system/ approval voting) and might think voting for 25 delegates might be a bit too much power for one delegate. The result is low effective participation in voting even if all shareholders voted but just for a hand full of delegates.

So effectively (if you know how the voting system works) approval voting and delegation voting is the same.

If people don't understand the voting system fully then we have the following contra points for the two systems:
Approval voting: Low effective participation
Delegation voting as opposed to wrong assumptions about approval voting: Having to play whack-a-mole with bad stake; bad stake can cause trouble. 

In reality both voting systems are the same if delegate operators can set up as many delegates as they want.

An attacker probably understands the voting system better than the average shareholder, so we give him an advantage with approval voting. 

This was a quick though I had after the mumble session. There might be a flaw in there but up to now I couldn't think of one.

Once people start sending money to various exchanges and back and realize the funds are available in seconds they will become addicted.  Transferring BTC can take 20 minutes to an hour.  Who has time for that legacy nonsense? 

I've noticed significant amount of forks lately. Any particular reason ?


I've noticed that one of the delegates misses blocks (3 so far) while the client is online.

Here is the last missed block:

 60948
     211d78002ecf8ad2b4b49c9a43b157e2064646ae             angel.bitdelegate              0       166 2014-07-26T13:20:10         0     YES                  NO
     a3c1f207ced3bc2b57869ed2661077ffea4207b4                mr.agsexplorer              0       166 2014-07-26T13:20:00        12     YES                 YES

List_errors mentions some exceptions but they are related to blocks 7531 and 47087 and 14872.
There are few more delegates working properly on the same client that are not missing blocks at all. Chances for this to happen randomly are 1/216. Is that particular delegate just unlucky or there might be something else?

Info reports  "blockchain_average_delegate_participation": "100.00 %" , How is this calculated ?

Quote from: happypatty on July 26, 2014, 06:32:23 am

Running a delegate is a delicate experience. I gave up on the idea. When you run a delegate, your own transactions didn't work very well, unless you stop producing blocks, rescan and then restart producing. May be they fixed some of these issues, I don't know. All I know is that I would definitely not recommend running a delegate while doing your own transactions.

You are not supposed to use your client where the delegate is running, as normal user. You should consider running separate client instance with your desired wallet(s) and send/receive/check balance/etc using the client's instance. Even better - use entirely different device for user actions.

On the topic: I saw no performance degradation on 0.2.3 . However the spikes might be related to the size of the blocks that need to be processed. Usually there are no transactions at all (hope this changes), but sometimes delegates need to verify blocks full of transactions which might increase CPU usage. I haven't seen spikes with more than 15% CPU usages but this doesn't prove anything. The overall CPU time for the client is unchanged between 0.2.1 and 0.2.3 (I dont have enough statistics for 0.2.2 as it was quick upgrade).

Quote from: GaltReport on July 26, 2014, 05:38:49 am

Quote from: chryspano on July 26, 2014, 02:56:43 am

I tried to register my account name but I get the following error message..

RPC Server Error: in method "wallet_account_register" : unknown account(20006)

I use the windows client, any ideas on what I may be doing wrong? I have 0.1 btsx and I choose to pay from the same account I want to register

I am getting that error too but in my case it seems to be only for accounts that I created with .com endings.  It let me create accounts with .com in them but doesn't let me register them.  I get that error.

You were right, problem was that I was trying to register a .something name, I tried "chryspano" and it registered fine.

I tried to register my account name but I get the following error message..

RPC Server Error: in method "wallet_account_register" : unknown account(20006)

I use the windows client, any ideas on what I may be doing wrong? I have 0.1 btsx and I choose to pay from the same account I want to register