It does make a difference. What happens to your share if it becomes an orphan block on the share chain? Other miners work on the competing block and you lose out on any dividends from your share. If my analysis in the OP is correct, this should be happening an alarming 9% of the time. A traditional pool, on the other hand, would count both shares as valid and pay dividends to both miners.

Again, if p2pool implemented a means of "merging" divergent share chains, that would adequately address this problem. Until then and ignoring p2pool subsidies, it's more profitable to mine an (honest) traditional pool.

Stale/orphan shares on YourTraditionalPool can also be valid block solutions. That's not the issue (the chance of your orphan block being a valid solution is just under 0.15%). The issue is that stale data occurs approx. every 10 minutes for a traditional pool, but every 10 seconds for p2pool while the network latency presumably remains the same (and therefore is of 60x more consequence). The discrepancy is because traditional pool operators are not required to linearly order shares into an auxiliary blockchain as p2pool does.

Put differently, when some other miner finds a share in a traditional pool, I don't have to have to update my unit of work unless that share is a valid bitcoin block solution. But with p2pool I do--every time--and often enough to where network latency has a significant dampening effect. Traditional pools have a "wasted work" overhead of about 0.15%, but as this effect is small and nearly the same across the board, it's not something we talk about much. However p2pool is unique in requiring synchronization 60x as often, making this effect very real, measurable, and a significant factor.

Put differently again, if my overclocked GPU is reporting 400MH/s and I signed up for deepbit, to name one pool just for the sake of argument, my useful contribution--after subtracting time spent stale data that doesn't have a chance of being accepted--would be closer to 399.4MH/s. That's such a small difference that it's easily lost in the noise and hardly worth talking about... except that with p2pool, my useful contribution would be 356MH/s--a full 43MH/s less. That is significant, and worth complaining about.


BTW, there is a solution, although it is not easy: create a procedure within p2pool for the merging of divergent/orphan chains.


EDIT: Put even more simply: what happens to orphan "blocks"/shares in p2pool? Therein lies the problem.

That's not how the bitcoin wiki describes p2pool...


The wiki also says:


Which is misleading. Stales don't affect your payout relative to other p2pool nodes (assuming everyone is equally well connected, which is actually not a good assumption), but they do affect the overall payout per unit of work crunched of p2pool vs. other pools.

EDIT: clarified wording

My understanding is that p2pool operates an alternative blockchain with a 10-second target interval, where each found block constitutes 1 share. Somewhat coincidentally I have previously looked at the properties of an altchain with 10-second intervals, and what I found was that the network latency/p2p propagation time was a significant factor. On bitcoin proper it takes about 1.9 seconds for a newly minted block to find its way to all the bitcoin peers. Assuming you're solo mining with long-poll enabled, that means you're working on a stale block 0.15% of the time, on average (since you can assume the time it takes a block to reach just you is half the latency). But on a 10-second round, that likelihood is now 9%, a couple of multiples larger than even the most ostentatious pool operator fees.

Is this accurate, or am I doing something wrong with my math?

EDIT: I can't find any reorglog statistics for p2pool online, which we could use to determine p2pool's network latency... if someone has kept track of this, let me know.

EDIT2: P2Pool is safe to use! My analysis above, while not incorrect, is incomplete and only half of the story. The amount paid per share that *does* make it into the share chain is also approximately increased by a corresponding amount, negating the effect due to stale work.

"gettext" is what you are looking for.

That's what the Satoshi client does, which this client interfaces with. All he's doing is trusting that the Satoshi client is doing its job.

I, too, would use and contribute to this project if it were released under a more permissive license (BSD preferably, LGPL if you must). As it stands I cannot even look at this code due to the possibility of legal risk to my company.

ArtForz hits my main complaints. As I said, either very rushed or not very competent. Given that we don't know the facts I'll be polite and assume it was the former. Maybe he really rushed to meet that new years deadline three years ago.

yes.

Guys, let's stay on topic. If you want to debate that, start a new thread.

@BP, yes it's the same company, but that post is not representative of our current projects.

While I generally agree with your sentiment, I take issue with a few of the details. Satoshi is an interesting case in that he clearly thought out many of the advanced use cases of bitcoin, and took baby steps toward implementing/enabling them before releasing the client into the wild. As an example, all of the contracts/scripting code was not necessary for bitcoin to do what bitcoin did at launch, and indeed some features were clearly untested as they did not work as advertised. However Satoshi was either very rushed or not a very competent programmer by industry standards, and that shows up in his code. Much of the work Gavin and others have done is just in cleaning up that mess. Also, Satoshi demonstrates an ignorance about the state of the art in academic computer science, unnecessarily cutting off valuable future enhancements. Finally, while Satoshi had the foresight to imagine complex use cases in the future, he lacked the imagination to think up many applications outside of tech and finance, which the current implementation unnecessarily hinders.

I have the utmost respect for Satoshi. He single-handedly took anonymous crypto-cash, which we've been talking about since the 90's, from concept to practicum. Beyond my respect as a fellow engineer, my company hopes to profit greatly from that. But... deification doesn't help anybody. It only obscures existing flaws and potential for future improvements.

The other aspect is that the economic underpinnings of bitcoin are fringe and esoteric, and the in practice application of it as a currency is clunky and, well, not very practical (I'm being honest and stating my informed opinion--not trying to start a flamewar!). Don't underestimate how much of a turn-off that is for the vast majority of developers and business people, who probably have real-world experience using e-payment solutions like Braintree, WePay, Stripe, or Square, or were trained in Keynesian economics. To these people (I count myself among them), the bitcoin project is seen as a combination of childish optimism and inexcusable ignorance. From that standpoint, the people bitcoin attracts are either 1) the fringe intellectuals (Austrian-school economists, extremist libertarians, etc.), 2) engineers who recognize the significance and disruptive nature of this technology, 3) those with something to hide (tax evasion, drugs, money laundering, general profiteering), and 4) the ignorant and/or naïve. While I of course count all the good sirs I have conversed with here in the first two categories, unfortunately bitcoin has attracted predominantly #3's and #4's, and in this subforum that is more true than others.

That's because we're not public yet.

I'm CTO of a Mountain View-based startup that is working on a number of products using a bitcoin-derived protocol. Actually when we first started a little more than a year ago we trying to solve a problem in a completely unrelated field. The primary technical challenge and the key to monetizing the product basically boiled down to building a distributed, peer-to-peer time-stamping service for notarizing changes in ownership. Sound familiar? Unfortunately none of us heard about bitcoin until the bubble over the summer when bitcoin mania spilled into the mainstream media. Naturally it was refreshing to find a ready-made solution to our problem, with most of the kinks already worked out.

So why am I telling this long, uninteresting, and self-absorbed story, you might ask? Because once we we saw that bitcoin solved our problem we wondered what else it could do. And lo and behold, just about everywhere we look, in every industry (even--especially--outside of tech and finance) there are low hanging fruit ready to be optimized or made obsolete by the introduction of products based on bitcoin P2P technology. We've set aside for now our original project and are now working on a number of products that all much easier, and many of them much larger in potential impact (and revenue)*.

It took me a while to convert (not the least because bitcoin's economic underpinnings are populist bullcrap and it will never take hold as a viable currency--but please start a new thread if you want to debate me on this), but now I am convinced that without exaggeration bitcoin is the most disruptive technology to emerge since the World Wide Web. Just not for the reasons most on this forum probably think.

In the time the truth will show itself. Now if you excuse me it's Christmas day and my present to myself is a long block of uninterrupted coding

* You'll have to forgive me for being cagy, but I'm under NDA and of course all potential businesses we've identified are company secret until we launch or decide for sure not to ever pursue.

(Oh, and before anyone cynical wonders outloud why I'm posting this (and I've said the same thing as the OP before), it's because we could actually use some competition. The potential applications are diverse enough and it'd actually validate our business in the eyes of investors.)

2013 will be the year that bitcoin goes mainstream, but not a way that you would currently recognize. 2012 will be a year of transformation, the impetus of which will not come from the Satoshi client (Gavin's great work notwithstanding).

Interesting. I've already got this working within our own (not yet publicly released) bitcoin-derived protocol. We also chose LISP as the language for writing "chain definitions", as we call them but I like your phrasing better, as well as replacing the opcode-based scripting system for transactions. We're also using the bittorrent protocol for the P2P overlay network and DHT capabilities, so I can report that works well (and better than bitcoin, I believe, although we haven't the metrics yet). I would add that the prospectus could include rules for accepting or rejecting future modifications. That's how we're handling it, combined with a PKI infrastructure.

Meaningless and inconsequential--blocks don't have inherent difficulties. If the pool operator gives me a block it could take me a billion hashes to find a solution--or I could get it on the first try. How long it takes is just dumb luck in choosing the right (or wrong) starting nonce.

I am doing no such thing. Rather I am recognizing that the practical reality of the situation such that much of the costs of mounting an attack would be up-front/sunk costs (buying hardware, building a botnet, etc.), so much so that in any realistic scenario the difference in cost between simply preparing an attack and actually mounting it would be relatively quite small.

In the absence of a cloud-based burst-compute utility suitable for hash-computations at a scale to rival bitcoin and at a reasonable price (which doesn't, and likely will never exist), utility computation is a terrible model for the economics of attacking bitcoin.


1) such burst computing capacity does not exist
2) you're assuming the price-per-hash of utility compute will be comparable to the expenditures of your average bitcoin miner. in reality, it will be orders of magnitude more with something like AWS.
3) bitcoin needn't "consume a majority of all fungible computing power"--just a majority of the discretionary computing power/excess compute capacity. As stated that's a false argument, because...
4) you're ignoring the opportunity cost of that burst computing capacity. for small amounts of compute power this is zero. but once you exceed excess capacity you will be competing with existing users, driving up the price far in excess of actual costs.
5) if you can isolate a node, a 10 minute block interval won't provide much more protection than a X-second interval--.
6) network latency is 2.1 seconds today, with really very little optimizations. i expect average network latency for well connected nodes to go down, not up in the long term, but that is really a topic for a different thread.


And those are valid points which I agree with. Bitcoin should remain at 10 min block intervals, IMHO--but for these reasons, not because it offers any additional protection against hidden-adversary double-spend attacks (it doesn't).

Show me, mathematically, why that is the case.

I have done the math (summarized earlier), and done simulations to verify this fact: as long as BLOCK_INTERVAL is significantly larger than NETWORK_LATENCY, one's chance of forcing a re-org to undo a transaction depends only on the number of confirmations and the percent of global hash power controlled.

So please, either bust out the math to show me where I'm wrong, or tell me how you're defining 'security'. Because from where I sit, breaking the security model means undoing a transaction, and the chance of doing that depends only on your relative hash rate and the number of confirmations.

But heck, don't take my word for it. Page 6 from Satoshi's whitepaper:


EDIT: For what it's worth, I agree with what has been posted earlier that decreasing the block interval yields little benefit unless you can get it down to single-digit seconds. 10 minutes remains a very good compromise. But nevertheless, decisions should be made on the facts.

I understand that, but that is not a meaningful distinction in the context of this thread or in the practicalities of attacking bitcoin. If I have 30% of the global hash power and overnight bitcoin changes from 10min blocks to 2min blocks, my likelihood of executing a double-spend after X confirmations is negligibly different before and after.

Yes it is would be 5 times harder if the honest network magically increased to 5x it's original size, but that's not what will actually happen if the block interval is changed.


If bitcoin ever reaches Visa-level of adoption, we will likely see many federated, industrial mining operations connected by direct fiber-optic connections. Latency will be no higher than it currently is with bitcoin or Visa (a few seconds, typically).

No, that's simply not true by any meaningful measure (see my previous post), although it's a commonly repeated myth on these forums.

That statement is equating security/safety with number of hash operations needed to undo a transaction. But that would only be true if work stopped on the honest chain. In actuality, the only thing that matters (and the math shows this) is percentage ownership of the global hash rate, and the likelihood of pulling off that attack decreases geometrically with the number of confirmations, regardless of block interval length.

The power dilution is approximately the network latency of the dishonest network minus the network latency of the global (honest) network, divided by the expected block interval. As a consequence, it has little difference if we're talking about dishonest pools. Given that the current network latency is about 2 seconds, it has very little effect at all. We can get well under a minute before it even starts being measurable.

No, it's not. The proof-of-work is a Poisson generator, meaning that the expectation value for the attacker follows an decaying exponential, which is itself a function of the number of Poisson events--i.e, the number of confirmations. So the probability of overtaking the honest chain after 6 blocks on the 2min intervals is exactly the same as 6 blocks on 10min intervals--hashes/block doesn't figure into the equations anywhere at all.