Nope.

That would be my advice, yes.  (Well, my advice is to run p2pool!)

Also, you shouldn't need a patch— as mentioned if you up maxconnections a bit (don't go over 900 or so!)  and wait a while you should get a fairly large number of connections in a while.

Sorry, Missed this part the first time. The file will automatically split. Thus the 0001.

This is really irrelevant for P2Pool because p2pool forwards blocks among the p2pool miners and has them all forward it in. This works really well because the p2pool forwarding is much faster than the bitcoin forwarding because it has to do less validation work.

Actually having large numbers of connection on the daemon you're mining from is a bad idea because servicing large numbers of mostly useless random windows users will slow down the daemon you need to be responding promptly to process blocks and mine.

In my P2pool operation I run four bitcoin daemons:  Two service p2pool nodes and only connect to my own nodes and a couple of carefully selected large miner daemons. One is a regular listening public node (with simply maxconnections=512, no crazy patches and it now has 489 connections), the other is a hidden unannounced node on secondary connectivity for dos resistance.

This is the sort of setup you want for reliable mining. Not some connection spammy patch.

No it wouldn't—  they only have to pay out of pockets their reduction in the victim pool's return. They can claim to be as lucky as they like, presuming they are hiding the identity of their blocks.

But P2Pool is resistant here, both because the block bonus makes it even more unprofitable to withhold, but also because the real justification for refusing to use a habitually unlucky pool, that it might be an indicator of an operator who is skimming, just doesn't apply.


Pretty much no one does this, IIRC none of the miners facilitate doing this in a way that would make it easy (e.g. provide a separate log file of found block). And now with all these non-public pools operating that give >100% reward it's hard to simply audit pools because they're not generally accessible.

(in light of the recent lucky run, I changed the threads subject )

It's not a bug, its a feature.

The client hears about it in the version messages, but it can't just trust it or some trouble maker will claim that the height is ten trillion. So, IIRC it takes a median and won't provide one if you only have a few peers.

If it doesn't have an estimate from the peers it uses the highest checkpoint.

This is already how BIP16 works. All BIP16 transactions are required to be valid under the old rules (and are validated twice to ensure this). The activation time is only when they start enforcing the new rules.

Reducing your pubkey sizes will also reduce what you pay in transaction fees when you spend coins sent to those addresses— and potentially it could make vanitygen faster due to having two tries for every private key.

People can, and do, audit the software— even the binaries due to the use of a deterministic build process— so any replacement with a compromised version has the risk of detection.  At least as things are currently constructed, an opaque blockchain wouldn't have this property.

Discussions of including the blockchain are ignoring the real issue too— initial syncup is slow because the chain validation is slow. The validation is slow due to IO related implementation issues.

Once this is fixed there will be a lot less cause for concern. Beyond that, the software should eventually make validation and downloading decoupled so that it could go on in the background— making the client usable even while downloading/validation is going on. This would be much better than making the install file a gigabyte.

In any case, it's easy to propose things— and the idea that the package could include a copy of some blockchain, with the according loss of zero-trust hasn't failed to occur to pretty much anyone— why not sit down and spend some time trying to improve it?

On some of these services people are being paid 140-150% PPS, in fact.

Careful with suggesting anything, some of the operators of these services are known to put large bounties up to "uncover" evidence against people who ask sharply pointed questions.

There actually turned out to be no way to convince the database system to actually purge the data. The cleanup is handled by creating a new database, copying the data over, and deleting the original one. Doing this completely even requires shuttdown the library so all the databases can be cleanly closed.  A real pain.

There is no particular reason you should need or expect more, really.  We don't currently have a shortage of available ports.

(and just because it wouldn't be clear to everyone: the 'patch' in the other reply here would result in memory corruption, and shouldn't be used)

Might want to get the suppression of "stale" shares made configurable by the pool in the pooler miner, as was recently done in cgminer, in order to make sure ltc p2pool performs well.

I haven't seen any mention of compressed pubkey support.

The latest versions of Bitcoin (perhaps just git, so .6 post but I'm not going to bother checking) will default to creating addresses based on compressed public keys.

These addresses look just like every other address but they take up less space in the blockchain when you spend from them (and thus lower txn fees in the long run).

Every private key has two possible addresses. One based on the compressed public key, one based on the regular public key.   It takes a bit more computation on top of the normal public key generation to get the compressed version.

It would probably be a good idea for vanitygen to offer / default to generating compressed public keys.

Have I missed discussion related to this?

It's worth mentioning that the (non-listening) nodes figures will probably drop substantially as the result of some new node behavior.

First, there are the announcement changes where nodes which aren't listening or arn't current with the block-chain will not announce their addresses to the network.

Second, the stochastic address manager will likely reduce the propagation of unreachable nodes so that old and never working addresses will probably disappear faster rather than circulating through the network like undead zombies.

Some of this may be counterbalanced by UPNP fixes increasing listening nodes, but this fix needs testers and isn't yet even in the pipeline for upstream until it gets some.

noirc was not sufficient to prevent you address from being relayed— bad guys couldn't get it from IRC but they could get it from the regular node to node address exchanges.

noirc + nolisten will be enough in the next version of bitcoin, however.

Oh great, it's a mildly disguised all pay auction (after all, if you stand to win 100 BTC shouldn't you pay up to 99.999 to your own voting address to win, and once two have done that shouldn't you keep on paying to minimize your loss?)  which also encourages bloating the blockchain with tiny transactions.

There is no reason to conduct a "vote" using the blockchain. In fact, doing so is a pretty poor idea because it gives miners the ability to influence the outcome by rejecting transactions.  It doesn't even secure you against manipulation, because the recipient of the vote-funds can just pay themselves (anonymously) to get whatever result they want since they're just going to get the funds back.

In the case of CLC you could, you just have to pay a 100 CLC transaction fee.  In the case of other ones, you may have to start two nodes (if you are the only one) and mine them yourself if you want to process a transaction.

What reject rate does your rpc miner show?  Are you running NTP (is your clock correct)?

The big -/+ means you don't really have much data for the estimate.  Those ranges mean that in fact your true stale rate might actually be pretty low.

Because you're a bit behind when you start its usually to get a couple stales right away that makes the number start out poor but then it improves with time.  It's not unusual for me to see stales at 20% shortly after startup but by efficiency is usually at 100% by the next morning or so.  (converges a bit faster if you have more hash power though)

I have no freeking clue what you're talking about, in fact.

I was told that the >100% payout private pools were operating services which returned clean coins to people engaging in unlawful activities, which seemed like the only explicable purpose for them since they are effectively paying people $1.15 for a _chance_ at $1.

If this was true I think the participating miners would have a right to know, since they'd be potentially putting them in front of investigations for the unlawful activities connected to the coins they received (if there was no such risk, why launder the coins?). My message explained this quite directly.

I included child porn in the list of potentially unlawful activities that people may trade with Bitcoin that the recipient of laundered funds may be investigated for in my cautionary message just because "Guns and drugs" sounded like SR, and I didn't have any reason to think the laundering was related to SR specifically, nor were they there to defend themselves— and I'm aware there have been issues in the past with people offering child sex services in our related communities.

I was particularly concerned that the people proffering these services were not even making an _attempt_ to argue a legitimate lawful purpose to them.

How was I supposed to know that Goat was a expat living in Thailand (?) who people had been previously accused of being involved in child sex trafficking?  :-/   I had not been made aware of those particular accusations (though perhaps the people telling me that the >100% payouts were for laundering had been). I was not aware of the previous boondoggle with the supposedly underage undocumented cam girl.  Though perhaps I might point out that in most of the developed world the obligation is on the provider of sexual content to document that their models are of age rather than demanding that other people, without the benefit of knowing their identity, prove them to be underage.

Do we really want to be running a community here where people express a concern the accused offer assassination market payments to "uncover" evidence against their accusers? I don't think this is acceptable.