[Announce] Project Quixote - BitShares, BitNames and 'BitMessage'

[nomailing]

we are considering a competition on the algorithm

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.

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.

[1714000122]

1714000122

[nomailing]

If you have a suggestion for parameters to Scrypt that you think would achieve the goal I am open to it.  After all, I am not tied to any particular algorithm just the goal of decentralization.

Depends upon how the algorithm is changed every couple of years.

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.

Obviously current hash power would have to 'vote' to move to new a hashing technique.  

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.

[td services]

Do you have a planned date when mining will start? I thought it also was this fall, maybe I misread something.

Also, will the mining code be available to test mining prior to the actual start?

Finally, how do the current investors plan on earning a return on their investment in Bitshares?

Thought I'd ask again since I think the questions got lost in all the economics discussion. This has a large impact on my mining approach and timing.

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.

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.

[AnonyMint]

Can we design it such that the cross-chain transactions will interface blockchains using competing protocols (e.g. no dividends)?

I think yes?

So then I can launch a slightly different protocol, but we can share much code?

Cross-chain transactions are compatible with Bitcoin.    After much work I was unable to create an efficient, secure, means of having 'one currency' with a 'fixed supply' split among multiple chains without allowing a 51% attack on one chain to steal 100% of the value stored on that chain.   So all cross-chain transactions work like https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

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.

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?

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.

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.

[AnonyMint]

I read in the white paper.

Outputs that go unspent for more than 1 year forfeit their dividends and are charged a
5% transaction fee to move their output forward in the chain. Balances below the average
transaction fee are forfeited entirely. This will allow the network to recover value from lost keys
and eliminate the need to store transactions and outputs forever at ever increasing costs (and no
benefit if the keys were lost). Because the block­chain is rotating it is possible to define the
maximum total disk size required to process the chain.

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:

“You don’t need to keep an internal record of everything that has been done to have everyone’s accounts settled. We recognized a solution that would keep everyone’s block chain relatively lean,” he added.

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.

The block chain will allow for 1 billion IDs from the start, but it will be expandable

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

[AnonyMint]

To further enhance security Hierarchical Deterministic Wallets are used to ensure that the same 'address' is never used more than once and that 'addresses' are never linked together via single transaction in the block chain in such a way that would compromise your identity through network analysis.  

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://bitcointalk.org/index.php?topic=279249.0

Even when a user ends address reuse by switching to BIP 32 address chains[i.e. Hierarchical Deterministic Wallets], they still have privacy loss from their old coins and the joining of past payments when they make larger transactions.

https://bitcointalk.org/index.php?topic=279249.msg3009655#msg3009655

As I understand the problem-to-solve is that if someone reveals your identity for any transaction then any other spends from the same public key are associated with your identity and any spends (inputs) from other public keys to the same transactions as the identified public key are with high-likelihood associated with your identity.

[AnonyMint]

4) the bitcoin block chain does not have a reliable block production rate, it is currently over 55 days ahead of schedule and thus fundamentally broken from an inflation control perspective and thus not a reliable time source for options expiration.

How can you fix this?

[bytemaster]

To further enhance security Hierarchical Deterministic Wallets are used to ensure that the same 'address' is never used more than once and that 'addresses' are never linked together via single transaction in the block chain in such a way that would compromise your identity through network analysis.  

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://bitcointalk.org/index.php?topic=279249.0

Even when a user ends address reuse by switching to BIP 32 address chains[i.e. Hierarchical Deterministic Wallets], they still have privacy loss from their old coins and the joining of past payments when they make larger transactions.

https://bitcointalk.org/index.php?topic=279249.msg3009655#msg3009655

As I understand the problem-to-solve is that if someone reveals your identity for any transaction then any other spends from the same public key are associated with your identity and any spends (inputs) from other public keys to the same transactions as the identified public key are with high-likelihood associated with your identity.

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.

[AnonyMint]

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.

[AnonyMint]

It is safe to merge outputs that haven't been merged in a while.

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

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.

What is this off-chain signing?

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.

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.

[bytemaster]

4) the bitcoin block chain does not have a reliable block production rate, it is currently over 55 days ahead of schedule and thus fundamentally broken from an inflation control perspective and thus not a reliable time source for options expiration.

How can you fix this?

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.

[bytemaster]

It is safe to merge outputs that haven't been merged in a while.

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

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.

What is this off-chain signing?

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.

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.

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. 

[AnonyMint]

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

[bytemaster]

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

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.

[bytemaster]

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.

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

[AnonyMint]

It is safe to merge outputs that haven't been merged in a while.

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

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.

What is this off-chain signing?

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.

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.

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. 

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

https://bitcointalk.org/index.php?topic=279249.0

More complicated implementations are possible where even the server doesn't learn the mapping.

E.g. Using chaum blind signatures: The users connect and provide inputs (and change addresses) and a cryptographically-blinded version of the address they want their private coins to go to; the server signs the tokens and returns them. The users anonymously reconnect, unblind their output addresses, and return them to the server. The server can see that all the outputs were signed by it and so all the outputs had to come from valid participants. Later people reconnect and sign.

[bytemaster]

If you have a suggestion for parameters to Scrypt that you think would achieve the goal I am open to it.  After all, I am not tied to any particular algorithm just the goal of decentralization.

Depends upon how the algorithm is changed every couple of years.

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.

Obviously current hash power would have to 'vote' to move to new a hashing technique.  

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.

Suppose back in the days when CPU mining was the majority and GPU mining was just starting to gain traction but still a minority.   The CPU miners would all vote to move to something that would keep them in power before the GPU owners could take over.  The FPGA developers wouldn't even begin investing any effort.  The only way to perform a successful ASIC take-over would be to perform a 51% attack before anyone knew it and then vote to keep yourself in power.   Of course, such an attack would immediately undermine the entire currency.

So the CPU users must pro-actively change the hashing algorithm at least once per year to prevent any secret ASIC developments.  Combine this with a hash algorithm that doesn't give ASIC as much advantage as SHA256 does (by being memory and computation hard, ie: the point behind the scrypt white paper) and even if ASICs were developed they would not be able to gain a majority of the hashing power quickly nor cheaply.

[AnonyMint]

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.

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

Those do appear to be a potential killer feature, but I am not sure if they are the most important need at the moment. Something to contemplate.

[bytemaster]

It is safe to merge outputs that haven't been merged in a while.

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

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.

What is this off-chain signing?

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.

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.

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. 

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

https://bitcointalk.org/index.php?topic=279249.0

More complicated implementations are possible where even the server doesn't learn the mapping.

E.g. Using chaum blind signatures: The users connect and provide inputs (and change addresses) and a cryptographically-blinded version of the address they want their private coins to go to; the server signs the tokens and returns them. The users anonymously reconnect, unblind their output addresses, and return them to the server. The server can see that all the outputs were signed by it and so all the outputs had to come from valid participants. Later people reconnect and sign.

This is exactly what I had in mind down the road.   

[bytemaster]

I started a new thread dedicated to the technical details of the Bitshares ID system.  You will see why it is VERY different from Namecoin with very different properties and scalability. 

https://bitcointalk.org/index.php?topic=283513.msg3033138#msg3033138