I see PetaMine are having a vote on switching to p2pool. http://www.reddit.com/r/Bitcoin/comments/28o1cy/petamine_is_holding_a_vote_to_switch_to_p2pool_if/
While they are not a pool, it is interesting nevertheless. Hopefully this happens and makes it very tempting for some of the smaller pools to join, triggering a cascade.

Would it be too much to ask for all major mining operations to be working via p2pool? It would be so cool to know in near-realtime which txs are being worked on.

OK. It is important to keep in mind that even without any changes and without any pool providing any additional data, multiple pools using a p2pool-like backend would provide reduced variance. In order to prove that a given tx is being hashed by a given pool, there are various ways to go. The simplest would be for the pool to simply provide a merkle branch linking the tx to the merkle root. This may be a paid service.* Alternatively the pool may provide the full ordered list of tx hashes in the share. If the pool is also willing to provide the txs corresponding to any unknown hashes, this proves that it is not working on any private transactions that have not been disclosed to the rest of the network. This additional data (the merkle branch linking a given tx, or the full list of txs, need not be sent on the p2p network, but can be available from an API on the pool's server.)


I don't think any more efficiency is actually required. The additional data that is required to wholly or partly verify the "working tx set" need not be transmitted on the p2p network (in fact if the data is to be sold, then it cannot be sent on the p2p network), and is actually quite lightweight for something served via a traditional webservice.


This is not quite correct. Larger pools in the superpool will still have lower variance than smaller pools, but it is possible for smaller pools in the superpool to have lower variance than large pools outside of it. A good example would be if BTC Guild and Discus Fish (both at 12% of network hashpower were to join into a superpool) Now BTC Guild has a lower variance, but it has come at the "cost" to them of also giving their competition Discus Fish a lower variance. Since they are equal in size and relatively small in comparison to the rest of the network, this seems like a good deal for both of them. If they were to let Eligius join their superpool, their own variance would get lower, and while Eligius variance would reduce, it would still be higher than theirs.



As I see it, the only pool that currently does not have an incentive to join such a superpool, is GHash.io. The tiny pools have nothing to lose, and the medium sized pools are better off joining a superpool with other medium sized pools (allthough possibly not with tiny pools) than not joining.

*This allows for new models of tx-fees. For example I could send a tx with no fees that would not normally get included in a block, but have a pay-per-share transaction fee contract in place with Discus fish. Discus fish would then work on including my tx in a block and receive a nanopayment from me for every share that they produce with a  valid merkle branch linking my tx to the merkle root. The downside is that this introduces variance in my tx fee, I may get lucky and pay a very low tx fee if one of the first shares that mining provider produces is a block, but I may also overpay, significantly if it takes very long before a block is found. The upside is that as a consumer I can choose which pools I wish to support with my tx fees.

Well, yes, except it  wasn't me it was forrestv. :-). I am actually quite familiar with how p2pool woorks, and the few differences between the p2pool sharechain and the blockchain itself that you point it are integral to my proposal.


Unless I am very much mistaken it is once every 30 seconds. And this increased rate is what allows the benefits that I highlighted in the OP. Since shares are worth less than blocks a pool mining for shares as ppart of a larger conglomerate of pools will see lower earnings variance. The pools are effectively insuring each other against bad days, while remaining completely independent as far as block construction etc. is concerned. Usually a high blockrate has a downside since it results in more orphans and wasted hashpower. However, since the block rate of the underlying network is unchanged, this does not apply in this case. And since this p2pool is intended for use by a few pre-identified centralised pools, we could even raise the share generation rate higher still if the latency of the network links between the pools is low enough.


There is one big difference. If I get the list of pending transactions from a pool node's memory pool, I have no guarantee that the node is being truthful. It may show a tx paying me as being in the mempool, while behind the scenes it is hashing away on a different (double) spend of the same utxo. However, a sharechain provides an unforgeable proof that one or more of the participants in that chain was actually actively mining my transaction. Pools can provide the same proof in the current framework by simply publishing their best submitted share every X seconds. However they then lose the smoothing of earnings benefit.


I see no reason why any pool would need to change anyythinng on their fron-end. The pool is still mining to their own address and they are still paying out users with mature coins like they currently do. Users would see very little change other than reduced earnings variance. So if Btc Guild (12%), Discus Fish(12%) and Eligius (8%) were to band together like this they would present to their users earnings variance only slightly higher than a non-aggregated pool with 30% of network hashpower, while remaining independent as far as transaction selection goes (i.e. Eligius would mine certain non-standard txs while Discus Fish does not). Even if this aggregation of pools were to grow to 60% of the network (thus providing lower variance than any non-aggregated pool operator could offer) no single pool operator would be in a position to mount a 51% attack. And the sharechain would provide early warning if a pool operator started withholding hashpower (to perform a Finney attack or selfish mining for example).


Aware of this. Today pool operators do this by having their own stash of mature coins which they can pay out to users while waiting for the freshly mined coins which will be coming to the pool address to mature. This will remain unchanged


I'm pretty familiar with the working of p2pool allthough my knowledge may be a little dated. I hope I have clarified the points in my proposal that created confusion.

Thanks for the constructive reply.

No, I understand that a 51% pool still has 51% irrespective of mining via p2pool or otherwise. I did not claim that this would prevent a 51% attack.


I've always assumed (incorrrectly it would appear) that there are multiple p2pools, to counter the very problem you highlight here. Nevertheless it would be a trivial modification to the p2pool source code to ensure that the pools that mine into THIS p2pool (lets call it poolp2pool :-)) do not share a sharechain with the already existing p2pool miners. Therefore the existing p2pool difficulty remains unaffected. So if you initially had just one major pool switching to a system like this they would just be competing with themselves for shares on the new sharechain and their revenues would be unaffected, they will however, in the process provide the rest of us with an unforgeable proof of which transactions they are currently working on. This data has value and it could even be sold to interested parties (anyone interested in accepting low-confirmation transactions, or trying to estimate the fee they need to include to get their tx into the next block). This is an advantage in itself. However, when a second pool joins this poolp2pool, things get even more interesting, since both pools (and their miners) now see reduced earnings variance. For a miner with too little hashpower to  mine in p2pool directly, this becomes the next best option and miners have less incentive to join the largest pool since even tiny pools mining into poolp2pool can provide low variance income.

I think there are some advantages to be had if some of the centralised pools would mine through a p2pool node, effectively creating a superpool.

Firstly, the resulting sharechain would provide an easy way for those parties with an interest in accepting low-confirmation transactions to know which transactions the pools are actively mining.

Secondly, if multiple pools point their hashpower at the same p2pool node, they will all see reduced earnings variance and get a share of the p2pool donations. This would remove (or at least drastically reduce) the incentive for miners to join the largest pool in order to reduce variance.

It would allow for much more accurate estimation of network hashpower and the hashpower split between pools (assuming pools don't hide their identities), which would also allow us to determine the fraction of the network in favour of a given proposal (think of the p2sh voting) more rapidly and accurately.

No, but this is.

According to http://freakonomics.com/2014/02/25/what-does-the-mt-gox-meltdown-mean-for-bitcoin-maybe-not-much/ there will soon be a freakonomics podcast on bitcoin. Now they have an estimated 750 000 podcast listeners per episode (Some of it also goes out on public radio, not sure what the numbers there are). Now this is a factor ~14 less than the estimated viewership of The Good Wife, but the demographics are a great fit for bitcoin. Whereas the median age of a "The Good Wife" viewer is 60 the freakonomics listeners are


Here is a graph showing the distribution of occupations


Also, they are obviously interested in economics and unlike the case in the Good wife episode, it will be clear from the context that Bitcoin is a real thing and not a figment of some scriptwriter's imagination.   

Dude, don't laugh at the lady. Apparently she finds those jokes uni-corny.

All sentences that start like this are ultimately proven false.

They BANNED unicorns??!! I don't believe this.  Link or it didn't  happen.

 

[/quote]
OK, so apparently mBTC is dumb, but kBTC is not. Care to clarify your feelings on the other SI prefixes?

You should learn to make up your own mind. Be suspicious of any attempts by others to guide your actions (including this post). Do your research, choose your course independently. None of us know the future, and your opinion is just as valid as anyone else's (assuming you've done your research). So whether Max Keiser is indeed a profiteer or not, should be irrelevant.

FTFY

I suspect the real madness will take another 1-2 weeks to hit. New money following the flood of >1000 USD new coverage will take some time to get into the exchanges, especially if the verification queues are backed up.

Was excited for a moment there. We should come up with a currency symbol for goxbux, to prevent this kind of confusion in future.  

Think it'll be a few more hours (or days?) before we hit 1000 at stamp, which is when it will be real.

Context :

Yup. You were right weren't you. That valuation could not be sustained  .

 

No, that's wrong. If by "average" you mean median and by "bubble" you mean the 5 highs you have included in your data set, then mental arithmetic shows that the answer should be 2.7. Your software gave the wrong answer because you entered ...3.73, 2,7) instead of ...3.73, 2.7)

That's a good suggestion, but still open to abuse. The selfish miner mines a normal block, then a block with a high fee tx. It releases the high fee tx before releasing either of the blocks. Now it looks like the tx did not make it into block 1, and block 2 gets full credit for the large fee-seconds count it displays. Of course this requires a minimum of two pre-mined blocks to work, so your countermeasure assures that the attacker has gamma=0 in the case where both the private and public chains are 1 block long, (which is the only case where gamma mattered in the SM attack as described), but at the cost of giving him gamma=1 for any block races where the split is more than 1 block back. It is  trivial to adapt the SM attack to exploit this by not revealing the private chain when the lead gets reduced to 1, but rather only once the public chain catches up (since gamma=1 means everyone will prefer our fork), which allows us to build longer secret chains.

I am also concerned about the potential to exploit something like this by not working from the head (i.e. we give the public chain a 1 block headstart). Unless the block creator explicitly maximised his transaction-fee-seconds score at the cost of all other considerations, I can build a block with a higher txfee-seconds count and know that my block will win the block race. 


Even if you fill up a 1MB block with 192 byte transactions, each carrying a 0.0001BTC fee, you only spend 0.546BTC in fees. A selfish miner will fill a block with all the public transactions it deems small enough and then fill all the remaining space with small secret transactions that carry fees (which he expects to get back). As soon as the block has been mined, he releases the secret transactions. Then no honest miner can exceed his transaction-seconds score, the best they can do is to match it, and unless they are using transaction-seconds as the only measure to optimise, they will probably end up with a lower transaction-seconds score.

Curious to hear your opinion on HanSolo's proposal.

Understood, but we aren't really relying on the self-asserted time are we? If we said that we give preference to the one with the earlier timestamp, or the one with the later timestamp, then people would certainly lie about their internal time. But given that we give preference to the block that matches our own internal timestamp the closest, it seems to me that the incentive is to be as accurate as possible with your self asserted time. As things stand today we are implicitly relying on self-asserted time in the sense that nodes assume that the time when a block is received is a good proxy for the time when it was mined. But, as selfish mining shows, this proxy is open to systematic abuse by the miner who mined the block and may choose to delay its broadcast. The miner can only adjust self-asserted time in one direction, but he has an incentive to do so. Under the modification proposed, the miner can adjust self-asserted time in both directions, but his incentive is to report time as accurately as possible.