Over the next two weeks, I'd like to work on documenting the blockchain format.  In particular, going from a block as a sequence of bytes; to fields with particular data types (uint32, hash); to semantic information about entities like accounts, balances, delegates, orders, and votes.  To keep the scope manageable, I'd like to limit my contribution to focusing on parsing the serialized blockchain.

I'll include information on the following:

- Byte-by-byte documentation of the serialized block format
- Constraints between various fields (e.g. the value in each block's parent block hash field must be equal to the value obtained by computing the hash of the serialization of the parent block).
- Reasons for design decisions
- Genesis-block parameters that can easily be tweaked
- Highlight major BitShares Toolkit features that either mimic features of other cryptocoins, or are different from other cryptocoins
- Describe in detail the implementation of high-level semantic nouns and verbs (e.g.:  What is a short position and how do you cover it?  How do we make TITAN transactions invisible?)

I'll post here with the Github URL when I start.

Also, since the bounty was posted before snapshot was taken, I'd like to ask if the bounty will include the BTSX spawned by the 500 PTS?

Hopefully this post satisfies the "scope and requirements" laid out in the opening post, and we can change from pending to active.

 

We have a really great snapshot visualization / tracking tool coming

Status on this?

A few comments on the whitepaper:

• I think it should be made clear in the whitepaper that account verifiers not only need to verify the demographic credentials of a user's account, but they also need to make sure that the account belongs to a user that has not already been counted. The paper explicitly mentions how the DAC does not allow a single user account to request multiple ballots for a particular election and how this prevents voting more than once in an election. But that assumes that the user cannot create another account for which he gets its demographic credentials verified again. Thus, to actual prevent multiple votes in an election, each account verifier needs to keep track of all the human beings they already verified and make sure before verifying another account that an account does not belong to a person that they already verified.
  
  
• It would be nice if the whitepaper went into a little bit of detail on how the zerocoin technology provides anonymity so that user's known accounts are not linked with their votes. I'm thinking metaphors not the actual cryptography/mathematics.
  
  
• I think another point that can be added to the list of benefits is flexibility in voting method. As far as I see it the VOTE DAC blockchain and network should be agnostic to the actual contents of the ballot. Anyone going through the public vote record on the blockchain who understands the rules of the election can independently determine whether a particular ballot is malformed, voting for a nonexistent candidate, or otherwise not appropriate for inclusion in the election. This allows the clients to be updated to create and interpret any future format of a ballot desired. We could have plugins added to client for all kinds of voting methods (first-past-the-post, approval, instant runoff, reweighted range voting, etc.). In fact, in order to reduce blockchain bloat, I think it would make sense to just include the hash of the ballot on the blockchain and allow anonymous uploading of the contents of a ballot on some other server.
  

These are good ideas and particularly for #3 you might want to make a separate thread for discussion.

Quote from: alt on August 01, 2014, 07:13:30 am

Quote from: testz on August 01, 2014, 05:02:46 am

Quote from: DACSunlimited on August 01, 2014, 01:23:13 am

This is a good suggestion, don't upgrade for now. 0.3.1 for delegates is coming in several minutes

Please publish 0.3.1 Windows installer.

for windows user, I think 0.3.1 is the same with 0.3.0

0.3.0 has a problems for delegates, i'm interesting for Windows 0.3.1 to run it as delegate.


Sent from my iPhone using Tapatalk

Dac Sun may release an updated Windows GUI, but be aware that we currently do not test or support running a delegate outside the Linux command line interface.

Known issue we are trying to track down the cause.

Console commands wallet_rescan_blockchain and wallet_scan_transaction may fix error in transaction list.

happypatty, please be sure to let us know if there are any stats you think we should be tracking directly in the blockchain database that would be useful. For example: https://github.com/BitShares/bitshares_toolkit/issues/580

Ever since upgrading to 0.2.3 everything works worse for me.  Wallet has issues registering accounts, transferring to myself and my delegate has started dropping blocks. 

I noticed a spike in my delegate cpu sometime after midnight last night, was also near the time my bter transfer of yesterday went through, which also killed my ability to transfer today.

Something seems odd to me....

It must be me then!

I didn't uninstall the old windows wallet when I upgraded, wondering if I should have done that?

I have multiple unregistered accounts that I can't register.  I get an error saying, "Unknown account".

Might have found the problem.  I see that the accounts I get errors on registering both end in .com

It let me create local accounts that end in .com but I think it can't register them.  Can someone confirm that?  Seems like a bug if it let's you create them with a .com but not register them.

It is not recommended to run delegate nodes using the GUI. It is untested and unsupported.

In addition, any wallet with block production enabled will by default not scan transactions, so you will not see any deposits you may receive.

Account names use the dot to signify child accounts. E.g. to register 'galt.com' you must also control the private key for 'com'.

If my delegate account issues a BitAsset, would its forging power remain the same?  I ask, because I would want BitAssets to suffer just because it is more profitable to forge (or vice versa).

We currently use the term BitAssets to refer to market-issued assets. Any account can issue user-issued assets. This will not affect delegate block production. However, please note that a wallet with delegate block production enabled will not scan any transactions by default.