I would like a comprehensive description of delegates and their role

[santaclause102]

I'm quite impressed with your very methodical approach

The voting process is simpler than you imagine, you get P votes for each delegate, so your total voting power is simply P*101. Here's a quote from BM on the topic in another thread:

With approval voting each individual can approve up to 101 delegates with their stake.  If you don't approve of a full slate (101) then you are effectively abstaining with 90% of your voting power.

Thanks cvk, I really appreciate that!

Couple of followup questions:

1) Regarding what you quoted BM saying, why did he say 90%, and why is it irrespective of how may delegates less than 101 I may choose not to vote for?

2) Can you confirm if these statements are correct:

Bitcoin minors simply look for the next prime number in a sequence (based on the agreed upon algorithm) and the first miner to find it and use it to encrypt (or sign) a transaction block is awarded the number of bitcoins for that era of the award schedule (50 initially, then 25 etc).

Bitshares delegates don't have to solve a CPU intensive task and race to sign a transaction block as with bitcoin. Rather, one of the 101 delegates is chosen in a random sequence to sign the next transaction block. The 101 delegates are chosen by popular vote of the DAC shareholders.

The 90% is based on this https://bitsharestalk.org/index.php?topic=8934.msg115820#msg115820

Your two statements are basically correct. Gamey clarified the POW in Bitcoin.... It is true that some problem that takes a lot of hashing power (when there are enough other miners competing with you to solve it) has to be solved in order to become the one who produces the next block and gets the block reward.

Another difference of Bitcoin's current POW and BitSharesX' current DPOS is that in BTSX delegates are completely paid by tx fees which come from those who use BTSX. In Bitcoin atm more than 99% of the pay for miners come from newly issued bitcoins, this effectively is an inflation of the bitcoin money supply. The dilution rate is about 10% per year. This can be analyzed like here https://www.youtube.com/watch?v=7mwmlJICyRA

[gamey]

1) Regarding what you quoted BM saying, why did he say 90%, and why is it irrespective of how may delegates less than 101 I may choose not to vote for?

2) Can you confirm if these statements are correct:

Bitcoin minors simply look for the next prime number in a sequence (based on the agreed upon algorithm) and the first miner to find it and use it to encrypt (or sign) a transaction block is awarded the number of bitcoins for that era of the award schedule (50 initially, then 25 etc).

Bitshares delegates don't have to solve a CPU intensive task and race to sign a transaction block as with bitcoin. Rather, one of the 101 delegates is chosen in a random sequence to sign the next transaction block. The 101 delegates are chosen by popular vote of the DAC shareholders.

If you only vote for 90% of the 101 delegates, then that means ~10% are not receiving your approval.  So your vote is only 90% of its maximum effectiveness.  This is a big problem with the voting system right now.  I've been trying to find a trusted member to create a list of delegates with factors that are not empirically observed from blockchain/performance.  It is these types of metrics which will likely be more important in determining actual security as it protects from sybil attacks.

Bitcoin miners don't use prime numbers.  They look for hashes with enough leading zeros.  Regardless, your general throught process is correct.

Your second statement is accurate IMO.

[tonyk]

svk...

[Thom]

I'm quite impressed with your very methodical approach

The voting process is simpler than you imagine, you get P votes for each delegate, so your total voting power is simply P*101. Here's a quote from BM on the topic in another thread:

With approval voting each individual can approve up to 101 delegates with their stake.  If you don't approve of a full slate (101) then you are effectively abstaining with 90% of your voting power.

Thanks cvk, I really appreciate that!

Couple of followup questions:

1) Regarding what you quoted BM saying, why did he say 90%, and why is it irrespective of how may delegates less than 101 I may choose not to vote for?

2) Can you confirm if these statements are correct:

Bitcoin minors simply look for the next prime number in a sequence (based on the agreed upon algorithm) and the first miner to find it and use it to encrypt (or sign) a transaction block is awarded the number of bitcoins for that era of the award schedule (50 initially, then 25 etc).

Bitshares delegates don't have to solve a CPU intensive task and race to sign a transaction block as with bitcoin. Rather, one of the 101 delegates is chosen in a random sequence to sign the next transaction block. The 101 delegates are chosen by popular vote of the DAC shareholders.

[svk]

I'm quite impressed with your very methodical approach

The voting process is simpler than you imagine, you get P votes for each delegate, so your total voting power is simply P*101. Here's a quote from BM on the topic in another thread:

With approval voting each individual can approve up to 101 delegates with their stake.  If you don't approve of a full slate (101) then you are effectively abstaining with 90% of your voting power.

[Thom]

Now that I'm a shareholder I feel the need to ramp up my understanding so as to make informed decisions, such as how to select delegates. I've discovered the bitshares wiki on github and am reading up there. I'm also studying the topics on wiki.bitshares.org.

Given the rapid pace of development "getting up to speed" is a moving target. My current level of knowledge is fairly low (releative to this community) so the dated materials shouldn't be much of an issue for me, and I plan to tune in to the mumble media and stay abreast of bleeding edge changes and what's coming down the road. I just watched Patrick Byrne's keynote address video at the bitcoin conference in the Netherlands, and an interview with him on Audio Triangulation. Loved both of those, really excellent talk.

I'm particularly interested in the delegate selection process, and just what factors are important to consider in choosing delegates to endorse with my votes. Until I feel I have a good handle on things I'm not intending to be an active trader, more of a sit & hold shareholder. Nevertheless, selecting delegates is one responsibility all shareholders have, and I take it seriously enough to be informed so as to make wise choices.

I find the bitsharesblocks.com webpage intriguing and informative. But before I can make informed decisions about 101 out of 881 voting delegates to choose from, I want to thoroughly understand the mechanics of exactly what the blockchain is, what a bitshares transaction is and how a delegate affects those elements.

I think a small relevation just occured to me: bitcoin minors simply look for the next prime number in a sequence (based on the agreed upon algorithm) and the first miner to find it and use it to encrypt (or sign) a transaction block is awarded the number of bitcoins for that era of the award schedule (50 initially, then 25 etc).

Bitshares delegates don't have to solve a CPU intensive task and race to sign a transaction block as with bitcoin. Rather, one of the 101 delegates is chosen in a random sequence to sign the next transaction block. The 101 delegates are chosen by popular vote of the DAC shareholders. Precisely how the full voting power of each shareholder (whose strength is proportinal to the number of shares in the DAC they own, i.e. is relative to their stake in ownership) is used to vote for 0 to 101 delegates I have yet to understand.

Lets say shareholder S has voting power P between 0.0001% to 99.9999% of the stake (owns P% of the stake). S can vote for 0 to 101 delegates. Is the strength of his vote for each of the 101 delegates equal to P / 101? If S only voted for a subset of the 101, we'll call that N, would the strength of his votes for each of those delegates be equal to P / N ? Are the votes applied equally for all delegates or if S only votes for 10 delegates can he choose to back 8 candidates with 5% of P, and 20% of P for one and 75% of P  for the other?

The delegate voting system is where I get confused, assuming I understand the other aspects correctly as I described above. My study continues...

[Thom]

  Thanks guys, your answers are helpful. Every bit helps build my understanding!

[svk]

I am indeed only using the client and it's RPC calls to extract the data, but as you've noticed information like number of users (accounts) per day or delegates etc isn't directly available. I get that kind of info through my own database, but that database only contains data from the client.

[tonyk]

Too many questions for me... Let me try to answer some of them  with my low pay grade...

You seemed to misunderstand. I never said or implied that anything was secret; I was only speculating about the code base required for delegates to fulfill their role. What you seem to be saying if I understand you correctly is that all of the functionality required to sign transactions and do everything on the bitshares network - examine blocks, get delegate stats, find users, send shares to other accounts etc etc, are built on a single toolkit. The same toolkit everyone has at their disposal is what svk used to obtain the info on his BitsharesBlock website. It's the same toolkit the client app is built upon.

Yes

[Thom]

I am not aware of any 'secret' or delegate-only code in Bitshares X.
Now, *svk has done his share of coding to make this site, but the basic functionality comes from the  BTSX client itself...

You seemed to misunderstand. I never said or implied that anything was secret; I was only speculating about the code base required for delegates to fulfill their role. What you seem to be saying if I understand you correctly is that all of the functionality required to sign transactions and do everything on the bitshares network - examine blocks, get delegate stats, find users, send shares to other accounts etc etc, are built on a single toolkit. The same toolkit everyone has at their disposal is what svk used to obtain the info on his BitsharesBlock website. It's the same toolkit the client app is built upon.

That is good to know. If I want to get into those details I'll turn my attention to code development discussions, presumably found elsewhere here on this forum.

My only interest in such technical underpinnings right now is to understand how things work, in more detail than most discussions but less detail than looking at lines of code. I'm looking on the net now to find such intermediate info or possibly a bitcoin developer that could answer some of these basic blockchain oriented questions.

I do need to be cautious however b/c of the significant architectural differences between the bitcoin and bitshares networks. It might therefore be better to find someone like svk to discuss such things with, but I probably need to refine my questions and focus on specific things starting at the top and working my way down in detail.

I will state my apologies in advance and ask, is there a better place to be posting such questions? I don't wish to become a PITA as I learn this stuff. Fell free to point me elsewhere if you think my newbie questions are too basic or are already answered elsewhere.

Regarding the DPOS paper / website Daniel published on April 3rd linked above, I have some questions that span the range of the higher levels of abstraction down into lower (code oriented) levels.

In the background paragraph Daniel says there are two problems to solve: 1) selecting a unique node to produce the block and 2) making the ledger irreversible.

For bitcoin, producing a block is a computational algorithm of work performed by the miners. My understanding is that work is finding the next prime number in a cryptographic sequence such as SHA256 or SHA512 for example. How finding that relates to a transaction I'm not sure exactly.

I hear discussions that give me the impression transactions and the prime number searches are entirely separate things, yet other discussions where the prime number found is used to "sign" transactions. Does signing the transaction just mean to encrypt it with the prime number key? Is a signed transaction the same thing as a block on the blockchain, and the word blockchain and ledger are synonymous terms? If the transaction is encrypted (and thus it's contents private) does the blockchain include metadata for public info to support messaging, account registration / delegate info etc?

I'm pretty sure what Daniel is referring to when he says "selecting a unique node to produce the block" is what the delegates do in DPOS or who comes up with the longest series of signed transactions in the bitcoin network. The irreversibility problem relates to how much effort is represented by each subsequent transaction, such that going backwards in the chain to unlink those transactions essentially becomes impossible. Is my understanding of this correct?

[tonyk]

I am not aware of any 'secret' or delegate-only code in Bitshares X.
Now, *svk has done his share of coding to make this site, but the basic functionality comes from the  BTSX client itself...

[Thom]

If you are anywhere near IT, you should not be afraid to run the client and execute commands in it...That's just my way of thinking...I am no pro in that field though.

I'm not afraid to do that, it's an interesting suggestion. I've looked briefly at the console and list of commands and it is quite large. It would be a rather tedious way to learn. I've got decades of SW development and some IT experience. The BitharesBlocks website has info that seems to come from a vantage point not available to client nodes. I could easily be wrong but in my mind there seems to be 2 major pieces of code: 1) the client node software, currently version 0.4.15-a and code used by delegates to sign / create transaction blocks.

If all of the info on the BitharesBlocks website comes from the same version 0.4.15-a client software I'm running (using python scripts or API calls available in the client), that surprises me. It doesn't shock me, just not the picture of the code architecture I had envisioned. That's the reason for my questions.

[tonyk]

If you are anywhere near IT, you should not be afraid to run the client and execute commands in it...That's just my way of thinking...I am no pro in that field though.

[Thom]

Which part of the data?

Only 4 account / user is an assumption. As the post clearly states so.

Which part? all of it. I see the assumption in his post, but what produced that data? Is it a forensic analysis of the blockchain, an instrumented version of "mining" code or what? I had a question above that hasn't yet been answered about the software used by the delegates to sign the blocks. That's a possibility in my mind for where this data might come from, that and the blockchain itself.

It may help me to visualize exactly what the data structure of the blockchain actually is. I'm a SW dev so I understand such things, tho I realize those tuned into this thread may not be.

I'm somewhat confused, as the website you pointed me at (BitsharesBlocks) has lots of info that I didn't think existed on the blockchain alone, like the list of "new users".

[tonyk]

Which part of the data?

Only 4 account / user is an assumption. As the svk's post clearly states so.