I'm not talking about "no orders."  I'm talking about "no bid ask spread."

Let people make bids and offers while market is open.  All these are limit orders.  Then, at end of 'round', market closes for an instant, algorithm finds fair price at which greatest amount can be traded, and executes all orders allowing fair price, all at same price.  Then market opens again for next period. 

'Continuous auction' as traditional stock trading maximizes number of trades, earns much commissions for brokers and trading houses.  Efficient in time only to maximum speed of market's ability to process orders and inefficient in price.  So called high volume trading is just gaming time efficiency against price inefficiency for profit.  'Continuous auction' also maintains existence of bid ask spread, which allows market makers and brokerages to live off price inefficiency.  But price inefficiency is investors money.  Investors would rather keep it.  If investors are P2P, brokers and market makers are not needed, so no reason investors can't keep their money.

Different model here, call it 'periodic fair pricing' or something, allows existence of bids greater than some asks until market period ends but then executes all bids and asks at same price.  Some time inefficiency, but absolutely no price inefficiency.  No bid ask spread, one massive transaction per trading period.  Each period, all orders execute at same price, so no price inefficiency to exploit.  Also no price inefficiency to support profits for brokers, market makers, brokerages, or fractional-second traders  -- all are unnecessary in new model. First few because nothing for them to do anymore, last because never had any useful role to start with.  If close of trading period is unpredictable (when block closes on 'market' subchain because hash is found)  also no way to exploit time inefficiency by placing massive orders in last fractional second before period close, either.

I hope it is not considered rude to post code here, but here is C code implements pricing algorithm.  I encourage you to play with it and see how it works.

/*  This code implements a "fair market" algorithm for trading.
    Instead of matching individual buy/sell orders for a particular
    issue one at a time as they impinge on a bid/ask spread, the "fair
    market" algorithm consolidates all buy and sell orders for an
    issue over some interval and then finds a single price which
    maximizes the number of shares traded.  For that interval, ALL
    purchases/sales which can be made are made at that price.

    Using a fair market algorithm, it is possible to proceed on the
    basis that the market opens every hour (or every ten minutes, or
    whatever), determines a "best price" for all buy/sell orders
    received during that hour, executes all trades that can be
    executed at that price, and immediately closes again.

*/

#include<malloc.h>
#include<stdlib.h>

struct order{
  int minprice;
  int maxprice;
  int amount; 
  int buyorsell;
};
#define SELL 1
#define BUY 0

struct sortrec{
  int keyprice;
  struct order *ref;  
};

int sortrecorder(const void *srpt1, const void *srpt2 ){
  return(((struct sortrec*)srpt1)->keyprice - 
         ((struct sortrec*)srpt2)->keyprice);
}


/* Sets *validresult to 0 for a malloc error or when finding that
   there is no price at which trades can be made.  Returns -1 for 
   a malloc error and 0 for  no-acceptable-price.  

   Otherwise accepts a vector of orders and the length of that vector,
   and returns the best price (ie, the price at which the greatest
   amount of the issue can be traded) for that vector.  If there is a
   range of such prices, it returns the highest. */

int findprice(struct order *orders, int ordercount, int *validresult){

  struct sortrec *ordervec;
  struct order* item;
  int index;

  *validresult = 0;
  /* if there are zero orders, or one order, then there cannot be any
     price at which a valid trade can be made. */
  if (ordercount <= 1)
    return(0);

  sortrec = calloc(ordercount * 2, sizeof(struct sortrec));

  if (ordervec == NULL) 
    return (-1);

  for (index = 0; index < ordercount; index++){
    ordervec[index].keyprice = orders[index].minprice;
    ordervec[index + ordercount].keyprice = orders[index].maxprice;
    ordervec[index].ref = &(orders[index]);
    ordervec[index + ordercount].ref = &(orders[index]);
  }

  qsort((void *)ordervec,  2 * ordercount, sizeof(struct sortrec), sortrecorder);

  int loindex;
  int hiindex = -1;
  int buys;
  int sells;
  int trades;
  int pricechanged;

  int vlength = 2 * ordercount;
  int lastprice;
  int bestprice = lastprice;
  int lastindex = -1;
  int besttrades = 0;
  int priceguess = ordervec[0].keyprice -1;

  while (hiindex < vlength) {
    pricechanged = 1;
    if (lastprice + 1 == ordervec[hiindex+1].keyprice ){
      lastprice = priceguess;
      loindex = hiindex+1;
      priceguess = ordervec[loindex].keyprice;
      for (hiindex = loindex; 
           hiindex < vlength && ordervec[hiindex].keyprice == priceguess;
           hiindex++);
    }
    else if (hiindex + 1 < vlength){
      lastprice = priceguess;
      priceguess = ordervec[hiindex+1].keyprice -1;
    }
    else pricechanged = 0;

    if (pricechanged){
      for (index = loindex; index <= hiindex; index++){
        item = ordervec[index].ref;
        if (item->buyorsell == BUY){
          if (item->minprice == priceguess)
            buys += item->amount;
          else if ( priceguess > item->maxprice 
                    && lastprice <= item->maxprice)
            buys -= item->amount;
        }
        else{
          if (item->minprice == priceguess)
            sells += item->amount;
          else if (priceguess > item->maxprice
                   && lastprice <= item->maxprice)
            sells -= item->amount;      
        }
      }
      trades = buys > sells ? sells : buys;
      if (trades >= besttrades){
        bestprice = priceguess;
        besttrades = trades;
      }
    }
  }
  if (besttrades == 0) 
    /* no trades can be made at any one price. */ 
    return(0);
  *validresult = 1;
  return(bestprice);
}

Here is something that would help.

Standardize some coin denominations, call 'minted coin'.  Random other denominations call 'bullion', for 'bulk metal.' 

Let a standard minted coin be anything that starts with 1, 25, or 5, and the rest of whose digits are zero. 

phase 1.  Merchants start splitting input into minted coin into own wallets, giving back minted coin as change.   Trigger phase 2 when 90% transactions last 100 blocks done exclusively with minted coin input & output. 

phase 2.  Now make 'normal' transaction be transaction exclusively in minted coin.  Other transactions still legal, just not 'normal' anymore (or maybe not 'normal' unless accompanied by bigger tx fee for miner). 

phase 3.  Clients concerned with privacy may start participate exclusively in tx have exactly same number, denomination, for input & output, and at least 2 inputs largest size coin used.  Other clients, not care, may allow tx where take maybe some number coin at same address , but if so let make another standard size coin. 

Easy for someone to figure out what's going on when there's an input that's 3.88 BTC, an output that's 3 BTC, and an output that's .88 BTC. 

Much less easy when there are 3 inputs of 1 BTC, 3 inputs of .25 BTC, 2 inputs of .05 BTC, and 3 inputs of 0.1 BTC, and output is exactly the same number and size of coins.  No way to know which is change going back to buyer.  No way to know which inputs & outputs represent buyer, which seller.  Maybe seller has inputs too, and is making change  Not even a way to know if the thing somebody bought cost 0.5 BTC or 3 BTC or 3.5 BTC, etc. Every address used have one coin, every address paid to have one coin. 

Trades in 'bullion' (arbitrary N-digit denominations) still possible, maybe not 'standard', or may require small 'minting fee'.  But also possible exchange 'bullion' for 'minted coin'  of standard denominations, down to level of negligible dust award for miners.   Not even possible when watching to tell difference between someone changing own 'bullion' for goods with merchant take 'minted coin' and getting 'minted coin' change, from someone just changing own bullion for minted coin.

Makes 'coinjoin' privacy by default.  Money go through a few ordinary trades under new rules, specially trades with or by privacy enforcing clients, no longer possible tell who own which. Is soft fork only; all tx legal under new rules also legal under old.  Takes no 'mixing' as such or 'mixers.'  Requires trust no extra party.  Implementation simple and easy make secure.

Edward.

Why this resulted in bitcoin failure to come up?  With security model in place should have resulted in a chain fork, yes?

Cumulative volume $6e8 in one hour, yes, but how much is actual investment?  Take number of people intend to hold stock even one voting period, even one dividend period, subtract all others, what left?  One one hundredth the bandwidth, one tenth the volume, maybe. 

Fractional-second traders are just parasites living off investor money.  Bad for investors, bad for business. 

Stupid trading model anyway, have "bid ask spread."  Just support more parasites.  Go to batches, bid ask spread is zero.  Everybody trade same price each batch.  Investors pure P2P, no need to support "exchange" or "brokerage" or anything else.  No symbiotic role anymore for such.  No need for bid ask spread to support them, no need for market supports for buggy whip makers either. 

Fuck obsolete inefficient trading model.  Fuck parasites living off inefficiency.  Time for new answer.

I have thought about this. 

One answer is don't do high frequency trading.  Is just parasites anyway.  Money 'invested' in a company for fraction of second not do company any good, not contribute wisdom to board, not vote stock even once.  Useless. 

Simply let bids, asks, all limit orders, accumulate and, when low enough hash generated, bam, all trade at once, same price.  One transaction, but big.  Algorithm pick price where greatest amount trade can happen, where bid line cross ask line.  If everybody can see bids & asks, even post facto, can verify own order is present and can verify price-pick algorithm did what supposed to.  Block chain expand by one transaction only.  Transaction has many txins and txouts.

Aim for hash periods of a minute or so.  Variability means nobody know exactly when transaction close.  High volume per round Inhibit volatility caused by high-frequency trading, means larger orders can go through without much affect on market.  No high frequency traders, no wild swings too fast for human to react, fair prices, nobody get cheated by getting fraction of second wrong, everybody trade same price each round.  No effect on real investor except prevent parasite sucking investor money away on trading system.  Price move only in jumps at intervals poisson distribution average around one minute.

Figured out socket layer part.  May be more to it than this, but this is sure.

Logger thing can't use operating system calls communicate with fake Windows update.  Is because fake Windows update is pretend part of UI manager and Logger or remote desktop thing not run with UI privilege.  Fake Windows update and Logger or remote desktop thing pass information each other using socket layer instead.    This what Windows "security" is like?

Privilege as invoker means logger or remote desktop thing can use socket layer access network.  But Fake Windows UI thing has no such privilege, can only use socket layer talk to local programs.   Looking more and more like must be remote desktop not just logger, but haven't found outside connection yet.

Okay, downloading again, more look.

Think probably a year or two worth of coding effort in part that installs here, plus whoever did has sensitive key from Microsoft.  Took resources random hacker would not have, stolen from high security machine which compile windows updates.     Part that search mail wallet.dat before installs though, simple and stupid, probably attach to main payload coded by someone else. 

Has XML code for windows registry addition of resident assembly module, contain requested privileges requestedExecutionLevel="asInvoker"  uiAccess="false", but hook into UI anyway, must bypass Windows security.  Next bit explain how.  XML for windows registry also contain reference to assembly module supposed to be update for "Microsoft.Windows.Common.Controls version 6.0.0.0", which gives publicKeyToken="6595b64144ccf1df"

Attackers found Microsoft key lets them sign code installs operating system "update"!   

Is DEFINITELY not just random hacker.  Such keys not available free and cheap download, had to be stolen.

Different styles in different parts.  Code which search and mail wallet.dat separate, coded with something higher level language, compiled with stupid compiler into bad inefficient  assembly.  Logger or remote desktop thing very different, very clever assembly, efficient fast hard to figure out and obvious hand coded.  Also separate into at least two executables when run, one for raping windows UI and one for taking advantage of rape.

Assembler attach table of macro values when assembled.  Can tell date assembler was called from date string stored in table even though code not use.   Most recent assembly of clever parts on 20 November 2012.  Fake windows UI update at 08:58:32 and linked logger or remote desktop thing part at 09:04:41.  So, not very recent, most likely is hacker download. Stupid compiler in first part not attach table include date.

Malware definite.  

Good (BAD!!) malware too, look like written direct in assembly.  Does things high level compiler never ever do like use as data (including instructions!) from code segment, to make value pun elsewhere, use as number or insert in string.  Horrible to trace, damned clever.

Executable first attempts find mail wallet.dat files.  Then install some kind amazing big logger.  

Not just keyboard logger, but whole UI.  Every element every window every action every mouse move click.  Record everything you see on screen, record everything programs read/write/send/receive.  Even special code for command window, handle text not graphic.  Scary amazing.  Never seen before.  Looks like has code for two display and two sets of keyboard/mouse but way second keyboard/mouse connected make no sense.

Not figure out what do with all yet; involves sockets layer but haven't found sure yet whether network or local.  Strong suspect network; nobody go to this trouble for anything but live eavesdrop/report, or maybe run remote desktop.

Also not figure out yet for sure whether just log use, or also give remote desktop.   Strong suspect remote desktop, or what for found code for handle second keyboard/mouse?  

Either way though, malware definite.  Never Ever run on windows box.  

Have seen enough this poison thing.  Will delete now.  Want more information, you know where get executable look at yourself.  Don't want it near my machine, and my machine not even the operating system it wants prey on.

----

If want to reward obsessive/compulsive disorder made me stare this so long, 1HCizpYzpcngaRHnrKfsm9iww4SExsMk34

Couple good things about Namecoin.

First, is something you can buy with at relatively fixed prices (domain names in .bit fake-tld) so has value supported by particular good.  This kind of like "trade money" sellers used to make say, "Redeem for 50-lb bag of flour at Ivan's Grocery" or similar.  So has minimum value as trading commodity, better than Bitcoin.  Bitcoin value is self intrinsic commodity due scarcity, but has not intrinsic redemption value.

Second, has primary use clearly legitimate.  So has Bitcoin, but must argue about because so much crooks use Bitcoin on silk road etc.  "Ebay for Maniacs" and "Most Brazen Illicit Drug Market on Earth" has been called, also first time many legal beagles hear Bitcoin.  They think like Paypal and Ebay, same underlying provider, same purpose.  Requires argument and education teach otherwise.

More picking at executable.  Full name of file that unzips is "wallet.dat litecoins112@gmail.com" 

Found asm code for reading own command line.  Found string that if passed to cmd instance invoke sendmail (treated as symlink to Outlook on Win box). 

Now trying figure out what it wants send.  Is more string, but obfuscated in executable with XOR something-or-other. Soon as I know what, will post back. Need documenting of Windows interrupts and DLL links; not use myself and no man pages.

Edward.

Got same message.  Picked apart zipfile, unzips just fine from command line with password given (always safer, command line unzip not run executable) is not wallet format, is executable format.  Bzzt, wrong answer.  Funny game!  Hmmm, my move now....

I don't quite understand this.  These dust are being sent to old addresses.  That means that whomever has the private key that can spend the money at the old txout can also use that same key to spend the money at the new "tiny little payment" txout? 

So if the dust is spent, there is evidence that the old address represents someone who is still paying attention and still has the key to that old money.  That seems like something important to know in trying to assess the real currency supply (ie, someone wants to estimate how much bitcoin has been lost).  That is not particularly dangerous or adversarial; it's just good sense to know. 

But it is dangerous to privacy, because if dust sent to multiple different addresses is gathered together into one account, that could be taken for evidence that the different addresses are in fact controlled by the same person?

Do I understand the threat right?

The correct solution then for the account holder, is to use the 'dust' and the 'old account' with the same key both as txin for a new transaction, with a single output.  There is no harm in letting someone know that the money has not been lost and that its owner is still paying attention, but consolidating the dust together with the account whose key it shares should do no harm to privacy. 

Is there any reason why that solution would be the wrong thing for the account holders to do?

Noticed this in today's news.

http://www.pcworld.com/article/2047980/news-junkies-opensource-project-links-bitcoin-with-publishers.html

He has created a server-side client that makes it painless for websites to process micropayments using BTC.

He is described as a "news junkie" and the article describes use on a news outlet, but we all know where this is really going....  Porn.

I have been thinking hard about instant clearing. The problem is the possibility of a double spend.  In a double spend, a transaction is lost in a block chain reorganization.  The reason the transaction is lost is because it refers to an input which has already been spent by another transaction.  Therefore it is invalid because of insufficient inputs.  Therefore it is necessary to wait several blocks to be sure that a block chain reorganization will not happen.  Otherwise the spender may be able to double spend.

I think I may have a solution to this problem.  The spender must post a surety bond.  It is not necessary that the recipient get this bond. If the spender loses it, then  it means that the spender has no motive to commit a double spend.  This can be done by making the spender demonstrate ownership of an account containing enough for the surety bond.  It can be done without requiring the spender to reveal the private key of that account.

The spender has the account he is spending money from.  He also has a surety account.  The surety account must be at least a week old.  This makes it very unlikely to disappear in a block chain reorganization.  The surety account must contain enough money to make sure a double spend is unprofitable.  That means at least the amount being spent.  To account for exotic triple-spend attempts, maybe double the amount being spent.  The recipient of funds presents nonce, which does not hash to the script that spends the account.  The spender must encrypt nonce using the private key of the surety account.  The recipient can check by decrypting nonce using the public key of the surety account. This demonstrates that the spender owns the surety account.  It does not spend the surety account. The public key of the surety account is then recorded in the transaction. 

If a transaction citing a surety account fails due to insufficient inputs, the surety account cannot be subsequently spent.

In practice the failure of a transaction due to insufficient funds occurs in case of a double spend.  It may also occur if a wallet is badly mismanaged.  The spender states  with a surety bond that neither thing has happened.  The recipient knows that the spender has no motive to commit a double spend.  The recipient knows that the spender has a strong motive to avoid mismanaging his wallet.  The recipient may therefore accept funds instantly without waiting for block chain confirmation, knowing that if the recipient loses anything the spender will lose more.

This requires a hard fork update to the protocol rules.  The new rule must enforce this constraint.  This requires extension of existing clients.  The extension must enable clients to handle instant-clearing transactions with surety bonds. 

I have been very careful to construct English.  I hope I have done it well enough.  If I have not, I apologize.  It is difficult.  I am using a grammar checking program.  It doesn't know all the words I must use to describe this. 

Edward.

Interesting guide.  Thanks to Shakezula. 

Not worth making new coin, unless do something new.  Cut and paste for starting point, but must write code to make new coin worthwhile.  Could try solve problems. 

Biggest problem cryptocurrencies scalability.  When billions use coin, block chain bigger faster than network can carry.  When billions of tx have every machine repeat each tx to check for agree need faster machines than exists.  You have idea to fix scalability, is worth doing altcoin.

Another big problem, cryptocoin anonymity isn't.  Blockchain records every tx.  Information mining, easy trace users through blockchain even with no names associated accounts.  Like able see all money moving around everywhere, becomes obvious who carrying.  Zerocoin has very clever way to solve, but makes scalability problem even worse, 40 kilobyte transaction premium.   Make coin with better anonymity, at least interesting.  Maybe never allowed to succeed, maybe illegal in future.  Interesting, anyway.  Learning how is worth doing.

Third problem, mining.  Convert electricity into coins, wasteful.  Waste keeps money cost up, means no point mining for most people, concentrates mining/chain verification in smaller number of people -- eventually probably one, and currency die.  Also money cost is transaction cost, and cryptocurrency strength in larger economy is minimize transaction cost.  Minimize transaction cost, easy transactions, is main reason for being better than official currency.  Minimize mining cost minimizes tx cost.  Custom ASICs, expensive GPUs, etc. were mistakes.  Bad direction for development.  Figure out way to not need, way to keep chain verification in many hands, be fair everyone, is worth doing. 

Fourth problem, maybe, what happen when mining reward ends?  People mine for money, what happen next time reward is halved?  Time after that?  Time after that?  Never tested.  Don't know.  Will any coin survive end of rewarding miners?  Will few remaining "transaction processers" be enough to keep secure, or will become vulnerable to attack, 51% takeover?  Remember powerful people want cryptocurrency stop.  Make $Billions off transaction fees now, cryptocurrency system would eats business.  What cost doing 51% attack on coin not reward miners by credit card toll troll?  Less than cost not doing it.  Figure out how mining.  Solve this problem and one before, definitely make new coin. 

Fifth problem, speed transaction clearing.  Find way to make instant transfers, not wait for blocks to close and block chain to deepen.  Many kinds of business cannot do otherwise.  Consider vending machine.  Scan QR code, transfer .0005 btc or whatever, then ... wait a half hour?? NO.  Just not work most people.  Fix it, worth doing.  Many altcoins attempt fix by making short block time, but short block time limits number tx per minute or network overwhelmed and chains diverge.  Destroy coin first or second time are too many tx per minute.  Short block times make first problem far worse.  Must find different way to speed tx clearing.  If figure out, very worth making altcoin.

Could also try add new capability.  Many possibilities.  Think of one or two or three, make altcoin with new ideas.

Big one right now, Prism proof email.  You have widely distributed database of public keys (accounts).  If leverage for real private mail from account to account, worth doing an altcoin. 

Another, what calls 'Colored Coins.' Make something take full advantage, keep track colors, definitely worth doing.  Could take advantage script transactions for contingent contracts in different kind assets; could do futures, etc. 

Cut and paste coin, nothing new, is foundation material.  But nobody want move into foundation.  Must build house on top.

Edward.


 

hayek:

I envy your limited experience with tyrants. :-(

No reason nations not use protocol. 

Issue cryptocoin convertible to/from regular currency that nation, "control" money supply same as now. 

Why pay attention existing bitcoins?  Can just replace all with "real" currency altcoin, not give away wealth to bitcoin holders.

Big win for Bitcoin, acceptance ordinary use.  Big win for acceptance legitimacy.  Big win legitimacy many legitimate transactions. Many legitimate transactions while not legal impossible Bitcoin.   Would not Bitcoin bought myself except essays like this: 

http://dillingers.com/blog/2013/08/26/an-investment-with-an-absolutely-appalling-history/

Google translate not handle well, but readable more than me.  English.  I feel same.  Only way justify Bitcoin value, if people use for ordinary online payments all kinds.  If that happen, three more value orders magnitude, easy.   If not, coin all just tulips.  Legitimate only way get future rich.

Not saying anonymity must weaken; but must accept police can penetrate with effort, timing attacks, etc, and not much strengthen else never be legal for ordinary use and all we all have tulips.

Can keep tracking Bitcoin hard like tracking cash; but not harder, else sacrifice future.

Edward.

I think proof-of-stake, or maybe even proof-of-burn, is a winner in the long run.  But both have problems.

In thinking about an alt-coin suitable for most money-flavored purposes in the long run, I reach a few conclusions;

1.  Ways to originate coins other than mining, tied into main currency economy.  For example, could issue initial coins to holders of savings bonds or stocks or etc, without requiring payment of coins back at savings bond maturity.  So coins become a part of the "interest" paid on a main-currency instrument.   Could do this not even needing cooperation of main entity issuing benchmark instrument; someone who can show that they own N shares of some asset through entirety of some period, gets coins proportional to holding.  But all of those coins count as "pre-mine", I guess.  If you don't come up with a crypto-secure way to show ownership of benchmark asset through the period, ownership of those coins must be awarded via genesis block.   Of course could do crypto-secure in parasitic way; someone shows they owned 150 bitcoin for two year period, gets 15 coin of new issue. 

2.  Proof of stake as main method of creating coins.  Needs some development.  Basic idea as I understand it is transaction outputs slightly greater than transaction inputs, depending on length of coin ownership of coins transacted, in an amount that mimics 'interest' paid over intervening time.  Not a bad idea; very simple.  Current implementations mix proof-of-stake with hashing proof-of-work.  Not sure that's a good idea; not sure how else do it.

3.  Recovery of dead coins.  This is sort of the anti side of proof-of-stake.  Part of the way of the world is that people sometimes lose coins.  Hard drives die, wallets get corrupted, coins are sent to unspendable addresses, etc.  I think any coin not transacted in seven years should be subject to yielding no PoS reward if actually spent.  If coins get ten years old untransacted, they should disappear, say twenty percent at a time, over following five years.  Allows disappeared money to be used to fund Proof-of-stake interest or if other means of mining used, keep positive stake in mining. 

4.  Block chain needs limit.  Much cheaper to keep 'ledger' that records which accounts own how much without recording every transaction.  Scales much better.  Transactions are evidence, not primary information.  Must be able to prove transactions, but once proven, ledger needs 'closed' so transactions don't hang around on chain forever. 

5.  Some way to clear payments faster than waiting for blockchain.  This is necessary for mainstream accept coin as money.  Someone wants to use vending machine, someone wants to pay for beer, etc.  Vendor doesn't want to wait 30 minutes to clear, spender doesn't want to wait 30 minutes to clear.  Need some strategy for issuing quick-clear or offline-clear coins like Chaum's e-cash or something, make place-holder coin until block chain catches up.

6.  In long run coin needs to be slightly inflationary;  Annual 2 or 3 percent growth in coin as units of account allows paying miners and so on without complicated tx fees, also allows economy to proceed, make more advantage by building businesses than just hoarding coins. 

Anyway, just my thoughts.

Edward.