Quote from: CLains on April 09, 2015, 01:11:25 pm

Can you spell out more clearly why moontokens are valuable?

Each MOONFUND token will be bought back from the market with BTS in the future via delegate pay. For every donation you will receive 15% more MOONFUND tokens than you would BTS on a current exchange. This means that as long as the Moonstone wallet becomes sufficiently popular over the next 5-30 months you can make a return on your donation.

I'm concerned about the numbers. Let's say you put a 30 month cutoff on the delegate pay. This means each 100% delegate can only generate 3,905,560 BTS during this 30 month period. You already have 1,350,349 MOONFUND liability with only 5% funded. If we assume the price of BTS remains the same over the next 30 days, then raising $130,000 requires generating a total of (1.15 * 130,000 / 0.005399) = 27,690,313 MOONFUND tokens (assuming the crowdfunding is successful). In order to generate enough BTS to buyback the MOONFUND at a 1-to-1 rate, you would need 27,690,313/3,905,560 = 7.09 100% paid delegates (so round that up to 8 delegates). The problem will be even worse if the price of BTS continues to drop over the next 30 days.

The problem is you are offering 15% return on BTS. If BTS price is expected to shoot up in the next year or so like we all expect it will, you will be overpaying a lot! It was a much more realistic deal when the return was on the dollar amount donated.

Edit: I don't think you should change the deal now that the fundraiser has started. But you should just be clear about exactly how many delegates you plan to include in the opt-out selection for the Moonstone wallet and what your maximum cut off time is before you take the delegates down (or at least stop using their pay to buy back MOONFUND tokens). That way people can properly assess the risk of not getting paid back (or what percentage they will be paid back).

Furthermore, you should not do a continuous buyback since you cannot know if you will be able to fulfill the entire buyback at a 1-to-1 rate prior to the cut off time. In this case, the people who are fastest to sell their MOONFUND tokens will profit at the expense of the slower movers. To be fair, you should instead regularly distribute dividends to MOONFUND holders.

My wish would be for DPOS to use threshold signatures to reduce a round of 101 blocks to just a single block. Then a random number is generated every block as part of the threshold signature that cannot be corrupted unless a super majority of the delegates collude. The threshold signature would always be of the block header of the previous block in the blockchain so that this way delegates have 8 seconds to generate the threshold signature rather than 2 seconds (assuming the client is designed to stop accepting new transactions into the pending block 2 seconds prior to the block-production deadline).

I would split the 101 delegates into two disjoint sequences that are updated every block. The first sequence might be as small as two delegates, while the second sequence will be the rest (e.g. 99 delegates). Each time a delegate is replaced, the delegate that was voted out of the 101 is removed from either the first or second sequences and the delegate that was voted in is appended to the second sequence. For every block (including missed ones), the head of the first sequence (the one who should be producing that block) is removed from the first sequence and appended to the second sequence (unless it was the delegate voted out in that block), and the head of the second sequence is removed and appended to the first sequence (and this is repeated again as many times as voted-out delegate in that block happened to be removed from the first sequence). And after that, for each produced block, the random number from the threshold signature of that block is used to shuffle the second sequence.

There can also be failover blocks which do not have a threshold signature (only the signature of the block producer). In the case of these blocks, the shuffling will not be done and the blockchain should behave as if the entropy source has temporary halted (only random numbers from the threshold signature should be used as the entropy source). Failover blocks are limited in the kind of transactions they can include in the block and the kind of behavior that is allowed to execute as part of the block. Only transactions that update BTS votes are allowed in failover blocks (as a means of changing the set of active delegates who can then hopefully begin produce blocks with threshold signatures again). A regular block at the same block height as a failover block is always preferred over the failover block during fork resolution.

Define:
ITERATION_MAX1 = 41
ITERATION_MAX2 = 84
R = random_seed as uint256 integer
H(...) = SHA256 hash function
C1 = 51^44 (which is less than 2^254)
C2 = 51^6 * 51! (which is less than 2^250)

r1 = permutation selector 1
r2 = permutation selector 2

uint256 r1 = R;
for (uint k = 0; k < ITERATION_MAX1; ++k) { // Probability of continuing loop is 5.7% for each iteration assuming ideal hash function
    if (r1 < C1) break;
    r1 = H(r1) >> 2;
}
if (k == ITERATION_MAX1) {
    r1 = C1 - 1; // In the extremely unlikely event (less than 10^-50 with ITERATION_MAX1 == 41) of reaching maximum iteration, bias the results.
}

uint256 r2 = H(R);
for (uint k = 0; k < ITERATION_MAX2; ++k) { // Probability of continuing loop is 24.9% for each iteration assuming ideal hash function
    if (r2 < C2) break;
    r2 = H(r2) >> 6;
}
if (k == ITERATION_MAX2) {
    r2 = C2 - 1; // In the extremely unlikely event (less than 10^-50 with ITERATION_MAX2 == 84) of reaching maximum iteration, bias the results.
}

Then r1 defines the new locations of the last 44 delegates in the previous round, and r2 defines the new locations of the first 57 delegates in the previous round.

To actually convert these two numbers into a sequence of 101 delegate ID (vector<delegate_id> new_order), it requires a helper function with the following signature:
void add(vector<delegate_id>& new_order, delegate_id d, uint offset);
This function first assumes that delegate_id can contain a value that will not be mistaken for a valid delegate ID (for example -1) to represent a free slot. In fact, initially new_order is set to a vector of 101 -1's. The function add mutates new_order by adding the delegate_id d into the free slot reached by counting up to offset starting from the end of the vector (meaning counting in reverse order).

Using the above helper function the rest of the code is:
uint k = 101 - 1;
uint256 remainder = r1;

uint256 divisor1 = C1 / 51;
for (uint quotient; k >= 57; --k) {
    quotient = (uint) (remainder / divisor1);
    remainder = remainder % divisor1;
    divisor1 = divisor1 / 51;
    add(new_order, prev_delegate_order[k], quotient);
}

uint256 divisor2 = C2 / 51;
remainder = r2;
for (uint quotient; k >= 51; --k) {
    quotient = (uint) (remainder / divisor2);
    remainder = remainder % divisor2;
    divisor2 = divisor2 / 51;
    add(new_order, prev_delegate_order[k], quotient);
}

for (uint quotient; k >= 1; --k) {
    quotient = (uint) (remainder / divisor2);
    remainder = remainder % divisor2;
    divisor2 = divisor2 / k;
    add(new_order, prev_delegate_order[k], quotient);
}

add(new_order, prev_delegate_order[0], (uint) remainder);


Warning, I have not bothered to test any of the above code! Take this as pseudocode for the idea. Be aware of likely off-by-one errors. I also have still yet to write the add helper function but that should be straightforward. Also this is hard coded for 101 delegates. I would have to tweak it a little to make it work generally for any N delegates.

I need to calculate the "next_delegate_order" such that the minimum distance between the same delegate is N/2 the number of delegates while maximizing the entropy and mixing.

I'm not sure I understand your requirements. If the index (0 to 100) of delegate A is n in one round and then it is shuffled to m in the next round, it means that you require |n - m| >= N/2 = 101/2 = 50.5? If so that is impossible. Where does delegate at index 50 (delegate rank 51) go? The two possible maximum indices are 0 and 100, but |50 - 0| = 50 and |50 - 100| = 50, both of which are smaller than 50.5.

Also, even if you relaxed that minimum distance requirement so it was possible, you would be unnecessarily (to me) reducing the possible shufflings allowed, so that would not allow for maximum entropy and mixing. Why exactly is the minimum distance requirement important and what is the problem with the current shuffling algorithm? If there is some reason you need that requirement but don't want to say, then at least make the requirement more precise because as stated it is either inconsistent or is too vague that I misinterpreted it as an impossible constraint.

1) EdDSA
2) Changes to consensus algorithm for better lightweight validation and security (see here, here, here, and here)
3) Decentralized agents with corresponding UIA on the blockchain with support for full read access to the blockchain database state, ability to craft and sign any valid transaction on behalf of the agent, inter-agent message passing on the blockchain, auxiliary nested blockchains regularly committed to the parent blockchain, and optional forced impeachment of agent executors through UIA slate vote (aka Automated Transactions, aka Turing complete scripts, aka smart contracts, aka DApps, aka DAC extensions, aka child DACs)

We don't see PLAY or MUSIC having their own version of bitUSD.  In fact, you see them using the BitShares version.

I haven't been following Play lately, but who says they, especially Music, aren't/won't be using their own version of BitUSD? The Music blockchain isn't ready yet, so how can you make that claim? Unless there is some huge news I somehow missed, I am sure Music will have its own version of BitUSD.

I see no reason why this would not have been the case with Vote and DNS. In fact, I think it would have left it open for the market to fairly value each separate chain AND the service it planned to provide.  You also would have had people like Toast working on DNS and bringing in a team of people very passionate about one thing: Decentralized DNS.  That DAC would have funded the building of Decentralized DNS DACs that easily plug into future BitShares browsers, wallets, apps...etc.  Each would have drawn in different demographics and then as they all grew, they could start implementing feature sets employed in other DACs.  And each chain would have its own marketing delegates with their own focused message. 

Yeah that's great except they all need a stable foundation blockchain to build on and also all either need or greatly benefit from the BitAsset system as well. Bidding on domain names isn't that great when you have to account for the price volatility of your DNS token over the 30 day bid period, for example. Using BitUSD would be better. Music lovers would rather pay 99 cents for a song rather than 1500 NOTE today but then 1800 NOTE tomorrow, for example. Great so they can each have their own BitAssets except now they split liquidity across many chains making each of the BitAssets worse than they would be if they were all on the same chain.

Okay, so let's have them all use the same BitAsset as the one on the BitShares X chain. Well this is a technically tricky but doable with some trade-offs. I have discussed a way this could be done in the past and have since become a stronger and stronger advocate of this approach. But even then, it takes lots of coding and testing before such functionality would be available for use. So then core devs need to work on that. But that work is reusable on all other blockchains, so it would make the most sense for the BitShares X devs to work on that and then when it is done all the other chains can adopt that technology. And their chains aren't really 1.0 ready until that feature is ready. They can work on the other business logic of the chain in parallel though if they can get the funding to do so.

So now you have BitShares X devs working on improving the foundations of the blockchain and BitAsset system. They are improving the performance, eliminating bugs, improving the market engine, and developing the new features needed to allow other chains to use BTSX's BitAssets. How long would this take and what resources would it require? Well we know at least how long it would take all of our core devs working on all but the last thing. That is because that is exactly what they are working on right now and they are still not done. It all took WAY longer than originally promised. That's what happens in software development. Also, it basically took all of the money I3 had raised (in fact, with all the price drops, how much longer do the core devs have before their year-end bonuses aren't enough to even pay them an unsustainably low wage for their services?) and some small additional money from delegate dilution pay.

Would there be enough money available to allow them to finish that task much less any extra to devote to OTHER devs working on VOTE and DNS functionality in parallel? Where would that money come from? Crowdfunding similar DPOS blockchain related projects would likely just be taking away buy pressure from BTSX, which would reduce the delegate dilution pay for the core devs working on the foundation of the blockchain. We are a small group and not growing fast enough. But to grow fast enough we need a compelling product to sell to others who haven't bought into the vision yet. That means going after the really high value services and providing those services in a very high quality way. A decentralized exchange on a very robust platform with a fast lightweight client that looks beautiful and is easy to use is what is required. This is part of the foundation that other DACs depend on. It makes no sense to waste limited resources (money and dev talent) on things that are not going to grow the token's value fast enough. We need the token value to grow because that is the source of revenue to pay for more devs who will then be able to work on many interesting different blockchain services and features in parallel.

So the way I see it, the economics of the situation would have forced DNS and VOTE to languish anyway until enough of the BitShares X foundation was built. What is worse is that they would have avoided paying for the cost of the foundation that they use since the dilution would have been for BTSX only and not of the other DACs' tokens. I think the BitShares ecosystem would have not looked very differently in terms of functionality available or user adoption at this point in time, and I would even say we would have most likely been worse off than we currently are.

At this point, I think we just need to finish getting the core blockchain technology and the client software polished to get user adoption to increase and hopefully have the price of BTS increase, and then use those extra resources paid for through delegate dilution of the higher BTS price to build the functionality necessary to allow third-parties to concurrently build DApps and/or child DACs on the BitShares platform with minimal effort while using BTS's BitAssets and even leveraging the consensus/networking systems of the BTS blockchain (basically "Turing complete scripts" but done by allowing the validators or "child DAC delegates" to run arbitrary sandboxed executable code that implements the business logic of their DAC/DApp and uses the BTS blockchain and optionally their own nested blockchains, which are committed to the BTS parent blockchain, as the persistent data store for their DAC/DApp). Once this foundation is set, my hope is that we can have developer resources explode and see many third-parties concurrently working on new features like prediction markets, bond markets, voting, DNS, etc.

Based on the outcome of the poll we have decided to denominate the buyback in terms of BTS. This means that for every BTC you send in the price will be converted into the equivalent in terms of BTS at the time of donation, and you will receive 1.15 Moonstone tokens for every BTS equivalent you donated.

How about giving the user two tokens for every BTS worth of BTC donated rather than just 1? For every 1 BTS worth of BTC donated, the donor would receive 1 MOON.A and 1 MOON.B. You would first use the delegate funds to buy back MOON.A with BTS at a rate of 1 MOON.A = 1.05 BTS. You would not buyback MOON.B while you still have less BTS in reserve than 1.05 times the amount of outstanding MOON.A yet to be bought back and destroyed. Take the average price of BTS (in USD) over the past week at the time enough BTS has been raised from delegates to be larger than 1.05 times the outstanding MOON.A supply and call that price P USD/BTS. If the total amount of MOON.A originally created as part of the crowdfund (call that S) multiplied by the price P is sufficiently greater than USD value of the crowdfund (for example 1.05 * S * P > 150,000), then you would not need to buyback MOON.B and could instead simply retire the delegates. This means that if someone simply holds their MOON.A until all of it can be bought back for BTS, the maximum dollar value percentage gain of their BTS holdings from the time of donation to the time of buyback would be 15.4% (similar to what it was before when you wanted to do the 1.15 UIA per USD donated scheme).

However, if you buyback all of MOON.A but the price P is not high enough to satisfy the inequality 1.05 * S * P > 150,000, then you can begin the buyback of MOON.B so that donors can continue to receive some interest on their BTS. Actually instead of starting the actual buyback after enough BTS is collected to buy back all remaining MOON.A, you would instead start a stage 2 in which another reserve is allocated (which contains R BTS, where R grows over time as more delegate funds are added to the reserve) for the eventual MOON.B buyback. Stage 2 ends as soon as 3 years elapses since the start of the crowdfund or R * (the 1 week moving average price of BTS in USD/BTS) > (150,000 - 1.05*S*P), whichever happens first. After the stage 2 ends, the delegates are retired and the buyback of MOON.B begins at a rate of 1 MOON.B = R/S BTS.

The end result of all of this is that if amount of value raised by the delegates within a 3 year period can reach $150,000, then donors will get back their USD value (via BTS) that they donated with at least 15% interest (and at least 5% return on BTS donated). If 3 years passes without generating enough value, then the donors will obviously get back less money. However, there is no defined time limit on at least paying back the BTS donated (with 5% interest), assuming the delegates can stay elected long enough that is. This means if BTS value increases a lot, the donors will get paid back sooner (less than 3 years) and in this case they will always have more BTS then they started with (at least 5% more) and they will have at least 15% more USD value than they started with. If BTS value continues to stagnate or even drops more, then it will take much longer to get paid back and the returns will be less. If it takes longer than 3 years, then the donor will receive less than 15% additional USD value than they started with (perhaps they will even lose USD value), although they will most likely still get back more BTS than they started with (5% more, but over a period that is potentially indefinitely long).