This idea has been scattered throughout some other threads, but there is no one place that fully explains the idea with pictures.  I believe this relieves two major problems with the network at once -- compression/pruning, and lightweight node security -- and does so in a non-disruptive way.  I am not positive that this is the right way to go, but it definitely warrants discussion.

---

Summary:  [SEE ILLUSTRATIONS BELOW]

Use a special tree data structure to organize all unspent-TxOuts on the network, and use the root of this tree to communicate its "signature" between nodes.  The leaves of this tree actually correspond to addresses/scripts, and the data at the leaf is actually a root of the unspent-TxOut list for that address/script.  To maintain security of the tree signatures, it will be included in the header of an alternate blockchain, which will be secured by merged mining.  

This provides the same compression as the simpler unspent-TxOut merkle tree, but also gives nodes a way to download just the unspent-TxOut list for each address in their wallet, and verify that list directly against the blockheaders.  Therefore, even lightweight nodes can get full address information, from any untrusted peer, and with only a tiny amount of downloaded data (a few kB).  

(NOTE:  I have illustrated everything as using straight merkle-trees, but as noted in the downsides/uncertainties section: a variant of the merkle-tree will have to be to used that guarantees efficient updating of the tree.)


(1) Major Benefits:

• (1a) Near-optimal blockchain compression:  theoretically, the size of the pruned blockchain would be proportional to the transaction volume (thus could go up or down), instead of the entire global history which always increases in size.  In practice, it wouldn't be so clean, but you really won't do any better than this.
• (1b) Trustless lightweight-node support:  New nodes entering the network for the first time, will only have to download a tiny amount of data to get full, verifiable knowledge of their balance and how to spend it (much of which can be stored between loads).  A single honest peer out of thousands guarantees you get, and recognize, good data.
• (1c) Perfectly non-disruptive:  There is no main-network protocol or blockchain changes at all.  All the balance-tree information is maintained and verified in a separate blockchain through merged mining.  In fact, it's so non-disruptive, it could be implemented without any core-dev support at all (though I/we would like their involvement)
• (1d) Efficient tree querying&updating:  The full-but-pruned nodes of the network will be able to maintain this data structure efficiently.  New blocks simply add or remove unspent coins from the tree, and all operations are "constant time and space" (there is an upper limit on how much time and space is required to prove inclusion of, insert, or delete a piece of data, no matter how big the network is)
• (1e) No user-setup or options:  Unlike overlay networks, achieving full trust does not require finding a trusted node, or subscribing to a service.  Just like the main blockchain -- you find a bunch of random peers and get the longest chain.  This could be bootstrapped in a similar fashion as the main network.

(2) Downsides and Uncertainties:

• (2a) Complexity of concept:  This is not simple.  It's a second blockchain, requiring merged mining -- though if it is successful and supported by the community, it could be added to the network by requiring that miners compute and include the root hash of this data structure in the coinbase script (just like with block height).  This is entirely feasible, but it could be a bear to implement it.
• (2b) Uncertainties about lite-node bootstrap data:  Depending on how the data is structured, there may still be a bit of a data for a lite node to download to get the full security of a full node.  It will, undoubtedly, be much less than downloading the entire chain.  But, there is obviously implications if this security comes at the cost of 1 MB/wallet, or 100 MB/wallet (still better than 4GB, as of this writing).  UPDATE: My initial estimate based on the "Hybrid PATRICIA/Brandais Tree" (aka Reiner-Tree), is that a wallet with 100 addresses could verify its own balance with about 250 kB.
• (2c) [SEE UPDATE AT BOTTOM] Merkle-tree Alternative Needed: Vanilla merkle-trees will not work, because adding or removing single branches is likely to cause complete recomputation of the tree.  But it should be possible to create an alternative with the following properties:
  
  • Commutative computation:  a node should be able to get the same answer regardless of whether the tree is computed from scratch, or is based on updating a previous tree.
  • O(log(N)) updating: removing or adding a single leaf node should be able to be done in O(log(N)) time.  With a vanilla merkle tree, this is true only if you remove a node and add a node to the same leaf location.

(3)  Assumptions::

• (3a) Need verifiable tree roots:  I argue that a regular overlay network won't suffice, solely because it's too easy for malicious nodes to spread incorrect data and muck up the network.  If there's enough malicious nodes in an overlay network, it could make lite nodes that depend on it unusable.  I am assuming it is necessary to have a verifiable source for pruned-headers -- a separate blockchain succeeds because correctness of data is required to be accepted.
• (3b) Merged mining does what we think it does: It is a secure way to maintain a separate blockchain, leveraging existing mining power.  
• (3c) Efficient sorting:  Leaf nodes of the main tree will have to be sorted so that all nodes can arrive at the same answer.  However, this can be done using bucket-sort in O(N) time, because the leaf nodes are hashes which should be uniformly distributed.

---

Alt-Chain Merkle Tree construction:

-- For each address/script, collect all unspent-TxOuts
-- Compute merkle root of each TxOut tree
-- Sort roots, use as leaf nodes for a master-merkle-tree.  
-- Include merkle-root of master tree in alternate chain header.

---

Getting your balance:

-- Download headers of both chains
-- Request unspent-TxOut-hash list.  
-- Compute sub-merkle root for this address
-- Request secondary-branch nodes  (O(log(N))
-- Compute master root; compare to block header
-- Request the full TxOuts for each unspent-TxOut-hash above

---

Alternate Chain:
All data is included on the alternate blockchain, which is maintained through merged mining on the main chain.  This is only one extra tx per block on the main chain.  That is the full extent of its impact on the main chain, and any nodes that are ignoring/unaware of the alt-chain.

---

Yes, this is a huge undertaking.  Yes, there's a lot of uncertainties. Yes, I need a new merkle tree structure.
But, this idea would kill two massive birds with one stone (kill two albatrosses with one block?)

Alright, tear it apart!

---

---

UPDATE:

After lots and lots of discussion and debate, I believe that the address index should be maintained as a trie-like structure.  Other's have expressed interest in a binary-search tree (BST).  Either way, the structure can be adapted to have the same properties we desire of a merkle tree, but with a lot more flexibility, such as very quick insertion, deletion, querying, updating, etc.  My preference is the creme-de-la-creme of tries -- a hybrid PATRICIA tree (level-compressed trie) and de-la-Braindais tree (node-compressed).  It looks something like this:



The structure would be indexed by TxOut script ("recipient"), and each node is recursively authenticated by the nodes below it.  The uniqueness of the trie structure guarantees that there is exactly one solution for a given set of TxOuts, which also means that only the existing set of TxOuts need to be obtained in order to create the trie (the BST requires replaying all transactions, in order, to have a well-defined internal structure).  For education on trie structures, see my pretty pictures in this post.

If you use an escrow, I'm in.

I seem to recall it being a bad idea to post payment address where all can see, because anyone can monitor payments to it and then claim it was theirs?

M

I am interested. PM sent

Bitcoin is at a decision point. Do we want to stick with the 1 MB block size limit and become merely a reserve currency or the equivalent of gold in the present day system? Or have we become used to the convenience of cheap, rapid, world-wide money transfers and would we prefer to become a commerce platform to supplant Visa, PayPal, etc.?

So far it seems we can't have both. Increase the block size to handle millions of transactions per hour and the hardware requirements to run the system will rapidly preclude anyone running the program from home and having a say in being their own bank.

On the other hand if we either hold the present cap or go with some scheme to only allow it to grow very slowly we'll soon start seeing the pinch on transactions. Eventually it may only make sense to send bitcoins in excess of $1000 or more due to fee levels. Commerce would be impossible except for using third party providers such as MTGOX codes that stay off the blockchain.

My proposal would allow us to have our cake and eat it too. It enables low cost world-wide decentralized transactions and store of value as we've come to expect with bitcoin. It also allows the network to expand to handle the massive volumes we'd like to see ourselves grow into.

Bitcoin 1 is what we have today. Quite convenient that the addresses start with a 1 actually. This chain would continue with the 1 MB per block hard cap. This is the store-of value chain that people can run nodes for on consumer hardware at home. It doesn't handle every satoshi for every losing bet on the entire internet. When someone wants to use this network for a transaction they can eventually expect to pay $5 or more in transaction fees.

Bitcoin 2 is the transactional blockchain. This one will quickly get to the point where it will require special hardware most likely in colocation centers to handle the deluge of transactions. Now what makes this different than an alt chain? The answer is how you get Bitcoin 2 coins. The way to get these coins is by proof of burn of your Bitcoin 1 coins. I propose setting minimum size limits for conversions between the two chains such as to go from Bitcoin 1 to Bitcoin 2 you have to send at least 1 coin. To go from Bitcoin 2 to Bitcoin 1 you have to send at least 50 coins.

Merged mining of both chains would obviously be simple for anyone capable of mining on the Bitcoin 2 network. One concern I have is if Bitcoin 2 could launch without a block subsidy existing solely on fees since we want to keep the original 21 million cap feature intrinsic to the bitcoin idea. Miners might also initially resist it as it would provide a lower fee area for users to transact. Another idea that could be pulled from previous alt chains would be setting a shorter block time. The prices would be identical between the chains avoiding any confusion on the part of users. Addresses starting with a 1 or a 2 would help differentiate which protocol was being used.

Building a wiring harness for a personal project that would turn into a 200+ piece run...

24pin Molex - female

TO

6pin  Aux - Female
15pin Sata Female




Any ideas on how to find a place to MFG them?

I think they will cancel the unpaid orders, i have 3 orders open and 2 of them unpaid because the 15 minutes time limit to pay with BTC was gone.

I am auctioning off Bioshock Infinite AMD codes for steam. There are 2 codes available to bid on. Minimum starting bid is 0.005 BTC. The auction ends Wednesday April 24 at 12AM EST based on the forum clock. You may bid on one or both codes. Bidding is in bitcoins with three decimal places. Example 1 @ 0.005  Example 1 @ 0.015 Example 2 @ 0.05 (this is two codes at 0.05 bitcoins each for a total of 0.1 bitcoins). I will PM the winners the codes following payment. Winners have 16 hours from completion of auction and my posting of payment address to pay. Good luck! Codes are registered at www.amd.com/neversettlepromo .

Please bid in increments of 0.005 bitcoins. Thank you.

The past week I can't stay connected. cgminer is not switching to backup pools either, its all rejected shares the first time. Today it crashed cgminer on all 11 of my pc's. It just showed the program stopped responding message. I just gone done redirecting them to slush's pool a couple hours ago to see if things were working again. Guess not.. I was very impressed before, I had no issues since switching to stratum except for the past 10 days or so.

leave out the "ipv6."?

anyway, looks like stratum mining is back up & working for me here ...

I have.

But all 3 pools I had in the conf went down at the same time. Cards were happy getting a break though.

It was down, and is back up now.

Onyl Kepler equal or higher than titan GPUs. GTX680 is K10 architecture, you can say it is a better fermi. K10 has no funnel operator :-(. Thay have the same amount of 32Bit registers and a lot of opration have the same speed  than a k20 but the importend operations are not available.

Btw I recommend to getwork miners to update to Stratum. Not that the Stratum pool is much more stable than Getwork backend, but considering the Stratum hashrate is on 95%, the Getwork backend will be closed down pretty soon (when Stratum will be on 99%).

Ahh ok sorry my bad, thanks for the clarification.. so your saying the 690's and below will still be somewhat limited or same speed with out much boost?

I have a gtx 680..

I'm migrating the database right now. Website is off, pool will be just restarted in few minutes.

I'll set minimal threshold back to 0.01. Considering current rise in price, threshold 0.05 is quite big for common users...