[SKY] Skycoin Launch Announcement

[iamback]

Again how about we focus on real world problems:

https://bitcointalk.org/index.php?topic=968344.msg10651033#msg10651033

Terrifying. You are hitting a wall trying to go with traditional banking systems, also I recall Dwolla was involved with the feds seizing MtGox account.

This is the MP3 thing all over again, the music industry embraced the sharing technology so late that piracy was already miles ahead of them when they entered the market. I guess the same will happen to Bitcoin, most Banks will fail to embrace the technology and Bitcoin will get it's side market that sooner or later will make the traditional banking system obsolete. Anyone that has used Bitcoin to transact any amount of money over borders or to pay for any product online knows it. Bitcoin is freedom from banksters and governments.

Unfortunately crypto-currency appears to lack an equivalently popular use case.

[1715099985]

1715099985

[1715099985]

1715099985

[xyzzyx]

Skycoin team may be interested in this:

"For the first time in history, a prototype radio has been created that is claimed to be completely digital, generating high-frequency radio waves purely through the use of integrated circuits and a set of patented algorithms without using conventional analog radio circuits in any way whatsoever. ... Every aspect of radio frequency generation is said to be created using a string of digital bits, and nothing else. There are no analog circuits, no filters, no chokes, none of the traditional circuitry and components expected in a radio transmitter. Consisting of a mere handful of components, including a couple of integrated circuits, an antenna, and not much else, the transmitter – dubbed Pizzicato – promises to change the face of wireless transmission."

More:
http://www.gizmag.com/digital-radio-transmitter-microprocessor-technology/36380/

[MemoryShock]

I would say the altcoin market is a disappearing one. This is an absolutely hopeless market of +600 shitcoins, operated by day traders and pathetic P&D scamers. None of the coins, not even NXT has a slight chance to make it, because there is nobody use altcoins in the real world. Ethereum perhaps will make it as smart contracts could address many real world business requirements...

+1
Nonetheless, while i agree the +600 alts will fade away, there are imho a handful of slots for alt-coins that posses a 'Focus Differentiation' strategy, which inherently gives them some unique sales proposition in a niche or defined market.

Examples are:
* Anonymity - there is a clear market for anonymous transactions, with Bitcoin delivering only pseudo-anonymity. A good contender is Darkcoin to lead this category, but Skycoin can deliver on that as well.

* Smart Contracts - there is a clear market for small decentralized apps, with Bitcoin not built to deliver due to scaling, block-rate, etc..., whereas either NXT or Ethereum can lead this category.

* Communication - there is clear need for a free, P2P, non-censored, border-less communication & hosting. Freenet is nice, and Tor works, but it's not "it". Skycoin can lead this category, in competition perhaps with MadeSafe.

As for the majority rest of alts. RIP.

I think that a few might surprise you.  There are some who have established cross blockchain transactions and messages.  Of course, their developments can likely be forked but creating a means for altcoins to use the attributes of others is a powerful notion.  There might be some life left in some of them...and perhaps more...

And then there is Maidsafe.  I see both Sky and Maidsafe as relevant so I'm just going to get some popcorn...

[altcoinUK]

I would say the altcoin market is a disappearing one. This is an absolutely hopeless market of +600 shitcoins, operated by day traders and pathetic P&D scamers. None of the coins, not even NXT has a slight chance to make it, because there is nobody use altcoins in the real world. Ethereum perhaps will make it as smart contracts could address many real world business requirements...

+1
Nonetheless, while i agree the +600 alts will fade away, there are imho a handful of slots for alt-coins that posses a 'Focus Differentiation' strategy, which inherently gives them some unique sales proposition in a niche or defined market.

Examples are:
* Anonymity - there is a clear market for anonymous transactions, with Bitcoin delivering only pseudo-anonymity. A good contender is Darkcoin to lead this category, but Skycoin can deliver on that as well.

* Smart Contracts - there is a clear market for small decentralized apps, with Bitcoin not built to deliver due to scaling, block-rate, etc..., whereas either NXT or Ethereum can lead this category.

* Communication - there is clear need for a free, P2P, non-censored, border-less communication & hosting. Freenet is nice, and Tor works, but it's not "it". Skycoin can lead this category, in competition perhaps with MadeSafe.

As for the majority rest of alts. RIP.

I agree, the three areas you have mentioned could be very well where altcoins have use cases - I just can't see how projects lead by nerds and without adequate funding can succeed and make users to switch from conventional technologies and business models. That's why I think Ethereum could have the best chance to make it, as they are getting on board business professionals and the project is having the funds as well. Perhaps Skycoin could learn from the failure of other, basically all altcoins including NXT and from the relative progress of Ethereum. (And yes, I consider NXT is a total failure as a project from usage viewpoint as nobody use it for any meaningful real world purposes, and of course it is not failure for the founders as they made a tons of money by dumping their coins).

[iamback]

I originally dismissed Skycoin's upthread idea to delegate to a timestamp server because I felt it could be another centralized point-of-failure, e.g. the timestamp servers could censor which transactions they would sign with a timestamp.

But I think the solution is the idea of an inner envelope which blinds the timestamp (can't read) and which is revealed (unlocked publicly) after the timestamp has signed, which I was reminded of conceptually from this document (not a new concept for me, just wasn't thinking of it in the earlier discussion):

https://groups.google.com/forum/#!msg/alt.privacy/MKy0G4zl0WA/NskNTe-efE4J

The digital cash would be placed inside the outer "encryption envelope,"
and could be decrypted using the organization's public key.  The
prediction itself (including name and date) would be itself in another
encryption envelope inside the first one, but it would be encrypted
using a key that is only known to the predictor himself.  In this way,
the organization could decrypt the outer envelope and find the digital
cash, but they would have no idea what is being predicted in the
innermost envelope, either the name or the date.

If, later, the "prediction" came true, the predictor would presumably
send yet another encrypted "envelope" to the organization, containing
the decryption key for the previous "prediction" envelope, plus a public
key (despite its name, to be used only once!) to be used for encryption
of digital cash used as payment for the award.  The organization would
apply the decryption key to the prediction envelope, discover that it
works, then notice that the prediction included was fulfilled on the
date stated.

So then we  don't need the consensus of mining. Each node can maintain its own blockchain autonomously based on a common set of rules. The transactions can be broadcast to the network. Clients can verify from the data retained whether the node has followed the rules.

This eliminates PoW and orphans due to network latency, but it doesn't eliminate orphans due to double-spends where the earlier spend was withheld from the network for some delay. It also eliminates the problems with propagating transactions from the winning block to all the peer nodes (sorry that was me questioning Peter Todd's math).

A problem is consensus about which timestamp servers were historically trustable.

And the insoluble problem may be verifying relative time, i.e. it is not known whose timestamp server is accurate. We need to study the current consensus issues for NTP (network time protocol).

It seems conceptually that my upthread point remains true;  decentralized consensus is closer to a lie or delusion. The only true decentralization are competing choices.

However, one possible solution is to use a PoW consensus network to periodically compile a list of trusted timestamp servers. The nodes of the PoW network would poll the timestamp servers that advertise themselves to the network, anonymously testing the timestamp server for veracity of its ability to timestamp accurately.

This would provide real-time transactions along with a reduced role for decentralized consensus that would mitigate its weaknesses.

Combining this with my ASIC-proof CPU-only PoW hash and a paradigm of making mining UNprofitable for everyone (to eliminate mining farms!) might be the killer design for an altcoin. Alternatively of course in instead of PoW would be experimentation with other consensus algorithms such as Skycoin's proposed Obelisk for this role of consensus on timestamp servers.

[Momimaus]

Is there an IPO or not?
Bitmessage was sent 2 weeks ago. Nothing happened since then. 

[SkyValeey]

Watching this.

[Tobo]

Is there an IPO or not?
Bitmessage was sent 2 weeks ago. Nothing happened since then. 

This IPO will last fo 3 months. Maybe everyone will get the relpy at the end of this IPO.

[loveyouforever]

BTC price is 300 USD now, if the IPO price is still 240 USD/ BTC, it doesn't make sense.

[oddwh]

Is there an IPO or not?
Bitmessage was sent 2 weeks ago. Nothing happened since then.  

Same here. I wait, quite sure everyone is in the same situation so whatever. If the BTC price continues rising, this could be a good news for us.

BTC price is 300 USD now, if the IPO price is still 240 USD/ BTC, it doesn't make sense.

That's why putting a fixed price in USD but asking BTC doesn't make sense, BTC is not enough stable.

[yufu571]

@Skycoin, bitcoin price is 260 dollar now, you guys should adjust the IPO price to 260 BTC/USD

yep!
Given the Bitcoin price is too low right now and with a brilliant future, I do not think it is a good time to invest in this project with Bitcoin ---- unless the skycoin IPO is priced by Bitcoin other than Dollar. 

marked

[skycoin]

Development Update

Debugging makes me feel like Jesus dragging the crucifix through the desert.

Two days were wasted fixing a bug with where "req.ParseMultipartForm()" needed to be called instead of "req.ParseForm()" because URL get/post parameters were not showing up correctly in logs. The url was working in unit tests, but was broken in wallet gui and still trying to determine reason. As soon as this is fixed, will begin sending out test coins.

Then the transaction "readable" for human readable transaction format is broken. I had to spend four hours writing function for serializing binary transaction format to human readable JSON transaction format, so that a transaction can be converted to JSON and then back, without changing the SHA256 hash of the binary serialization of the transaction.

This is very important, because users of Bitcoin do not understand what a transaction is. They have never seen a Bitcoin transaction. Bitcoin transactions are not human readable. They are in some Forth like stack language that makes most C programmers wince. Skycoin transactions are simple enough that most users will be able to understand what they are and what they do. You can look at the transaction and visually see that it is correct. I think the average user will be able to create Skycoin transactions by hand if they need to and that it will help them understand what a balance actually is and what a transaction actually does.

The JSON serialization is important for tool, that generates transactions offline so they could be moved in human readable form from a cold computer to active node for "injection".  When we tried to move the genesis transaction for the IPO, we found out that the wallet readable serialization was completely broken... You cannot convert from a wallet readable back into a binary transaction with the same SHA256 hash as the original transaction. The function for injecting transactions into network from GET/POST request was also missing. That is in place now.

We did not realize this was not working, until we tried to move the genesis transaction from the cold computer.

The JSON serialization is also required for doing cron job to backup the transactions and balances in human readable format every hour, so they can be rolled over to a new chain or ledger if required. ASICminers was listed on three different stock exchanges and each exchange went under one after another. They were able to track ownership stakes through multiple shutdowns of the exchanges and contact investors and pay dividends. By having cron job and doing hourly backups of the transactions and balances, we can have contingency in place ensure that the balances are preserved if the coins need to be rolled over to a new ledger.

There is only one planned rollover in the future, but we want to be prepared if there is a severe attack that requires changes to the binary format of the blockchain that would require an emergency rollover. The transactions are exported from one ledger as JSON, imported into the new ledger and balances are same. The problem without the JSON format for transactions is that modifying the binary format of the blockchain breaks the block serialization format, so the old blocks cannot be loaded from disc. So the JSON standard makes it human readable, easy to run scripts on, future proofs it for import. This is part of emergency/contingency planning.

We also had to write bash scripts and generate a wallet deterministically using the Skycoin deterministic address/private key generator, insert the private keys into bitcoind, lock the wallet and then move that from cold store. SX was broken, which is what we were using before. Two days after bitcoind was working, we found out that SX is not longer being maintained was replaced by BX and that BX works.

bx tool from the lib-bitcoin/darkwallet team
- http://chimera.labs.oreilly.com/books/1234000001802/apd.html

SX was one of the inspirations for the Skycoin command line and JSON interface. Except that our interface is designed to be usable and instead of trying to do everything. BX is revolutionary because it allows you to do things that you cannot do with bitcoind, such as checking the balance of a bitcoin address without having the address private key in your wallet.

That is the state that Bitcoin is five years after launch. It is still impossible to query the balance of an address without a third party utility, using blockchain.net or having the address in your wallet.

Bitmessage Problems:

Some users are reporting that Bitmessage is not syncing and they are not getting message confirmations. We had the same problem in testing. We attempted to connect to Bitmessage and it depended on which country we connected to network from. If you connected to Bitmessage through server exiting in particular countries from clean state, we were later unable to sync all the messages, unless we deleted the node/peer lists from the bitmessage data directory. Without deleting the peer list in the data directory, message syncing failed even if connecting through another country.

This could be a bit of unluck or could indicate something else (sybil attack? slow nodes?).

We think Bitmessage is working good enough (we tried everything else and its worse), but that will affect some users.

[Tobo]

Bitmessage Problems:
Some users are reporting that Bitmessage is not syncing and they are not getting message confirmations. We had the same problem in testing. We attempted to connect to Bitmessage and it depended on which country we connected to network from. If you connected to Bitmessage through server exiting in particular countries from clean state, we were later unable to sync all the messages, unless we deleted the node/peer lists from the bitmessage data directory. Without deleting the peer list in the data directory, message syncing failed even if connecting through another country.
This could be a bit of unluck or could indicate something else (sybil attack? slow nodes?).
We think Bitmessage is working good enough (we tried everything else and its worse), but that will affect some users.

Should people try it again if they have not received confirmation messages?

[skycoin_xtc]

Should people try it again if they have not received confirmation messages?

as long as you see "Acknowledgement of the message received" in Bitmessage, you're fine

if you see "Message sent. Waiting for acknowledgement" for more than 24 hours, send again

[coin@coin]

In my opinion a project of this magnitude should:

1) Have non anonymous founding members. What is it with the anonymity? All of the best projects out there (Bitcoin 2.0) have all public faces behind them.
It makes a lot of difference IMHO.

2) Use a service like Koinify, Omni, Swarm, or Lighthouse to crowdfund the project. It will go way better than it is going now.

I like this project, don't get me wrong, and I support it. Just that there are better ways to go about it.

[skycoin]

Update:

I reset the genesis block, so if you had a copy of the old blockchain and run it, you get error after updating. You have to delete the old blockchain. I forgot to mention this.

Pull repo

In "~/.skycoin" there are files

blockchain.bin <-- delete
blockchain.sigs <-- delete
blockchain.bin.bak <-- delete
blockchain.sigs.bak  <-- delete
peers.txt
blacklisted_peers.txt
wallets <-- this is where your wallets are

"rm blockchain*"

Delete the blockchain related files. Then run client and you will have new genesis block.

!!! Make sure to keep the "wallets" folder. Maybe back that up first

In the future, I think different blockchains will be in different sub directories by hash, but that is not implemented yet.

[digi123]

Update:

I reset the genesis block, so if you had a copy of the old blockchain and run it, you get error after updating. You have to delete the old blockchain. I forgot to mention this.

Pull repo

In "~/.skycoin" there are files

blockchain.bin <-- delete
blockchain.sigs <-- delete
blockchain.bin.bak <-- delete
blockchain.sigs.bak  <-- delete
peers.txt
blacklisted_peers.txt
wallets <-- this is where your wallets are

"rm blockchain*"

Delete the blockchain related files. Then run client and you will have new genesis block.

!!! Make sure to keep the "wallets" folder. Maybe back that up first

In the future, I think different blockchains will be in different sub directories by hash, but that is not implemented yet.

I haven't been able to find the files you are specifying.
The skycoin folder on desktop contains these files - src folder, address_gen,  blockchain, blocksigs,  cert,  libg_s_dw2-1.dll,  libgmp-10.dll, and skycoin.

I can also find wallet files in .skycoin in document and settings, but the files you have mentioned I can not see anywhere.

What do you mean by "Pull repo"

Could you please specify exactly how to locate these files.

[Jamil.Kamil]

When and how to get this coins guys please can you tell me processing...?

[cryptomonetarist]

Bitmessage Problems:

Some users are reporting that Bitmessage is not syncing and they are not getting message confirmations. We had the same problem in testing. We attempted to connect to Bitmessage and it depended on which country we connected to network from. If you connected to Bitmessage through server exiting in particular countries from clean state, we were later unable to sync all the messages, unless we deleted the node/peer lists from the bitmessage data directory. Without deleting the peer list in the data directory, message syncing failed even if connecting through another country.

This could be a bit of unluck or could indicate something else (sybil attack? slow nodes?).

We think Bitmessage is working good enough (we tried everything else and its worse), but that will affect some users.

I sent several buy requests through Bitmessage over 3 days ago, status "Acknowledgement of message received" and I still have not received a response. Guys are you still there?

[skycoin]

Development Update:

You have to nuke the blockchain files in .skycoin again. "rm ~/.skycoin/blockchain*"

Skycoin Transaction Format:

There is an output

[
    {
        "hash": "043836eb6f29aaeb8b9bfce847e07c159c72b25ae17d291f32125e7f1912e2a0",
        "src_tx": "0000000000000000000000000000000000000000000000000000000000000000",
        "address": "2jBbGxZRGoQG1mqhPBnXnLTxK6oxsTf8os6",
        "coins": 100000000000000,
        "hours": 100000000000000
    }
]

An output has
- a balance of coins
- a balance of coinhours
- an address that "owns" the outputs. the person with the private key, whose public key hashes to the address can spend the output

1,000,000 base units = 1 coin. I think the base unit is called a "drop". So each coin is divisible to 6 decimal places. 1 million coins is 1% of total. So there will only be at most ~6 digits before the decimal and 6 digits after the decimal to keep it manageable. Anything more than 6 digits before/after decimal place becomes difficult to count.

A transaction is:

 {
  "hash": "96943281a3fd298bf05c848300d173ab9bf586b4024b080d1ca3aad03a458b9c",
  "inner_hash": "ca67e004b932137f8469d72e1e4147621f890cfc23f6d2f70e38eeb08da85aba",
  "sigs": [
    "5610209b061ff472766f9d36e70834c605a8911aa63dc64538bdf5d83339c8da10522810623a6e8 70865eab6ccdbe61741e27e7a21afd537e11768e90fbf96d900"
  ],
  "in": [
    "043836eb6f29aaeb8b9bfce847e07c159c72b25ae17d291f32125e7f1912e2a0"
  ],
  "out": [
    {
      "hash": "c09d5afa78684e14a676b13961a756e6fa9b2c5bebb7be71cf2dc143b4f633cc",
      "src_tx": "ca67e004b932137f8469d72e1e4147621f890cfc23f6d2f70e38eeb08da85aba",
      "address": "2jBbGxZRGoQG1mqhPBnXnLTxK6oxsTf8os6",
      "coins": 99999990000000,
      "hours": 66666666666665
    },
    {
      "hash": "d5651588726225707c0b3fd97a9325b0863580f5b70d8a081035cb2aabaa8c53",
      "src_tx": "ca67e004b932137f8469d72e1e4147621f890cfc23f6d2f70e38eeb08da85aba",
      "address": "D2S9qZ1x2uiET7zXCdTDcPbbibfRuJdg3U",
      "coins": 10000000,
      "hours": 1
    }
  ]
}

When executed this will spend output
- 043836eb6f29aaeb8b9bfce847e07c159c72b25ae17d291f32125e7f1912e2a0
and will create outputs
- c09d5afa78684e14a676b13961a756e6fa9b2c5bebb7be71cf2dc143b4f633cc
- d5651588726225707c0b3fd97a9325b0863580f5b70d8a081035cb2aabaa8c53

This transaction takes an output, spends it and creates two new outputs.

A transaction is
- a list of outputs being spent (outputs destroyed)
- a list of new outputs created (new outputs)
- a list of signatures, one per output being spent
- There is an "inner hash" which is the hash of the list of outputs being spend and outputs being created
- You take the hash of the output being spent, compute the SHA256 of the inner hash, with the hash of the output. Then you sign this hash with your public key

A transaction may not create or destroy coins. A transaction must create outputs with exactly as many coins as are consumed in the inputs.

If you have 20 coins in an output, to send 5 coins to someone, you send 5 coins to them and 15 coins back to an address you own. The transaction consumes one output and creates two new outputs.

Serialization Format:

Skycoin uses a 4 byte length prefix serialization.
- A byte array is serialized by 4 bytes for the length of the array, followed by the bytes.
- An array of 12, 48 byte structs is serialized as a 12*48 in 4 byte prefix, followed by the elements
- structs are serialized similarly

To protect against transaction mutability, the inner hash of a transaction is the "id" of the transaction. The "hash" field is the the hash of the binary serialization of the full transaction.

Struct Data:

An output is defined as

type UxOut struct {
   Head UxHead
   Body UxBody //hashed part
   //Meta UxMeta
}

// Metadata (not hashed)
type UxHead struct {
   Time  uint64 //time of block it was created in
   BkSeq uint64 //block it was created in
   // SpSeq uint64 //block it was spent in
}

type UxBody struct {
   SrcTransaction cipher.SHA256  // Inner Hash of Transaction
   Address        cipher.Address // Address of receiver
   Coins          uint64         // Number of coins
   Hours          uint64         // Coin hours
}

Only the body matters for hashing. The UxHead is metadata, but is used for coinhour computation. Coin hours are intended as "soft constraints". A coin hour constraint may experience a soft violated when moving transactions and balance to a new ledger (ledger migration), but is enforced in general.

A transaction is

type Transaction struct {
   Length    uint32        //length prefix
   Type      uint8         //transaction type
   InnerHash cipher.SHA256 //inner hash SHA256 of In[],Out[]

   Sigs []cipher.Sig        //list of signatures, 64+1 bytes each
   In   []cipher.SHA256     //ouputs being spent
   Out  []TransactionOutput //ouputs being created
}

//hash output/name is function of Hash
type TransactionOutput struct {
   Address cipher.Address //address to send to
   Coins   uint64         //amount to be sent in coins
   Hours   uint64         //amount to be sent in coin hours
}

The inner hash is the SHA256 hash of the serialization of the In Array and Out array appended together.

CoinJoin Transactions

In Bitcoin,
- if two addresses are used as input in the same transaction, they belong to the same wallet
- This allows most addresses in a wallet to be linked as belonging to a single wallet with high probability from the public transaction history

A CoinJoin transaction is a transaction that mixes multiple outputs, from different wallets in a single transaction.
- Even a modest rate of coin mixing through CoinJoin (5% of transaction volume) introduces enough diffusion into network to severely frustrate association of specific addresses to individual wallets or users from public data. Especially for high volume services that end up processing most of the transactions on the network.
- If the third party CoinJoin server is trusted, this has the same level of privacy as ZeroCoin and quantum zero knowledge proof schemes, but with a much simpler protocol.

- In Bitcoin, you can tell CoinJoin transactions apart from normal transactions.
- in Skycoin, there is no difference between a normal transaction and a CoinJoin transaction.

The protocol is simple:
- you send inputs and outputs to a 3rd party CoinJoin server
- they take inputs/outputs from multiple users, randomize order, send back transaction
- each user signs their outputs and sends signature back to the server
- the server injects the transaction into the network

The 3rd party server is unable to steal your coins. If the transaction fails (someone did not send back signatures), you just try again until it succeeds. This is mixing, with no risk of theft of the coins.

There are three axises that information is leaked in Bitcoin
1. addresses from single wallet are colocated in transactions
2. multiple input addresses, single output adddress + change (vs multiple input with sender's coins going into multiple outputs addresses)
3. coin balances vs change addresses are identifiable. If you have 15.328942343 coins and send someone 1.0 coins, then you will have 1.0000 coins in one output and 14.328942343 in the change output. In practice this makes it easy to identify the output address.

Skycoin addresses #1 with CoinJoin for spatial diffusion
Skycoin can address #2 with higher level messaging protocol for receipts exchanging multiple addresses for transactions, off the blockchain, when possible. Also darkwallet type address generation from receiver public key. This also eliminates address reuse automatically.
Skycoin can address #3 by capping coins to integer values and distributing outputs in wallet to a known distribution in combination with #2

Once those three things are done, there is effectively zero bits of information in the public ledger about the receiver or recipient or owners. The outputs, addresses, balances become meaningless pseudo-random numbers that contain no information. They cannot be used to infer the hidden variables from the public record. Nothing can be determined from the public blockchain alone.

With discrete random variable A and random variable B, where A is public and B is unknown, we can ask "How many bits of information does A tells us about B". For transactions these three conditions correspond to P(B | A) = P(B) where A is the public visible variable and B is the unobserved variable that someone ones to infer from the hidden variable.

#2 requires "communication addresses". This is a hash of a public key, that is used to look up data in a DHT (distributed DNS system), to obtain a communication address and receive a list of unused virgin addresses to split the receiving of coins over. The infrastructure for this is almost done, but is a long term project.

Practical CoinJoin, may just be you and the CoinJoin server. The server would maintain a pool of outputs and mix them in with your outputs and never reuses addresses. The CoinJoin server may itself, mix its pool of outputs over other CoinJoin servers. This achieves a high level diffusion at a practical level of cost and implementation complexity.

Temporal diffusion, means that the payment into the N-output addresses occurs over multiple transactions instead of being localized with every input and output in a single transaction. The send is split up over multiple transactions.

Example:
- you have a wallet with outputs with coin balances of [1, 3, 5, 7, 11, 17]
- You want to send 12 coins to someone
- You use their communication address to ask for a list of virgin unused addresses for receipt of coins
- You send the output with 5 coins in one coinjoin transactions to address 1 (with multiple other wallets in the transaction); N inputs M outputs
- You send the output with 7 coins in another transaction to address 2
- They now have 12 coins

If the coins are stored with balances sampled from a known statistical distribution (as as uniform distribution of prime numbers less than N) then this does not leak any information

Similarly you could do coinjoin transaction and spent the 17 output, into four outputs
- input [17]
- output [1, 5, 11]
- The outputs all go to never used addresses
- the output of 1 and 11 goes to the recipient
- the outputs of 5, goes to a never used change address

Misc/ Bitcoin Thought Experiment: Perfect Pseudo Anonymity

Off topic but

To make a Bitcoin variant that leaks no information about wallets or owners from the blockchain, consider the following
- each output can only contain 1 coin
- each transaction can only spend 1 output and create 1 output
- addresses cannot be reused. An address that has received a coin in the past cannot receive another coin.

In this system, to send 10 coins, you have to do 10 transactions. The transactions each transfer a coin from a never used address to a never used address. This is the simplest system that leaks no knowledge about wallets/destinations/recipients.

You could also relax this to allow N inputs and M outputs, but keeping the single coin per output requirement.
- If each send transaction is implemented over a single transaction with N inputs and N outputs,  then the input addresses become "linked" and its no longer anonymous. If two addresses appear as inputs to a transaction you know they belong to the same wallet.
- If the send transaction is implemented with N inputs and N outputs, with CoinJoin, then information is still leaked, but it is fractional bits of information. If two addresses appear as the input to a transaction, the probability they belong to the same wallet is increased.
- If the send transaction is implemented as N inputs and N outputs, as CoinJoin but only 1 address/output from each wallet can be used as input, then no information is leaked. This is back to the 1 input, 1 output case. There is also diffusion. You know that each input will go to one of the outputs, but you dont know which. If you have N inputs and N outputs, there are N factorial ways of assigning the input coins to the output coins.

For a practical system instead of only storing a single coin per output (meaning 150 outputs or transactions to send 150 coins), you fix a probability distribution over the natural numbers and then ensure the inputs output balances conform to that statistical distribution.

Example:
Choose uniform distribution over the prime numbers less than 23
{2, 3, 5, 7, 11, 13, 17, 19}

- A wallet is a set of addresses.
- We store outputs associated with the addresses.
- The outputs have balances.
- We never use an address twice (deterministic address generation for infinite sequence of addresses).
- We store our wallet balance over multiple outputs, sampled from a statistical distribution chosen ahead of time

So we have 150 coins in a wallet stored over a number of outputs.
- We will send 50 coins to someone
- We will send 100 coins back to ourselves
- We pick numbers out of the statistical distribution until we get a set that adds up to 150 (our input balance)
- We split the setup into  a subset that sums to 50 and a subset that sums to 100 (if you cant do this, reroll)
- Each number in the subset that sums to 50, becomes an output that is sent to a separate unused address of the recipient
- Each number in the subset that sums to 100, becomes an output that is sent to a separate unused address, back to your wallet
- In practice, you would not spend all the outputs in the wallet

If you have N coins and are sending M coins. You want to sample uniformly from the set of arrays sampled from the distribution, who elements add to N and which can be split into two subsets that each add to N and N-M. There is a proper way of doing this, but its complicated (similar to proper way to shuffle an array, using permutation instead of random substitution for each element of array).

The key here, is that all information about which subset of the outputs is change and without are being sent to someone else, is eliminated. The distribution of outputs no longer depends upon user choice. However, if a user later spends two outputs from addresses in their wallet, in the same transaction, then we can link them as belonging to same wallet (which allows us to go back and gives information about the partition of outputs into the change addresses and the addresses of the recipient after the fact).

Therefore a practical system seems to require a CoinJoin type mixing at each stage and requires that the send is split over multiple transactions rather than all inputs and outputs created in a single transaction.

Summary:
- fix the distribution of output balance to a known probability distribution (eliminate information about which addresses are change)
- to do a send, send from N addresses to M addresses. N addresses to 1 address + change, like Bitcoin leaks information
- dont reuse addresses
- CoinJoin with mixing of addresses from multiple wallets as inputs for each transaction is required. Unless each transaction is 1 input and 1 output. Otherwise information is leaked that associates two addresses to the same wallet, by the fact those addresses appear as the owner of the inputs of the same transaction.

It is theoretically possible, if you work through the above, to get perfect level of privacy that cannot be improved, but in practice the requirements are too tedious. "Good enough" privacy means
- all the mixers form a single large mixer network (they mix together over each other over time) and that users have the option of mixing (default support for CoinJoin transactions)
- multiple input and multiple output addresses (unlike Bitcoin's single output address type sends)
- eliminating address reuse for default for transactions (working on this, similar to the above)

IPO Update

It done when its done. Fixing bugs.

- There was bug where OSX/linux treat files differently depending on whether the file name has uppercase/lower case letters that was affecting the webgui.
- Fixes to GUI/web wallet
- web wallet GUI did not report or show error on failure of send transaction
- There was bug where if you create a wallet, then close client and create another wallet, then close and reopen the second wallet will disappear (but only if you did this in the same day according to unix time), because the second wallet will have the same name as the first wallet because an uninitialized pseudorandom number generator was used to generate the random part of the wallet filename that is appended to the date. The wallet seed always used the secure random number generator, so did not affect security, but disappearing wallet bug was very disturbing.
- changed transaction hashes from double SHA256 to single SHA256 to be consistent with identifiers of other data objects
- JSON serialization/deserialization of transactions and outputs
- a couple of other things

I want to move on from coin debugging and get DHT implemented so the darknet and consensus algorithm running. Debugging and re-factoring is 10x slower than getting new code working.

I think the client is ready to start distributing coins. Running final checks and code review.