Vote for scroodge pls!

dxtr-wallet (unlocked) >>> wallet_approve_delegate xeldal
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate bitcoiners
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate bits
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate blockchainer
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate cryptomoon
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate slavix
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate jabbajabba
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate kpd-1
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate happyshares-1
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate xeroc-delegate-1
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate liondani
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate spartako
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate ninja
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate dele-puppy
Delegate approved.
dxtr-wallet (unlocked) >>> wallet_approve_delegate enki
Delegate approved.

Right now I'm transfering my funds to me, so vote stats get updated accordingly.

Edit: Votes should be updated now.

Quote from: dxtr on July 20, 2014, 04:55:12 am

Are those init* delegates going to be gradually replaced by actual delegates from around the world?

Right now it's kind of hard to push your delegate up, when EACH (!!!) init* delegate has over 3% of total votes...

And init* delegates create majority of active ones.

BTW: From my perspective it looks like if someone has, say, 3.9% of all shares, and creates 101 delegates all of which he approves, then each and every delegate gets 3.9% Approval. This makes a total of over 390% and effectively blocks others from becoming a delegate.
Shouldn't instead those 3.9% of all votes be divided equally amongst those delegates user approved, so that total # of votes for all approved delegates makes sum of 3.9%?

It is my understanding that the 3.9% stake gets divided over everyone you vote on. So if you have 10% stake, and you voted for 100 delegates then your 10% gets divided over 100, meaning 0.1%/delegate.

Well, that was my understanding too...

But just go and start up windows BTSX client and go to Directory -> Delegates and count down how many active delegates with over 3% of votes are there and sum them up.

Maybe it's just a display bug, I hope so...

What happened to Trading Open/Halt Conditions as described here: http://v3.bitshares.org/banking/ ?

Are those going to be implemented or what other mechanism is going to be there to enable trading with sufficient market depth?

It seems delegate registration fees are changing quite randomly. It dropped down below 100,000 XTS and now back up to over 10 million..

Code: [Select]

>> blockchain_get_config

{
  "blockchain_id": "5a50ec8c2433e7d5fce13187be2db73d112dcdc6b3766751fbff6162e90836b0",
  "symbol": "XTS",
  "name": "BitShares XTS",
  "version": 107,
  "genesis_timestamp": "20140715T000000",
  "block_interval": 10,
  "target_block_size": 25600,
  "max_block_size": 51200,
  "max_blockchain_size": 107374182400,
  "address_prefix": "XTS",
  "min_block_fee": 1,
  "inactivity_fee_apr": 10,
  "delegate_num": 101,
  "delegate_reg_fee": "11,444,627.53767 XTS",
  "name_size_max": 63,
  "memo_size_max": 19,
  "data_size_max": 65536,
  "symbol_size_max": 5,
  "symbol_size_min": 3,
  "asset_reg_fee": "1,155,907,381.30560 XTS",
  "asset_shares_max": 1000000000000000,
  "proposal_vote_message_max": 1024,
  "max_pending_queue_size": 100,
  "max_trx_per_second": 10
}
>> blockchain_get_config

{
  "blockchain_id": "5a50ec8c2433e7d5fce13187be2db73d112dcdc6b3766751fbff6162e90836b0",
  "symbol": "XTS",
  "name": "BitShares XTS",
  "version": 107,
  "genesis_timestamp": "20140715T000000",
  "block_interval": 10,
  "target_block_size": 25600,
  "max_block_size": 51200,
  "max_blockchain_size": 107374182400,
  "address_prefix": "XTS",
  "min_block_fee": 1,
  "inactivity_fee_apr": 10,
  "delegate_num": 101,
  "delegate_reg_fee": "116,088.31803 XTS",
  "name_size_max": 63,
  "memo_size_max": 19,
  "data_size_max": 65536,
  "symbol_size_max": 5,
  "symbol_size_min": 3,
  "asset_reg_fee": "11,724,920.12160 XTS",
  "asset_shares_max": 1000000000000000,
  "proposal_vote_message_max": 1024,
  "max_pending_queue_size": 100,
  "max_trx_per_second": 10
}

No it goes with what BM said - the price melts down to amount the next candidate is willing to pay, if he pays - it is automatically increasing total_fees and reseting the clock waiting for next rich candidate for a delegate to participate.

But it goes along with: Rich get richer, poor get poorer...

This is how you get $$$ (currently no one selling, I bought all 11)

wallet_market_submit_ask dxtr 100 XTS 10 USD
In above you sell 100XTS from dxtr account to anyone willing to buy it at 10$/piece.

Guess in this run I won't register a delegate:

Required "456,475.97790 XTS"

 

OK, I can see, that this delegate currently has only 2 network connections, I can see now that error message as well.

Sorry, that's possibly because I'm splitting attention with BRA-GER (0-6)

How is the network going to deal with transaction flooding?
I know that when there is value put in network, then making thousands of transactions means money, but let's assume that there is a triggering event, that causes hundreds or even thousands of users to, simultaneously, create a transaction of any kind.
Now there are max 30tx/blk, but there might be a peak demand of network for 500 or 15k transactions per minute - then all those transactions are pending, effectively blocking new transactions from entering into blockchain.
On the other hand all delegates know what those pending transactions are, and how many are there.
What if delegates could control block production rate and/or block capacity in order to deal with pending transactions faster.
Something like delegate A sees that there are over 500 pending transactions, so he issues a block with indicator that block creation rate should be increased.
Now the whole network can agree or disagree - they all have necessary data to verify.
Next in queue, delegate B validates this aswell and if he agrees, he confirms A's suggestion, and delegate C will produce next block faster.
Then, if pending operation decreases to 100, delegate D can suggest decreasing rate to normal, delegate E can confirm, and delegate F can produce a block at normal rate.
There could be more than one thresholds for pending operations amount so that rate and/or capacity of a block could have many shifting gears.

I don't know if it's worth something, or am I just making a fool of myself