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

[Defkin]

not me I haven't made my first coin here yet.....

I started on this pool by mining that very long coin the other day and accidentally broke the server....shhh don't tell anyone.

[jake262144]

I pledge a coin or two if we area able to get to 200GHash/s with the same insanely low stale rate.
All in all, I'd rather mine on a small-to-medium sized pool than a 500GHash/s behemoth, though. For network decentralization's sake.

[ZodiacDragon84]

lulz

[jake262144]

*continuing the hillbilly act*
Damn, them blocks have gone into hiding or just vacated our hunting spot.
:spits, scratches balls:
I'm winded. Could grab a cold beer too. Tiring this block hunting, that's what it is.

[ZodiacDragon84]

still better mining here than at some of dem der stuffier high class type class type pools i rekon jake. we just gunn has to tighten our belts and clamp down on dem pickaxes so D&T can kechem!

(Most hillbilly I could muster in one night)

[jake262144]

Wow, you're doing a much better job at it than I have been

[ZodiacDragon84]

Hey doc. Do we support P2SH?

http://blockchain.info/P2SH

And @ Jake, I'm a garbage man in Nebraska, you have no idea the people I meet buddy.

[DrHaribo]

I will get a better server and set up a donation system. I think we are large enough now that donations can at least pay part of the server costs.

Hey doc. Do we support P2SH?

http://blockchain.info/P2SH

To be honest I haven't had time to read up on P2SH yet. But I will do so ASAP.

Also, I don't like using other people's hash power to do something they don't like. So if you have an opinion on P2SH please let's hear it.

[sturle]

Hey doc. Do we support P2SH?

http://blockchain.info/P2SH

To be honest I haven't had time to read up on P2SH yet. But I will do so ASAP.

I'll move my 2 Ghash/s from solo mining to BitMinter if you start supporting BIP 16!

[ZodiacDragon84]

After somber study, I believe I would go with  BIP 16 (for P2SH) If I was mining solo. As I have no plans of leaving this pool, It would rest on the pools shoulders, and ultimately what Doc would decide. Jr seems to gung-ho to get his BIP 17 out there, and Gavin just wants to make it work with BIP 16. They both believe their way is best. I would suggest maybe archiving a backup copy of the current bitcoin software and running that, as securely as possible to maintain wallet and chain integrity until more research and testing can be done on testnet with both implementations

[ZodiacDragon84]

Lotsa Namecoin blocks today...wierd

[P4man]

Also, I don't like using other people's hash power to do something they don't like. So if you have an opinion on P2SH please let's hear it.

Good to hear the pool operator wants to know what the miners think. I suspect thats more than what Luke did before casting his (miners') vote(s).

That said, I have no real opinion on the subject. I got no clue what its about. Maybe if someone could give me an executive summary I might form an opinion, but absent that, my second instinct is to trust Gavin above Luke.

[DrHaribo]

I've been reading up on this now. Here are some threads I looked through:

BIP 16: https://en.bitcoin.it/wiki/BIP_0016
BIP 17: https://en.bitcoin.it/wiki/BIP_0017

Gavin Andresen (Lead Core Bitcoin Developer) trying to explain the matter in layman's terms: https://bitcointalk.org/index.php?topic=61125.0

Luke Jr (Eligius Pool Operator) explaining his side: https://bitcointalk.org/index.php?topic=58579.0

Discussion about BIP 17, Luke Jr's suggestion: https://bitcointalk.org/index.php?topic=60433.0

I think they were right to drop OP_EVAL (BIP 12) for being too risky (potential security problems). I also think bitcoin needs the increased security, escrow and other fancy stuff that comes with multisig transactions.

So, BIP 16, BIP 17, or postpone? Not sure yet.

It's very difficult to understand the different results we get from choosing BIP 16 or BIP 17. It's very technical. My pool software creates its own generate transaction, so I have at least looked at bitcoin transactions a little bit before. It seems totally confusing to me. I can only imagine how it looks to the average miner. I think only people who have been working on core bitcoin code can actually understand the issues well.

About voting with hash power, I think that can be the right way to do such changes, but pools complicate that a bit. It's a bit late now, but if there will be more such voting in the future, then perhaps it would be an idea to implement some sort of voting inside BitMinter. Say you vote on the website and the pool creates votes in the blocks we make to match how much hash power in our pool voted for the one or other option. The choices in this case would be "BIP16", "BIP17" or "blank". This would allow each miner to use their hash power the way they want.

[DrHaribo]

The choices in this case would be "BIP16", "BIP17" or "blank".

Actually there should also be "no vote". "Blank" meaning "I want the pool to create blank votes", and "no vote" meaning "I don't care, let the other miners decide".

[jake262144]

There ye go P4:
BIP12 (op_eval), BIP16 (op_p2sh) and  BIP17 (op_chv) are different implementations serving the same purpose of introducing multi-signature transactions at protocol level. To the end-user there's no real difference between them. BIP12 is now dead due to a fatal flaw having been discovered so the choice is between BIP16 and BIP17.
According to Maged, even most of the devs don't care which one eventually gets implemented.

With BIP16, transactions initiated by you look like normal transactions to the network while transactions sent to you require additional work, thus will be a tad slower until everyone upgrades their bitcoind to support them and more expensive (slightly higher fees). BIP17 does things the other way around.

Old clients won't confirm BIP16 transactions but will confirm BIP17 transactions and treat them as valid even though they don't actually parse them correctly.

BIP12 was being worked on since October. In December, a flaw was found making the transaction language (Script) turing-complete thus making it impossible to be statically analyzed. Some of the BIP12 code was recycled into BIP16. Lately, Luke fervently advocated his implementaion, now specified as BIP17 as being more elegant. Not "far superior", mind you, just "more elegant".

Whichever option eventually wins, I have full confidence in the devs having done the due diligence and scrutinized the code for flaws as best they can.

I suggest you don't believe the recently popular n00btalk deprecating the BIPs as rushed, unverified code being shoved down the miners' throats.

DISCLAIMER: This post has been written according to my best knowledge. I can't guarantee, however, that it is absolutely correct.

[Defkin]

One other item was that the trojan makers have started to make some effort towards BTC. While no one is suggesting that the BTC code itself is under threat everyone who has a wallet on an unsecured system is and it is only going to get worse. I know I cannot secure a windows PC, worse those with less computer skills are going to think they are secure because norton told them so. I wouldn't even know where to start with a mobile OS.

So 3 options really. Go with one of the two upgrade options that of us voting 99% of us can not technically evaluate anyhow. And correct me if I am wrong the Devs already voted on the BIP16 although it was not unanimous so it spilled over to us?

Or delay implementation and run the risk of the public losing confidence in BTC if the hackers manage to steal enough coin and this is going to become more likely as the more of less computer savvy join BTC.

This is my vote and reasoning behind it.

1. I am not qualified to make an informed vote but the mechanics mean I must cast a vote anyhow.
2. Having the public lose confidence in a currency is far from good no mater how it happens - delay is out.
3. It appears the jack jr lost the dev team vote so sent it to the miners turning the decision into a raffle rather than and informed choice.

I guess that means I vote for BIP 16........

 
 

[Turbor]

I support Gavin. He's the leader we should follow !

[teflone]

I support Gavin. He's the leader we should follow !

This...

[jake262144]

So 3 options really. Go with one of the two upgrade options that of us voting 99% of us can not technically evaluate anyhow. And correct me if I am wrong the Devs already voted on the BIP16 although it was not unanimous so it spilled over to us?
I guess that means I vote for BIP 16........

Let straight this misconception out:
There is no "vote" in the sense of a democratic vote with the miners telling the devs which way to go. It's the same definition of vote as anything being done by the block chain: any change with >50% support gets accepted and merged into the main block chain.
Everyone is expected to go with BIP16 since that code has been compiled into the most recent bitcoind.
The "vote" means just that the devs are waiting to check whether or not over 50% of the total hash power has been upgraded with BIP16 support and therefore BIP16 is alive or do they need to wait longer.

Tycho will decide what happens anyway, thanks to the brain-dead sheep crowding at his pool. That's the price ultimately paid for the centralization that pools bring.
If anyone wants to sanitize the situation and they happen to have a friend mining for a giant pool, please whack them across the head until they change to a small pool, perhaps even this one.
P2pool would be even better as it allows (and requires) each miner to run his own bitcoind.

Luke raised one hell of a row and seriously undermined the trust in the dev team with his irresponsible actions:
2 questions about this P2SH thing
How to vote for/against p2sh?
Miners don't even know they can vote on P2SH

[sturle]

About voting with hash power, I think that can be the right way to do such changes, but pools complicate that a bit. It's a bit late now, but if there will be more such voting in the future, then perhaps it would be an idea to implement some sort of voting inside BitMinter. Say you vote on the website and the pool creates votes in the blocks we make to match how much hash power in our pool voted for the one or other option. The choices in this case would be "BIP16", "BIP17" or "blank". This would allow each miner to use their hash power the way they want.

I think calling this a "vote" is misleading.  To cite BIP 16:

To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.

To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create.

Never ever put "/P2SH/" in the coinbase to state an opinion unless you actually have upgraded bitcoind to validate P2SH transactions as specified in the BIP, or there will be a miscount with consequences as described.  For BIP 17 this is even more important, because BIP 17 type transactions can be stolen by anyone until more than 50% of the hashing power correctly validates the transactions.  If e.g. Deepbit choose to "vote" for BIP 17 without actually validating the transactions, any BIP 17 type transactions can be stolen before they reach the block chain.  (This has been demonstrated on the testnet, where people have fun stealing luke-jr's test transactions.)

IMHO BIP 16 is the way to go.  BIP 17 has support from one developer while the rest support BIP 16.  BIP 17 will probably never gain the support it needs, and only delay the process of getting multisignature transactions into Bitcoin.  Multisignature transactions are important for security reasons.  Especially for larger companies where large transactions needs to be signed by at least two persons.