Quote from: abit on February 14, 2016, 11:20:33 pm

@tonyk what do you think if I develop this and launch a testing network? Will you lead the testing work? And what do you think is the best approach?

1.I think it is very unlikely 'BTS main' to simply jumps into this new direction itself. Nor I am saying it should - I just see a ton of benefits if it does. Others have pointed concerns. Concerns with various degrees of seriousness. I have yet to see any outweighing the positives, but it is just one man's opinion.

2. I do not see a test chain having any way to prove one way or the other if this thing works. At  the end, We are mainly testing market incentives; and with test-chain where such  incentives are removed  I do not see the experiment working.  What I see is  a new chain testing the theory. I mean a full blown chain of its own, even if its init status matches BTS share distribution 1:1.

If we developed the new features, we need to test the functionalities first, right? So that's what I said "testing". If it doesn't work at all, for example crashes once a hour, it's not possible to launch a real chain. When to release a real chain, or how to , is another story.

3.Assuming we more or less agree on p.2 - It was truly amazing how you have seeming excelled at Graphene code. Especially amazing was the speed with which you did the '*poor man's bandwidth fees' feature [Do not get me wrong - I called it poor man's because it is lacking the stuff that reduces the usage at high tx times (or increases the fee at such times) and paying the fees by locking funds in the future in order to earn fees post factum. On the opposite - they way you did it - aka keeping the fees and just earning them by having a balance for time X, is much closer to what I believe is better (for this proposal purposes and in general)]. So even that the feature (changes) to the existing code I have proposed so far in this thread seem to be just 2-3 times more work than what you have done (coded) for bitshares already, my biggest issue remain funding this new chain. And while I am willing to do what you call testing for free [I am not very sure what will I really test, as I am not much of a coder. So it will be more like running the code as a user and seeing if it works, more than true testing]

Yes, you proposed the features, you should know what you want better than anyone else, so you're the best one to check whether it works like you want, the more comprehensive, the better. I mean this kind of testing. You don't even need to run the code, I or other volunteers (if we have) will. I think I didn't say "for free". Yes, it would be a new chain, we, the founders, will have all rights reserved, except that some social consensuses (if any) and legal limitations (if any) that we need to follow.

So wile I and seemingly you are ready to start working on this for free, I would feel much better if we had some more solid plan regarding the future financing of the project. While "if it starts successfully, we can later on run workers on the dShares" is a plan, but a plan not good enough in my oppinion. And not because I have wasted my own time, but more because I have not given the project enough chance to succeed. In particular I do not consider just diluting Bitshares [or dShares] by worker proposals 'financing the development'.

I'm going to set default witness pay and the cap of worker payment to zero. Or maybe change related code entirely. My idea is to pay what we're able to afford, or say, pay from income. Pay by ourUSD but not shares. If no income, no payment. Will you accept this? Anyway we define the rule first (at least before asking for any external fund). Less change is better.

For me it should work something like this - real investor  is found. He pays the devs in cash (so they can live). The worker proposal is for ( actual cost to develop * 1.33 ) and the worker pay is locked (for 1.5-2 years; ); the investor recieves those new shares after said 1.5 year. Selling those worker pays in the DEX in some sort of "Worker Backed Assets" is a interesting possibility, but then again the feature itself requires development (money) in itself.

This looks like a good idea. I haven't totally thought through it though. It's not urgent imo, unless you need to fund yourself in this way.

* 'pragmatic man's approach' is probably a better term - it cuts the fancy [and more difficult to implement] and not particularly useful stuff out; while also keeping the possibility to pays the fees directly.

Anyway, those are some of my current thoughts. Your (and anybody else take) on those issues is welcomed.

Looking forward to hearing more from you. Maybe PM?
Thanks!

@abit:

Great work!  Just wondering if you've made any progress with dynamic adjustment based on load?

Won't do that in the near future.

It's not OpenLedger that is able to hide or show your orders to others, BitShares (the backbone) is. Right now everything is transparent.

If you don't like OpenLedger, you can run a local node which connects to the backbone, and run a light client which connects to your local node. See http://docs.bitshares.eu/bitshares/tutorials/full-node-usage.html

@fuzzy can you make the topic longer when posting a new thread next time? I always ignore the posts if nothing can be get by reading the topic alone. Time is money, my friend.

//Update: the idea in OP is interesting.

Quote from: abit on February 15, 2016, 03:47:32 pm

Good job  , finally you published something out.

I'd recommend that you run a performance test for example on following code:
https://github.com/pureland/bitshares-2/blob/baaa44d920bd010a5344c164ae61ea76ffff3323/libraries/chain/db_balance.cpp#L44-L56

Code: [Select]

vector<pair<account_id_type, share_type>> database::get_balance(asset_id_type asset_id) const
{
vector<pair<account_id_type, share_type>> results;
pair<account_id_type, share_type> result;
auto& index = get_index_type<account_balance_index>().indices().get<by_asset>();
for (auto itr = index.find(asset_id); itr != index.end() && itr->asset_type == asset_id; itr++)
{
result.first = itr->owner;
result.second = itr->balance;
results.push_back(result);
}
return results;
}

IMO std::vector will kill performance.

thank you 
I would change a way ,
like a multiple transfer ,  a transfer send to many user
it would take more spare of chain ,but small cpu time
consider account id take 8B, and shares also take 8B,  it mean increase a receiver of a transfer , it just increase 16B  ,
if a transfer send to 10,000 accounts , it is just increase 160KB apace , it is not too much .
if want to reduce the space more ,
1.2^32 is a big value , and now there are only about 100k account ,so in a multiple transfer ,use 4B to record account_id, and also use the small apace to record shares
2.set two parameters
   account_id_length  and share_length
   to define how many bytes acount_id take and how many bytes shares take , it would reduce to 8B for one receiver increasing in  multiple transfer.

So you have thought about data transfer and data storage. That's good.
But that's not enough, we also need to think about CPU and memory.

Quote from: xeroc on February 15, 2016, 03:34:44 pm

wow .. awesome progress these days ...

One thing though: could you please fork from github.com/cryptonomex/graphene instead of bitshares? That would make it way easier for me to run code like this on the testnet!

if it is a worker on bts chain , I think it is reasonable that fork from github.com/bitshares.

Looking forward to seeing your worker proposal

熊熊最近很活跃啊。上车了？

你应该详细写下这个资产以前的收益 怎么回购之类的

看这贴 https://bitsharestalk.org/index.php/topic,17175.0.html

//更新：抱歉，刚发现链接没贴进来。晕。

Nice UI