Quote from: alexkravets on July 26, 2014, 06:44:15 am

Perhaps a naive suggestion to address this. 
What about a small area inside the blockchain metadata for this ?

If the blockchain itself records delegate ID's and a few small past-performance parameters ?

The blockchain already has information about the missed blocks. I think this is enough as a start, I'm building some tools to help visualize that.

Enough for which purpose ? If entire security and performance of DPOS depends on behavior of delegates, seems like keeping a trust-free historical audit inside the blockchain would be useful.

One use was already pointed out in this thread, which is to allow defaulting to a sound voting slate of most reliable delegates sporting the smallest pay rate ?

How many BTSX should be allocated for each PTS coin held on Feb. 28th ?

I heard 644, when inspecting the genesis block found her https://raw.githubusercontent.com/BitShares/bitshares_toolkit/master/libraries/blockchain/genesis.json

I noticed that for each PTS coin I would receive roughly 322 BTSX or half the expected amount.

If PTS holders are entitled to 50% share and there were roughly 1,552,000 PTS coins in existence on Feb 28th, shouldn't each receive 644 ?

What gives ?

Probably same issue here.

I tried running

wallet_import_keyhotee <firstname> <middlename> <lastname> <brainkey> alexkravets

With my middle name being "" since my keyhotee profile does not show a middle name and brainkey being the password that unlocks my keyhotee profile and I get this:

10 assert_exception: Assert Exception
false: Account name is already registered under a different key
    {}
    bitshares  wallet.cpp:1228 bts::wallet::wallet::add_contact_account

    {"account_name":"alexkravets","key":"BTSX6T8eyWMsBcnUecwRLP7Uy11TJd5dybGvhbujSuvgHxDqa3u9av"}
    bitshares  wallet.cpp:1258 bts::wallet::wallet::add_contact_account

    {"account_name":"alexkravets"}
    bitshares  wallet.cpp:1425 bts::wallet::wallet::import_private_key
error creating private key using keyhotee info.
    {"firstname":"Alex","middlename":"","lastname":"Kravets","brainkey":"XXXXXXXX","keyhoteeid":"alexkravets"}
    bitshares  wallet.cpp:3644 bts::wallet::wallet::import_keyhotee

    {}
    bitshares  common_api_client.cpp:675 bts::rpc_stubs::common_api_client::wallet_import_keyhotee

    {"command":"wallet_import_keyhotee"}
    bitshares  cli.cpp:540 bts::cli::detail::cli_impl::execute_command

If such an algorithm existed I would be very interested in it.

Latest newsletter http://goo.gl/I7r1mM says that Ripple-style consensus will be replaced with an earlier tweaked TaPOS.

Is there a version of TaPOS that solves the centralization-one-block at a time problem that all block-chain systems face ?

(Any miner who solves a block has a window to insert arbitrary transactions to front-run the market while removing transactions that would go against him).

Dan,

After I saw your remark about once-block-at-a-time centralization that all chains face (you too ethereum) I thought that was gonna be enough to not consider block-chains for a decentralized market ...

Your previous concerns about Ripple style consensus have all been debated and put to rest by the Ripple community almost a year ago.

There IS one issue which is a Ripple-like consensus system DOES start centralized (but already much less so than ANY chain with top 3 pools having 50% hash power) but over time decentralization is inevitable as more nodes join and users choose to customize their UNL lists.

N^2 growth in traffic objection as N nodes join does not apply in practice because nodes only exchange messages between low and high watermark of local peers not everyone.

Perceived lack of incentive to participate for nodes is addressed by two thing:

1. Running a consensus nodes is a constant near-zero cost and keeps falling with moore's law.
2. Running a consensus node benefits the owner in various secondary ways (lower latency access to network, etc) which should be plenty enough for brokers, banks & market makers to do.

Cheers ...

TL;DR: How does modified TaPOS address the centralized-one-block-at-a-time problem ?

Good to see this going in house. This tells me things are getting serious at Invictus.

I only would like to caution against the temptation to de-APIify it and commingle it with BitShares domain.  If it's impossible to build a decentralized DropBox replacement DAC just as easily as it will would be to build BitShares on top of it then it's become an internal BitShares implementation artifact.

Sorry, I meant my post as a clarification for bounty takers.

C++ is not my forte, but my impression after looking at

https://github.com/ripple/rippled

Is that although the entire code base is pretty large, the core domain-independent consensus part is under a thousand lines and should be extractable, however thankless task that maybe :-)

Cheers ...

Sign me up


Sent from my iPad using Tapatalk

I have looked into Ripples algorithm and that is the fallback... I still do not like the Unique Nodes List...

Yes, it took me a while to wrap my head around the concept too, despite being advertised as trust-free Bitcoin and all other blockchain-based systems which are pool mined ( which is an unavoidable outcome of competition ) actually all have One Giant Unique Node List today, namely ALL Bitcoin users trust top handful of pools not too collude and none of them to become too big.

What ripple does differently is to formalize exactly what such trust entails, namely only not to conspire and unlike Bitcoin, any node gets to maintain its own, not necessarily pulicised ensures that no Sybil attacks or conspiracies are feasible not only because they are exceedingly unlikely, but also because all consensus proposals must be signed by nodes private keys, any attempt at validating invalid transactions or omission of valid ones leads to immediate smoking-gun incontrovertible evidence against attackers at which point they can be dropped automatically from everybody's UNLs

Key difference is that unlike in Bitcoin, participating nodes have key pairs which must be used and which provide strong reputational naming fir the rest of the network, compare to any other coin, where participating nodes are essentially fully anonymous and therefore have many more ways to misbehave.

Meta remark: One of the attractions of the DAC concept is that it's a much higher level layer "application software"
Just like meatspace corporations can change their physical infrastructure, a DAC should be abstracted away from its consensus level "wiring" its operating activities should use higher level primitives and not be commingled with low level p2p consensus.

Should we call it VDAC for Virtualized DAC ?

I'm thinking of creating a "consensus isolation layer" akin to to hypervisor between a collection of DACs and underlying "hardware of consensus" from this point of view for example, Ripple is a cross currency, distributed market based payment DAC *commingled*  with a cryptographically secured p2p avalanching-consensus-based database toolkit.


Sent from my iPad using Tapatalk