Usually I would send PM to the owner of delegate that is not performing at its best.

However in this case I have no idea who is the owner. Both of these delegates are consistently signing blocks before their time-slot.

504025  2014-09-16T21:49:00 delegated-proof-of-steak        0       166     0.00000 BTSX    -6      0.000933
504035  2014-09-16T21:50:40 delegate.nathanhourt.com        0       166     0.00000 BTSX    -6      0.002048

PS: A possible solution for this would be installing ntpd.

What happens when someone buys $1000000 worth of btsx.
Then buys $500000 bitUSD.
Then sells $500000 worth of BTSX.
Then sells all bitUSD for BTSX.
All within a few hours?

Imagine the following usecase:
A BTC holder (RICHY) wants to buy BTSX.

What RICHY needs to do currently:
1 Deposit BTC into an exchange (paying taxes, trusting the exchange).
2 Buy BTSX from orderbook on that exchange only (paying taxes, trusting the exchange).
3 Transfer BTSX from exchange's account to own BTSX wallet (paying taxes, trusting the exchange to do that).

What is the better option for RICHY:
1 Send BTC to specified BTC addresses. (possibly paying taxes, no trust issues)
2 Receive BTSX to specified BTSX account. (trusting 50% + 1 of BTSX delegates)

How can this be implemented?

Basically in delegates there is some level of trust already. There is no technical issue for delegates to monitor BTC blockchain.
Appart from some legal issues there is no technical issue for delegates to be mediators/ESCROW agents between blockchains.
There could be BTCAsk and BTCBid transactions on BitsharesX blockchain that signify intent between parties to exchange BTSX for BTC at certain ratio.
When such transactions are matched delegates could be an ESCROW for BTC(or bitcoin blockchain) -> BTSX transfer. This requires trust in delegates to forward BTC properly. In order to force/ensure good behavior a delegate bond may be placed (in BTSX). As all the transactions are visible delegate shouldn't be able to cheat or he/she risks his/hers bond/delegate seat. As they only perform ESCROWnotYetSureWhat they will not hold any amount of bitWhatever longer than confirmation time.

Here is my proposal (It requires some coding and consensus but it is doable):
[Updated Proposal Start]
1 Unchanced from Original Proposal (see below)
2 Unchanged from Original Proposal (see below)
3 A new kind of transaction (BTCBid) is created with the following properties:
   3.1 BTC amount (this is amount of BTC on BTC blockchain that a bidder is willing to exchange for btsx)
   3.2 BTSX/BTC ratio (Bid price for BTSX in BTC, meaning how much BTSX the transaction issuer wants for each of his BTC)
   3.3 Transaction id of a BTC transaction sending 0.01 BTC (or any other amount or percentage as bond or fee) to a delegate controlled BTC address. (Or if we dont want to be matching bids/asks, BTCBider could just point matching BTCAsk transaction and transfer BTC directly there, Or the bond might be in BTSX, Anyway we could go without transferring funds to a delegate controlled addres if required)
4 Unchanged from Original Proposal (see below)
5 Unchanged from Original Proposal (see below)

6 Whenever there is a match between BTCBid and BTCAsk AND the transaction in 3.3 is confirmed in BTC blockchain => Delegates include special transaction in BitsharesX blockchain signifying the fact that specific BTCBid/BTCAsk are matched and in the next 24 hours the issuer of BTCBid should transfer the specified amount of BTC to the address of the issuer of BTCAsk transaction.
7 If 6 is completed in expected timeframe delegates should exercise their ability (5) and transfer the BTSX to the issuer of BTCBid transaction. If 6 is not completed the delegate holding the bond specified in 3.3 should transfer it (or parts of it) to the issuer of BTCAsk as reparations for the lost time.
[Updated Proposal End]

[Original Proposal Start]
List of stuff to implement:
0 OPTIONAL A delegate bond/cover might be required from delegates in case someone decides to get the BTC and hide.
1 Every BTSX account should be granted the ability to publish own BTC address ( and it should be included in the BitsharesX blockchain).
2 A new kind of transaction (BTCAsk) is created with the following properties:
   2.1 BTSX amount (this amount becomes unspendable)
   2.2 BTSX/BTC ratio (Ask price for BTSX in BTC, meaning how much BTC the transaction issuer wants for each of his BTSX)
3 A new kind of transaction (BTCBid) is created with the following properties:
   3.1 BTC amount (this is amount of BTC on BTC blockchain)
   3.2 List of transactions (in BTC blockchain) - all transactions should satisfy the rule: Total amount should be equal to <BTC amount (from 3.1)>. All the funds are sent to BTC addresses of BTSX delegates(the list of delegate(s) is selected by this transaction issuer. ). This list might need to be "appended" to the transaction at a later time (possibly with separate transaction(s)). I'll just include it here for simplicity
   3.3 BTCAsk (2.) transaction id. Indicating that the bidder wants to exchange with the asker BTC for BTSX. (In a more complex scenario these transactions could be matched in a way similar to how market works. However even if they are matched no exchange should be done until other conditions are met... see below)
4 Ability to monitor BTC blockchain should be implemented in bitshares_client enabling it to:
   4.1 bitshares_client should be able to monitor if a specified transaction is confirmed (in BTC blockchain).
   4.2 bitshares_client should be able to extract details of a BTC transaction (in BTC blockchain) these details should include: sending address, receiving address, amount.
5 A new rule (transaction) for the BitsharesX blockchain (and client) should be implemented such that:
   5.1 50% + 1 of delegates should be able to transfer BTSX from an account that has issued BTCAsk (2) transaction to an account issued BTCBid (3).

Behavior of a delegate (well it is actually another thing to implement) :

Once a matching pair of BTCAsk and BTCBid transactions are included in the BTSX blockchain delegate should:
6 Delegate monitors BTC blockchain.
7 Delegate check if transactions in BTCbid (3.2) are confirmed in BTC blockchain. This means the issuer of BTCBid on BTSX blockcian has sent BTC (in BTC blockchain) to a selected (by issuer of BTCbid) subset of delegates.
8 Here comes the trust part (This could be eliminated with rule 0). A delegate (X) checks If an address listed in BTCbid (3.2) (assuming it  is matched with BTCAsk) is his (X's) address. If a delegate X has received BTC (in BTC blockchan) he is supposed to immediately send these BTC to the address of the issuer of matching BTCAsk (2) transaction. A delegate should not keep these BTC longer than absolutely required to confirm the transaction on BTC blockchain. This way the delegates do not hold BTC for longer than few minutes. And if they fail to conform they lose their bond which might be used to cover for the loses.
9 Each delegate monitors all matched BTCAsk and BTCbid transactions and their respective BTC addresses. Once the issuer of BTCAsk transaction receives his BTC each delegate is supposed to sign a transaction (see 5) moving BTSX specified in BTCAsk (2.1) from the issuer of BTCAsk transaction to the issuer of BTCBid transaction.
[Original Proposal End]

This should effectively allow cross-chain trustless (somewhat depending on the bond and consensus) trading. Cut off all the exchanges - they are not needed. This looks pretty good to me.

Sorry if this is too long/complex/obscured. I'll try to answer questions and provide more clarity whenever possible. However I'm in vacation and my responses could be slower.

Now I'd like to see some comments....

UPDATE: One more thing: If implemented this will remove feed requirements for cryptocurrencies. And will make BitsharesX basically global free market.
UPDATE2: Perhaps it could be better if not only delegates can be ESCROW in the above-mentioned manner. There is no reason for any account that has posted a bond to be an ESCROW.
UPDATE3: Even better would be if the BTSX from BTCAsk are held as a bond and released once a transaction from BTCBider's BTC address to BTCAsker's BTC address is confirmed. So this will symplify the whole process... Perhaps I should describe this separately.
UPDATE4: I've added updated (somewhat simpler) proposal (Maybe I should've thought it through entirely before posting...)

Could we have wallet_list_accounts to show another field indicating if a delegate has block production enabled ?

368403
     1d57020bf8042649d56d0f91ca08f451b13b1888                        init53              0       166 2014-09-01T02:24:10         0     YES                 YES
     7481ca8e6954140421a8c2a0d51e620d2db2510b                        init53              0       166 2014-09-01T02:24:10         0     N/A                  NO


Are all of them on a fork or just other failure?

Now that BitsharesX is running stable more than a month...
And we have the testnet experiencing all kinds of attacks ... (Good Job! Once again to alt)
We have also stress tested the test networks many times during the dry runs, and the networks were remarkably reliable...
We see the REAL BitsharesX network loaded below 10% of its capacity... (correct me if I'm wrong here, but I haven't seen significant transaction volume, except some isolated peaks)

I'm ready to execute a controlled "stress test" - creating significant amount of transactions to show the world what the network is capable of. (of course this was done many times on the dry runs but this is the real deal). The aim is about 0.8 transaction per second for a few minutes.
This should be done at pre-anounced time when everyone is online monitoring the delegates, the network, the seed nodes and the performance.
Perhaps this might include some network flood against some of the seed nodes and/or delegates. The entire procedure should last only a few minutes and will be closely monitored.

Of course such test is costly so the minimal transaction fee should be paid. The normal users that pay default fee should still be able to use the network normally because their transactions should be included with priority.
If this idea is accepted by the community I'll suggest this to be the first project funded by the angel fund (collected by angel delegate which is ~ 7000 BTSX ) and see if that will be approved by voters (how will this happen is TBA).

This will effectively burn the sum acquired by angel delegate AND provide proof that the network is reliable. This might give us some insights on how the network is prepared to handle the approaching waves of new users. It might also show us weak spots.

Given the relatively inexpensive nature of the test it is better to be done sooner than later.

Share your thoughts on this.

What happened?