Bitcoin Forum

Here is what I propose:

• Every block in the block chain only pays out 90% 99.9% of its block reward. The other 10% 0.1% is kept on reserve in the block.
• A second "balance" chain is created, which consists of transaction chain blocks hashed in a tree along with the usual nonce and a hash of the previous balance chain block.
• Each balance chain block holds the balance of every non-empty bitcoin address up to the point of the last transaction block included.
• The balance chain difficulty is 100X 1000X the transaction chain difficulty.
• The node that solves a balance chain block recieves all of the reserved block rewards from the included transaction blocks.
• In this manner, over time old transaction blocks can be forgotten since the most recent balance block plus the most recent transaction blocks are all that are needed to verify transactions. To keep the integrity of the network, of course, more history should be saved, but we probablly don't need more than a few thousand balance blocks while still being very secure.
  In this manner, the only data required for each full node would be: (1) block headers for all balance blocks (2) the most recent balance block (3) transaction blocks that occurred after the most recent balance block.
  

Do you think this scheme could work? I'm not even remotely an expert on this stuff, so forgive any glaring errors. Thanks!

That's pretty interesting. One thing that I see is that you would have to have people mining all the chains though and each one would still be vulnerable to the 51% attack unless say they confirm a merkle hash of each block in each chain.

If you want to be able to verify transactions from "most recent balance block + transactions since this balance block", this "balance block" does not only need to record the balance of each bitcoin address, but in fact (the full details of) each "non-spent" transaction.
Some data around block height 181185: there are 659574 bitcoin addresses with a non-zero balance, and 1591739 "non-spent" transactions. This is at least 391 Mb of data you need to include in the balance block (at least 258 bytes per transaction), if my math is correct. Or at least a 1 hour download on a decent DSL line (not taking into account other nodes will want to get the data too).

So this can reduce storage space requirements (Mbytes instead of GBytes) and transaction lookup times, but network load will be higher (peers need also to relay the second chain).
At the current transaction volume (1100 transactions/h = 400 kb/h or 9.6Mb a day), it is definitely not a good solution: 1 balance block a day = 400 Mb a day (390Mb for that 1 block + 9.6Mb of new transactions), or an increase of 40 times the network load !

Why would the balance chain need to be shared on the network? It can easily be computed using the transaction chain, since each balance block specifically covers "up to" a certain transaction block. Only the nonce values would have to be shared on the network for the balance blocks.

Hmm interesting.

So the node solving the balance block just broadcasts the balance block header and every node constructs and verifies the balance block locally.  Once a balance block is deep enough in the balance blockchain it for all intents and purposes can become the genesis block and data prior to it (both balance blocks and tx blocks) can be truncated to save space.

I would make the balance block more like tx block difficulty x 1000.  Since you need to record all unspent outputs having too many balance blocks simply increases the workload on the network.  At block difficulty x 1000 there would be a new balance block ~ once every week.

So the next question becomes how do you bootstrap a new node if not all nodes have blocks going back to the genesis block?

Boostraping a new node could be done something like this:
Node requests the oldest active balance block (say balance block 6** blocks deep.
Node downloads this block and considers it an unverified "genesis balance block".*
Node requests and downloads all tx blocks since the "genesis balance block".
Node requests headers for the newer balance blocks.
Node constructs and verifies the subsequent balance blocks.

Node now has a complete history from the balance block to now.  To spoof this would require work equal to (balance block depth)*(balance block difficulty)

* This new node will never have any tx history prior to this block.  From this node' point of view the network began here.
** 6 was chosen arbitrarily but some number would provide sufficient assurance that the block is legit.  If a BB is 100x harder than normal block then verifying a chain 6 deep represents 600 blocks worth of hashing power.  

A very interesting idea.

Something along this line is necessary... In the design there's some talk of merkle-trees, which I think were supposed to perform a similar function, but I believe something like this is ultimately a better solution.

Changing the block reward seems a poor choice. I propose instead that we rate-limit the balance blocks, e.g. one per difficulty change, and then hash them into the same chain (e.g., have the solved block reference both the balance block and the parent block), and just wait something like 60 confirmations before relying on the balance block (an inconsistent balance block would cause the solved block to be rejected).

-bgc

It might be necessary to require that the first block after a difficulty change be a balance block...

-bgc

That won't work.

You wouldn't be able to make it higher difficulty.  If it was 100x normal difficulty then there would be no blocks for roughly a day.  If the balance block wasn't higher difficulty then it would be "weak".    An attacker could cheaply construct a false chain.

By making the balance blocks higher difficulty you make it computationally infeasible for the attacker to construct an entire false chain.  Remember if  some old balance block eventually become a new "genesis block" then we need to make sure it is not possible for an attacker to simply rewrite the chain. 


As an exmaple if balance blocks are not relied upon until they are 10 blocks deep into the chain AND balance block difficulty is 1000x normal then to create a false chain would require the attacker to have same hashing power as generating 10,000 normal blocks.

In your proposal it would be far too easy to construct a false chain that begins with a fake balance block (one low difficulty balance block and 60 more blocks).  An attacker could spoof new nodes into think that is the "reality".

In my proposal, the balance block is validated for consistency by all nodes, and eliminated if its inconsistent, and there's no extra reward for this... but the block isn't USED until it has e.g. 60 or 600 blocks after it, essentially 'locking it in'. How does this not work?

-bgc

FYI I made a few edits to the OP ( using strikethrough ) based on the suggestions made thus far

Then what is the point of even having a balance block?  The point of a balance block would to allow nodes to eventually forget older data.  New nodes won't have old data to rely upon.  By making the block cheap to construct you just made it trivially easy for an attacker to "spoof" new nodes and provide them with a "false history".  It is a modified version of an isolation attack except more devestating and much cheaper. 

If you never get rid of old data then yes new nodes can reduce the danger by downloading everything back to the genesis block however there is no point in even hashing all unspent tx into a balance block.

So you either can rely on an old balance block as canonical or you can't.   If it is cheap to construct then you can't.

I think it needs to be analyze but it has merit.  The reality is Bitcoin will never change to that but it would be a good concept to test in an alt chain.  It puts a max limit on how "old" the block chain is.  Rather being  "from genesis to now" the blockchain becomes more a rolling 10,000 (or 50,000, or 100,000 ) blocks.  

True, it should be tested as an alt-chain. Maybe "rollcoin" or something.

I'm sure there are a million problems with this approach that just aren't immediately apparent

My suggestion is NOT cheap to construct. If you can isolate a node and it carries NO history, then you could generate a fake history just as long as the current blockchain with a few graphics cards: just imagine the difficulty staying constant from the genesis block. Currently this is prevented in two ways: the client software includes hashes of some known blocks, and the bootstrapping process connects you to what are supposed to be legitimate nodes. Clients would not trust a balance block until it has e.g. 600 blocks on top of it at the current difficulty.

Maybe I'm missing something obvious, can you link me a description of the kind of attack or limitation that is not present in the current network but would be present with a balance block extension?

-bgc

I'd say avoid any rule changes by forgetting about changing bitcoin's reward scheme to incentivise miners to hash away at the balance chain, since updating the ledger once a week is practically free, merged mining makes the hashing cost nothing extra, and by participating they'll be enabling significant disk space savings for themselves going forward.  Plenty of incentive there already IMO.

Then it can be gradually adopted by miners without controversy, and once enough of them are on board, as measured by the balance chain block rate, other clients can feel free to start trusting it.

Also, instead of having a simple tx tree, maybe use something like this structure instead: https://bitcointalk.org/index.php?topic=52859.msg885838#msg885838 (https://bitcointalk.org/index.php?topic=52859.msg885838#msg885838).

I'm an amateur here too, though, so maybe there are lots of problems with this we're not seeing.

Hmm the more I think about this the more I think it could work.

In reality, you only need to store the most recent balance block and subsequent transaction blocks. As long as you have block headers for all previous balance blocks, you can be assured that noone can cheaply spoof a fake balance chain due to the high cost of each proof of work. You wouldn't even need old transaction block headers, and you could easily bootstrap a new node just by sending them (1) the balance block headers (2) the most recent balance block (3) all transaction blocks that occurred after the most recent balance block.

This would cut storage requirements massively.

I just need to find some free time so I can code this up

I had grand plans of pioneering ideas like this.  And this might be the other half of the solution to the other scalable-blockchain thread (which I expanded upon, and d'aniel linked above: https://bitcointalk.org/index.php?topic=52859.msg885838#msg885838).  Complexity is a problem though... creating a new blockchain with the networking, etc, is not a trivial task (or maybe it is, since there's so many other merged-mining chains to use as a template).  Also, I don't know what the compute-complexity of the balance trees are.  I'm going to have to spend some time with pencil&paper on this one...  At least the chain itself will be small once it's running...

On the upside, if it is feasible, it would be totally worth it.  It would completely enable lightweight nodes to get on the network and verify their own balances and unspent-output lists without downloading even the pruned blockchain -- they'd only need the headers of the main chain and balance chain, and one merkle branch per address (a few KB).  I had kind of looked past the idea because I assumed it was going to cause a hard fork, but using a second chain seems to solve that elegantly...

So code up a prototype:

+ Implement code that computes and publishes 'balance blocks' and 'balance block hashes'. Convince a couple people with extra download bandwidth to run it.
+ Modify one of the bitcoin implementations to download the latest 'balance block' from some trusted place at startup, and use it if transactions/blocks can't be found in the traditional block database.
+ Extra credit/paranoia : query a couple of trusted places for the balance block hash, and make sure it matches the hash you got.
+ OR: randomly spot-check the balance block by requesting blocks in the traditional way, and make sure the balance block doesn't list any outputs as unspent that are actually spent.

You don't want bitcoin address balances, there are no addresses way down deep inside. You need to know which transaction outputs have not yet been spent, and the value of those outputs.

I'm not excited about this proposal, because I think it is solving a problem that doesn't need solving yet, and my priorities for bitcoin continue to be wallet security and network stability, not making it quicker for newbie solo miners to get a full blockchain so they can start validating transactions/blocks.

Gavin,

If your re-read my proposal on the other thread, the proposal does enable you to get the entire unspent-txout-list for any address, with only a few kB from the network (after you have the headers).  This means that you only download a couple kB from the network for each script/address in your wallet and you can operate fully without trusting anyone or anything except for the headers.

Hash160 addresses used more than once will have the same script hash and thus be aggregated into a multi-node sub-merkle-tree.  BIP 16 and other creative scripts used once will be leaf nodes represented by only a single-node sub-merkle tree (well it would just be a single value, not a tree).

This isn't for miners... this is for lightweight users.  It means that I can import an address on my phone wallet and get a full list of unspent outputs with only the headers plus a few kB from the network -- you only need the master-merkle branch (which is O(log(N)) where N is the number of unique scripts/addresses in the blockchain) and the sub-merkle tree (which is the number of unspent txouts for that script/address).  That's a huge improvement for Bitcoin as a whole, when even crappy smartphones can be 99% fully operational, using only block headers and a few kB from the network.  (I say 99% because they can't do 100% of the verification needed for mining, but they can at least verify that the inputs of a zero-confirmation-tx are valid and unspent without relying on any other service).

It's always been an assumption in my mind that lightweight nodes will be second-class citizens in the BTC world.  But if this can be made to work, computationally, I believe even lightweight nodes can be as secure as full nodes.  And of course, you get the 90%+ compression.  And it's all opt-in -- client developers can just ignore the second chain if they want.

The remaining uncertainties are:  (1) How complex will it be to maintain a separate blockchain and all that stuff, and (2) what is the compute complexity/optimizations of building & updating such a blockchain?

etotheipi:

Sorry, I was responding to the original proposal, not yours, I should have made that clear.

Better protocol support for lightweight clients is a Good Idea.

Hey thanks for the feedback, I am learning a lot more about Bitcoin just by thinking about this stuff ( and realizing how little I really understand! ).

Ideally yes a test altchain is the way to go.

  Under this scheme, the relative reward for mining in the two chains would likely vary over time.  You probably want to make the expected reward per compute cycle equal for the two chains or you might see fluctuations in hashing power between them.  Merged mining, like d'aniel suggested, is probably a better idea.

I like being able to trace bitcoin all the way back to the generating transaction.  Not that I've done it, but it's interesting and I imagine it could be useful.  I started looking at this thread because I had an idea (https://bitcointalk.org/index.php?topic=85433.0) (deemed "bad" for now because of some aspects which I think can be fixed) for increasing the cost and decreasing the benefit to thieves who steal bitcoin.

Although this is an interesting idea, I don't think that it's viable.  How do you encentivise miners to secure this alt-chain?  However, a running balance table server isn't a bad idea as a pay-for service for light clients to use as a means to check their own addresses to make sure that they havn't missed something.  For example, one (or serveral) balance servers could exist that individual lightweight clients could contact out-of-bitcoin-band as a quick check upon startup, or a secondary check.  If the balance returned does not match, the lightweight client may have to try again, but if the balance returned matches what it thinks that it should have upon startup, the client can happily assume that it has all the relevant transactions to continue.

The service could be paid for in an anonymous, monthly fee.  Once every 30 days or so, the client tries to send the chosen balance server a small tip, and the server collects the addresses presented in that transaction (since lightweight clients tend to use fewer new addresses, or a more sophisticated lightweight client for the desktop could simply create a special transaction that uses as many input address as may be important, or simply uses the monthy transaction to consolidate addresses into a new operating address producing the server's monthly fee in the process).  When the client is restarted in the middle of the month according to the datetime available to the client, it first checks to see what it thinks that it's balance is, and then sends off the appropriate requests to the subscribed balance server.  If the server responds with the matching balance, the client happliy can quick boot and be ready for action (like bitcoinspinner).  If the balance returned is differnet, the client then should tell the user that it needs to update itself before spending, and proceed to do so in the background.  If the server feels it's not been properly paid, it returns an error code; or of the address is unknown in the blockchain; which would likely be the same as a zero balance to a running balance server.  Lightweight clients (that hold block headers) could still manage local transactions sans live Internet access, but with a warning to the user that Internet was not present and this could present a risk.  This setup would allow android clients to get into a working condition as fast as BitcoinSpinner most of the time, while also permitting delayed transactions/offline transactions to occur, which BitcoinSpinner & BitcoinJ most certainly cannot do.

Why do users run Tor exit nodes?  Why do people participate in P2Pool?   There's a dozen things like it -- and people do it anyway because it adds value to the system (which means it also adds value for themself).  If the incentive is that we help avoid centralization of a this global currency, then people will do it, as long as the cost isn't too high.

You're right, though, if it's too expensive: if it requires a system with 192 GB of RAM and 48 CPU cores to keep the second chain updated, then it's probably a no-go.  But in the absence of that, people will do it, maybe solely because they're selfish and they want better performance&security on their own smartphone. 

I haven't done the calculation yet.  However, I suspect that once the second blockchain has been seeded (i.e. one can securely acquire the current unspent-txout-tree), then a regular computer will be able to maintain and update that unspent-txout-tree (short of Visa-level tx volume).  In that case, there will be no problem getting users and miners to support it,

EDIT:  Also, If merged mining didn't exist then I would 100% agree with you.  But because it does exist, the second chain be secured for "free", which lowers the cost and risk dramatically.



I think what you've posted there is a good idea, in general.  However, I'm more interested in finding solutions that don't involve third-parties and extra fees.  Or rather, I just don't like conceding to them until it's clear that a decentralized P2P solution is infeasible. 

  Not sure that this is a good analogy, since there would be economic incentive to merged-mine both chains.

I don't follow.  The proposal in this thread suggests that there would be a second chain, and it's purpose would be for nodes to securely exchange pruned/compressed blockchain snapshots.  The result of mining a block on the second chain would not produce anything of financial value, but it doesn't matter because it's basically free with merged mining (besides a software upgrade).

If someone or a team produced this solution, and there was great confidence in this solution being correct and usable -- then the cost for users to support it is:

(1) Upgrade their mining servers and probably miners, too.
(2) Spend electricity computing unspent-TxOut-tree snapshots

I have no doubt that someone or a team would step up and produce the solution.  And I have no doubt that users/miners would do (1) if they were confident that it would work.  Number (2) is more uncertain, but if it's a matter of a CPU-minute every hour, most miners would do it given the benefits it brings to the network.  Plus, you only need some miners to participate, you don't even need a majority.

Btw:  I don't have much experience with merged mining, so maybe I'm making a poor assumption here...

Perhaps, but only if the benefit to the network is demonstratable as compared to alternatives.  While a p2p solution might be possible, it's not always necessary.  And if it's not necessary, it's not likely resource/economicly justifiable.  Bitcoin is p2p for sound reasons, but what reasons carry over to what amounts to a tracking service?  If the server that a particular client chooses should go down or be DDOS'ed, the result from the perspective of the user is the same as if he had left his service area; a temporary inconveince.  And in the case of header-only/lightweight clients, not necessarily even a dehibilitating one.  I'll admit, this idea has merit; but it seems to lack encentive.  I can admit I might be overlooking something here, but what gain does a miner have for participating and sharing his findings?  Both are important, because if his gains are personal, he then has limited incentive to share the results.

A co-dependent blockchain with the same period as bitcoin itself seems like it's just adding noise.
However, a daily digest of (postive) balances might be useful in a number of ways; with (perhaps) an hourly update produced of recent (but 6 confirms deep) changes to that digest.  I can see such a bitstream being used as a secondary verification of authenticity for major retail chains that didn't want to track the blockchain at every location, but wanted to also protect against some form of local hack/fraud/yet-unknown-attack-vector.  I could also see small, independent vendors on the edge of the network (read not enough bandwidth to commit) to maintain a realitively trustworthy local database of address balances so that he could accept bitcoin transactions from walk-in customers without getting hosed by every script-kiddie in his neighborhood.

Just to clarify:  I have in mind the hybrid solution between this thread (a second chain w/ merged mining for non-disruptively maintaining snapshot info) and my modification of the unspent-TxOut-tree idea for compression and pruning (https://bitcointalk.org/index.php?topic=52859.msg885838#msg885838).  If all we were talking about was compression/pruning, then I understand why you're skeptical, though I still disagree (I believe it would be widely supported).

But we're talking about any client having the ability to retrieve full unspent-TxOut lists, nearly instantaneously, with the same confidence as a full node, with only headers, and while maintaining complete decentralization.  If lightweight clients suddenly have the same usability & confidence as full clients and everything remains completely decentralized -- that's an extraordinary boon to the network that a lot of users would go out of their way to support.  I mean, really go out of their way to support it.

Hell, even if it was just compression/pruning, I think users would still support it.  Therefore, I think the extra benefits would have users racing to implement and support it.   Though, if that idea turns out not to work, it is still relevant to talk about the expected acceptance of a second blockchain solely for compression purposes.

Yet, 1) those goals are the same as the pruning & lightweight client features of the protocol, not yet ready and 2) I don't agree that those goals can be met with a dependent & parallel chain any better (and probably less well) than #1.  You're still talking about a potentially huge block/file that would have to be downloaded every ten minutes.  What gain is there in that?  Might as well stick with the main network or an overlay such as Stratum.

And it's quite literally impossible for lightweigt clients to have the 'same confidence as" a full node.  The best that a lightweight client can have is some confidence.

It certainly doesn't hurt to talk about it, but I don't agree that such an idea has merit when compared to other methods od achieving similar goals already discussed.  And if I can't see it, I'f wager that there are many more who are going to be sceptical of it's value as well.  Without a minimum critical mass, nothing is going to matter.

Go back and read the proposal.  It allows for a lightweight node to carry nothing but the headers (for both chains) and then it can verify the full unspent-TxOut-list directly against the headers.  Ultimately that's what a full node does -- the headers are the base of all trust.  Therefore, once you've got the headers and the longest chain figured out, a wallet of 100 addresses could be sync'd and verified against the headers with the same confidence as a full-node with less than 1 MB of downloading.  (that's for the initial sync -- after that you either re-sync, or update the unspent-TxOut-list for your wallet with the new blocks/tx as they come in)

For the nodes that are maintaining the compressed/pruned list, they only need to do that massive full-chain calculation once.  The tree/snapshot can then be updated incrementally, which is many orders of magnitude faster than recomputing the whole thing on every block.



My concern with other methods is lack of verifiability that your node actually has the correct tree.  It could be corrupted, or maliciously modified, and there's no way to know, since nothing in the tree is traceable back to the headers.  The only solution is to trust a third-party/server, or download substantial portions of the entire blockchain.  

It's for this reason that I thought blockchain pruning would not work without enforcing accurate snapshot hashes in the header, and thus it wouldn't work because no one would support such a huge change to the protocol.  But the idea of putting all that data into another chain with merged mining makes it completely feasible and non-disruptive to others that don't care.

While this is true, it's far from a complete picture of the intergrated security model that full nodes have access to.  In order for a lightweight client to accept a payment transaction, it must either 1) have Internet and access to a supporting server or 2) accept the evidence that the sender's client provides.  Although a lightweight client sending to another should have no problem sending a copy of the input transactions, which the lightweight client can then verify that it fits into it's own claimed spot on the merkle tree connecting to it's own copy of the block header, this is still not quite the same as what options of verfications that a full client has.



I don't see that, sorry.


Of course, but this is holds no notable advantage over just a lightweight client once the running network can fully support them.  I can't really see what the use case is beyond what lightweight clients & pruning can't provide.


???

Of course a lightweight client can download the merkle tree and verifty that.  It jsut needs to be able to identify conditions that would prompt that action based upon some local risk model.  There is nothing that prevents a lightweight client from collecting the block headers, and downloading up to and including an entire block if a risky inbound transaction is received.


???

The block headers do contain accurate snampshot hashes.  That's why the merkle tree exists and why the merkle tree root(s) (current block & previous block) is in the block headers.

That's pretty straightforward.  Give them more BTC than they could earn mining Bitcoin.  As the reward drops it will only become that much easier.

The solution I proposed does not rely on a "supporting server". It does not require trusting the sender's client.  And the internet access part is a given for any node that has any hope of accepting zero-confirmation transactions with less than complete-trust.  I have assumed all along that the node has a connection.

The solution I proposed does not require any trust of any nodes, any more than a full node on currently trusts any other node -- you trust the longest chain of headers.  Any data that is consistent with the longest chain is as trustworthy as it gets, regardless of who it came from.  In this case, the second-chain headers contain a hash of a merkle tree specifically designed for a node to verify the complete unspent-TxOut-list for any script/address.  

Let's say you have only the headers of both chains and you are verifying  an input of a zero-conf tx.  A peer sends you a list of unspent outputs.  But, how do you know the list is legit?  Even if you verified the outputs are part of the blockchain, how do you know they haven't been spent since then?  

The solution I proposed does exactly this.  I download an additional 1-2kB of data (the master merkle branch for that address), and then I can see that the unspent output list is correct against the headers.  This includes the fact that none of those outputs have been spent since then.  


[/quote]

Then we're not talking about the same thing.  I'll make a graphic to depict this concept more clearly.  Until then, this conversation can't continue, because you will otherwise never believe that what I am proposing is possible.  I didn't believe it was possible, either... which is why I'm so excited about this idea because it actually does this :)

Then this proposal is already a fail.  Because what do you offer then?  Decentralization?  You might as well say 'the cloud' for all the relevance that would have to the end user.


Again, not materially different than a lightweight client or any normal full client willing to provide a pruned block upon request.


Not any data so consistant, which is why bitcoin requires the format that it presently does.  The blockchain structure is self-re-enfircing from amny directions; not just from a single merkle tree branch up to the block header.  It is possible, although unlikley, to create a transaction that falsely gives you an arbitrary amount of bitcoins from non-existant inputs and find a merkle tree branch that it can 'fit' in, but that would never last a millisecond of verfications from a full client.


But requires constant Internet, so offers zero advantage over the (full future) live network or an overlay network such as Stratum.  In fact, Startum does eactly what you seem to want to do both decentralized and without an alt-chain.

Again, a lightweight client can become up to a full client at will, as well as participate in Stratum where it might need to.  There is noting that prevents this kind of actions.



Then we're not talking about the same thing.  I'll make a graphic to depict this concept more clearly.  Until then, this conversation can't continue, because you will otherwise never believe that what I am proposing is possible.  I didn't believe it was possible, either... which is why I'm so excited about this idea because it actually does this :)
[/quote]

Okay.

Couldn't merged mining be used to secure the alt-chain?

Probably, under certain conditions. 

Sorry, I'm not familiar with the Stratum alternative.  If there is no alt-chain for verification, what is stopping malicious nodes from distributing bogus data to the rest of the network?  Someone malicious can effectively DoS a significant proportion of lite nodes just by setting up a thousands of fake peers that connect to as many other peers as possible and all give out the same incorrect data.  It might take more work for nodes to sort it out than if you just decided to be a full node (credit to Casascius for this argument).

This goes back to the original source of this thread:  an overlay network makes sense in some contexts, but perhaps using an alt-chain secured through merged mining might be a better alternative (albeit more complex).

Under what criteria does a node decide that important data is correct in an overlay network if there is no way to compare directly to the blockheaders?   It seems that to do this in a decentralized manner without an alt-chain,  you have to trust whatever information is given to you by the majority of your peers.  But peers are cheap and easily spoofed.  One resourceful attacker can muck up the entire network with a million fake nodes.  This is where an alt-chain is beneficial:

--In a non-alt-chain network, you need a majority of nodes telling you the correct answer to end up with the correct answer
--With an alt-chain secured through merged mining, it only takes only one honest node for you to get the correct answer (verified through proof-of-work), even if the other 999 peers are malicious

Unfortunately, my understanding of merged mining and Stratum's overlay network is really weak.  Please fill me in if I'm missing the mark.

  You're right,  I was confused.  Thanks.

Stratum uses a different model.  I'm not one of the developers, so I only understand what the intent is; but each stratum server is a full bitcoin client first, and also participates in the secondary network.  The stratum servers don't depend upon each other to do anything outside of what the bitcoin network already does.  The stratum protocol functions as a controlled spigot to the bitcoin network firehose.  A stratum capable client can query a single stratum server that the user trusts (because he has a service paid for, or because he personally set up that particular server) and privately query the stratum server for data about particular addresses or transactions.  The client, should it not trust any particular server, can reach out to several stratum servers in a semi-random way (either biased towards servers that it has contacted before and not be told falsehoods, or by some other method) and query multiple servers and check responses against each other.  It provides a standard method for a single full bitcoin node to function as the blockchain to hundreds or thousands of light clients, that may or may not actually maintain either block headers or transaction inputs.  Like a distributed version of a split wallet service, like BitcoinSpinner without the vendor lock-in.


That a remote possibility, but again most of the light clients that we expect to see in the future will be desktop apps that don't mine but are still capable of switching to full node mode at will or by user direction.  If the stratum network is being DDOSed, or is otherwise unreachable, most (probably not all) such clients would simply jump directly onto the main bitcoin network to acheive their ends.  This is likely to cause problems in it's own right, but the option always remains open.


I'm skeptical of that, myself.  I will reserver my final judgement based upon what you can show me later.


First, it can compare to local blockheaders, it's just not limited to that.

Second, see above about checking several servers against each other, or simply running your own stratum server at home for use on your android.


You make that sound like that's easy to do, or cheap.  Yes, such an attack vector is possible under thin conditions.  Still, it's potential gain is limited to what the spoofed client is willing to send or what he believes that he has received, not all he has.  I can't see all that kind of effort just to steal my lunch money.  If you're buying a new car with bitcoin, you're going to be taking some more deliberate steps anyway.  The general trend is that security & convience are at odds to each other, and these light clients are intended for convience with relative security, not the full absolute security that a hardened full client could provide while also running it on a cell phone.  This also doesn't consider the use of risk assessment algos.  For example, if your client tries to reach out to the stratum network to check a transaction sent to itself, but can't connect to your personal stratum server, so it falls back to polling 8 random servers & eight servers from within it's own 'good' history.  It gets back all the right responses, but the version number of the nodes it knew about all have different checksums than last time.  Could be that you haven't used this app in a while and everyone really has upgraded, or it could be that you've been corralled into a honey-pot network.  The client notifies you of it's risk assesment, you can either take the transaction on faith or reject it and refuse to hand over the product.


True.  You also need the same from an alt-chain just to be able to have one.  That only shifts the problem across time, it does not change teh problem logically.


Once the block has been created, true.  Not true while the block is being settled upon.  This is why bitcoin, itslef, requires 6 confirmations before the standar client will resend the coins.


My understanding of merged mining is limited, but my understanding of regular proof-of-work is not.  That said, as I undertstand it, merged mining permits the alt chain to leverage bitcoin's securlty to shore up it's own; generally by inerweaving specially identified transactions into the bitcoin blocks, while interweaving all or part of the last bitcoin block's header into the alt-chains's header; thus proving a time sequence in lockstep with bitcoin's own.  While this little hack would permit a mnor alt-chain to benefit from the securty of the bitcoin blockchain, it does nothing that I know of to actually improve teh trustworthyness of the miners that created the alt-chain block to begin with.  Does namecoin do this?

Okay, we're comparing to the same thing, at least.  The Stratum servers can be set to communicate with a full-node that you trust, but many users will either pay a fee to use one, or trust based on majority response from a bunch of free servers.  When the latter is used, you can get awfully creative in trying to figure out what servers are telling you the truth, profiling them, blacklisting nodes, etc. 

What I don't get is why you scoffed at the necessity of having a connection, but I don't know how the Stratum overlay network you describe can work without a connection...?   You must contact one of the servers in order to construct your outgoing transaction, right?  So why not connect to a alt-chain node and query your address balances the same way?  It's slightly more data to download, but it requires zero setup, zero trust, and uses the same networking protocols already used everywhere else (because it's already done in Bitcoin-Qt and the variants used for merged mining nodes). 

Again, you can download your entire unspent-TxOut-list from any node with the same confidence as a full node.  If you don't see it, then you didn't understand the proposal.  This is assuming that the second chain is secure, but I'm pretty sure merged mining is taking care of that.

As for the spoofing -- people don't need a good a reason to be dicks, they may just want to disrupt stuff.  For a "small price" they may be able to disrupt an otherwise useful network, enough that people stop even bothering using it, and accept lower-confidence data.  Or just stop using Bitcoin.  There doesn't need to be a good reason for it, because anything is a good reason to the person actually doing it. 

That may be a fairly strong positive to some while at the same time a significant negative to others.  This is a hypothesis which seems to me to explain the somewhat amusing failures between different individuals to conceptualize one another's views on possible future trajectories of Bitcoin and beyond that, crypto-accounting solutions generally.

I don't think that I'm expressing myself well here.  I not 'scoffing' at the idea that some clients need live Interent access in order to function.  I'm saying that more than one method to support lightweight clients that require live Internet already exist, and none of them actually require the resource overhead of an alt-chain.  Make no mistake, the distributed security of bitcoin is an awesome thing, but it's also expensive in many ways.  Murged mining helps in that regard to a limited degree, but it's a crude kind of hack.  Not at all the smooth, elegant & interwoven solution that bitcoin itself is.

What I want is a lightweight client, that can run on my Android phone, and if the cell network is down (snowstorm, Katrina, zombie outbreak, whatever) or I'm deliberately out of my service zone (camping, safari, fishing trip, whatever) my light android client can still transact to some degree sans live Internet.  The light client as described in Satoshi's white paper, that holds the block headers & copies of it's own input transactions; can spend bitcoins because it can create & sign a proper transaction.  It can also receive a transaction.  What it can't do, without live Internet, is check the validity of a transaction; beyond checking to see if the provided input transactions fit into the Merkle tree.  Even with live Interent, an independent light client can't do that nor discover new transactions for itself without scanning whole blocks itself.  That's teh role that both Stratum & this proposal seem to fill.  If this proposal requires live internet at the time of transaction,then it offers no practical advantages over Stratum.  Stratum is, itself, a distributed p2p netowrk protocol.  It may not look like bitcoin, but it doesn't need to either.


No, not must.  A client with the block headers, copies of the transactions used to send money to it's own addresses (it's input transactions) and a local wallet.dat can create & sign transctions locally, and it can thus use any of a number of ways to communicate that transction over to the vendor; who then may or may not be able to verify it and may or may not be able to forward that transaction to the Internet immediately.  These are not requirements.  However, a client that holds only a wallet.dat would need the live support of a Stratum server to construct it's own transaction, so that kind of (ultralight?) client would require live internet.


It's not slightly more to download.  It's at least as much with potentially several orders of magnitude more to download, store & verify.  There is also the multiplicity issue with blockchains.  Bitcoin requires that multiplicity of redundent data, but the light clients do not.  That is one of the driving forces for overlay networks such as Stratum, to limit the multiplicity.  just because you might not be seeing that across your own data plan, doesn't mean that someone doesn't need to pay for that extra duplication of effort as well.  One way or another, the end users are going to be paying for the network. 

I can see that, what I can't see is what gain is there in downloading a regualr digest of a pruned blockchain, when you could just help finish the touches on pruning and do the exact same thing within the bitcoin netowrk, no murged mining hack nor additional network resources required.  What you guys  are trying to acomplish is already possible within the protocol.  Without additional advantages, why bother?

And this is another thing, that is one huge assumption.  We didn't know that bitcoin itself would work two years ago.  How do you know that murged mining works as described?  I sure don't.


While dicks will always be dicks, those dicks can't really steal anything of significance, and the high costs of doing what you are talking about is a huge deterrent.

I like the idea about merged-mined second chain since its optional and non-disruptive.
I think you should go for it etotheipi!
It will be your answer to a competing Electrum/Startum client-server approach.
You have a large group of followers with Armory, so adoption shouldn't be a problem.

At some point in time Armory would need to get rid of bitcoind dependency for networking.
That would be the right time to introduce the concept!

PS: I recently started using Armory for off-line transactions and I love it :)