Topic: Announcing Project Invictus: a P2P Exchange Collaboration - page 3. (Read 11191 times)

If all of the nodes on the network *only* consider the hashing power in deciding which block to accept then the network is subject to 51% attack and a government could buy up enough hashing power to perform a DOS.   However, I think that BitShares has another means of preventing the 51% attack.

Every node in the network has financial incentive to accept the block that pays the most dividends.   Because all transactions are 'broadcast' every node has an idea of how many dividends *should* be available in a published block.   Any block that doesn't contain 80% of the published fees could be rejected.   An attacker with 51% of the hashing power would no longer have the power to deny valid transactions with high fees.  They could only succeed in denying the bottom 20% of transactions which would push up fees and thus mining rewards/dividends and therefore increase the network security until there was an equilibrium between fees and security.

In this way I have given all share-holders a financial incentive to reject forked chains even if they are not mining.  Miners would then realize they would be unable to spend their profits with these users and thus would not have any incentive to cheat the shareholders out of their dividends in an effort to manipulate which transactions are in or out.

This is true for the size of the Bitcoin network now (I think), but it won't be true if the world's currencies and securities were backed by PoW. See: https://bitcointalksearch.org/topic/energy-consumption-will-become-an-issue-if-bitcoin-really-breaks-through-181759 , and keep in mind that the figure is only for USD. There are orders of magnitude more in securities, so considering everything, there is not enough coal in the world to power the world with PoW securities.

There is no central point of failure. I am suggesting a federation of issuers where each issuer is game theoretically incentivized to be honest. Not only would this federation be more energy efficient, it would also be immune to nationstate attacks given the security of the signing algorithm. Should the issuer misbehave, the stakeholders would impeach the issuer, so it's very close to a PoStake system.

With all due respect, raising the issue of legality is missing the point of this exercise, given the history of debt money.


With PoW, the profits from mining is proportional to the security of the network, which is also proportional to energy expenditure. Even in the current bitcoin network, with the very high mining reward, there is not enough security, as it can be shut down by nationstate fiat quite easily. It is more secure to have a single authority per blockchain that is responsible for rubberstamping it, with the ability for shareholders to impeach the authority, than it is to have a distributed PoW scheme. With a federation of blockchain currencies and their respective signing authorities, and with inter-currency backing, there will be trust that builds from within the system.

What is money? Money is a collective agreement based on trust. The system that I have described is a cryptographic manifestation of collective agreement amongst voluntary agents.

Merged Mining is a CRITICAL aspect for scalability of many different block chains.   Unfortunately, merged mining requires a merkel tree as the proof-of-work and thus takes more space in the block headers that must be stored forever.   So if you want to create a system like bitshares that will ultimately have 1000+ chains each trading in a subset of the available securities then merged mining will be critical.   However, you do not want to 'artificially' limit the depth of the merkel tree nor do you want to allow merged miners to get a 'free lunch' at the expense of everyone else by including every chain under the sun in their POW merkel tree regardless of the potential value of that chain.   

So, I have devised a new approach to allow BitShares to natively support merged mining with proper profit incentives to minimize the size of the merkel POW tree without placing any limits on the size.    If there are two BitShare chains (Red and Blue) and each chain is trading in a different subset of securities then a miner who is doing merged mining for both chains has 3 options, mine red, mine blue, or do merged mining.   If they opt for merged mining then both the Red and Blue networks experience a cost to accept the larger POW and yet the miner effectively doubles his payout.    So the new approach use the depth of the merkel chain that proves the work to discount the percent of the reward that goes to the miner with the balance going to the dividends.    Thus you can calculate your mining reward as  block-reward / 2^proof-depth.   The end result is that if Red and Blue BitShares have equal market value and difficulty then merged mining is equally as profitable single mining and in both Red and Blue chains benefit from the added hash power.

If Red and Blue chains have different values and difficulties then miners will have to carefully choose which chains they mine based upon the expected growth of both chains relative to the division of their hashing power.   This would enable good and useful merged mining without the costs of unprofitable merged mining being foisted on the larger networks or creating a 'master / slave' chain setup.

I think the problem with any public backing of crypto-chains is a central point of failure.   These would effectively be a new form of bearer bonds and thus illegal.   So while in theory you could have many 'signers' and more 'transactions' with 'lower energy input',  I think the 'energy input' argument is entirely missing the point.   We waste far more energy and resources decorating our homes for christmas and manufacturing all of the decorations than energy would ever be put into mining.

With BitShares mining and 'owning' are equally profitable and the algorithm is far more decentralized.  The profits from mining will approach the average profitability / interest rate in society and thus consume no more resources than the value provided to the consumers.   Ultimately transaction fees back all mining and people will not pay for more security than is necessary.

I came to research P2P exchanges after realizing the pitfalls of the PoW scheme. [5]

I believe that all PoW coins (including hybrid schemes) are a tradeoff between two extremes; one being extreme waste of energy, and the other being a weakness of the network. Consider how much energy would be wasted should Bitcoins grow to replace the USD within a decade, or how weak the network would be today should mining rewards be eliminated.[1]

There have been several approaches that I found that don't rely on PoW, including Ripple and Open-Transactions. Unfortunately I find that Ripple approach is entirely too centralized, and I am not convinced that the ledger closing algorithm [4] will scale successfully into a fully decentralized network. OpenTransactions, AFAICT, has significant architectural problems in that users of an issued currency must trust the Issuer, and the Issuer in turn must trust the Server not to inflate the currency. There is a mechanism in the works for the Issuer to audit the Server [2] to ensure that the currency hasn't been inflated, but I don't see how this is atomic, and I don't see how the audit would work unless the Issuer has full knowledge of all transactions, in which case we might as well use a block chain for fairness in transparency, and also so that users can choose to migrate to a new Issuer should there be a compromise of sorts.

I now believe that the future global crypto currency system will be a federated system of block-chains, where each block-chain is signed by one (or a group via group signatures) Issuer (rather than mined collectively by PoW). Similar to OpenTransactions in some ways, except there is a public block-chain. The Issuer is the Server, and the currency of the Issuer is a special account that holds a balance of other currencies. I like to think of the Issuer as a public corporation with shares and its own bank account containing fiat & other securities. Should there be a problem where the Issuer is misbehaving (e.g. by not signing valid transactions into the block-chain), the shareholders can vote for a new Issuer, and the other currency Issuers would recognize the newly voted Issuer as proper. So, if you trust the Issuer Alice, and you see that Issuer Bob's currency is backed by shares of Alice, then you can proportionately trust Bob to behave good; for in the worst case Bob's accounts could even lose their ability to redeem the underlying shares of Alice. In this way, the federated system of currencies is built on mutual trust and voluntary actions of the Issuers.

Such a federated system of PoW-less currencies has the additional benefit that transaction times can be very short, so a P2P exchange can work fairly well with the chain-trade algorithm [3]. With branch currencies (think, the opposite of a basket currency; one currency is branched out to many), you can have a federation of high-speed exchanges across the globe, each centralized yet backed by the same root currency.

With regards to fiat and the pegging of currencies to fiat: I don't think we need to worry about that at all. The system described can accommodate a new generation of currencies, as well as a new generation of IPO stocks and asset-based currencies (which aren't distributed via PoW btw); it wouldn't have the constant downward market pressure of miner rewards; it wouldn't have any problem getting adoption. If one wanted to issue a new currency backed by fiat, one can still do so, and it would be up to the users to trust this issuer, as it should be. Similarly, I wouldn't be concerned with pegging to Bitcoin either.

[1]:  If you're still not convinced, first I would try to convince you that Bitcoin would be more robust today if it were based on Proof-of-Stake. Unfortunately I don't believe that pure Proof-of-Stake currencies work, as a matter of theory involving achieving consensus in a distributed asynchronous system. See http://macs.citadel.edu/rudolphg/csci604/ImpossibilityofConsensus.pdf
[2]: https://bitcointalksearch.org/topic/m.2459550
[3]: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
[4]: https://ripple.com/wiki/Consensus
[5]: https://bitcointalksearch.org/topic/energy-consumption-will-become-an-issue-if-bitcoin-really-breaks-through-181759

bytemaster, not sure we should be including call/put options yet, as these might be better implemented via a more generic language/mechanism, after the core architecture has been defined. Same with escrows / bitmessage integration etc. The exchange I described above requires no escrow mechanism. [3]

brb.

I just wanted to inform everyone that I have started a 1 BTC bounty + 1000 BitShare bounty for the creation of the next generation proof of work to be used in the BitShares blockchain: https://bitcointalksearch.org/topic/m.2478855

So far I've liked everything I've read on BitShares. Is there a whitepaper or a link to some more information on it?

In what way do you see BitShares falling short of the ideal (particularly in light of the posts in this thread in the past 24 hours).   BitShares has absorbed the inter-chain trading of MarketCoin and expanded/enhanced upon it so I would like to know what else is missing so I can work to address it.

I have been following the p2p exchange discussions to catch up with the different proposals and projects. I have discussed a plan, PeerTrader, with some developers and posted it at https://bitcointalksearch.org/topic/m.2471088 . The closest I've seen so far are Marketcoin and Bitshares. I appreciate this thread to try to arrive at a common goal and plan to develop this critical piece of cryptocurrency infrastructure.

To achieve higher speeds and greater privacy we will require a system like Open Transactions where you have an anonymous server that cannot 'forge' receipts and can destroy all transaction history while still providing a provable balance.      An anonymous transaction server can back 100% of its issued IOUs with collateral held in the blockchain and identifying a large number of trusted yet anonymous 'escrow agents' to handle any disputes regarding withdraws of funds from the server. 

Now we can allow anyone to make deposits into the OT server by contributing to the escrow balance.   Anyone can also make withdraws from the OT server's escrow fund by presenting the last signed receipt as an input to the transaction.      At any time any party may open a 'dispute' regarding a withdraw from the OT server's pool which will immediately freeze all withdraws until a super majority of the escrow agents 'vote' to either  'halt' operation of the server or clear the server of wrong-doing after performing an audit of the server.    All withdraws have a 24 hour waiting period where they can be challenged.

To open this 'dispute' you must post a good faith fee that will be forfeited if the signed receipt is proven valid.  To launch a new OT server you must post a surety bond that will be forfeited if the server is found 'guilty' to the individual who first reports the failed audit.   

What is the end result of this system?   All parties have incentive to audit / monitor all withdraws for fraud.   The escrow agents collect a small 'fee' from every deposit / withdraw and thus do not want to risk losing their reputation over a single OT server as they will be providing their services for many OT servers and private transactions.  Depositors, traders, and others would all have interest in reporting fraud as well as the OT server itself. 

Assuming a 'provable' audit could be performed on a OT server (which I think is possible) then we can achieve both high-speed and anonymous transactions in a secure, decentralized manner.   

This would have to be supported by the block chain directly to automate the escrow, surety bond, deposit, and withdraw, and dispute process. 

In the event that the server 'disappeared' then it will be up to the depositors to 'prove' the most recent audit / receipt which would allow the escrow agents to redeem receipts on behalf of the server. 

End result:  high-speed, anonymous, secure, and fraud-free trading.     

Scaleability issues that must be addressed:

1) Every block must update the dividends per share of all bond types and this information must be tracked as far back as the oldest 'unspent' output.  Dividend calculations are required for every input and must either query every prior block's divided table or there must be a lookup table based upon 'coinage'.   

2) The number of potential trades / exchanges grows with O(N^2) of the number of currency units thus for 8 units, there are 56 possible short/long combos each of which requires 16 bytes / block 'forever'.

3) Even storing just the 'unspent' outputs at under 50 bytes each would result in TB of data in short order assuming transaction volume similar to Bitcoin, but exchanges will probably have several orders of magnitude more trades than bitcoin experiences and therefore unspent outputs must be managed better than Bitcoin.

Conclusion:
   Transaction fees must be based more upon the net gain in unspent outputs rather than the total size of the transaction.  We can 'forget' all of the inputs after enough proof of work, but the outputs we will pay for forever.   

   We want to motivate people to combine dust and this can be done in two ways, reduced trx fees *and* not paying dividends below a certain threshold. 

   We must recover old transactions and force people to keep all outputs 'current' to limit the amount of 'dividend history' that must be maintained.  At the very least, any dividends that go unclaimed for more than 1 or 2 years could be 'forfeited' and thus all outputs must be spent every 2 years or they lose their dividends.   Though a more 'pro-active' approach of 'taxing' 2+ year old outputs and paying them out as dividends would serve to keep all outputs current and recover value lost to lost private keys.   This 'tax' can be thought of as an 'inactivity fee' that banks charge accounts and as a means of reimbursing the network for holding on to your unspent output for a very long time which has significant costs when you factor in the total number of nodes that must replicate and index that output. 

   The chain must support 'cross-chain' trading to allow parallel BitShare chains to develop that enable trading in a wider range of currencies, stocks, and commodities as well as higher volumes than could ever be supported by a single chain.    Thus when the transaction fees get too high on one chain, the market can create a new parallel chain that complements the existing chain.  Because every chain enables trading any asset type it is easy to synchronize value between the chains with only a subset of nodes performing arbitrage roles.

While BitShares is the only proposal that I know of to have a dividend component, the unspent output scalability issue as well as the O(N^2) trading pairs and higher transaction volumes will mean that any block-chain based approach will need to have an efficient mechanism to 'go-parallel'.     

  Addressing these scalability issues is a critical component.

Based upon some of the recent updates / additions to BitShares here is a summary of the 'changes' to Bitcoin.

 A BitShare is a new crypto-currency that has most of the properties of BitCoin.  They are mined into
 existence, transferred via a block-chain, secured by encryption and proof of work.  The primary difference
 between a BitShare and a BitCoin is that a BitShare will pay you dividends via 50% of the transaction fees
 and mining rewards.

 The BitShare block-chain introduces a few new rules and transaction types that turn it into a secure,
 multi-currency, bank, exchange and escrow service.


 Definitions:
 1) BitShare        - Dividend Paying Crypto-Currency
 2) CryptoBond      - An IOU secured by a BitShare or other CryptoBond
 3) CryptoUSD       - An IOU USD secured by BitShares.
 4) CryptoGold-USD  - An IOU Gold secured by CryptoUSD
 5) CryptoBS-USD    - An IOU BitShare secured by CryptoUSD

 I will now go over these new transactions:

 1) Short Sell

    - A transaction that provides collateral as input and specifies an ask for a CryptoBond at
    a specified exchange rate.  This transaction may be canceled.

 2) Bid

    - A transaction that provides a payment BitShare or CryptoBond and a request to purchase a BitShare or CryptoBond
      at the specified exchange rate.

 3) Call / Put

    - A transaction that gives another party the right to claim the output at the specified price by the specified date (block).  The
    output of this transaction represents two sides of the trade and both sides can exchange their position with other addresses.  Call
    options come due once per month.   These instruments may be traded like CryptoBonds or BitShares via the exchange system.  The collateral
    necessary to secure the position is held for the duration of the instrument.

 5) Register Escrow Agent
    - specifies the fee and surety requirement, term limits, hash of the arbitration agreement, BitMessage address, Surety bond, and a list of
    other Escrow Agents that may release the Surety bond along with an expiration date.  The input to this transaction is
    the surety bond and may be denominated in any CryptoBond.

 5) Escrow Transaction
    - A transaction that specifies an escrow agent and pays an escrow fee and surety requirement and a hash of the 'agreed contract' signed by both
    parties.  If dispute is filed, this transaction automatically clears after a certain amount of time.  No new transactions may be issued
    using a particular escrow agent if there is an open dispute

 6) Escrow Release
    - A transaction signed by a party to the Escrow Transaction to release their funds to the other party and the fee to the escrow agent.

 7) Escrow Dispute
    - A transaction signed by either party to lock the funds until they are released by the escrow agent.

  Escrow Dispute Resolution
    - A transaction signed by an escrow agent that divides the escrow funds among the two parties.  This transaction may be disputed as
    well and will be resolved by whoever is allowed to release the surety bond.


 9) Foreign Chain Trade
   - A set of transactions that implement atomic cross-chain trading.


Built-in Exchange Rules:

   Every block the miner is responsible for deterministically pairing bids/asks that are already present in the chain.  The Miner is
   also responsible for giving all margin calls priority over all other bids.  The process of pairing bids/asks and resolving
   Margin Calls is deterministic.  Transactions matched by the miner may not be spent for 24 hours when the mining reward is released.

   Between blocks, no transaction may exchange value between two CryptoBonds unless done at an exchange rate between
   the bid and ask price of the prior block.  This will enable rapid off-chain negotiation and instant spending of the resulting
   trade when it gets included in the next block.  This rapid off-chain negotiation can only occur between parties with an
   active connection to the network and the ability to sign with their private keys.

   The miner may collect a 5% fee anytime Margin is called.

   Anytime a position runs out of margin, it is liquidated and the proceeds are paid out as dividends.

Agreed with #2

I originally agreed with you on #7 but only because I thought it was 'too difficult' and 'orthogonal' to the trading function.   But when you consider the #1 complaint against earlier versions of BitShares was that you 'still have to use escrow' you realize that the *primary purpose* of most exchanges is escrow.  The key thing to understand / avoid in creating a P2P exchange is how to avoid using 'escrow' at every time a bid/ask is matched because escrow and moving fiat is way to slow to be placed in this bottle neck.   Thus you want to create an escrow system that helps people get into / out of crypto-bonds.

Why should escrow be built in?   Because money held in escrow faces exchange rate risk and therefore you want the 'escrow-funds' to be denominated in the same unit as the fiat funds.   Two, you want to avoid trusting a 3rd party at all if both parties execute a successful transaction and in the event of a conflict you want the escrow agent to be restricted in who they can send the funds to.   Third, you want the escrow agents to be anonymous, decentralized, and profitable to ensure they have profit motive for providing just arbitration services.   Fourth, you want the escrow agents bonded so that their decisions can be disputed by yet another 'anonymous' agent.

All of these 'features' of escrow are best implemented via a blockchain and to avoid the blockchain synchronization issues it is best to integrate escrow into the P2P exchange chain as a simple addition of a few output scripts.   

So in conclusion, the 'ideal' exchange seamlessly supports escrow and thus handles fiat.  The fact that it makes fraud almost impossible means that it will not be 'profitable' to attempt fraud and thus all users can trade confidently even with fiat without having to deal with capturing their SSL logs and potentially compromising their account information even on successful transactions.   It also avoids artificial limits on the means of performing the fiat exchange as (cash, check, money order, wire transfer, paypal, etc... ) could all be used provided evidence of the 'transfer' could be captured and presented to the 'anonymous' escrow agent. 

#13  agreed.

2. Isn't this a function of the userbase? How do you present a large number of bids/asks on an otherwise perfect P2P exchange that only 7 people worldwide use? I think this should be removed, but I understand why it's here.

Suggestion: "It must present the deepest market possible given outside constrains on the system, such as userbase"

7. I've voiced my concern about putting requirements for fiat in these criteria. I won't go into too much detail (again) but I would actually suggest that fiat is a corruption of 'ideal money' and so necessitates a corruption of the 'ideal exchange'. I hope we're not using fiat in 10/50/100 years time, and what is an 'ideal' exchange will be different because of that, and probably won't mention fiat. Just a thought.

13. I'd like to suggest an expansion to this "It should address known scalability issues with Bitcoin or be able to take advantages of scalability improvements when they are made to Bitcoin". Not the most elegant wording, but hopefully you can understand what I mean by that. It worries me if we try and develop too much at this stage we'll miss the opportunities for innovation. Scalability is an issue for Bitcoin, but not just yet. We'll see what develops over the next few years.

I think the current requirements for integration with the system as I've written up are:

• Can be used as a parent chain for merged mining
• Uses transactions where outputs can be confirmed
• Uses transactions which are confirmed in a blockchain
• Irreversible transactions

One of the advantages is it works with standard Bitcoin transactions, and can be used with addresses (instead of pubkeys) if the same keypair is used on both the Bitcoin and Marketcoin network.

The last three properties are important for proof-of-payment, the first is important for having a perfect-knowledge system (or close enough for these purposes; not sure of the limits here). Maybe knowledge discovery is a better term.

I'm planning to expand the proof-of-payment algorithm so 'pledges' (similar to what Marketcoin uses) can be used as proof-of-intent-to-pay, where once the trade is made coins will be released. This is a little more complex though. It would be nice to support this for the first mainnet release, but I'm unsure if it's properly do-able or feasible as I haven't put that much thought into it yet.


I think there plenty of productive uses if we use liberal amounts of imagination, in terms of salient productive uses, not so sure.


I hope so, that's what Marketcoin is, ultimately. Let's see in 6 weeks


Awesome! I look forward to seeing how this pans out!

On the note of the atomic trading alg and comparing it to Marketcoin:

• Marketcoin requires no changes to the Bitcoin/altcoin network
• Marketcoin does not use nLockTime (Marketcoin's finalisation system is different, you can look at the reversal as similar to nLockTime but it isn't the same thing)
• Marketcoin has very interesting economic properties such as eliminating arbitrage between all currencies on the exchange
• After the orders are locked in a block only one party has to do anything, the seller of MKC just sits back and waits
• Way fewer steps
• Possibly less opcode needs, but this won't fall either way until the protocol is fully developed

Also, love the use cases.

Criteria of the Ideal P2P Exchange

 1.  It must be without any central points of failure.

 2.  It must present a deep market with a large number of bids and asks.

 3.  It must enable orders of any size to be filled in a single transaction (provided there is reasonable market depth at a given price)

 4.  It would enable all forms of financial transactions including: long, short, put and call options.

 5.  Trades must be atomic and not subject to failure after a bid and ask have been paired.

 6.  It must lock in all trades in minutes and finalize those trades within 24 hours.

 7.  It must enable secure escrow of fiat transfers between parties.

 8.  It must be easy enough for anyone who can use Bitcoin and an existing centralized exchange to understand.

 9.  All trade data must be public to enable the creation of charts necessary to facilitate trading.

 10. It must be scalable

 11. It must not depend upon 'external' price sources of price information (tickers, voting, self-reporting, etc)

 12. It must shelter as many users and transactions from legal liability as possible.

 13. It should address known scalability issues with Bitcoin

http://bitcoinmagazine.com/libertybit-suspends-operations/

Feeling the pressure yet?

Yes, if the system is robust enough to support a wide array of derivatives, then we should expect faster and more institutional adoption. He's the rule, if Goldman Sachs is making money off of it, then don't expect a government shutdown anytime soon.

Regarding requirements on a P2P exchange...    should we add the ability to take out short positions? 

More Details on P2P Escrow:

1) all communication would be done via bitmessage.
2) all escrow agents would get to pre-define their terms:  (fee, surety rate (20% above) time tables, bitmessage address, required evidence, etc) in the block chain
3) The escrow agent does not collect the fee until the transaction settles and can only divide the funds between the two parties.
4) Escrow agents could place their bond with another escrow which will create a 'web' of trust, only a few of the escrow agents would have to be 'public' or 'known' to enable all escrow agents to function honestly.
5) The block-chain would then automatically enforce the fees, time tables, and other aspects of the escrow contract.
6) When funds are released by the escrow agent, it may be 'challenged' in the block chain for 24 hours.  If a 'challenge' transaction is placed into the chain then a new dispute is raised with the agents bond on the line.    
7) This process of appeal can continue until you reach a non-bonded agent (presumably the trusted public figure) or 3 consecutive appeals result in the same decision.

Because all communication occurs over BitMessage it can all be integrated into the BitShare client app which will be able to 'track the progress' of the dispute, confirm payment, etc.   Because all escrow agents, transactions, and dispute decisions are logged in the blockchain, it is easy to discover and follow which escrow agents have been used the most, have resolved the most disputes, what their fees / schedules are, and how long it takes them to resolve disputes.   It would also give you insight into how often one agent is involved in a dispute and which side of the dispute they side with (normally).  All of this information would make the 'outliers' stand out and help people choose anonymous escrow agents.

End result?  Cheap, 'trustless', escrow with anonymous dispute resolution necessary to facilitate fiat-trade.