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

[bytemaster]

There is some inertia with mining and also the 'set-it and forget-it' management.  Which would probably provide enough dampening to cause all chains to approach average.

That said, I can see some benefit for encouraging some merged mining.  Though I don't think it needs to be as exaggerated as it is in your approach.

I think you could achieve some compromise between:

reward / (depth^1)   and reward / (depth^2)

Perhaps along the lines of reward / (depth^1.5).

It would be nice if there were some principled approach to figuring this out.

[1714204079]

1714204079

[1714204079]

1714204079

[1714204079]

1714204079

[1714204079]

1714204079

[greBit]

You got an ETA on the Secure Messaging whitepaper? I would likely be keen to work on a few bounties on that project

Also I just frikin love this open approach to development. I hope it will succeed and set a precedent for others to follow

[bytemaster]

You got an ETA on the Secure Messaging whitepaper? I would likely be keen to work on a few bounties on that project

Also I just frikin love this open approach to development. I hope it will succeed and set a precedent for others to follow

I have to choose between white papers and writing code.   I am trying to do a brain dump to some others who will hopefully produce the white paper.

Bottom line: 
Read the BitMessage white paper.   
Replace their address discovery / key lookup system with BitID.   
My message encryption scheme is similar to theirs.
Broadcast message with similar system to BitMessage... with the following changes:
     1) proof of work scales difficulty on any given channel to maintain 128kbit/sec average
     2) alternative proof of work, lighter weight version of BitShares POW that is memory and CPU hard and GPU resistant but still runs in about 1 ms.
     3) channel 0 is the discovery channel (everyone listens on) and is restricted to small messages
Storage:  Fixed sized storage for emails per channel.  To broadcast a new email you must bump someone else from storage.
     1) weight of message in storage =  (1 month - age_of_message) * proof of work on message / size of message.  (this equation may be tweaked to make it non-linear)
          - result is a defined maximum disk usage per channel, maximum 1 month, market-based priority on storage time.
     2) all messages of any length are compressed with the best possible algorithm we can find for the message... trying multiple algorithms if necessary.
Contacts:
     1) works like skype, you can add friends which will then share which channel you are listening on with your friends.
     2) automated sharing of a common private key for chat rooms and mailing lists.
Real Time Communication:
     1) The fact that you are communicating with your family is no secret, so certain contacts can be flagged to allow 'direct connect'
           -- the only thing revealed by doing a direct connect is that you *might* know this person.
           -- when and how much you communicate with this person is still hidden  (unless you start doing large-file transfers)
     2) From the outside, direct connections look identical to all other communication channels.
           -- packet sizes and timing should appear similar enough
           -- doubles as a normal peer-to-peer connection.
     3) From the inside, direct connections do not require proof of work.
     4) Control the number of hops on the network via 'indirect connect',  you and your contacts clients will pick a random 3rd node that you will both connect to.  This node does not know it is being intentionally chosen, it just sees two incoming connections.  Network latency is no longer 'arbitrary', but can be kept to 1 hop.   This is slightly more private than a direct connection, but still requires proof-of-work.

Then implement it with much better software architecture that allows the system to be used for more than just human-readable messages, but for data between software components.

I am sure we will find other improvements along the way, but that is the rough outline of our objectives.


     

[AnonyMint]

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

Perhaps your logic was something like this.

If coins are allowed to be moved between blockchains at par (no market exchange variance) and the blockchains don't exchange coins at par with any blockchains that don't adhere, the problem remains that 50% attacking the blockchain with the lowest PoW difficulty will infect with ill effects the blockchains with higher PoW difficulty.

[bytemaster]

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

Perhaps your logic was something like this.

If coins are allowed to be moved between blockchains at par (no market exchange variance) and the blockchains don't exchange coins at par with any blockchains that don't adhere, the problem remains that 50% attacking the blockchain with the lowest PoW difficulty will infect with ill effects the blockchains with higher PoW difficulty.

I actually managed to find a way of protecting the higher-POW chains.  Effectively, the only light-weight/decentralized/signature is proof of work, so the only way to 'sign something' from one chain to another chain is via proof-of-work which means that the signature of 'one chain' handing value to 'another chain' could be forged with POW and thus instead of a 51% attack allowing double spending of your own coins, a 51% attack allowed stealing of 100% of the weaker chain while leaving the main chain secure.

[AnonyMint]

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

Perhaps your logic was something like this.

If coins are allowed to be moved between blockchains at par (no market exchange variance) and the blockchains don't exchange coins at par with any blockchains that don't adhere, the problem remains that 50% attacking the blockchain with the lowest PoW difficulty will infect with ill effects the blockchains with higher PoW difficulty.

I actually managed to find a way of protecting the higher-POW chains.

I don't think so. Btw, in addition to that link, I have another unarguable point on how to achieve anonymity in the blockchain, which gmaxell says is "off topic".

Effectively, the only light-weight/decentralized/signature is proof of work, so the only way to 'sign something' from one chain to another chain is via proof-of-work which means that the signature of 'one chain' handing value to 'another chain' could be forged with POW and thus instead of a 51% attack allowing double spending of your own coins, a 51% attack allowed stealing of 100% of the weaker chain while leaving the main chain secure.

Exactly my point at the first link above. [redacted] Realize that stealing coins is effectively from both blockchains, since the dominant blockchain is issuing all coin supply.

P.S. I spent more time researching my PoW scheme, including such issues as direct-mapped vs. set associative L1 caches. That will give you a hint.

[bytemaster]

P.S. I spent more time researching my PoW scheme, including such issues as direct-mapped vs. set associative L1 caches. That will give you a hint.

We are preparing terms for a large competition (estimated prize at $10,000 (no commitment on that yet)) for the generation of the best possible proof of work that will achieve the following goals:

1) Keep things decentralized, optimized on commodity hardware widely in circulation.
2) Motivate the development of better general purpose computers, ie. R&D on mining has outside benefits.
3) Can be validated very quickly.
4) ASIC resistant and GPU proof.

I hope you contribute your PoW work to the effort because everyone benefits from sharing knowledge.

[bytemaster]

AnonyMint... your comments on this forum have earned you some notoriety.. http://www.reddit.com/r/Bitcoin/comments/1lfuev/innovation_is_spreading_the_cryptoecosystem_is/

[bytemaster]

Those following this thread may be interested in this poll..

https://bitcointalk.org/index.php?topic=285701.msg3054804#msg3054804

I believe I can use economics to defeat centralization of mining in the hands of ASIC developers and those with economies of scale.    Ie:  If I put a fixed limit on mining payout to $5 million per year, the no one would invest capital in ASIC development.    But with bitcoin's $200 million / year payout the equation is entirely different.

See the other thread for my analysis of the security implications.   This is all just theory, but I think I might have something here.

[AnonyMint]

Those following this thread may be interested in this poll..

https://bitcointalk.org/index.php?topic=285701.msg3054804#msg3054804

I believe I can use economics to defeat centralization of mining in the hands of ASIC developers and those with economies of scale.    Ie:  If I put a fixed limit on mining payout to $5 million per year, the no one would invest capital in ASIC development.    But with bitcoin's $200 million / year payout the equation is entirely different.

See the other thread for my analysis of the security implications.   This is all just theory, but I think I might have something here.

Now you know where I stand.

https://bitcointalk.org/index.php?topic=285701.msg3057936#msg3057936

[greBit]

I have to choose between white papers and writing code.   I am trying to do a brain dump to some others who will hopefully produce the white paper.

Could we get another Bytemaster thread for discussions about the Bitmessage sequel ...

Ive posted on the Bitmessage topic but its pretty well buried on the 20th page https://bitcointalk.org/index.php?topic=128230.msg3055421#msg3055421

Basically I was just wondering if there could be an alternative approach to 'Streams' as it seems a little inflexible, but it is possible that i misunderstood something.

[bytemaster]

I have to choose between white papers and writing code.   I am trying to do a brain dump to some others who will hopefully produce the white paper.

Could we get another Bytemaster thread for discussions about the Bitmessage sequel ...

Ive posted on the Bitmessage topic but its pretty well buried on the 20th page https://bitcointalk.org/index.php?topic=128230.msg3055421#msg3055421

Basically I was just wondering if there could be an alternative approach to 'Streams' as it seems a little inflexible, but it is possible that i misunderstood something.

We can talk about that on this thread.    From an abstract sense, the security provided by bitmessage is based upon hiding in the crowd.  You hide which messages are for you by privately picking them out of the stream of data flowing by your computer.   Unfortunately it doesn't scale to have one stream of data so an alternative method of grouping messages such that only 1 / 1000 are destined for you is required or you have to revert back to inbox based designs...

So lets consider this problem from the perspective that not all people require the same level of security.   For example, it is pointless to hide the fact that you know most of the people you interact with in real life.   The government already knows who you work with, anyone you use a credit card with, anyone whom you text message or call on the phone, and anyone who you ever use regular email to communicate with.   Adding a lot of overhead to 'hide' this connection between you and them is pointless.  It only adds value to those who want to establish a new contact with someone and want to keep that contact secret (say sending something to wikileaks).    I suppose there is some benefit to hiding how often you exchange messages with your friends and family but it is certainly pointless to hide that you know them.

As a result you can modify BitMessage to directly connect to most of your friends and family.  The existence of the connection doesn't reveal any new information to an observer.   You then send both regular anonymous traffic as well as direct messages / emails / chat  to your friends and family.   Now you no longer have to deal with expensive streams with proof-of-work that get broadcast to the entire network.  Instead your direct communications are hidden by an encrypted TCP connection that is simultaneously multiplexing BitShares, BitDNS, BitChat, and BitID messages.   Thus no 'streams' required for most of your communication.  For your secure anonymous needs where you want to hide your IP address you have to fall back on a streams based design.

I hope this helps and if you have ideas that are better I welcome them.

[greBit]

Yeah I realise this, im just wondering if the current implementation of Streams is a little too much of a blunt tool. Perhaps something better could be developed.

Just reposted this from the other topic...

So this is my understanding of the use of Streams & POW in Bitmessage. Please correct me if I am wrong...

[POW]

Proof of work acts as a limiter on the ability of someone to post a message over a broadcast channel.

• It serves to deter SPAM.
• By making it more expensive to send a message, it acts as a way to reduce the number of messages sent over a channel, reducing the bandwidth+storage costs of each node.

The POW difficulty need not be static but could adapt dynamically in an effort to constrain the bandwidth + storage requirements of each node to some fixed level

• One could have different POW requirements for each channel

[STREAMS]

If there were no Streams, we would be left with a best-effort broadcast channel.

• This would force each node to be responsible for the relaying and storage of a huge number of messages.
• Or the POW difficulty would be so high as to render the system useless
• It would not scale.

So we partition the network into a number of Streams, where each Stream is a best-effort broadcast channel.

• Each identity is assigned to one stream (it is fixed in the BM address).
• Some streams may be more active than others, node requirements(bandwidth/storage) will vary.

Partitioning is an effort to even out the network load.

• The only opportunity to do this load balancing and create a new partition is when a user wants to create an identity (BM address)
• If the current stream is deemed 'too busy', the identity will be created on a brand new stream

Once a stream is established, there is nothing the network can do to make itself more efficient and more evenly distribute the load on the nodes.

• It must resort to making it more difficult to post messages, by increasing POW difficulty
• This will likely not be in the user's interest

At my current level of understanding, it seems to me that Streams are quite a rigid mechanism. I see two problems:

• Once a stream is established, it cannot be re-partitioned because each identity is directly linked to a particular stream
• There is a trade-off between cost_to_run_a_node and level of anonymity. If a stream is quiet, the node's own messages will be less well hidden than if a stream was really chatty. In the current system, the user is less empowered to make a choice based on his own individual needs.

Thoughts ...?

[bytemaster]

BitChat in our system does not fix a user to a stream.

All users are in stream 0 which is the 'discovery stream'.
When you 'friend someone' you share with them your stream ID.
You can switch stream IDs at any time and notify your friends that you moved.

Thus dynamic load balancing is possible.

[greBit]

BitChat in our system does not fix a user to a stream.

All users are in stream 0 which is the 'discovery stream'.
When you 'friend someone' you share with them your stream ID.
You can switch stream IDs at any time and notify your friends that you moved.

Thus dynamic load balancing is possible.

How is that different to Bitmessage? Users can change and move to new addresses if they wish, it just requires the hassle of telling your contacts that you have moved to a new address

Also with a global broadcast channel, will there not be a scalability issue when there are 12 gazillion users needing to 'discover' each other?


Anyway, it would be nice if the hiding_in_the_crowd mechanism could be somehow decoupled from a user's address.

Here is a less than well thought out proposal...

We assume that the set of users' addresses (public keys) are uniformly distributed.

We can define a 'crowd-specifier' as being an address prefix such as '1ab'

• Any address with that prefix can be considered part of the crowd

When Alice sends to Bob, instead of attaching the 'stream_id' value to the message, she will attach a small prefix of Bob's public key address.

• The size of the prefix is chosen s.t it encompasses a minimum 'crowd-size' to prevent observers from inferring the true recipient

When connecting to the network, Bob, then provides his peers with a crowd specifier prefix, according to his particular needs at that moment.

• He may want to be part of a bigger crowd and give a shorter prefix
• He may lengthen the prefix if the messaging system starts to demand too much HDD space or bandwidth

Perhaps there is a less naive way to perform the partitioning, with the use of some hash functions.

[bytemaster]

BitChat in our system does not fix a user to a stream.

All users are in stream 0 which is the 'discovery stream'.
When you 'friend someone' you share with them your stream ID.
You can switch stream IDs at any time and notify your friends that you moved.

Thus dynamic load balancing is possible.

How is that different to Bitmessage? Users can change and move to new addresses if they wish, it just requires the hassle of telling your contacts that you have moved to a new address

Also with a global broadcast channel, will there not be a scalability issue when there are 12 gazillion users needing to 'discover' each other?


Anyway, it would be nice if the hiding_in_the_crowd mechanism could be somehow decoupled from a user's address.

Here is a less than well thought out proposal...

We assume that the set of users' addresses (public keys) are uniformly distributed.

We can define a 'crowd-specifier' as being an address prefix such as '1ab'

• Any address with that prefix can be considered part of the crowd

When Alice sends to Bob, instead of attaching the 'stream_id' value to the message, she will attach a small prefix of Bob's public key address.

• The size of the prefix is chosen s.t it encompasses a minimum 'crowd-size' to prevent observers from inferring the true recipient

When connecting to the network, Bob, then provides his peers with a crowd specifier prefix, according to his particular needs at that moment.

• He may want to be part of a bigger crowd and give a shorter prefix
• He may lengthen the prefix if the messaging system starts to demand too much HDD space or bandwidth

Perhaps there is a less naive way to perform the partitioning, with the use of some hash functions.

If you follow some of my old posts on the BitMessage forum I had an idea of hierarchal streams based upon bits in the address.  The problem is this opens up a new kind of attack where your address can be isolated and forced into a stream with only messages for you and the attacker.   I also don't want people to have to change their 'address' just to change channels. 

[bytemaster]

I recently came up with a way to eliminate all price fixing from BitShares and would like to introduce the concept here.  This is still theory, and does not represent a commitment to a particular implementation at this point.

Price Fixing in the abstract sense is anytime a parameter of our system is not based upon market forces. 

Examples Include:
1) 5% fee for margin calls
2) 5% fee for moving old outputs forward (inactivity fee)
3) 50/50 split of mining rewards vs dividends
4) Margin call when collateral falls to 150%
5) 200% initial margin

Each of these numbers represents an 'arbitrary' choice based upon one opinion / estimate of what is optimum.   They are also static and the reality is that the optimum setting for these numbers must change over time.  So what works today may be 'too high' tomorrow.   In a low volatility market, calling margin at 150% may be entirely too conservative and many people would consider 200% initial margin to be too conservative.   The point is that all of these numbers represent a form of price fixing that could leave the market vulnerable to both competitors and in the worst case complete failure.

The network needs to gather meaningful, honest, information upon which to make decisions on where to set these numbers.   This is where creating a prediction market on the block chain would come in to play.   If you think the margin call threshold is too high, short it.  If you think it is too low, buy it.    Note that you will lose money if you do not buy or sell based upon where the 'group consensus' will move.   

Given such a market for speculating on the group consensus of each of these parameters, the block chain can take a 30 day median price and use these prices to tweak each of the 5 parameters I listed above.  The result would be a slow, predictable adjustment in the network parameters based upon real-time speculation on the group consensus.

I would probably build in 'safe guards' that limit the range that the prediction market may tweak the parameters and if things end up pegged to one side of the range or another that may be an indication that something needs to be changed in the software.  The market would still function freely and thus the developers could release a patch that expands the range if the prediction market indicates a demand for values outside of our 'safe range' and we conclude that it is not due to manipulation.   It would then be a 'democratic vote' via hash power to expand the authority of the prediction market to set parameters.

I expect this to be highly controversial... so bring your best arguments for or against!

[onecent]

Interesting project.  I'm very excited to watch it develop.

[cunicula]

I recently came up with a way to eliminate all price fixing from BitShares and would like to introduce the concept here.  This is still theory, and does not represent a commitment to a particular implementation at this point.

Price Fixing in the abstract sense is anytime a parameter of our system is not based upon market forces.  

Examples Include:
1) 5% fee for margin calls
2) 5% fee for moving old outputs forward (inactivity fee)
3) 50/50 split of mining rewards vs dividends
4) Margin call when collateral falls to 150%
5) 200% initial margin

Each of these numbers represents an 'arbitrary' choice based upon one opinion / estimate of what is optimum.   They are also static and the reality is that the optimum setting for these numbers must change over time.  So what works today may be 'too high' tomorrow.   In a low volatility market, calling margin at 150% may be entirely too conservative and many people would consider 200% initial margin to be too conservative.   The point is that all of these numbers represent a form of price fixing that could leave the market vulnerable to both competitors and in the worst case complete failure.

The network needs to gather meaningful, honest, information upon which to make decisions on where to set these numbers.   This is where creating a prediction market on the block chain would come in to play.   If you think the margin call threshold is too high, short it.  If you think it is too low, buy it.    Note that you will lose money if you do not buy or sell based upon where the 'group consensus' will move.  

Given such a market for speculating on the group consensus of each of these parameters, the block chain can take a 30 day median price and use these prices to tweak each of the 5 parameters I listed above.  The result would be a slow, predictable adjustment in the network parameters based upon real-time speculation on the group consensus.

I would probably build in 'safe guards' that limit the range that the prediction market may tweak the parameters and if things end up pegged to one side of the range or another that may be an indication that something needs to be changed in the software.  The market would still function freely and thus the developers could release a patch that expands the range if the prediction market indicates a demand for values outside of our 'safe range' and we conclude that it is not due to manipulation.   It would then be a 'democratic vote' via hash power to expand the authority of the prediction market to set parameters.

I expect this to be highly controversial... so bring your best arguments for or against!

I am delighted to see your thinking move in a productive direction. (though this is just one of several complex problems you will have to confront in order to fix your design)

As I see it there are two abstract problems that are best analyzed separately.

1) Why should we expect a relationship between a virtual asset price in the blockchain and a specific real wold asset price? Say the asset in the blockchain is named "k" why should the blockchain price of virtual "k" be correlated with the real world market price of actual "k" instead of the real world market price of actual "j" or "z" of "f" or a mixed basket of "k","j","z", and "f"? [prediction market doesn't actually help at all with this]

2) Why should we expect a relationship between the virtual asset price in the blockchain and a unique real wold asset price? This is different from (1). Say the asset in the blockchain is named "k" why should the block chain price of actual "k" to track a single real wold asset price instead of a random basket of asset prices (e.g. why always "k" or "j" or "z" of "f" instead of a weighted-average of "k" or "j" or "z" of "f" with time-varying weights on each of the assets.) I think a prediction market can introduce incentives for market participants to agree on a persistent consensus definition of the virtual asset. Deviation from the current consensus (whatever it happens to be) will cause an individual to lose money in the prediction market. So we could end up with a market consensus where 1 so-called bitUSD is interpreted as 1 bitShare or 1 rouble or 1 piece of chewing gum. However, the consensus interpretation should be consistent over time because the prediction market links interpretations at time t to interpretations at time t+k to individual payoffs for 'voters'. The prediction market seems likely to converge upon a simple and time-consistent asset definition.

I'll incorporate this in a formal mathematical argument eventually (the formal mathematical argument is still a work in progress).

I don't want to bring in your examples because I think they confuse the issue.

[bytemaster]

Imagine you wanted to start a bank, so you create a cooperation and issue  1 million shares of stock to the shareholders.  On the date the bank is formed, it has no capital.

Now imagine that there are 1000 shareholders, among them are cunicula and bytemaster.

Now imagine that cunicula would like to sell some of his equity in the bank in exchange for USD, so he advertises that he would like to sell 100 shares for 1 USD.

Now imagine that someplace else in the world, bytemaster would like to borrow some USD from the bank.   This bank is no fool, and demands collateral for the loan.  Fortunately, bytemaster has some equity in the bank and offers to put a lean on it to back his loan.  The bank agrees, and issues bytemaster brand new USD Notes which are an IOU from the bank.  Now the bank is not dumb, it makes sure the collateral is worth at least 2x the value of the USD note it gave bytemaster because the bank now has a USD debt on its ledger. 

Bytemaster sees cunicula's advertisement and decides to sell the USD Note to cunicula in exchange for his shares in the bank.   Now cunciula knows the bank is solid and is holding plenty of collateral backing its Notes and so he accepts the USD Note from cunciula and deposits it into his savings account at the bank where he earns interest on his deposit.

Time passes and eventually bytemaster pays off his loan or the bank seizes his collateral to cover the loan. 

A little later, Charles comes along with the USD Note he received from cunicula when he sold his car.  Charles decides he would like to invest in the bank so he puts in a bid to buy the bank's stock with his USD Note.   If no one in the market is willing to take the bid and the bid is above the margin threshold, then the bank will step in and redeem the USD note to purchase $1 USD worth of stock.    The bank could do this because it has plenty of collateral.

Now I believe everyone can agree that if this were a real bank and the bank stock has a non-0 value that each and every transaction would be valid and 'safe'.   The USD note's from the bank would have a market value of about 1 USD and the purchasing power would be defended by the bank which would honor its IOUs.   There should be no doubt that the USD would track real USD even though the bank never had any USD on deposit, only offsetting ledger entries and collateralized loans.

So take this system that works in a traditional corporation manned by real people operating for a profit, and replace it with a blockchain.   The only thing the blockchain needs to know is the market value of USD relative to the bank's stock.  Fortunately, there is a reliable way to get that information:  always pair every individual who wants to borrow USD with someone who wants to buy USD.    Then have the borrower pay interest to the buyer.  The bank acts as the middle man and takes a cut on transaction fees and match making.   Of course, the borrower and buyer must always agree on the price and neither will bid more or ask less than what USD is worth. 

So, buy this simple analogy, I hope I have shown that the BitShares system is really no different than existing banks except that instead of issuing new USD with your house as collateral, it issues new USD with the bank stock as collateral.