An altcoin make a technical change? Keep dreaming.   I am aware of none of them that have this.

It isn't available in testnet either.  It it's just a question of "enabling it"— you have to prevent it from being a memory exhaustion attack via exponential growth. (this isn't theoretically hard but it would, you know, require a little bit of work).

Care to describe your protocol some? it turns out that a lot of things are possible with a bit of transformation.

The reason the blocks are accessed in so few places now is because 0.8 did most of the work for this change, it just didn't carry through all the way to the deletion part.

The deletion itself is already implemented in patches staged in github which will probably be merged soon.  It requires turning off  the node-network service bit as failing to do so would be very detrimental to the network (cause new nodes to be unable to bootstrap in reasonable time). It's also important to not remove the most recent blocks, since they are potentially needed for reorganization.

What I hope to ultimately do here is have a knob where you can set the amount of space you'd like to use (subject to a minimum that is at least enough for the most recent blocks and the chainstate), the host would then pick a uniformly random sequence of block ranges to keep, up to their maximum. Bootstrapping could then continue normally even if no single peer were available which had all the blocks. The caching approach you mention doesn't seem to make a lot of sense to me, since access to very old blocks is uniformly probable... basing what you save on requests opens stupid dos attacks where some goes and fetches block 66,666 from all nodes over and over again to make that one block super popular to the expense of all others.

If you'd like to work on this, I might suggest starting from 4481+4468  and work on making it so that the depth that undo files are kept is different from block files (e.g. keep undo for 2016 blocks and blocks for 288) and make it so if blocks are needed for reorg beyond the block limit it can go re-fetch them.

Another path would be working on improving key-birthday support in the wallet— e.g. comprehensive support for dates on imported keys, and support for rescanning ranges where you don't have the blocks using bloom filtering.

A third path is working on the encoding for signaling sparse blocks— I'd like to see it so that nodes have a compact random seed (e.g. could just be 32 bits) where knowing the current height, seed, and number of block ranges, you'd know which ranges a node has (e.g. working like how selecting N uniform random entries over large data doesn't need more then N storage).  I've got one solution, but it requires O(n) computation with the current height per peer to figure out what ranges a peer currently has, and perhaps better is possible.  My thinking here is that we'd allocate a service bit that says "I keep the last 2016 blocks plus some sparse range" and a network message to advertise the sparse range seed on connect. (Later, we'd create a new addr message that lets you just include the seed directly).

Yes, check out the recent paper on  "Scalable Zero Knowledge via Cycles of Elliptic Curves": http://eprint.iacr.org/2014/595

Which is a pretty wild technique.  Basically they managed (through an enormous amount of computation) to find a pair of pairing-compatible elliptic curves such that the number of points on one is the size of the finite field the other is defined over, and vice versa.

What this means is that in a ZKP written using curve A it's cheap to run the verifier for ZKP written in curve B. And for ZKP in curve B its cheap to verify proofs for curve A.

They take this structure and write proofs of the form "Verify a ZKP in the other curve of the machine state;  Execute one more instruction on top of that state.". Then they alternate these constructions, allowing for completely linear scaling.

The downside is that this magical stunt requires they use curves where the ultimate verifier (not insider a proof but on a computer) is a far bit slower. It also only allows for 80 bit security (The size ratios make achieving 128 bit security much harder). It also only helps for problems that work by repeated application of a universal circuit, like running tinyram, rather than running a hard wired application specific circuit— which many applications will have preferred for performance.

Letting miners _freely_ expand blocks is a bit like asking the foxes to guard the hen-house— it's almost equivalent to no limit at all. Individual miners have every incentive to put as much fee paying transactions in their own blocks as they can (esp. presuming propagation delays are resolved or the miner has a lot of hashpower and so propagation hardly matters)— because they only need verify once the cost of a few more cpus or disks isn't a big deal. In theory (I say because miners have been bad with software updates), they can afford the operating costs of fixing things like integer overflows that arise with larger blocks, especially since they usually have little customization— other nodes, not so much?

Since miners can always put fewer transactions in, it's not unreasonable for the block-chain to coordinate that soft-limit (— in the hopes that baking in the conspiracy discourages worse ones from forming). But in that case it shouldn't be based on the actual size, but instead on an explicit limit, so that expressing your honest belief that the network would be better off with smaller blocks is not at odds with maximizing your revenue in this block.

If you want to talk about new limit-agreement mechanisms, I think that txout creation is more interesting to limit than the size directly though... or potentially both.

Even for these uses— Median might not be the right metric, however— consider that recently it would have giver control to effectively a single party, at the moment it would effectively give it to two parties. You could easily use the median for lowering the limit and (say) the 25th percentile for raising it though... though even thats somewhat sloppy because having more than half the hashrate in your conspiracy means you can have all the hashrate if you really want it.

Are you in China?

Your english seems fine— far better than my {whatever your native language is}, no doubt.

Importing Bitcoin data into a SQL database is tricky, you end up with hundreds of gigas of data once you're out of Bitcoin's pretty efficient encoding.   If you're prepared to deal with that, look into Bitcoin ABE.

Capability?  Agreements between two people are between two people, they can do whatever they like.  Perhaps you intended to ask a question that was directed to actual technology? If so— I can't extract it from your message.

Neat, I will be sure to read this.

Have you seen https://bitcointalk.org/index.php?topic=321228.0 ?

Incorrect. The block with the best target (and target history sum, more specifically) is the one with the most work. Having a lower hash is just chance.

The protocol is that the first valid chain greatest sum work (and work is defined as the target specified in the bits header) is the correct one. What you are suggesting would harm convergence, especially in an adversarial model— as CJYP notes.  Imagine nodes choose the lowest hash in a race. Say you find an unusually rare block, since you are sure you'll win any equal length race instead of announcing the block you keep it secret until you hear competition in the network.

Even absent adversarial miners, lowest hash is less stable and less safe for 1-confirm transactions since the network is not synchronous some miners can just be late to report and late to switch. Right now a few seconds after you've seen a block and not seen any competition it's fairly likely that the block will not be orphaned, but with lower-hash-wins it would be less likely, moreso when you consider miners wouldn't have anywhere near as much incentive to optimize for block forwarding.

 Miners don't actually give a darn, otherwise they'd do the thing P2Pool has done for years and would setup the ability to relay blocks taking advantage of the transactions sent first. (Which you can get for all blocks running the relay node client, http://sourceforge.net/p/bitcoin/mailman/message/32676543/)

Can you cite these people specifically?  The strongest I've seen is that it "may not be necessary" and shouldn't be done unless the consequences are clear (including mining incentives, etc), the software well tested, etc.

Great. I live in the middle of silicon valley and no such domestic connection is available at any price (short of me paying tens of thousands of dollars NRE to lay fiber someplace). This is true for much of the world today.

I agree with this partially, but I know it's at all the whole truth of it. Right now, even on a host with solid gigabit connectivity you will take days to synchronize the blockchain— this is due to dumb software limitations which are being fixed... but even with them fixed, on a quad core i7 3.2GHz and a fast SSD you're still talking about three hours. With 100x that load you're talking about 30 hours— 12.5 days.

Few who are operating in any kind of task driven manner— e.g. "setup a service" are willing to tolerate that, and I can't blame them.

There is no need to delegate your mining vote to a third party to mine— it would be perfectly possible for pools to pay according to shares that pay them, regardless of where you got your transaction lists from— bur they don't do this.

And tell them what?  That hours ago the miners created a bunch of extra coin out of thin air ("no worries, the inflation was needed to support the economy/security/etc. and there is nothing you can do about it because it's hours burried and the miners won't reorg it out and any attempt to do so opens up a bunch of double spending risk")—  How exactly does this give you anything over a centralized service that offers to let people audit it?  In both there can always be some excuse good enough to get away with justifying compromising the properties once you've left the law of math and resorted to enforcement by men and politics.

In the whitepaper a better path is mentioned that few seem to have noticed "One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency". Sadly, I'm not aware of even any brainstorming behind what it would take to make that a reality beyond a bit I did a few years ago. (... even if I worked on Bitcoin full time I couldn't possibly personally build all the things I think we need to build, there just isn't enough hours in the day)

That isn't the whole tool in the belt, but I point it out to highlight that what you're suggesting above is a real and concerning relaxation of the security model, which moves bitcoin closer to the trust-us-were-lolgulated-banking-industry... and it that it is not at all obvious to me that such compromises are necessary.

It's beyond infuriating to me when I hear a dismissive tone, since pretending these things don't have a decentralization impact removes all interest from working on the technical tools needed to bridge the gap.

I'm not sure why you think that— miners are paid for their participation. Some of them habe been extract revenue on the hundred thousands dollars a month in fees from their hashers. There is a lot of funds to pay for equipment there.

Oh, I wasn't trying to express any opinion/dislike on the inefficient use but to point out that to some extent load expands to fill capacity, and if the price is too low people will use it wastefully or selfishly.

Same cost for miners, who are paid for their resources. Not the same cost for verifiers, because not everyone has to verify everything.

In spite of all the nits I'm picking above I agree with you in broad strokes.

Gee. And yet no one is suggesting that. Perhaps this should suggest your understanding of other people's views is flawed, before clinging to it and insulting people with an oversimplification of their views and preventing polite discourse as a result? :-/

Maybe, we've suffered major losses of decentralization with even many major commercial players not running their own verifying nodes and the overwhelming majority of miners— instead relying on centralized services like Blockchain.info and mining pools. Even some of the mining pools have tried not running their own nodes but instead proxying work from other pools. The cost of running a node is an often cited reason.  Some portion if this cost may be an illusion, some may be a constant (e.g. software maintenance), but to the extent that the cost is proportional to the load on the network having higher limits would not be improving things.

What we saw in Bitcoin last year was a rise of ludicrously inefficient services— ones that bounced transactions through several addresses for every logical transaction made by users, games that produced a pair of transactions per move, etc. Transaction volume rose precipitously but when fees and delays became substantial many of these services changed strategies and increased their efficiency.   Though I can't prove it, I think it's likely that there is no coincidence that the load has equalized near the default target size.

But this isn't the only objective, we also must have ample decentralization since this is what provides Bitcoin with any uniqueness or value vs the vastly more efficient centralized payment systems.

Agreed.

At the moment it seems fine. Forever? not likely— I agree, and on all counts. We can reasonable expect available bandwidth, storage, cpu-power, and software quality to improve. In some span of time 10MB will have similar relative costs to 1MB today, and so all factors that depend on relative costs will be equally happy with some other side.

This is ignoring various kinds of merged mining income, which might change the equation somewhat... but this is hard to factor in today.

I think at the moment— based on how we're seeing things play out with the current load levels on the network— I think 100MB blocks would be pretty much devastating to decentralization, in a few years— likely less so, but at the moment it would be even more devastating to the existence of a fee market.

Yes, sort of— fee requirements at major pools, monero apparently planning a hard-fork to change the rules, I'm not sure where thats standing— I'll ping some of their developers to comment.  Monero's blockchain size is currently about 2.1GBytes on my disk here.

The improvements Andrew and I came up with do not change the scalablity at all, they change the privacy (and do work for all possible sizes), and since its not scalability related it's really completely off-topic for this thread.

Sounds like you have a broken SATA driver/controller. Try starting up some disk benchmarks and see if your computer becomes unusable when there is the slightest activity.

You're running a non-git version of bitcoind. Next major version will have them for you.

WRT peer height.

The syncheight is based on what the peer has advertised to us, so if a peer is not synced up yet its syncheight will be -1. You might want to fall back to displaying the starting height there if and only if it's value is more than one less than your current height and syncheight is -1.

It's completely normal and unsurprising for the genesis block timestamp to be 'rigged'. ... I don't know about in BCN, but in Bitcoin there really is no facility to mine a genesis block, it's hard coded... so you end up building a separate tool to create one. Your tool _could_ read the current time, but thats ~2 more lines of code than just manually setting the time at some value. By itself I wouldn't find that concerning.

First, the entire privacy model for Bitcoin is predicated on users not reusing keys. Without that, bitcoin is obscenely non-private, and gravely disadvantaged compared to any other store of value or transaction system in wide use.  This alone immediately would destroy any value an 'account' system would have, and so you can basically stop at this point and think no more.

Though there are other reasons, beyond the increased difficulty of evaluating zeroconf transactions Sergio mentioned above—

Then the account model has major problems with corner cases... e.g. You have problems with determinism in conflict situations:  e.g. Alice has 2 BTC and pays Bob 0.9 BTC, then Alice pays Carol 1 BTC.  Later Bob gets angry the transaction hasn't confirmed and demands Alice reissue with a fee. Alice does but then Bob gets paid twice and Carol not at all.

Even just anti-replay you need an random access lookup to see if the nonce has been used already, and the nonce is per input if you ar eto have conflict control. You have more data (the list of nonces) is unprunable (or difficult to make prunable)... and so any space you saved by not having extra outputs is lost in abundance by having to store nonces forever— even after an account goes to zero value, since if it were funded again someone could replay a years old spend— once the spending actually does happen.

In short, account like setups _seem_ simpler and more intuitive, but they have ugly edge conditions that are difficult to get right and create overhead that wipes out the possible gains. When you consider that the privacy model precludes that kind of use in any case, there really is no upside and a lot of downside.

Beyond being unethical and stupid, closed source miners are a risk to the ecosystem. What happens when some important update is needed to these devices? Or what if they're shipping with a back door? What if they need fixes to work with p2pool or some other future mining improvement?

Not clear to me. A lot of technical work doesn't get invested in. I mean— sure you could get a few thousand dollars or something. Getting millions would be much more dicy, especially if you're thinking like I do and thinking that any serious altcoin competition with bitcoin could potentially be very bad for all cryptocurrencies (damaging network effect), plus competing with bitcoin is a long uphill battle. Perhaps it's arguably more profitable to do some splash where you've got effectively infinite supply, and feed a huge incoming speculative demand ripple/stellar style.

I'm probably out of my depth— figuring out how to extract money from speculators isn't something I really have experience with... it's just not so surprising to me. Though next I'd be worrying that if someone did all these dishonest things, what backdoors do they have in the software? :-/ In my case I only ran any of these codebases sandboxed on separated machines. Presumably altcoin exchanges have similar setups?