Topic: [Announce] Project Quixote - BitShares, BitNames and 'BitMessage' - page 13. (Read 48303 times)

How about if miners are tumblers wouldn't that solve the problem to great extent?

https://bitcointalksearch.org/topic/coinjoin-bitcoin-privacy-for-the-real-world-279249

BitUSD and BitGold are what we are betting on.    Diversification is best.

I am very interested in any improvements that could be generated.  To see my current algorithm which is generic and self-contained:

https://github.com/InvictusInnovations/BitShares/blob/master/src/blockchain/blockchain_time_keeper.cpp

The test I used to simulate behavior:

https://github.com/InvictusInnovations/BitShares/blob/master/tests/timekeeper.cpp

My algorithm only works assuming the growth in hash power is not continuous and that there are periods of time with steady or decreasing hash power which gives the algorithm enough time to correct.

We would need to estimate not only the current hash power, but the median rate of change in hash power.   The challenge is avoiding over-corrections that cause large oscillations in the median error.

Perhaps use Newton's method or gradient descent rather than assuming a Gaussian, steady state.

Off-chain is where I create a transaction with 3 inputs from me and 3 from you.  I sign it, send it to you, you sign it and broadcast it to the network.   These types of transactions will be cheaper than using the built-in block chain for bids and orders. 

That my friend is a problem I spent days on before coming to a workable solution.   So here it goes:

Given a known genesis time, you can calculate the 'expected time' of block N based on the target interval I as   G + N*I.

Given the last 2 weeks of blocks, and the timestamp included in the block, it is possible to calculate the 'median error from expected time'.

If the median error from expected time is positive... we are producing too fast, set the target interval to 1.05 * I
If the median error from expected time is negative... we are producing too slow, set the target interval to .95 * I
If the median error is accurate within a safe range then keep the target interval at I.

Combined with a continuous adjustment of difficulty based upon the following algorithm:

Current Difficulty = median difficulty of last 4096 blocks (about 2 weeks).
Next Difficulty     = current difficulty * target interval / median_interval

On a purely random basis (steady hash power with normal distribution of times proportional to difficulty) this algorithm keeps the max median error from expected time less than 12 hours after decades of simulation.
In a system with increasing hash power the clock should skew, but will correct when the growth rate stabilizes.   This algorithm should also adapt continuously and thus minimize the area between the target difficulty and current hash power producing a graceful curve.   Once the clock skews to much as a result of increasing hash power, the sudden increase in difficulty by 5% should limit the damage.

The key here is that the target should not be off by more than a day or 2 max.  Combined with a hash algorithm that is limited to scaling with CPU and no huge ASIC style jumps and we can hopefully keep the block rate production within much tighter tolerances than Bitcoin.

I don't see what time has to do with it, unless you are thinking of what you wrote below.


What is this off-chain signing?


Yeah merging can be solved that way, yet it is the forking due to giving change that can't be delinked. Nearly every transaction involves giving change.

Also your merging solution isn't so solid if paying to a merchant whose incoming address are well known.

Bottom line is that the blockchain is subject to traffic analysis. Very difficult to avoid.

Every new altcoin has to have a killer feature, else it has no chance of gaining traction.

It seems you all are betting your initial effort on the BitName and Messaging features. I don't think those are the killer feature.

When looking to buy a car, I am not so interested in whether it has a communications system. I am more interested in the features of the car.

It is safe to merge outputs that haven't been merged in a while.  This is particularly true when you consider 'off-chain' option/bid/ask negotiations where two different people both sign a transaction rather than let the miner do it.  If this occurred on a regular basis then you could safely merge inputs/outputs without it correlating with a high likelihood of you owning both of them.  

My thinking was that after a coin had ping-ponged back and forth without merging for 4 or 5 transactions you can safely merge it.

A large transaction would be comprised of many smaller transactions thus, if I wanted to send you $100 but only have outputs of $5, $20, $10, $50, and $15 then I would broadcast 5 independent transactions to you without having to exchange 5 addresses.   Spread out the broadcast of those transactions over 10 minutes and it would be hard to correlate them.

How can you fix this?

Hierarchical Deterministic Wallets don't solve the problem of needing to combine change from several keys into one spend. So it seems to me your claim of "never" above is incorrect. Every user is going to end up with small balances in their keys at some point and need some way merge them.

https://bitcointalksearch.org/topic/coinjoin-bitcoin-privacy-for-the-real-world-279249

I read in the white paper.


Forcing old transactions to send to a new key every year, doesn't do much to reduce the size of the block chain. I don't know why you think it does?

Is that and cross-chain the only ideas you have for scalable blockchain?

I also saw this:


But if you don't limit the number of keys that users can have, then you can't compress the ledger to a fixed size.


Ah so you arrived at the same solution I did, which is you must limit the number of keys users can have?

Agreed that scales better. I didn't realize Bitcoin has scripting for transactions. Are you including Script? Have you considered including CoinWitness (or Microsoft Research's Pinnochio), given gmaxell says Script is currently "mostly unused" in Bitcoin, then maybe experimental isn't so risky? Probably not realistic, but future-proofing is a thought.

If BitAssets can reliably track designated assets, then it may not be necessary to cross-chain if all one wants is the store-of-value and not some features of the other chain, just hold the proxy in your chain. Secure atomic cross-chain will be useful when you don't trust the exchange, e.g. an individual.

OK, can you at least say whether or not the planned return on investment involves mining. If it is from just selling mobile apps or other interfaces and services, it doesn't affect my plans, but if it involves deploying preconfigured and optimized mass CPU power to mine at the very start then it would have a large impact.

Yes, it's very important to have it setup that the mining algorithm can be changed. Just look at https://en.bitcoin.it/wiki/Prohibited_changes to see how difficulty this is, if you don't plan a change ahead.

Current hash power would never vote to give up their power. Therefore it is much better to use proof-of-stake to vote for protocol changes or parameter changes of the network. Anyway, the value of the network ultimately stems from the stakeholders who define the market capitalization of the coin. So they should be the ones who should be able to vote for a change of the mining algorithm. If this isn't defined in the beginning, then it is hard to argue for a change later on, when the coin is running.

So why not code it modular with maybe scrypt (50%) AND hash256 (50%) in the beginning and add some more later on. And use proof-of-stake to vote for the relative contribution.

I hope you consider to implement several PoW systems simultaneously in Bitshares. Then let proof-of-stake voters decide for the relative contribution of each PoW algorithm. This would be much more secure because an attacker would need not only 50% of the CPU power, but also 50% of ASICs and 50% of the stake (if we consider an example where all 3 contribute equally). At the same time it would be much more energy efficient because stakeholders could vote to decrease the contribution of PoW to maybe 20% and increase the contribution of PoS to 80%. In addition to the better energy efficiency it would also lower the effective inflation of Bitshares for regular users/consumers/investors.

Any trading system that requires one chain to 'monitor' another chain is not scalable.   The chains must function with 0 knowledge of the other chain.  Clients may support both chains, but only those clients care about both chains.    I don't want to inherit BTC's scalability issues by requiring 'miners' to see the BTC TRX.

I don't want you to control the money supply of my coin. I want mine to debase at 5% per annum, all going to miners, no dividends. I just want to make sure that if my blockchain accepts transactions from your blockchain, that you reciprocate. Can we design a general interface for this so any altcoin can participate reciprocally?

I would probably try to support your other features, but I have to study them in detail before I can say for sure.

Isn't the entire point to get more options out there for the market to choose? If it is all opensource, why do you care which protocol wins? Surely you can continue to innovate on what ever takes the lead in the market. I want your Asset, ID and messaging features. It is just the details that I have to review first.

I don't know your business model, perhaps it is making clients for the communication, etc.. I am thinking it would be best for you to not tie your clients too tightly to one variant of your protocol and design as much modularity as you can, so your efforts aren't lost if you need to change things or some other altcoin protocol is winning more marketshare.

As for atomic operation, Sergio described a very simple algorithm. For example, Bob has BTC and Alice has BTS, so put a TX in BTS blockchain saying that Alice is waiting for TX from Bob in BTC on the BTC blockchain. Put a timeout, but it is non-repudiable during that timeout period. Bob then can safely send the BTC TX. The BTS blockchain automatically sees the BTC TX and finalizes the TX to send Bob BTS.

What do you think?

I assume you mean the GPU/ASIC-resistant PoW. I purposely haven't responded to your request for my algorithm, but I will share at the right time, when I get closer to releasing something.

We have a method to our madness, but that is our trade secret.   As for timing code availability, we are considering a competition on the algorithm so the final candidate is not known at this time.