[1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff]

[nelisky]

I can't say for sure how long it has been, but from a day or two ago I have 0 accepted (and 0 rejected) shares? Wtf? cgminer reports the speed accurately (2.4.1 on openwrt) but that's that, basically.

Are you seeing accepted shares in cgminer, but not on website under "my account" -> "workers" ?

You are sure you are using the correct credentials in your cgminer config?

If you send me your BitMinter user name I can have a look at things on the server side. You can email me at operator@bitminter.com

No accepted shares on either cgminer or website, and yes, I'm sure the credentials are correct (unchanged). I'll email you the username.

Following up on this issue, the problem lays in endianess. I will submit a pull request for this to cgminer, it is working fine for both default work fetching and GBT, haven't tested on stratum yet.

[1713521537]

1713521537

[1713521537]

1713521537

[MinorMiner]

Looking forward to testing stratum to Bitminter for a while to make sure things run well then that will be one less thing to worry about with ASICs arriving (whenever they do).

I do hope the luck gets better though. it's been kinda painful over the last week.

Hope everyone had a great Thanksgiving ( that celebrate it )

[-ck]

If you were having a problem with cgminer + GBT on this pool, I'd like to recommend upgrading to cgminer 2.9.5 which has fixes for rare large coinbases which were causing a cgminer crash.

[DrHaribo]

Stratum is almost ready for testing.

And yes, we have had too many orphans lately.

I think it's time to start limiting the number of transactions we include in a block. It would make the blocks smaller, which would make them propagate faster through the bitcoin p2p network, and reduce their chance of being orphaned.

Our latest orphan at height 209437 had 722 transactions. I see EclipseMC also got an orphan today with 695 transactions.

Suggestions for pool transaction rules? Max X transactions per block and max Y minimum-fee transactions per block? Anyone know what other pools are doing?

It's a shame to have to limit transactions, but we can't keep throwing away money so that SatoshiDice can make money faster. Not that they are doing anything wrong by using Bitcoin, but this is how it is from our perspective.

Edit: if you want to comment on this and don't have access to post outside the newbie section, write in the BitMinter newbie thread instead: https://bitcointalk.org/index.php?topic=22432.0

[lumberjack]

Pondering some of Gavin's suggestions on https://bitcointalk.org/index.php?topic=95837.0

Perhaps some combination of 'Create Smaller Blocks' and 'Punish High-Frequency Users' settings? Maybe:

blockmaxsize=100000
blockminsize=0
blockprioritysize=50000
mintxfee=0.0005

[sturle]

I think it's time to start limiting the number of transactions we include in a block. It would make the blocks smaller, which would make them propagate faster through the bitcoin p2p network, and reduce their chance of being orphaned.

Are you sure this works?

Last time I did a shallow analysis of this, I found that while there was a connction between block size and the chance of getting orphanded, the larger orphaned block was almost always newer than the winning block.  Which means that the orphan block is larger because it has been accumulating more transactions while the older block was busy propagating through the network.

Smaller blocks means we have to wait longer for normal transactions to get confirmed by the network.  SatoshiDice transactions have a fee, and will win over standard no-fee transactions from normal clients, MtGox, etc.

Suggestions for pool transaction rules? Max X transactions per block and max Y minimum-fee transactions per block? Anyone know what other pools are doing?

It's a shame to have to limit transactions, but we can't keep throwing away money so that SatoshiDice can make money faster. Not that they are doing anything wrong by using Bitcoin, but this is how it is from our perspective.

By reducing the number of no-fee transactions we actually give higher priority to SatoshiDice transactions.  Blocking transactions to or from 1dice addresses with fee < 1 BTC is a better solution, IMHO.

[DrHaribo]

For comparison, what some p2pool users are using: https://bitcointalk.org/index.php?topic=18313.msg1326067#msg1326067

blockmaxsize=100000
blockminsize=0
blockprioritysize=2000
mintxfee=0.0005

Are you sure this works?

Yes. The slower a block propagates through the bitcoin peer-to-peer network the higher the chance it is orphaned. That's because others will be making blocks that compete with yours because they haven't seen your block yet. And the bigger the block the longer bitcoin nodes take before accepting the block as valid and passing it on to other nodes.

So I would think that reducing the block's transactions by X kilobytes will reduce the chance of the block being orphaned by Y percent. But I can't say what X and Y are.

Smaller blocks means we have to wait longer for normal transactions to get confirmed by the network.  SatoshiDice transactions have a fee, and will win over standard no-fee transactions from normal clients, MtGox, etc.

I haven't looked at what the SatoshiDice transactions usually carry in fees. But yes, slower processing of transactions is the downside to limiting how many transactions we include in each block.

This is unfortunate for Bitcoin. And I think it is too early for a real market-effect when it comes to processing transactions. The new coins you mint are much more valuable than any transaction fee. The incentive for a miner is to just toss all the transactions and maximize the chance of keeping those new coins. If pools did that, though, it would be a disaster for bitcoin.

So why risk our 50 BTC for an extra 0.1 BTC in fees? Because otherwise we destroy bitcoin (and the value of those 50 BTC). But we must keep this risk manageable.

By reducing the number of no-fee transactions we actually give higher priority to SatoshiDice transactions.  Blocking transactions to or from 1dice addresses with fee < 1 BTC is a better solution, IMHO.

I like the idea of a "market" for transactions and their fees. Giving priority to the transactions that pay us also is the way for us to make the most profit.

But blocking SatoshiDice transactions is a valid suggestion, I think. Even if we lose some (insignificant amount of) coins doing so, it means newbies can try out bitcoin and see fast transactions. The fees are so insignificant anyway. What is best for bitcoin - slowing down newbies or SatoshiDice? It may be more important to give new users a good impression of bitcoin than to support the SatoshiDice spam.

Of course the real problem is that bitcoin in its current state does not scale beyond minor usage. That's something the bitcoin devs can hopefully fix in the long run. But in the short run I need to take care of the miners in this pool and keep the pool from going bankrupt paying orphans.

[kano]

Ah another pool looking to increase their pay by making BTC worse rather than fixing their pool.
Puts you in exactly the same class as Eligius - that's what Eligius did,
Well I guess this is another pool that people should avoid.

[DrHaribo]

Ah another pool looking to increase their pay by making BTC worse rather than fixing their pool.
Puts you in exactly the same class as Eligius - that's what Eligius did,
Well I guess this is another pool that people should avoid.

Miners are unhappy losing money. And the pool is in the red. I'm paying for the privilege of running this pool. When I run out of bitcoins, I'll have to shut the pool down.

So Deepbit, Eligius and many p2pool miners already use transaction limits below the bitcoin defaults. Probably more do as well. I think this is a good way to improve the situation until bitcoin scales better.

How do you propose to "fix the pool"? The pool is already well connected on the bitcoin peer-to-peer network. Directly connected to most pools. But if you have suggestions how we can get other pools accepting our blocks faster without reducing the amount of transactions, I'm all ears.

Well I guess this is another pool that people should avoid.

I guess most miners will instead avoid pools with many orphans. But this is why I want to hear opinions. If you mine on this pool and you think processing SatoshiDice transactions faster is worth losing some of your mining income, please speak up.

[loshia]

Doc,

As i said a couple of times you are my number 1 among all pools. So I am ok whatever you and community decide to do, in order to make this pool stay alive. If number of transactions depends on our payouts frequency (if it related to it at all), i am ok you to change it..If we have to pay something in reasonable amount like fee to reduce orphans it is ok also at least for me

Kano,

You have been very helpful to me several times. You know what you are doing for sure. And you are good also for sure. I see that for some reason you and Doc do not like each other very much. I will ask both of you to arrange your personal things in private. Stating here that we shall avoid this pool seems not good thing to do at all. From the other hand Doc has to respond something and shit begins to happen.

At the end nothing good will came out of your fight. I can bet on that. If you have something to propose to Doc how to avoid orphans just do it. Some of the users here have invested a lot in hardware and every % maters. From the other hand Doc deserves at least not to loose any money because of his hard work. We have to find a way out all together

Peace

[meowmeowbrowncow]

Ah another pool looking to increase their pay by making BTC worse rather than fixing their pool.
Puts you in exactly the same class as Eligius - that's what Eligius did,
Well I guess this is another pool that people should avoid.

Miners are unhappy losing money. And the pool is in the red. I'm paying for the privilege of running this pool. When I run out of bitcoins, I'll have to shut the pool down.

So Deepbit, Eligius and many p2pool miners already use transaction limits below the bitcoin defaults. Probably more do as well. I think this is a good way to improve the situation until bitcoin scales better.

How do you propose to "fix the pool"? The pool is already well connected on the bitcoin peer-to-peer network. Directly connected to most pools. But if you have suggestions how we can get other pools accepting our blocks faster without reducing the amount of transactions, I'm all ears.

Well I guess this is another pool that people should avoid.

I guess most miners will instead avoid pools with many orphans. But this is why I want to hear opinions. If you mine on this pool and you think processing SatoshiDice transactions faster is worth losing some of your mining income, please speak up.

Bitcoin was never a freebie rather a pay for use system.  Pools must operate profitably.  If not, there is a more serious flaw in Bitcoin that should be addressed.

If the tx fees are insignificant, many other pools with lesser tx's and faster propagation then an equilibrium should be found by BitMinter following suit.


Re: Kano.  While finding this equilibrium is not ideal - it is necessary if pool coffers are running dry.

[willphase]

one option would be to dynamically scale the donations for instant payout depending on the number of orphaned blocks - the numbers could be made public and you could also make it so people can set a 'max' amount - and if it exceeds the max then they revert to 0% donations and having to wait for 120 blocks.  It would probably be worth adding an additional donate option that is independent of this for people to make a completely voluntary donation of bitcoins.

Then it puts the decision in the miners' hands, and hopefully means Doc doesn't keep losing bitcoins to keep the service going.

Will

[LazyOtto]

And yes, we have had too many orphans lately.

I think it's time to start limiting the number of transactions we include in a block.

Can you absolutely rule out the possibility that something changed in BitMinter's pool processing about two weeks ago?

About that time is when the number of orphans changed from the typical very low, less than 1.5%, to the recent rate of nearly one per day.

Just for a comparison, I looked at Ozcoin. Their most recent orphan was on 2012/08/24. They also accept all transactions into blocks and include transaction fees in payouts.

-- edit --
And, yes, Ozcoin is dealing with about half the hashrate as BitMinter.

[kano]

There are a number of issues here.

#1 as LazyOtto has stated above but to expand on it: what changed with bitcoin that suddenly means you are getting more orphans?
You are blaming bitcoin (saying you must reduce your txn count your pool processes)

Show a record of the number of transactions per block you have been confirming and the number of orphans you have been getting and show a statistical proof that your pool isn't getting more than the other pools.

You see, if your pool IS getting more orphans than the other pools and the other pools are processing a similar or greater number of transactions as you are - then the issue is squarely with your pool.

So go look at EMC or OzCoin or Slush or ... show proof that the problem for everyone with similar sized blocks and not you - then I'll shut up.
I already asked organofcorti to do this for all pools so we could have graphs showing the pools that shouldn't be mined at but he thought it was too difficult to identify blocks for all pools.
Pity, it's dead simple for about 50% of the blocks.

For your pool it's dead easy also.

#2 so when I get these 60/72 whatever GH/s ASIC devices so I can implement mining on them in cgminer, your argument says that if I mine solo I should only mine 0 txn blocks.

I would only be one person, me, so the number of blocks I would find would be small (e.g. at the moment 100GH/s is about one block every 40hours)
I wouldn't want to risk losing a block when I'd be such a small hash rate? RIght? Wrong.

Bitcoin is about confirming transactions.
If you don't think that is the case then indeed you've never read Satoshi's paper or understood what you are doing.

Personally, I even mine solo on a pair of 6950 GPU cards (coz I decided for their final month I'd bet on being lucky and finding a block rather than the rather small payout they'd get pool mining) and no they aren't mining 0 txn blocks.
They are mining whatever bitcoind throws at them by default.

#3 money - you say the pool is losing it. Why? Because you are paying out orphans to attract miners? If that's the case then you are your own problem.
If not, then the other problem could be PPS.
Pools that run PPS put a high margin on them for this exact reason. If you don't charge enough on PPS you risk happening exactly what you are describing.
Where is this 'lost' money going?

... and don't forget that in less than a week each block is gonna pay only 25BTC ...

[DrHaribo]

Can you absolutely rule out the possibility that something changed in BitMinter's pool processing about two weeks ago?

Change from v1 to v2 blocks and other little things. But there's no change to how a block solution is handled and pushed out on the network. No delay there.

It may of course be that we were just incredibly unlucky with the orphans lately.

And the stale blocks are not shown by most pool at all, they throw away all stale work.

Just for a comparison, I looked at Ozcoin. Their most recent orphan was on 2012/08/24. They also accept all transactions into blocks and include transaction fees in payouts.

According to blockchain.info OzCoin had stales since 2012/08/24:
1 x 2012-10-18
1 x 2012-10-16
1 x 2012-10-09
2 x 2012-10-07
1 x 2012-09-15

Those don't appear on the OzCoin website. Maybe there's a bug there?

blockchain.info doesn't show the one on 2012/08/24 though. Some orphans don't propagate far enough for blockchain.info to see them. Therefore it would be hard to make orphan stats without accurate stats from each pool itself.

5 orphans in october is not so good. But zero in november is very good. If OzCoin is running with default settings then I suppose it's just good vs bad luck?

[sturle]

Are you sure this works?

Yes. The slower a block propagates through the bitcoin peer-to-peer network the higher the chance it is orphaned. That's because others will be making blocks that compete with yours because they haven't seen your block yet. And the bigger the block the longer bitcoin nodes take before accepting the block as valid and passing it on to other nodes.

That's the theory, yes, but it doesn't check out very well when you analyze the orphaned blocks vs the winning blocks.  The advantage to smaller blocks is very small.  There may be one for very small blocks, e.g 1 transaction blocks.

E.g. for the latest orphan, the Bitminter block was 242.8 KB.  The winning block was 250.8 KB, i.e. larger than our.

I have another suggestion: Start making new work as soon as you get a new valid block header built on top of the one we are working on.  The likelyhood of the block being invalid, is low.  This will give us a head start on the next block in front of the other pools.  We may delay LP until the new block is validated.

[DrHaribo]

I have another suggestion: Start making new work as soon as you get a new valid block header built on top of the one we are working on.  The likelyhood of the block being invalid, is low.  This will give us a head start on the next block in front of the other pools.  We may delay LP until the new block is validated.

I have been thinking about making new BitMinter blocks available through the web service with long polling, to get around blocks having to go through the peer-to-peer network to reach other pools. That could also be a good way to get the necessary data to start mining before bitcoind does its checks, like you suggest. Doesn't have to be long polling, btw.

If most pools would get blocks directly from each other without going through bitcoind and if they start mining after only minimal checks like you suggest, then that might get rid of most orphans. No X number of nodes to propagate through, almost no verification = near instant block propagation as far as mining is concerned.

You are right that pools are unlikely to make invalid blocks. And you can check the previous block hash (from the block header), to ensure you don't accidentally help in a 51% attack.

Like you said, start mining after a quick check like that. Start mining a 1-tx block on top of that new block, maybe with a LP signal. Possibly you could include txes if you can be sure which ones would be valid (would take some effort). Meanwhile you can submit the block to your own bitcoind for full verification. If it checks out, start mining on top of it with full transactions. If it doesn't show as the top block in bitcoind then either it was invalid or another block got there first. Either way, start mining on whatever bitcoind says is the top block on the main chain.

[mdude77]

As requested by Doc (poolop), MPoolMonitor now supports BitMinter.

https://bitcointalk.org/index.php?topic=86502.0.

Regards,

M

[DrHaribo]

As requested by Doc (poolop), MPoolMonitor now supports BitMinter.

That's great news! Thank you for adding support 

[AfricanHunter]

Came over to see if I was imagining the bad luck, guess I wasnt after all

I would be up for nearly anything that keeps the pool going. Love Bitminter