For the latest updates checkout my blog: http://bytemaster.bitshares.orgAnything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else. These are merely my opinions and I reserve the right to change them at any time.

Why not publish / announce it on BTT so that people can give feedback and criticize it? This might uncover overseen flaws / inefficiencies before it is put into practice. This might also draw quality people / developers to the Bitshares community if they find the approach innovative (easy way of quality recruiting) and see an opportunity within the bitshares ecosystem and community to expand on their intellectual unrest. There also was a lot of good feedback for the BTS X attack vectors...

sumantso

Why not publish / announce it on BTT so that people can give feedback and criticize it? This might uncover overseen flaws / inefficiencies before it is put into practice. This might also draw quality people / developers to the Bitshares community if they find the approach innovative (easy way of quality recruiting) and see an opportunity within the bitshares ecosystem and community to expand on their intellectual unrest. There also was a lot of good feedback for the BTS X attack vectors...

I am neutral regarding BTCtalk presence; but having more eyes to look at it can help a lot.

Lastly, proof of work creates a barrier to entry that prevents incumbents from being easily displaced. Compared to Bitcoin, DPOS is at least 10x more decentralized in block production and perhaps infinitely more decentralized relative to market competition.

Quote

The process behind DPOS when combined with TaPOS produces a network that has more provable consensus behind it than Bitcoin, Peercoin, and Nxt by a factor of 3 or more.

Those are awfully specific assertions...

Logged

Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

This is very exciting; a really promising advancement. I have some concerns about their implementation, however:

Quote

2.1 Becoming a Representative

To become a representative you must register your public key with the network and be assigned a 32 bit unique identifier. This identifier can then be referenced in the header of every transaction.

32 bits only provides about 4 Billion possible IDs. Assuming that many will be lost, forgotten, etc., I think that this is not nearly enough. This is exactly the problem that currently plagues IPv4 and is the main reason why a transition to IPv6 is currently underway. There is no reason not to use 64 bits (or even just 48) as a rep's ID, and it provides the overhead that will assure that there will be enough unique IDs for the next hundred or even thousand years. 32 bits is emphatically not enough.

I understand that only 100 reps are working at a time (but why only 100?), but since being a rep is well-compensated, I foresee that most users of a currency that adopted this system would also "throw in their hat" to be potentially voted to be a "working" rep (among the 100) - and they will all need IDs.

Quote

It may be possible for a single individual or organization to control multiple representatives in the chain, but this process would involve deceiving a large percentage of the shareholders into supporting sock-puppets.

This seems to just brush off the issue. I see no actual methods, incentives or reasons that would prevent sockpuppet representatives - after all, on the internet, nobody knows you're a dog (or a sockpuppet). The author assumes that "deceiving a large percentage of the shareholders" is somehow inherently more challenging than getting them to vote for a legitimate representative, but it certainly isn't as I can see it. Shareholders are still not going to be meeting most of these representatives in real life.

The only possible solution I can see to this would be a strong Web of Trust that can trace any sockpuppets to a common source - but since most trust signing is going to happen between pseudonyms on the internet, anyway, even this would probably just become "some silly formality" that users engage in without really understanding what they're doing, and a new sockpuppet would have no problem finding itself well validated in the web in a short time.

All in all, it's a very promising idea, and I don't think that these challenges I've described are impassible. I would look forward to a response (and perhaps even an updated proposal) from the author(s) on these concerns.

In a previous thread a requirement was mentioned for each representative having to put up some coin in holding to be eligible for this task? did you determine that this was no longer necessary?

in section "Keeping Representatives Honest", your explanation states that it would be up to the wallet software to prevent new transactions tagged with an invalid-signing-representative id. why wouldn't the network itself prevent these new transactions? Or the network could allow these transactions but overwrite with null for a representative id. if some popular wallet software had a default representative id, and this representative was coerced or somehow turned malicious, the wallet might not prevent new transactions and thus the users could all still vote for the problematic representative. I think the network itself needs to prevent this case I'm not rely on the wallet software.

Without the barriers to entry caused by proof of work, the honest majority would identify the attack and issue a fork of the code that ignored blocks produced by the attacker. It would be disruptive, but not fatal.

Sorry for my poor English and understanding. If these blocks are really ignored, what will happen to the valid transactions included in them ?

Would you implement something like how Bitcoin handles orphan blocks? (I can't find this part in PTS /Bitshares /keyhotee codes in Github)

Blocks in shorter chains (or invalid chains) are not used for anything. When the bitcoin client switches to another, longer chain, all valid transactions of the blocks inside the shorter chain are re-added to the pool of queued transactions and will be included in another block. The reward for the blocks on the shorter chain will not be present in the longest chain, so they will be practically lost, which is why a network-enforced 100-block maturation time for generations exists.

These blocks on the shorter chains are often called "orphan" blocks. This is because the generation transactions do not have a parent block in the longest chain, so these generation transactions show up as orphan in the listtransactions RPC call. Several pools have misinterpreted these messages and started calling their blocks "orphans". In reality, these blocks have a parent block, and might even have children.

For the latest updates checkout my blog: http://bytemaster.bitshares.orgAnything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else. These are merely my opinions and I reserve the right to change them at any time.

In a previous thread a requirement was mentioned for each representative having to put up some coin in holding to be eligible for this task? did you determine that this was no longer necessary?

in section "Keeping Representatives Honest", your explanation states that it would be up to the wallet software to prevent new transactions tagged with an invalid-signing-representative id. why wouldn't the network itself prevent these new transactions? Or the network could allow these transactions but overwrite with null for a representative id. if some popular wallet software had a default representative id, and this representative was coerced or somehow turned malicious, the wallet might not prevent new transactions and thus the users could all still vote for the problematic representative. I think the network itself needs to prevent this case I'm not rely on the wallet software.

After designing it out we realized that an individual has no control on whether their block gets included even when they produce on time.

It would allow the person after them to skip them and thus punish them. This risk seemed worse than just not paying them.

For the latest updates checkout my blog: http://bytemaster.bitshares.orgAnything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else. These are merely my opinions and I reserve the right to change them at any time.

For the latest updates checkout my blog: http://bytemaster.bitshares.orgAnything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else. These are merely my opinions and I reserve the right to change them at any time.