[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[PhantomPhreak]

Great news! Pay-to-PubKeyHash Functionality Added
https://www.counterparty.co/pay-to-pubkeyhash-functionality-added/

Great news! Filter added to block this crap in less than 5 minutes, and 1 line of code.

Great instead of developers responsibly engaged towards finding a solution - you're promoting cat and mouse.

You realize you're also saying fuck it to net-neutrality? And trying to take into private hands what kind of transactions people should and shouldn't make on the Blockchain.

What's next sanctions of certain individuals you don't like? Sanctions for transactions broadcast from Nodes in countries whose governments foreign policy you don't approve of?

He's talking about a patch to Eligius, the same mining pool that attacked CoiledCoin, not to Bitcoin Core itself. (In any case, it's definitely not 1 LOC .)

[1715112614]

1715112614

[1715112614]

1715112614

[1715112614]

1715112614

[1715112614]

1715112614

[BitcoinTangibleTrust]

Product and Service Updates March 28, 2014

Purchasing 1/2 Ounze of Gold with BitcoinTangibleTrust with Counterparty community member, led_cd:
Led_cd has confirmed his desired gold he wished to purchase: 1/2 Ounce of Gold American Eagle here: https://agoracommodities.com/product/12-oz-gold-american-eagle/
Listed Price: 1.4090 BTC
Our Price: 1.4 BTC

Agora has setup a BTC Address for BTT customer payments. Once led_cd has verified and made payment, he will receive his new Digital Gold Coin on Counterparty.

Agora has special instructions to route led_cd's physical gold directly into custody and deliver proof of purchase to BitcoinTangibleTrust. DiamondState Depository is ready to receive the gold and confirm custody.

led_cd has a new Asset on Counterparty that will be sent to his address:
You can see the asset detail here: http://blockscan.com/assetinfo.aspx?q=GLDAGOAAAAAAA

• 1 Unit for 1 Coin
• Non-divisible
• Callabe True

NOTE: We couldn't issue 0.5 denomination of the coin AND make it non-divisible so we went with 1. However, I wonder whether we should normalize our issuances to the same measure for precious metals, by weight, or whether we should stick to units purchased, which is our current approach. I'd welcome any community thoughts on how we might address this issue.

BitcoinTangibleTrust makes the news
We were surprised to learn that we were in the news today.
http://www.bloomberg.com/news/2014-03-28/bitcoin-2-0-shows-technology-evolving-beyond-use-as-money.html
Special thanks Anotheranonlol for catching the article. We've been a little buried here structuring our purchase and custody process.

Thank you Counterparty Devs and the Counterparty Community,
Bitcoin Tangible Trust Team
Cross Posted to Counterparty Forums: https://forums.counterparty.co/index.php/topic,203.0.html

[Peter Todd]

Great news! Pay-to-PubKeyHash Functionality Added
https://www.counterparty.co/pay-to-pubkeyhash-functionality-added/

Great news! Filter added to block this crap in less than 5 minutes, and 1 line of code.

Great instead of developers responsibly engaged towards finding a solution - you're promoting cat and mouse.

You realize you're also saying fuck it to net-neutrality? And trying to take into private hands what kind of transactions people should and shouldn't make on the Blockchain.

Heh, well, I had an interesting discussion about this stuff with one of the core devs, and there's actually kind of a nice advantage to Counterparty and similar moving to a system where careful steganography and similar measures are being taken to keep the system unblocked: if someone does do the "fill the chain with child porn" legal attack on Bitcoin the community can argue that they certainly didn't support it in any way. It also goes back to things like trying to ban or discourage address reuse: if your protocol can be censored, changing it to be harder to censor tends to be actually good for the ecosystem as a whole.

An interesting thing to do might be to change Bitcoin to validate that 33 byte PUSHDATA's are valid pubkeys in the IsStandard() rules. The easiest way to co-erce arbitrary data to look like a pubkey is via something like Mastercoin's encoding scheme, and that has the nice property of being easiest to implement with steganography that hides the data and gives everyone in the ecosystem good plausible deniability.

Anyway, I'm gonna write more about this in the coming weeks as a semi-formal paper, as well as talk about when you can get away with the lesser security of hash-linked side-chain schemes. Some best practices libraries implementing both would be useful for everyone in this ecosystem.


Also, congrats on BitcoinTangibleTrust for doing something with this tech.

[maaku]

Let me start with the good. There is a reason we (developer hat on) are generally up in arms about "abusive" data-on-blockchain proposals: it is because we see the potential of this tech! We know that issued assets and smart property contracts could grow to eclipse bitcoin traffic entirely. Some of us are even convinced this could happen quickly.

Why is this bad? Because despite bitcoin being in the process of going mainstream and getting all sorts of attention from everybody, everywhere, the number of full nodes is declining. As mentioned by others this is in large part due to the rise of SatoshiDice. Now I don't object to gambling services on bitcoin, nor do I know any other developers who do. What you do with your money is your business. The issue is that SD gave a trivial amount of satoshi's back to indicate a lost bet, which effectively was an uneconomical-to-spend data message similar in size to a class A Mastercoin transaction which Counterparty is sadly now adopting. That drain on the resources of the network from this extra data processing is causing people to turn off their full nodes and switch to SPV clients.

I don't want to cause undue fear and panic as with time and effort and education and innovation this situation is correctable. But if left to run its course this trend would mean the death of bitcoin. And parasitic[1] systems like mastercoin and counterparty make the situation worse. It's like adding bad weather, stormy seas, and sharks while we're treading water trying to find a solution.

Furthermore, it's simply not necessary. You can accomplish all of Counterparty's goals via off-chain solutions the same or similar security guarantees. There has been a lot of mis-information out there about this! That's why I pointed to the Freimarkets paper I co-authored with jtimon. It's not because I want to claim credit for the idea (it is as old as bitcoin), but to show there are worked out counter-proposals that could be implemented today.

We tried to make very clear from the beginning that OP_RETURN was never meant to be used. Enabling small data commitments is like cooperating with a mugger: losing your pride is preferable to losing your life. Likewise, if you insist on abusing the block chain than please at least don't do something so recklessly stupid and hurtful as a class A mastercoin transaction. Put a hash of the data in the block chain instead. OP_RETURN was only ever meant to contain a hash - 32 bytes.

But ultimately what you *should* be doing is running your own network and have a low-volume mechanism for transferring coins between the two. That helps bitcoin scale and gives you added capabilities like SPV support, pre-signed offers, and scripting extensions.

Our objection from the start has not been "we don't want to see this" but rather "we don't want to see it done in this particular way" because it externalizes costs and makes the situation worse than it already is.

[1] "Parasitic" has a well defined technical meaning and is not meant as a derogatory term here.

@Matt: Hi, it was good to meet you at CoinSummit!

[porqupine]

Let me start with the good. There is a reason we (developer hat on) are generally up in arms about "abusive" data-on-blockchain proposals: it is because we see the potential of this tech! We know that issued assets and smart property contracts could grow to eclipse bitcoin traffic entirely. Some of us are even convinced this could happen quickly.

Why is this bad? Because despite bitcoin being in the process of going mainstream and getting all sorts of attention from everybody, everywhere, the number of full nodes is declining. As mentioned by others this is in large part due to the rise of SatoshiDice. Now I don't object to gambling services on bitcoin, nor do I know any other developers who do. What you do with your money is your business. The issue is that SD gave a trivial amount of satoshi's back to indicate a lost bet, which effectively was an uneconomical-to-spend data message similar in size to a class A Mastercoin transaction which Counterparty is sadly now adopting. That drain on the resources of the network from this extra data processing is causing people to turn off their full nodes and switch to SPV clients.

I don't want to cause undue fear and panic as with time and effort and education and innovation this situation is correctable. But if left to run its course this trend would mean the death of bitcoin. And parasitic[1] systems like mastercoin and counterparty make the situation worse. It's like adding bad weather, stormy seas, and sharks while we're treading water trying to find a solution.

Furthermore, it's simply not necessary. You can accomplish all of Counterparty's goals via off-chain solutions the same or similar security guarantees. There has been a lot of mis-information out there about this! That's why I pointed to the Freimarkets paper I co-authored with jtimon. It's not because I want to claim credit for the idea (it is as old as bitcoin), but to show there are worked out counter-proposals that could be implemented today.

We tried to make very clear from the beginning that OP_RETURN was never meant to be used. Enabling small data commitments is like cooperating with a mugger: losing your pride is preferable to losing your life. Likewise, if you insist on abusing the block chain than please at least don't do something so recklessly stupid and hurtful as a class A mastercoin transaction. Put a hash of the data in the block chain instead. OP_RETURN was only ever meant to contain a hash - 32 bytes.

But ultimately what you *should* be doing is running your own network and have a low-volume mechanism for transferring coins between the two. That helps bitcoin scale and gives you added capabilities like SPV support, pre-signed offers, and scripting extensions.

Our objection from the start has not been "we don't want to see this" but rather "we don't want to see it done in this particular way" because it externalizes costs and makes the situation worse than it already is.

[1] "Parasitic" has a well defined technical meaning and is not meant as a derogatory term here.

@suppow: Hi, it was good to meet you at CoinSummit!

The threats/blacklists/net neutrality discussions aside.  

I'm not really sure what viewpoint really stands among core Bitcoin developers as to scalability problems. Peter thinks there is a problem, Gavin thinks it's not a problem - what kind of contribution to data load on the blockchain would constitute 'abuse'? - is there any real danger? At which scale?

What's wrong with charging a fee for each 40 bytes of OP_Return as has been proposed ?- everyone doing transactions that require additional data could switch to that implementation and contribute to network maintenance with fees. If issued assets and smart property indeed blow up to take up a significant fraction of the Network traffic - and a side-chain implementation happens to run shorter block times with 66% less fees - of course people will switch! I just don't understand what advantage there is to be had from a pseudo-factual speculative debate about the effect of this or that as it can or maybe won't happen, when free market forces can be allowed to do the work.

[maaku]

Every release since 0.7 has included performance improvements as a key feature, starting with the very important merging of Pieter Wuille's ultraprune branch. Remember that this time last year we were ridiculing Peter Todd's "keep bitcoin free" campaign to enshrine the 1MB block limit. Even Peter Todd has switched positions on that one, so I think I can generalize to say that we all see the need for bitcoin to scale to higher traffic levels, and identify many outstanding problems to be solved between here and there. But beyond that I don't feel comfortable commenting on the specific positions of individual developers other than myself.

What's wrong with charging a fee for data use is that it does absolutely nothing to solve the problem. Fees go to miners, not full nodes. You don't collect a single Satoshi for running a full node. And until that incentive problem is fixed (it's not clear it can be), scaling bitcoin up means centralization and degradation of the peer-to-peer network, to the point of becoming compromised or unusable.

[prophetx]

Let me start with the good. There is a reason we (developer hat on) are generally up in arms about "abusive" data-on-blockchain proposals: it is because we see the potential of this tech! We know that issued assets and smart property contracts could grow to eclipse bitcoin traffic entirely. Some of us are even convinced this could happen quickly.

Why is this bad? Because despite bitcoin being in the process of going mainstream and getting all sorts of attention from everybody, everywhere, the number of full nodes is declining. As mentioned by others this is in large part due to the rise of SatoshiDice. Now I don't object to gambling services on bitcoin, nor do I know any other developers who do. What you do with your money is your business. The issue is that SD gave a trivial amount of satoshi's back to indicate a lost bet, which effectively was an uneconomical-to-spend data message similar in size to a class A Mastercoin transaction which Counterparty is sadly now adopting. That drain on the resources of the network from this extra data processing is causing people to turn off their full nodes and switch to SPV clients.

I don't want to cause undue fear and panic as with time and effort and education and innovation this situation is correctable. But if left to run its course this trend would mean the death of bitcoin. And parasitic[1] systems like mastercoin and counterparty make the situation worse. It's like adding bad weather, stormy seas, and sharks while we're treading water trying to find a solution.

Furthermore, it's simply not necessary. You can accomplish all of Counterparty's goals via off-chain solutions the same or similar security guarantees. There has been a lot of mis-information out there about this! That's why I pointed to the Freimarkets paper I co-authored with jtimon. It's not because I want to claim credit for the idea (it is as old as bitcoin), but to show there are worked out counter-proposals that could be implemented today.

We tried to make very clear from the beginning that OP_RETURN was never meant to be used. Enabling small data commitments is like cooperating with a mugger: losing your pride is preferable to losing your life. Likewise, if you insist on abusing the block chain than please at least don't do something so recklessly stupid and hurtful as a class A mastercoin transaction. Put a hash of the data in the block chain instead. OP_RETURN was only ever meant to contain a hash - 32 bytes.

But ultimately what you *should* be doing is running your own network and have a low-volume mechanism for transferring coins between the two. That helps bitcoin scale and gives you added capabilities like SPV support, pre-signed offers, and scripting extensions.

Our objection from the start has not been "we don't want to see this" but rather "we don't want to see it done in this particular way" because it externalizes costs and makes the situation worse than it already is.

[1] "Parasitic" has a well defined technical meaning and is not meant as a derogatory term here.

@Matt: Hi, it was good to meet you at CoinSummit!

how much does it actually cost to run some full nodes?

I'm thinking Mastercoin Foundation and Counterparty could fund several of these with MinerCoin  

I'm serious...

Then maybe we can start comping people extra for running the op_return 80 patch that LukeJr suggested.

[porqupine]

Every release since 0.7 has included performance improvements as a key feature, starting with the very important merging of Pieter Wuille's ultraprune branch. Remember that this time last year we were ridiculing Peter Todd's "keep bitcoin free" campaign to enshrine the 1MB block limit. Even Peter Todd has switched positions on that one, so I think I can generalize to say that we all see the need for bitcoin to scale to higher traffic levels, and identify many outstanding problems to be solved between here and there. But beyond that I don't feel comfortable commenting on the specific positions of individual developers other than myself.

What's wrong with charging a fee for data use is that it does absolutely nothing to solve the problem. Fees go to miners, not full nodes. You don't collect a single Satoshi for running a full node. And until that incentive problem is fixed (it's not clear it can be), scaling bitcoin up means centralization and degradation of the peer-to-peer network, to the point of becoming compromised or unusable.

Please correct me if I'm misinterpreting what you are saying (and ignore the later points of this post if so) - but I understand the current situation as follows:

a) Currently a very significant problem is lack of incentive for Full Node participation combined with simultaneous Network Scaling
b) Counterparty transactions currently take up 5mb of an 18gb blockchain but if use of counterparty and similar protocols increases dramatically the above problem will be exacerbated before it is possible devise an adequate solution.

If I may, I think just as you don't see it as immediately feasible to address Node incentive and Network scaling, phantomphreak probably doesn't see it as immediately feasible to go from a working secure protocol to a not-yet-coded potentially vulnerable side-chain, for the sake of 40 bytes. Still I doubt there are any serious counterparty or bitcoin users that see a positive future where certain functionality exists at the cost of the health of the entire network as a whole.
As a lot of good developments may come from foresight in implementation, and much can also come from necessity - counterparty as a protocol requires more blocks to be functional (i.e.  distributed exchange order matching) than simple sends, if the network even begins to be over-burdened it's effect will be felt there first, and I don't think anyone will continue to use something so unoptimized without moving towards a solution. In the short-term I think Luke Jr's proposal is actually a lot more sensible than at first-glance. Yes, in a way it is undermining net-neutrality and may take a large share of criticism for that - but it also provides a method at least for counterparty and mastercoin to switch to a cleaner implementation (the benefit of which is apparent here and now) without making a seemingly irreversible commit to the protocol at the core.
Again if I'm not misunderstanding: the core developers it seems to me are very naturally worried that to implement a large or limitless OP_Return is to encourage other projects to put similar functionality into the blockchain before node incentive and scaling problems can be addressed.

[dexX7]

how much does it actually cost to run some full nodes?

I'm thinking Mastercoin Foundation and Counterparty could fund several of these with MinerCoin  

I'm serious...

Then maybe we can start comping people extra for running the op_return 80 patch that LukeJr suggested.

Instead of pumping resources into getting 40 additional bytes, why don't we actually start to build an overnet instead? I'm extremely thrilled by the idea and I somehow hope this all gets pushed even further in that direction.

[Bountyful]

how much does it actually cost to run some full nodes?

I'm thinking Mastercoin Foundation and Counterparty could fund several of these with MinerCoin  

I'm serious...

Then maybe we can start comping people extra for running the op_return 80 patch that LukeJr suggested.

Instead of pumping resources into getting 40 additional bytes, why don't we actually start to build an overnet instead? I'm extremely thrilled by the idea and I somehow hope this all gets pushed even further in that direction.

Intriguing dexX7! Go on... What are you thinking?

[prophetx]

how much does it actually cost to run some full nodes?

I'm thinking Mastercoin Foundation and Counterparty could fund several of these with MinerCoin  

I'm serious...

Then maybe we can start comping people extra for running the op_return 80 patch that LukeJr suggested.

Instead of pumping resources into getting 40 additional bytes, why don't we actually start to build an overnet instead? I'm extremely thrilled by the idea and I somehow hope this all gets pushed even further in that direction.

Intriguing dexX7! Go on... What are you thinking?

details please.  have no idea what you are talking about

[dexX7]

OP_RETURN can be used to store references to external resources, say for example very long meta transactions that don't fit into 40 byte, an asset contract or whatever. The storage pointed to could be a website which lists something like <hash_used_in_op_return_tx><very_long_message> (for the sake of an example), a side chain or a P2P structure like a DHT. To my knowledge this was discussed several times, but never tested on a broader scale.

[porqupine]

OP_RETURN can be used to store references to external resources, say for example very long meta transactions that don't fit into 40 byte, an asset contract or whatever. The storage pointed to could be a website which lists something like <hash_used_in_op_return_tx><very_long_message> (for the sake of an example), a side chain or a P2P structure like a DHT. To my knowledge this was discussed several times, but never tested on a broader scale.

That's missing the point, then you're back to the question of how do we securely store data in an accessible, decentralized way, and it's onto side-chains, which come with their own problems and which no one has coded working functionality for - that Counterparty has here and now, and this is for 40 bytes of economy with only pseudo-speculative importance, when as Canton said gambling transactions are taking up 5gb to Counterparty's 5 mb.
I do agree the status of these things may change, but as I wrote, I don't see why speculations about the future should regulate implementation that a freemarket is capable of doing on it's own.

[sparta_cuss]

Let me ask a really basic question, since I can't figure it out by reading all of the posts about the 80-->40 OP_Return change and what this means for data stored on the blockchain.

Q: Why does someone run a node?

I understand why miners mine; they earn fees. Nodes do not. So why does someone do it?

[atweiden]

Here is what Satoshi Nakamoto had to say about Bitcoin scalability:

Long before the network gets anywhere near as large as that, it would be safe
for users to use Simplified Payment Verification (section '8') to check for
double spending, which only requires having the chain of block headers, or
about 12KB per day.  Only people trying to create new coins would need to run
network nodes.  At first, most users would run network nodes, but as the
network grows beyond a certain point, it would be left more and more to
specialists with server farms of specialized hardware.  A server farm would
only need to have one node on the network and the rest of the LAN connects with
that one node.

http://www.mail-archive.com/cryptography@metzdowd.com/msg09964.html

Maaku, Electrum server has implemented your ultimate blockchain compression concept, and I know for a fact that it it is still quite resource intensive. It is in Python, so there's that .

Do you forsee a future where average users can use your C++ blockchain compression implementation to easily access the blockchain via Bitcoin-QT directly? Do you forsee the user experience of Bitcoin-QT competing with Electrum's speed, simplicity and ease of use?

I am heavily biased here given that I've poured my own resources into Electrum (Kivy) for the better part of 2013 and 2014 so far, but I see no future in which average computer users are running Bitcoind or Bitcoin-QT. Maybe I'm mistaken and ultimate blockchain compression will turn things around. However, the user experience and branding of Bitcoin-QT make it seem like a reference client and I do not think it will grow to be much more than that.

You'll have to excuse me but the death of Bitcoin talk has got to be an exaggeration. I'm sorry, I don't mean to offend, but that has to be an exaggerated assertion. If you are in fact right about the scalability concerns, Bitcoin is surely doomed. Malicious third parties will seek to corrupt the network, and they certainly won't seek out amiable terms with Bitcoin developers.

One last thing. I feel you're really underestimating system adminstrators who are dedicated to Bitcoin. Realistically, unless I'm wrong and your C++ ultimate blockchain compression will flip the Bitcoin-QT user experience upside down, system adminstrators or perhaps philanthropic users who are sold done-for-you services are going to be the only class of users capable of running full nodes. This has implications on network topology, for better or worse.

Bitcoin isn't dying, at least I hope not. But Bitcoin-QT may in fact be systematically losing market share to competing wallets. And for good reason. Users aren't used to software that requires a blockchain to function. The existence of a blockchain is 100% weird to the vast majority of computer users, who have grown to expect Facebook and Twitter to work instantly with no questions asked. Most people have no interest in the blockchain. The people who require a local blockchain (and not one that is for example reachable over Tor), can be serviced with done-for-you automated server setup solutions and whatnot. I suspect Satoshi foresaw this very early on.

[Fernandez]

The thing I really got from all these discussions is that Bitcoin is controlled by 12 miners. This is scary and is opposite to the decentralized nature.
I guess when big money comes in greed overrules everything and power grab happens.

[Spekulatius]

how much does it actually cost to run some full nodes?

I'm thinking Mastercoin Foundation and Counterparty could fund several of these with MinerCoin  

I'm serious...

Then maybe we can start comping people extra for running the op_return 80 patch that LukeJr suggested.

Instead of pumping resources into getting 40 additional bytes, why don't we actually start to build an overnet instead? I'm extremely thrilled by the idea and I somehow hope this all gets pushed even further in that direction.

..Skynet

[Luke-Jr]

The thing I really got from all these discussions is that Bitcoin is controlled by 12 miners. This is scary and is opposite to the decentralized nature.
I guess when big money comes in greed overrules everything and power grab happens.

If that's what you got from it, then you're either assuming that a majority of people would do things differently (unlikely), or that Bitcoin being controlled by 12 developers is somehow better (no thanks)...

[dpb]

OP_RETURN can be used to store references to external resources, say for example very long meta transactions that don't fit into 40 byte, an asset contract or whatever. The storage pointed to could be a website which lists something like <hash_used_in_op_return_tx><very_long_message> (for the sake of an example), a side chain or a P2P structure like a DHT. To my knowledge this was discussed several times, but never tested on a broader scale.

That's missing the point, then you're back to the question of how do we securely store data in an accessible, decentralized way, and it's onto side-chains, which come with their own problems and which no one has coded working functionality for - that Counterparty has here and now, and this is for 40 bytes of economy with only pseudo-speculative importance, when as Canton said gambling transactions are taking up 5gb to Counterparty's 5 mb.
I do agree the status of these things may change, but as I wrote, I don't see why speculations about the future should regulate implementation that a freemarket is capable of doing on it's own.

Why does the data need to be stored in a "decentralized way?" Why should it matter if someone tries to store invalid data or remove valid data? If I made a trade and the hash of that deal is saved in the blockchain, all I need to prove I have what I traded for is my own copy of the trade which can be validated with the hash in the blockchain. It's like how in Bitcoin, seven lying nodes can be overruled by one honest node. The work is proven and it doesn't matter how many peers disagree.

[maaku]

@atweiden: Bitcoin Core will never, ever compete resource-wise with Electrum. This is because an electrum client has no clue whatsoever about the state of the bitcoin blockchain and relies 100% on the servers it connects to. The server could be lying to you and you wouldn't know it.

That said, the UTXO hash-tree commitments if/when it makes it into Bitcoin Core will let you run a stripped down client like Electrum by connecting directly to any random peer exposing the UTXO query interface. It also makes it possible to express compact fraud proofs demonstrating that one particular node is lying to you, at least once that fraud has been detected by a full node. These all benefit you greatly, raising you to a security level beyond Electrum or Android Wallet. However it is not and never will be the same as fetching the entire block chain and validating it.

In the shortest summary possible, the goal of the UTXO commitment project is to raise the security of the cheapest clients to an acceptable minimum bar - they can work by peering directly to nodes on the bitcoin p2p network, and can understand an exchange fraud proofs, but has little more drain on resources (for them) than Electrum does today.

However yes, it does require substantially more work for full nodes, potentially pushing out more full node operators and making the entire situation worse. If ever it doesn't make it into Bitcoin Core, it will be for this reason and that concern. But that's not to say that I haven't thought about the issue. Unlike Thomas's tree used in Electrum, the one I'm advocating on the mailing list and writing an implementation for can be used for stateless mining and validation - requiring only 32 bytes of validator state to be kept by any full node by attaching the necessary proofs to the transactions themselves. This could pave the way to sharded validation and open-source bitcoin full-node appliances, for example. But exactly what the end-game is here is still unclear at this time.

@Fernandez. Yup. Bitcoin hangs by a thread. If you have a miner, point it at p2pool and do your own transaction selection. You'll make more money anyways (p2pool has a lower stale rate than any of the pools).