It seems like a reasonable thing, not sufficient on its own but reasonable... (in fact!) I've previously proposed it myself.  (not sufficient, among other things that it doesn't do anything to keep incentives aligned, or keep centralization gains moderate.)

Yes, but thats only true for a certain set of limits at a certain size. 100MB blocks wouldn't be tolerable on thrifty resources like that today. You may be making an error in reading my message as some kind of opposition instead of tradeoffs which must be understood and carefully handled.

Centeralized services are inherently more efficient, enormously so. My desktop could handle 40,000 TPS with a simple ledger system, giving nearly instant confirmation... physics creates limits for decentralized systems in scale and latency, and thats okay— the decenteralized systems are much better from a security perspective.  My point about there being alternatives to increasing scaling are not limited to (semi-)centralized systems, though they're useful tools which will exist in the ecosystem, there are decenteralized approaches as well.

I also think it's wrong to think of semi-centralized systems as being in competition with Bitcoin, if process transactions for Bitcoin value they're part of the broader ecosystem; and Bitcoin's trustlessness should enable semi-centeralized systems which are far more trust worthy than what is possible in semi-centeralized systems absent something like Bitcoin. We should be able to adopt them in the places where they make the most sense and have the least risk, rather than try to force all of Bitcoin to the level of centralization needed to make processing $0.25 coffee cup purchases economically efficient while still doing a poor job of it.

Yes, its complicated— but it's also concerning. The only altcoins that I'm aware of which have diverged from the current Bitcoin behavior in this front, and did so with the benefits of all the discussions we've had before being available to them, have been suffering from crippling bloat. That they have stronger privacy features which make transactions somewhat larger is somewhat relevant, but the average mixing size on monero is small.. and we may need to adopt similar functionality in Bitcoin (esp as increased mining centralization, partially fueled by the cost of operating nodes makes censorship more of a risk).  This doesn't prove anything one way or another, just something to think about— the way it was originally presented sounded to me like you were saying it was solved over there, but instead I think that the experience in Bytecoin and monero brings about more questions than answers.

This thread is beginning to just rehash the discussion from the several prior ones, please take the time to search the forum some, read, and contemplate a bit before replying.  

Imagine— you want your message to be read by dozens or hundreds of people— consuming a few minutes of their valuable time each. It makes sense to spend quite a few minutes making sure you are well informed first, considering how much of other people's time your message will consume.

In particular, I think it's especially unhelpful when people make posts which make it clear that they don't understand that there isn't a free lunch here. In particular, I think any productive post will have been made understanding the following points:

• Blocksize has a trade-off with decentralization. If verifying the blockchain is made expensive (relative to hardware and bandwidth costs), then past some limit Bitcoin becomes a centralized system where everyone is economically forced to trust some consortium of large miners— which are themselves more efficient if centralized since they can just verify once, instead of verifying for themselves. (If the economic majority is trusting and not verifying, you need to also do the same so you don't end up split from the other users of the system.)
• Bitcoin isn't secure unless there is income to pay to apply computation to the honest chain (and thus far the alternatives appear not clearly workable), we argue that once the subsidy is gone transaction fees will support the security. But the existence of a market for transaction fees requires a degree of scarcity to make the rational price non-zero and to encourage efficient use. Just like Bitcoin itself wouldn't be valuable if everyone had access to infinite Bitcoins, our incentives require a degree of scarcity of blockspace.
• Bitcoin currency throughput can be increased to arbitrary levels without increasing blocksizes, especially if you're willing to make decentralization tradeoffs. Importantly, handling high volume transactions in other ways than expressing each and every one in the global bitcoin ledger can help avoid pulling down the available security for all transactions just because a large volume of low value transactions need the throughput and can accept the lower security. Work in this space has been under-developed, but I'm not aware of anyone disagreeing with the broad possibilities here. Because of the lack of need until now it's only recently become possible to raise substantial funding for work in this space.

None of this to say that its not an interesting subject to discuss (though it has been discussed in depth before), but it's at least my view that posts which are unaware of these points are unlikely to be productive. If you don't understand what I'm saying in these points, you need to read up more (or even feel free to contact me in PM to talk to you about them one on one before taking the stage yourself).

The Bitcoin systems exists in a careful and somewhat subtle balance between two extremes: one where it is too costly to transact in, thus not valuable— or one where it is to costly to verify and so it offers little to no trustlessness advantage over traditional systems (which have a much more efficient and scalable design, made possible in part because they are not attempting to be trustless). Like most engineering tradeoff discussions every choice has ups and downs.

With respect to  the suggestion to use the scheme from bytecoin (and it's forks like monero and fantomcoin), since that didn't exist when the prior threads were active I might as well give my thoughts on it—

Sadly, what bytecoin does is objectively broken. (Had their paper had a modicum of peer review this would have been noticed</whine>) My understanding is that it has a limitless blocksize (well at some point I presume nodes run out of ram, so not really limitless, just "undefined") with a median operation such that a miner cannot produce a block larger than a median of recent blocks without throwing out a fraction of their fees which is quadratically related to the size— the bigger the block the more coins you must throw out. Unfortunately, it's perfectly possible to pay miner fees 'out of band', e.g. author a transaction with zero-fee but pays the miner directly (some Bitcoin mining pools like Eligius already do this), so this as a control on blocksize cannot work in the long run. It also fails to control for the incentives of larger centeralized pools— who can justify beefier nodes due to the mining income— in pushing everyone else out. I understand that monero will be hardforking soon, in part to reign in the blockchain growth (which has grown almost 2GB in its 3 months of operation in spite far far lower exposure than Bitcoin), though also because the median is too constraining when there haven't been a lot of transactions recently.

Mod note: I'm going to remove posts that look like they haven't even read _this_ thread, much less past ones— prior threads spiraled a bit into uselessness with people jumping in repeated/rehashed uninformed opinion that had been thoughtfully covered in prior posts.

P2Pool is completely decenteralized and the miners (or subpools) themselves announce blocks, there is no delay to send a block "to" p2pool because there is no p2pool to send it to. P2Pool also uses a very advanced wire protocol that allows it to announce new blocks to p2pool peers using a small fraction of the bandwidth that Bitcoind does... so in terms of orphaning there is no disadvantage.  P2pool, however, is sensitive to latency on returned shares in order to encourage miners to optimize their latency, so to the extent that a subpool increases latency considerably it will get paid somewhat less— though this doesn't impact block orphaning  (other pools allow miners to submit shares rather late, meaning if you you're low latency on them you're effectively subsidizing your slower co-poolers).

There have been some pools that frontended p2pool in the past, some haven't advertised it loudly (you can notice them by observing that their hashrate is the same as p2pool's).

It does not converge to the expectation after the fact. This is the gamblers fallacy.  You expect to be near the expectation, indeed, but after your first dice is cast your winnings and losses are _permanent_ and have no bearing on the future results.

There is pretty substantial differences in the mining income for the whole network... once you're up at the 10% level the overall network variation is a substantial part of the variation you experience, the change in your 10%-tile income between 10% and 40% pools is pretty small.. a percent or so.

Usually "tragedy of the commons" refers to interests being out of alignment (e.g. whats good for you is bad for everyone).  Arguably the issue is a freeloading loss, but I'm doubtful.  Considering that hardware companies are successfully selling hardware at price _far_ beyond what reasonable models of future income show is profitable, it's really hard for me to buy that miners are acting rationally enough to be micromanaging operating costs to the point where they're sitting around not writing functionality because they hope someone else will.

Okay I am glad we agree on that first point.  On the second— well, lets see— people buying hardware that are sure losses by basically any reasonable calculation, dropping them on 5% PPS pools... taking half their income to a blockchain dice site...

Every nameable centeralized pool has been hacked (except f2pool afaik, but it hasn't been around that long), in some cases with _large_ amounts stolen. In the case of ghash.io in addition to taking the operators funds they executed doublespends to the tune of 3kbtc lost.  And thats after the survivorship bias— many pools in the past were popular and vanished with users funds.  By comparison I don't think P2Pool is risky at all, it's the centralized pools that are risky even if you're counting on selling your coin before ecosystem damage makes it worthless.

You're reasoning incorrectly about expected returns. The expected return is the expected return, regardless of if there are any future blocks or not. The hashrate decreasing or increasing isn't relevant— mining is an instantaneous, memory-less process.  If you are unlucky and get less than your expectation or lucky and get more— there is no making up for it, regardless of what the difficulty does in the future (see also: gamblers fallacy).

Beyond that, the difference in variance between mining in a 10% hashrate pool and a 40% hashrate pool is negligible— the variance is dominated by the network finding variance long before that point. Moreover, the optimal variance reducing strategy (assuming that all pools are equally good) is to mine on all pools weighed proportional to their hashrate— something which I've never seen anyone do, so much for "rational".  (Not to mention that the fees and risk of undetectable theft, further lower the expectation of centralized pooling)

Even ignoring that, it still remains that control over the consensus state and pooling for payment is technically orthogonal. Even if you had some great need to be in the largest possible income sharing pool, there is no need to fuck over the decentralization of bitcoin (and a lot of reason not to, since doing so _will_ result in outcomes adverse to your interest, e.g. the network changing POW function or eroding trust in Bitcoin), and so you'd expect to see people solving that so they could have 80% pools safely if the motivation were really variance reduction and not ignorance and lazyness...

I don't think the incentives are wrong. But even in the face of acceptable incentives, sometimes bad outcomes happen. There are people mining right now with millions invested who hardly understand Bitcoin at all... incentives and rationality assume a degree of knoweldge which doesn't always exist.

Unfortunately, many of the issues that apply to POS also apply to proof of activity, sometimes they're less severe (see, for example, the issues with the worthlessness of old private keys— PoA it just gives you a huge reduction in computation costs, but the computation is not free), but I think in all cases they create some amount of true centralization advantage (mining no longer linear in resources because you must combine them) and admit attacks which Bitcoin would have been completely secure against. Maybe in reality and with the right parameters the trade-offs are good but it's very hard to analyze— ever so much more so than POW.

PoA also has some issues with behavior at odds with good security practices— if the actual spending keys must be used then multisig, offline wallets, and HSMs are actually expensive to use— we don't need more disincentives to good security.  If the mining rights are delegated to other keys, users may transfer ownership— further complexifying incentive arguments.

The schemes that break pooled mining are non-starters, they'd create huge advantages for vertically integrated operations which can get acceptable variance without risk, and huge advantages for hosted operations.

The sets of proposals I am most fond of are:
* Coinbase only mining —  where miners pool only for their coinbase transactions, and are free to generate their network consensus locally or get it from another source. With this the entire network could safely (in terms of network safety, not miner income) be on a single pool.

* Smart property mining— where mining asics can will only process consensus state work authenticated by their owner (or owner designated parties). This would allow miners in hosted facilities to not be at risk of being redirected for attacks. (Sure, any hardware tamper proof can be defeated, but if you have to decap chips to bypass the protection— cheaper to just manufacturer new chips).

If widely used this "solution" would be hazardous to the network: in cases where it would do anything at all it would cause severe consensus splits (and the resulting reorganizations of length long enough to permit successful double-spending), without some centralized process to ensure complete uniformity of the "approved list" even users of this approach could become consensus-split and it would encourage miner consolidation and registration with an approval authority to avoid being on the losing side of such a split / or suffering block delay 'punishment'. It would almost certantly result in taking the currently broken status-quo where there are only a few miners at all and nearly setting it in stone, and it would set us up for an ugly path where miners now had identities and it was interesting to start talking about other restrictions for them.

Ignoring the wrongheadedness of the overall design for a moment, the actual proposed implementation is still broken:
You cannot include a signature of the block into the coinbase because the block (which includes the coinbase) cannot be modified once it is mined. If you include a signature of the height than once a block has been released at that height an attacker can just move it into a new block they mine at that height— impersonating them with the rebinding.  ... this sort of thing can be fixed, but if you cannot get right even some of the boring details why do you think you have a overall design that does anything except causes harm?

While I fully support someone taking realpra's money, if he keeps insisting after having these things explained to him, do so with no expectation of adoption. I certantly would have nothing to do with any project distributing an approved miner ID list, since influence over would be a risk to my personal health and welfare (not to mention that of the Bitcoin system), and I'm confident that very few people would be foolish enough to run such software.

There are a bunch of complicating factors. For one, 'the largest' pool physically owns and/or controls a substantial portion of that hashpower. They admit to 40% but there are reasons to believe they are not being completely honest— (during dos attacks which made the pool seemingly unreachable from the internet they did not experience a large apparent hashrate drop).

Then combine that with the fact that many miners, even— historically— some pool operators have misunderstood mining as a race in which the 'fastest' had super-linear rewards (even ignoring misconduct like selfish mining)... Then you have factors like— I've met with people who have invested millions in mining and had _no idea_ mining served any purpose other than the lottery for the initial coin distribution.

Plus we have ecosystem symmetry breaking where centralized pools that must be trusted to not rob the miners were widely adopted first, the trust requirements hurt competition, and the lack of good reporting tools except via centralized pools discourage using multiple pools (assuming equal risk and fees, loadbalancing between pools is the variance minimizing strategy)... etc. Just a lot of little cuts, which makes it hard to make progress.

In my experience most people mining now are utterly saturated in dealing with the untrustworthyness of hardware vendors, they're too exhausted (or bankrupt) after that to worry that their actions might be making the Bitcoin they're receiving worthless... sometimes I think the maturity window should have been longer than 100 blocks, too— since the fact that many miners immediately sell their income can't help things either.

You can transform any pubkey on any G to a pubkey on another generator by means of addition.  In particular, if there is some bad generator O where you can compute the log of Ox for arbitrary x easily, one can use find the discrete log of Gx as log_O(Gx)/log_O(G) mod order. One doesn't need to prove anything about the hardness of the discrete log to just show the arithmetic relation that if on a curve discrete log is insecure with respect to one generator then discrete log is insecure with respect to all generators of that group.

A better example that I could have given is how the byte order is chosen (big endian or little endian). You surely can't create an implementation without knowing how to deseralize the bytes, but byte order isn't relevant to security.

It's very useful— with one addition: The BRS ring-signature also produces a key image which is a deterministic function of the signer's private key, can only be computed with knoweldge of the private key, and is provably linked to the ring signature so you know that the image you received is the image of one of the keys on the ring, though you don't know which.  You then prevent that key image from ever being reused.

Huh!? ring signatures do nothing to enable pubkey reuse, and in fact— in the bytecoin ringsignature (BRS) approach all pubkey reuse must be _absolutely_ precluded.

BRS signing effectively allows users form something similar to a CoinJoin but without the other inputs owners participating.

Less efficient, but set membership is a bit harder to screw up:

Take N distinct cards, permute them at random (shake in a bag if you like), separate into two groups— you now have N bits (which set they ended up in).

This has a nice property that you can use it for ultra-fast key agreement: take a $2 drugstore pack of playing cards, shuffle well.. give the other person the other half. Nearly instant, computer free, minimal preparation, 52-bit shared secret.

You mean like? http://bitcoin.sipa.be/pruning-size.png

I'm not sure what developers you're talking about— but anonymity loves company. Good privacy should be a default, if it can't be then it's probably to inefficient to give much improvement. Infrequently used privacy systems which are detectable risk raising suspicion and censorship for there mere use. (One of the attractions of CoinJoin and CoinSwap is that they're potentially indistinguishable from ordinary transactions)

wow. You're kidding right?  Can you suggest a _single_ widely adopted financial system in the history of the modern world which made everyone's transactions and 'balances' mandatorily public?

Imagine you collect a paycheck in Bitcoin— when you get a raise, do you want your landlord increasing your rent?  "I know you're good for it."

Imagine you resell a product you paid for in Bitcoin and hear from your customers "I know you paid less for it, I want a better price!" or from your suppliers "We want a bigger share, we know you're selling these items for top dollar.".

Do you want your competitors knowing what your sales figures are, what products you're selling, and to which customers you're selling them to?

Do you want your employer potentially questioning the causes you donate to?— or just the risk that they _might_ question them, forcing you to self censor your actions for fear of losing your job, "It's just not working out".

Should the barista at the coffee shop know your bitcoin-net-worth or your lack thereof? Or the mugger they pass the info off to know that you're the ideal person to kidnap? Should loan-sharks know when you're tight on funds and most likely to take a predatory loan or participate in some long shot investment gamble?

Should your in-laws know you're paying for contraception while they're clamoring for grandchildren, or what kind of porn you like?

Should people in your community know what you're paying for your child's education— funds you could be instead spending supporting the community garden?

Should bidders for a deal know what your prices were— undermining the inherent motivation to be honest in auctions which depends on keeping some information secret?

Good fences make good neighbors and financial transactions frequently reveal a bit about our most intimate secrets and values.  Being able to answer "it's none of your business" when it really isn't is what frees people from feeling they have to impose their values on everyone else and frees people from everyone else constantly imposing their values on them for all things.

Transparency is an essential tool in our social tool-belt too— but like all things it must be used in an intelligent and controlled manner. Sunlight can be a disinfectant but it can also cause skin-cancer.

In a world where massive power asymmetries exists having control over your private information is one of the few re-balancing forces which are theoretically available to everyone... and this applies in a multitude of business and personal contexts far more numerous than what I've listed here, sometimes in gross ways and sometimes subtle ways. In some sense a financial transaction underlies every interaction we make with another person— though sometimes the scarce assets exchanged don't include money— sometimes we trade with less formal systems like reputation, trust, future obligation, etc instead of or in addition to money... but such trades are always happening, and without some privacy in them we can have privacy in nothing. (Some people hope that Bitcoin, or Bitcoin inspired systems might help create formalized versions of some of these non-monetary value exchanges in the future too… hopefully not while also undermining their privacy.)

Used in a poor way (as some wallets have enshrined and some businesses seem to be promoting) Bitcoin is one of the least private transaction and value systems ever created. I'm hopeful for the human-welfare-enhancing possibilities that Bitcoin could create in the future, but if it goes a route that further erodes the privacy we have in our interpersonal interactions then it could instead fuel a terrible dystopia.

There are also some Bitcoin specific risks— In Bitcoin our goal is to build a system of exchange which minimizes the need for trust... but we still must trust miners to establish the ordering of transactions. As a result miners have a substantial power to censor, but privacy undermines that risk— so long as we have enough of it. Anything that creates an incentive to control mining— e.g. to achieve censorship goals— risks undermining the whole system, so we're all better off if the system is more private... even the non-existing hypothetical person that has no need for privacy.

So back to your question— I'd turn it around, if Bitcoin undermines people's privacy how could it possibly be adopted— are people that foolish? And if so, could free society survive the harm such an outcome would create?

Nodes currently only store the historical blockchain for serving out to newly initializing peers and for stats queries in the rpc. Since 0.8 the software is restructured so that it never accesses it otherwise, and the next release will likely include a feature to operate with only about 1GB storage.

Right "anonymous" in this context is about participation having "membership", not about privacy (though anonymous and anonymous do sometimes go hand in hand).  Sorry about that, it's a bit of terminology overload that occurs in the literature.

Ah, good spotting then. It was a product of this discussion today: http://download.wpsoftware.net/bitcoin/wizards/2014-07-20.html  start at 00:56:13

I made an erroneous assumption that you'd been watching the logs and made the post as a result.

It's perfectly possible, but it has some pretty severe overheads— and the tech is immature and rapidly improving. E.g. Just recently Andytoshi and I invented a way for coins of different values to partially share anonymity sets.

One challenge with all strong privacy systems is that they breaks pruning and increases transaction sizes substantially (4x+ in size for these ring signatures, typically).  Right now a full verifying node in Bitcoin requires on the order of 1GB of storage, if we'd had the bytecoin-ring-signatures from day one and the same traffic it would be more like >100GBytes.

They have entirely different scriptPubKeys, however. The sameness is only even remotely interesting because of bugs in bc.i (and perhaps some other wallets that just ignore the version bytes).

You might want to attribute where you saw this discussion…