1. Is it normal that serving up block is repeated so many times, and is that the output indicating that my witness is producing a block?

Yes, and sort of.  "Serving up block" just means you are telling other p2p nodes about a block.  You should get one for every node you're connected to when you produce a block (because none of them know about your shiny new block until you tell them), so you'll see a bunch of them when you produce.  But you'll also get a few of them for every block you see -- all that means is you heard about some block before some of your peers, so you get to be the one to tell those peers about the block.  You might even see a large number of consecutively numbered "serving up block" messages for a bunch of blocks in the past, if a peer is syncing from you.

None of this matters if you build from 8e96d9c89cd24a733d4838901f781af0315ec667 or later, as the "serving up block" message is removed (it is sort of spammy and not all that informative).

2. How can I check if my feeds are transacted correctly?

For now, use your account history at https://graphene.bitshares.org/#/account/spectral/overview

If you are using the CLI wallet, you can do

get_account_history spectral 10


Can anyone explain why vesting balance objects would show up differently on different nodes?  On my main active witness node (with no keys loaded into the cli_wallet I get...

This definitely shouldn't be.  It's a known bug that we're trying to track down.  Thanks for this data -- it may allow me to rule out a hypothesis about what's happening.

I think I know the basics how bitshares works, but I am still not sure from where specific bitassets came from. I know that there are 101 delegates responsible for providing information about price of pegged assets.

1. Are they providing information about all pegged bitAssets at the same time, or they are 101 delegates for each pegged bitassets?
2. How decide when to create new pegged assets?
3. How often new bitAssets are created so far?

Hi, you happen to have gotten here as we're doing a major upgrade of the system.  You may be confused by some outdated information (version 0.x), the new version we wrote from scratch (version 2.0) will address many of the very questions you're asking.  We'll switch over to version 2.0 on October 13.

In BitShares 0.x, the 101 delegates that run the network must publish price information for all pegged assets.  To create a new pegged asset, you need to convince a majority of the 101 delegates to publish price information for it.  Not many new BitAssets have been created because coordinating so many parties is a high barrier to entry.

In BitShares 2.0 (powered by the Graphene technology), we have fixed all these problems.  Anyone can get a symbol, create a market-pegged asset, and publish a data feed for that asset.  Once a feed is published, people can borrow the asset into existence like any other market pegged asset in Graphene.  (In BitShares 0.x, assets are created by shorting, which means newly created units of an asset must immediately be sold on the internal market.  In Graphene, creation (a supply operation which changes the total number of units in existence) and sale (a market operation by which already-existing asset units change hands) are totally separate, which greatly simplifies both the concept and the implementation.)

The asset object has one account designated as its owner, and another account as the feed producer.  The owner has many powers, including forcing settlement of all outstanding units of the asset or changing the feed producer.  If this provides more centralized control than you would like, the owner can permanently revoke many of his powers through the asset permission system, and the authority system (hierarchical threshold multisig) allows both the owner and feed producer to be distributed among many accounts, with consensus of a quorum required to do anything.  (How big a quorum is needed is the "threshold" part.)  The proposed transaction system allows you to use the chain itself to coordinate signing of transaction.

I admit that documentation is lacking, maybe I'll throw something together if our testnet is running smoothly and I don't have anything to do.

What is the best practice for not missing any block during an update?

The update_witness command in CLI wallet allows you to change your witness's block signing key.  This architecture allows several different downtime-free update procedures according to your specific hosting situation:

(1) Create new witness on new server with new block signing key (you can use suggest_brain_key in CLI wallet, or the get_dev_key binary, to generate a new key).  When the new witness is synced, run update_witness to change your key, shutdown old witness and delete old server.  Good method if you use a pay-by-the-hour hosting provider that lets you quickly create and destroy servers (e.g. DigitalOcean).

(2) Create new witness on the same server with new block signing key in different datadir.  When new witness is synced, update_witness to change your block signing key and shut down old witness.  Good method if you have a large server capable of running two witnesses at once (e.g. dedicated host).

(3) Create temporary witness on your own personal machine.  When it is synced, update_witness to change your block signing key and cause the temporary witness to start producing.  Then shut down the old witness and spin up the new witness on the same server; it is okay if it takes some time, because your temporary witness is still signing blocks.  Then when new witness is ready, run update_witness again to change your block signing key back (or create another new key).  Good method if you have a decent personal machine you can occasionally put on witness duty for a few blocks when you're doing an upgrade, and don't want to mess with multiple VPS's as in (1) or pay for a large server as in (2).

Also note that the block signing key can be different from the active and owner keys which control account funds.  The only key which needs to live unencrypted on a machine with 24/7 internet connectivity is the block signing key; if an attacker compromises the server, the only thing they can do with the block signing key is sign blocks.

I designed this system, and my goal was to give witnesses better options for dealing with the various IT headaches of signing blocks in DPOS.

I just gave update_witness quite a real-world test on this testnet -- I initially ran all of the init witnesses in a single process on the cloud server that I used to create the testnet, then bytemaster and I migrated a bunch of them to different machines within the first day.  In prepping them for the hardfork, I've had to shut down and re-create the witnesses, and also migrated them to better balance them between the multiple machines.  I used the update_witness command for all of this and achieved it with minimal downtime.  In particular for today's hardfork upgrade, I had no downtime on block signing during the upgrade / migration, even though I had to upgrade 8 witnesses on multiple machines, and I also migrated some of those witnesses to better balance them between machines.  The update_witness code and its supporting logic in the block production loop are rock solid!

Some of my init witnesses have been down, but that's mostly due to issues in the p2p layer, the worst of which are resolved in the latest code.

I think I'll write this up in a wiki article sometime this week

I have to look more deeply to learn more about RNG's, but couldn't you use blockchain transaction events & data for entropy?

You need some kind of commit / reveal scheme.  Otherwise an attacker would be able to control several bits by repurposing some field as a nonce and grinding it.  E.g. if Eve sends 0-255 satoshis to each of her 4 sock puppets, that's 2^32 possible blocks, and she can check which is favorable.  The attacker might need to control a single malicious witness if the block signature bytes are included directly or indirectly in the hash (only the witness would be able to check several signatures for hypothetical blocks).

We've been doing a lot of thinking about this, and the hard problem is that if the last participant to act in the protocol controls N bits of entropy, they can grind those bits for a favorable result.

In BTS 1.x this is mostly (but not entirely) mitigated by the commit/reveal process, the witnesses cryptographically commit to a hash on round K and then reveal the value that produces that hash on round K+1.  The last participant (actually the last N participants' actions where N=101 is the number of witnesses in a round) is locked to producing a block.  They still control 1 bit of entropy, however, since it is possible for them to drop out.

In any gambling game where the randomness is based entirely on blockchain entropy -- on any blockchain -- a dishonest block producer would be able to cheat fairly undetectably by making a bet, producing a block without broadcasting it, checking if they like the result of the game, then throwing away their block if they don't.  In essence allowing any player who controls a block producer to take the better outcome of 2 games which would likely give the player an edge over the house (very bad for the casino's financial viability).

It strikes me that the best way for a blockchain to "import" notions involving the real world, like "this key belongs to this real-world person," is an oracle (ID provider) approach (an oracle is an entity that answers difficult questions, in this case an entity that answers questions about the real world for the benefit of the blockchain).

We can flag an account as being "this ID provider knows who this person is" by setting the account owner to a 2-of-2 multisig of the user and the identity provider.  The ID provider's terms can specify they won't allow the changing of the account's active key to any other real-world person.  The ID provider cannot disable the account, change the active/owner authority, or take the user's funds (unless they secure the cooperation of the user or obtain the user's private keys).

In other words, we shouldn't try to implement the notion of "this account is not transferrable between real-world persons" by saying "the keys for this account cannot be changed."  Instead, we should implement the notion of "this account is not transferrable between real-world persons" by allowing an account holder Alice to make a blockchain-enforced pledge of the form "I, Alice, will not change this account's keys without the consent of my ID verifier, Vera;" and Vera uses peoples' trust based on her real-world reputation [1] to make an off-blockchain pledge of the form "I, Vera, will not allow an account to change its keys in a way that will result in the transfer of the account from one real-world person to another."

The question Vera is answering for the blockchain is whether a proposed key change is legitimate (Alice is trying to recover after her keys were lost or hacked) or forbidden (Alice is trying to transfer the account to another real-world person, which would violate her pledge).  If it's legit, Vera signs and the change occurs; if it's forbidden, Vera refuses to sign and the change cannot happen.

NB since this is a 2-of-2 multisig, Vera has zero power to change the account unless Alice agrees with the change.  Vera's only power is the ability to veto owner/active key changes for the account.

This is all supported by the chain itself already, but there needs to be some standardization (e.g. it seems reasonable to allow Vera to attach a custom transaction to attach an annotation to an account specifying a purely informational, non-blockchain-enforced document expressing the circumstances under which Vera will allow a key change; the placement and formatting of the annotation need to be standardized).  And of course UI work to express these semantics and annotations to the user.

[1] Vera's real-world reputation might include telling everyone her real-world identity; people will be more likely to trust Vera if they know she's findable and prosecutable by the meatspace legal system in case she engages in fraud.

I believe the transaction fees levied will be set by the elected delegates who collectively control the genesis account authority. So it could be cheaper if the shareholders will it to be.

This.  We're going to great lengths to make many of the parameters settable by the delegates.  In times past, some have looked negatively on changes made by the developers.  With chain parameters, we will have the technical means for many different potential changes to be implemented by the network without developer involvement, including the fee schedule.

The key to growth is user acquisition, and the key to user acquisition is incentivizing marketers to help us acquire users.  Diluting to fund this incentive is unsustainable, funding it through fees means that each individual marketer's pay is tightly coupled to performance and the system is fiscally sound (incentives to acquire new users < fees from new users).  In order for this to work, the incentive must be high enough, therefore fees must be high enough.