"Making"? The system already has the scarcity built in, and the suggested removal of it would require an incompatible hardfork no technically different than changing the inflation schedule. Bitcoin has never been changed like that.

If you're going to go for the hyperbole: I'll accept that and raise you—  Violating the contractual agreement embodied in the Bitcoin software in order to remove some of the scarcity which is currently necessary for making the act of honestly expending resources to secure it economically rational. This would be a change which has a universally anticipated consequence of increasing centralization, forcing an unknown number of participants to trust third parties, and removing all reason from the long future security arguments of the system... Peter outlines an argument that the equilibrium of an uncapped blocksize is a single miner. All for the sake of increasing short term transaction capacity when we are no where near utilizing the levels currently available and when that capacity could be provided by other means. This is what we're basically talking about.

... I think this is horribly over-stated, but it's at least more pedantically correct than suggesting that anyone is proposing adding any limitations.

Huh? It's the arguments that the pools (note: miners are not even invoked here, the idea that the authority is handed over to a couple pools is already so easily accepted) will reject "too large" blocks that demands a conspiracy.  Peter Todd's point is that a single miner can push off all the smaller ones, all on their own— unless there is a conspiracy to stop them from including these otherwise valid blocks.  As you argue such a conspiracy "will result in abuse of current rules", and I agree.  Worse, if we as a community can't figure out a criteria to conspire on and put it into the system— where there is no risk of defection— how can we expect a pool-conspiracy to do better when they have less powerful tools to enforce conformance?  Also, while the network is choking on blocks which will be rejected users are left around waiting longer times for confirmation because its not obvious when a chain is going to get orphaned because it violated the invisible cartel rules.  Finally, even if the cartel is successful at preventing single miners from breaking the system, its in each member's individual best interest to mine the largest possible blocks, so we should expect a slow evaporation which has the same conclusion: a single primary miner/validator.

Not quite— only if you assume miners don't directly peer (either intentionally or by connecting to everyone). They do.  Besides— a single megaminer has no orphans. Miners and non-mining users are different, counting orphans only count the impact on miners. If you disenfranchise the non-miners from validating you're handing control to a special interest group with high fixed costs— the kinds of blocks you can get away with mining are very different if you're trying to appease all users broadly vs just miners.

Using orphans may well be a valid way to dynamically control block speed without a fixed time constant, but it doesn't address the concerns around the economic motivations of mining, or the disenfranchisement of the non-mining users whos voice is embodied by the strict rules of the system which constrain miners absolutely no matter how powerful a miner conspiracy they have.

I'm interested in hearing more thoughts about how to safely integrate other blockchain like systems... e.g. what protocol extensions they need to share more security and facilitate cross chain trades. I've generally been a bigger fan of non-chainlike alternatives because I think the diversity has the most potential to make a big marginal improvement— but I also think there is room to add value with chainlike systems too.

I'm not disappointed. Although I don't currently agree with Gavin on this, I believe he has clearly behaved in a  praise-worthy manner: His responses are understated and considerate— which must be difficult where the opposition (e.g. me) might be read as saying "OMG YOU'RE CENTERALIZING BITCOIN YOU MONSTER". This is hard stuff with long term consequences that none of us can truthfully say we completely understand and, at the moment, without the kind of immediate urgency (or even running code) which would help crystallize thinking.

Above all other things, I'm glad that he's taking some time to spend adding some thoughts to this when it isn't an immediate issue.  A lesser, not-consensus-driven developer would just rest quietly comfortable that there would eventually be an emergency that would allow pushing their way though... Gavin isn't like that, which is why you even get to hear what he's thinking on this when it's still just a philosophical debate.

Doesn't even have to be a pull request. It could also be an alternative protocol and a little gateway daemon. Both as a proof of concept and as a rapid deployment tool.  We really could use some diversity in the P2P transports. As noted by Sergio Demian Lerner and others there are a lot of harry DOS attack corner cases... we can't have really any diversity in the Blockchain stuff, but we absolutely can and should have more in the node to node transport.

This may, in fact, be the first time in my life that I've been accused of not having enough imagination. First the grey hairs, now this... I guess I'm finally getting old.

But perhaps you've not been paying attention where I've been throwing ideas against the wall. My imagination has far from run out. (Nor has PeterTodd's, as he's independently come up with some of the same ideas— as well as many that I haven't thought of...)

…Not to mention a zillion other less workable ideas that are waiting for some breakthrough or another to make viable… mostly I try to spare the public the more inane stuff... and certainly I've had no shortage of imagination for all the technical and economic failure modes that can result from removing part of the scarcity that drives a cryptocurrency.  We've even had non-blockchain scarce altchains— Liquidcoin (for speculation)—, perhaps you don't remember because it imploded into complete non-convergence before half the people who wanted to run it even got it installed (though its 'innovation' was uncapping the block rate instead of uncapping the blocksize).

Generally the ideas to improve Bitcoin's scalability seem to only change around the constant factors in costing equation— N*∝N is still quadratic even if you multiply in only a fraction validating. Or at least, so far, the in-blockchain-ideas don't allow unbounded scaling (as blockchain external thing like fidelity chaum-banks, however, do). As far as I can tell, if we're to have a system which is practically decentralized and secure— then there must be limits for technical and economic reasons.  I _hope_ that if we're clever enough we can improve scale without compromising decentralization, but examples from existing currencies and the state of the technology make me more confident in both centralized and decentralized off-chain approaches— which we'll have to have no matter what happens with blockchain scaling.   (And it bears bolding out: Off-chain DOES NOT MANDATE CENTERALIZED, though it seems that plenty of people love centralization, and its hard to argue against for low value things).

I want a pony. Made of cake. Special healthy cake that makes you lose weight. If I can choose without compromise of course I'll want all the features and none of the costs.

The users of Bitcoin— with their understandable desire for fast transactions and low fees— are, above all, users of _BITCOIN_.  If fast transactions and low fees were their utmost priority they would be using VISA and the USD, which among numerous other advantages, have deep and fundamental advantages over direct Bitcoin transactions for achieving low transaction costs and high speed.  Decentralization is costly as heck, and if you punt on it you can scale much better (go look at what ripple is doing— even though it has gone the rather uninspired blockchain-ish global consensus like bitcoin route— it has replaced a scarce resource consumption consensus with trusted verifiers that produce blocks as fast as they achieve a majority).

Blockchains are just simply bad at fast and cheap. They are a zero information hiding global flooding network (==costly) that depends on achieving a worldwide consensus (==slow). When a butterfly in china buys a dumpling with Bitcoin, processors in Nebraska must whirl, and everyone must wait until we've had time to hear back about all the whirling or risk having their transactions reversed. And in spite of being slow, costly, and with a heaping helping of the market-failure-maker of externalized costs... it turns out that that blockchains can actually do a whole lot. An O(N^2) algorithm can be quite fast when N is small. And with enough thrust (compromise) even a pig can fly (scale). But we shouldn't mistake that for scaling without compromise— because, at least as of yet, no one has figured out how.

I believe that Bitcoin plus a nice mixture off-chain transaction processing can be all things to all people: It can provide unbreakable trust based on cryptographic proof, it can provide infinitely scalable transactions. The chain doesn't scale great, but it can scale enough to handle high value transactions (I pay $30 for an international wire today) and scale enough to interlink infinitely scalable additional mechanisms.  People can pick their blend of security vs cost by choosing how they transact.  If, instead, we try to make the blockchain do it all directly, we get nothing: We lose the zero-trust but would still not be as fast or cost effective as systems which don't pretend to be decenteralized. In doing so we'd force people— against their will and interests— to accept the system changing out from under them and forcing them to trust other parties. They may ask rightfully ask— "When fast and cheap transactions 'require' pegging the subsidy and creating inflation, will respecting the promises that were made to me once again be considered negotiable for the greater good because I'm not a core developer or big mining bank?"

... But at the same time, this is all greatly benefited by making Bitcoin scale better.  Any scaling improvement is equally a improvement of decenteralization at a given level of scale, and I absolutely am working my brain overtime on how to make it better, and open to listening to every idea presented.

Decenteralization— offering an alternative monetary system which doesn't require all that messy and misplaced trust— is the fundamental purpose of Bitcoin: it is the one thing Bitcoin does which nothing else can hold a candle to.  It is messy and political and, at times, morally ambiguous. It is a fantastic experiment. It is the BIG IDEA that makes this all worth doing. This is why we're all here. But, it doesn't always neatly translate into quarterly profits for Bitcoin startups, or simply explained day-to-day benefits, it drags in messy politics when you just want to shut up and code. Of course, Bitcoin actually has to _work_ for people but if we can't make it work and be decenteralized we might as well give up and go home.  The trust in classical currencies isn't eroded because of evil— it's eroded by successive application of pragmatic local decision making which leaves people with nothing they can count on to hold true for long.  Bitcoin might show us a way out of that— with its awful suicide pact of inhuman razor-sharp mathematics made nearly immutable through decentralization— but only if we're ready to deal with the consequences.

That I can agree with— but I think not in the way you intended it. Some of the argument about the uncapping risk are mooted if you only increase the maximum blocksize once its apparent to everyone the transaction load is some multiple of it. This way you don't get the fees race to the bottom.   You argue that removing the limits is okay because hopefully we won't commit suicide, I counter that it's even more okay to not back them off them until its apparent to all that they must be backed off.  Without a credible claim for long term decentralization Bitcoin will still retain many of its flaws but have no selling point to the ordinary people you wish to attract. We can't have both by uncapping the chain, but we can have both with the additional systems.

What you're describing there is a distributed system, not a decenteralized system. If only some small number of wealthy nodes do all the validation— instead of pools, why not call them Central Banks?— then everyone else is forced by economic reality to trust them to behave honestly, and there is no economic force beyond a consensus of a small number of like-motivated-parties not to make helpful "optimizations" according to earnest beliefs the greater good or in response to coercion.

In Bitcoin, as it exists today, running a full node is dirt cheap and would remain dirt cheap forever— unless and until we have a hard fork with the consent of the users— and so you're not forced to trust anyone or anything beyond your ability to audit source code and your understanding of software and mathematics.  All modern banking is distributed, and Bitcoin as a distributed system isn't especially inspired. It's fragile and has high overhead.  In site of this, because of decentralization we have something better. I hope we don't lose it because the rush to make MAD MONEY with speculation has left us with too large of a community who doesn't realize how powerful the ideas behind the system actually are— and how those ideas are the fundamental that make Bitcoin valuable, not how many transaction per second the system can handle (how many transaction per second does a gold bar process?).

The obvious thing to do in that case is to have the sender choose whatever representation it believes will be more efficient based on what it knows from the peer. (e.g. transactions it has previously offered the peer, or the peer has offered it).

In the p2pool case for p2pool shares p2pool miners are incentive to pre-forward what the transactions they are mining by the fact that their shares are punished (nodes attempt to build off their parent instead of the share). Though I don't think that really usefully applies to the Bitcoin network.

I'm not sure where you're getting 10% from— but orphaning rates are not that high, even extrapolating on block size. Your analysis is also ignoring RTT, and changing the data size transmitted doesn't change the contribution to latency from the speed of light.

P2Pool already implements basically the protocol you're describing. Works reasonably well.  I don't know that it's especially interesting except for miners, however. Objectively, it doesn't seem that miners care that much since they haven't all switched to p2pool.

The parent must be fetched or the network will not converge.
The time does not tell you this, its not monotonic (and can't be monotonic without creating minor vulnerabilities.)
The amount of work assigned to a header is a strict function of the prior chain. There is no permitted variation _at all_

If you're going to go crazy with compression you could actually transmit only half the transaction IDs (16 bytes rather than 32) and half that, I suppose.

St. Barbara's FixedGate Miner 3.0

This doesn't have anything to do with the POW.

No— and no good way to estimate it except basically pure conjecture.

Many nodes don't listen to inbound connections— but still otherwise fully participate in the network— and there is no way to detect one of these except by having it connect to you.  Some of these are on tor or just on frequently changing IPs so you can't easily even count them even if they connect to you.

You appear to be claiming that I misquoted RFC 6716. You do realize that I wrote (and revised in many subsequent revisions) that section of the RFC, right? It's not clear to me specifically how you're misunderstanding that sentence but what it's saying is no different there than what we might say about Bitcoin: only the code that defines how a node responds to a block is normative, not the code that actually authors a new block.  I'll consider accepting an apology— but after all the other times you've been a jerk spewing adhominem and vague allegation about subject matter you were totally wrong about you're going to have to phrase your apology very nicely.

And would you cut with the allegations that you need to quote me for any particular reason? If for some bizarre reason I wanted to edit my comments I could edit them right inside your posts. As far as I can tell you're doing that to imply that I'm dishonest in order to piss me off. Congratulations, you've been successful. I'm wondering if you behave like this in person, and if so— do you get a discount on cold-compresses for all the black eyes you must inspire people to give you?

An argument can be made for that, but I am very skeptical.  Bitcoin is a distributed consensus system. The deepest and most fundamental definition of correctness— above _all_ other considerations— is that they actually achieve global consistency.  It is more important the Bitcoin nodes achieve a consensus than behave in any accordance to an other particular definition of "correct" (though, other forms of correctness matter of course, but they is a dim flicker to the furnace of consistency).  A specification can say many things, but if the installed nodes behave differently from the specification but consistently with each other and its over a matter which would cause a failure to achieve a consensus then it is the specification which is wrong in any practical sense, not the nodes, and the specification which must be changed. In effect any not-practically-executable specification is a dead letter, pure fodder for rules-lawyers to debate, and not something that would exert influence on the real world.

A parallel formal description may be good for additional confidence, but unless it can be extracted (e.g. like the software to extract code from COQ proofs) into reasonably performant production grade code it cannot practically be the normative specification.  Sure, you could call it that— but the claim would be a lie. It's worth noting that suitably authored (e.g. ACSL annotated) C is machine checkable, and also runnable— allowing a who layer of additional tests (e.g. catching some cases where a checker can prove that the algorithm will complete, but failing to warn you that it would take 2^64 operations or words of memory to get there...)— and also allowing it to be an actual normative specification which could functionally define the behavior on the network both on rules-layer paper but also in practice by actually defining the behavior of real nodes which must be exactly matched.

An RFC would be perfectly capable of documenting the protocol rules, it would just be very hard to do, and very hard to gain confidence that you got it right.

In RFC6716 we went the route of using source code as the primary normative specification: "For the practical reasons of compatibility and testability, it would be advantageous to give the reference implementation priority in any disagreement.  The C language is also one of the most widely understood, human-readable symbolic representations for machine behavior.  For these reasons, this RFC uses the reference implementation as the sole symbolic representation of the codec."

Opinion's differ on this being the best thing to have done for RFC6716, but the argument applies much more strongly for Bitcoin— where even the smallest disagreements can break the software for everyone in the world, not just the users of the oddball software— than a multimedia codec.

It may be the case that future refactoring, cleanups, and modularization eventually end up segregating the protocol rules part of the reference client into isolated parts that seldom change (only when changing the rules!), and then they'd act (either internally or pulled out and stuck in a digital-dead-tree) as better specifications than we have today.

The original idea for ripple was a credit network based on pairwise trust. The reliance of pairwise trust instead of global consensus gave it a significant scaling advantage compared to blockchain crypto-currencies: if you make a set of trades that can be settled entirely within your local community there would be no need to tell the whole world about them. It would have been possible to use ripple along side Bitcoin in order to get low cost high scale transactions denominated in Bitcoin— which you then periodically and automatically settled with actual Bitcoin.

The ripple system of today is very different: It is a blockchain global consensus system— like Bitcoin, with all the inherent scaling limits— which exchanges pre-mined coins.  It replaces the attack resistant decentralized POW consensus in Bitcoin with a something which is either dependent on centralized trust or, alternatively, is sibyl vulnerable (depending on how  UNL actually plays out— the system basically punts sybil resistance to the user, instead of being fundamentally sibyl resistant like POW systems; my expectation is that sybil resistance is too hard to punt to the user and the effect will that people will only trust a few big nodes— effectively making it a centralized system).

How did it go from a interesting and potentially worthwhile addition to the cryptocoin ecosystem to— what basically amounts to— "just another premined altcoin"? Frankly, the whole things sounds like something RealSolid would have come up with now.

Unfortunately, the large consolidation of hashpower under a single administrative entity creates peril, not security. Doubly so with the hashpower assigned to one of the largest mining pools.  The consequence is that there are fewer operations which must be seized, coerced, or hacked in order to undermine the operation of the network.

Congratulations are in order, indeed— but its regrettable that more hasn't been done to mitigate the risk to the Bitcoin ecosystem (getting devices sold ASAP, splitting operations to reduce the incentives to capture it, mining solo, p2pool, or on smaller pools) yet.  I hope more independent parties come online before continued consolidation (rightfully) undermines confidence in Bitcoin technology.

Then it sounds like 'write calls' doesn't mean what we think it means here.... or leveldb is doing something crazy on win32. In strace output it's pretty clear that it's being batched as expected under Linux.

There is no randomness in mining.

Cut it with the offtopic posts. They are being removed.

Edit: Geesh. Unless your post is narrowly related to having received an asic/avalon unit (or at least closely related like your shipment info) then it doesn't belong in this thread. See the original post's gigantic type.

Sadly, Bitcoin isn't a magical anti-tax fairy. When you sell those coins for something else, you'll owe taxes on them and in all likelihood you won't even be able to enjoy preferable tax treatment (e.g. capital gains tax) for it.

Perhaps you're planning on breaking the law and not paying taxes on your income— well, okay, but Bitcoin isn't special there, you can do that just as easily if you're paid in cash— but this is insanely foolish at least in the US— tax collection is insanely powerful and the deck is not stacked in your favor.

They can also be placed in an addr.txt, as the OP asked about. Addr.txt has the advantage of just feeding the database, not forcing connections like addnode does.

Unless there is some attack on bitcoin bootstrapping there probably isn't a reason to use addr.txt, however.

Adding a long list of addnodes like that is somewhat inadvisable, it wastes resources on the network...

That doesn't make you sure it won't be corrupted. No widely used filesystems give you atomic operations across multiple files (and even if any did— we're not invoking them).  Especially with 0.8 introducing a brand new potentially warty storage engine it's good to have the checking though turning it down is way better than turning it off— most of the benefit comes from checking the most recent blocks.

If multiple people sign for the same output I can only accept one.  After the first couple collisions I ended up listing a bunch of outputs to make collisions less likely.