Has anyone found a way to create a vanity onion address for use with a bitcoin node?

I've found plenty of generic onion vanity generators, but somehow the files created aren't useable by bitcoind. It's probably a minor tweak needed, but I've not managed to work out how to do it yet. Has anyone?

Hi all, I just wanted to share a recent experience I had with localbitcoins, which has left me substantially out of pocket, and most likely the other user in the transaction substantially better off.

I placed an advert selling bitcoins for cash deposits. Making it clear in the first sentence that I accept only cash deposits.

A person opens a trade and sends me the money via bank transfer (i.e. not cash), which is not as safe as it can be reversed.

Localbitcoins escrow service decides after almost 3 weeks of debate to release the bitcoins to the buyer even though the buyer, despite repeated requests from LB and myself, never provided proof that they were the account holder of the bank account sending the funds.

This doesn't seem right to me - that I was forced to sell bitcoins by a riskier method that I made clear from the beginning I wasn't willing to risk.

I'd be interested to hear comments from other people on here about this.

As far as I see it, Market Makers help to stabilize the exchange rate, Market Takers destabilize it. Surely, it's in mtgox's interests for the price to stabilize so that more people can adopt bitcoin and increase their customers.

The solution to this seems to me to be quite simple, and is something Intersango already implemented a while back. Simpy: reward market makers, and penalise market takers. IMHO, all exchanges would be wise to do this.

I'd actually like to see no more than 0% commission for market makers - perhaps even a negative commission considering the importance of their role. Funding from this would naturally come from the transactions made by the market takers.

I don't claim to be an expert on economics, so apologies if I'm completely missing something here. (If I am, Intersango was too, though!).

If enough people are interested in seeing this happen, and comment, perhaps mtgox will address this.

I think BTCGuild's decision to revert to 0.7 for mining was the wrong decision. Let's explore why I've come to this conclusion.

Firstly, let's ask - who do we want to be in control of bitcoin? By in control I mean, to define and maintain the integrity of bitcoin.

I personally feel that bitcoin should be defined as closely as possible to the white paper that Satoshi wrote.

I also feel that the people better skilled to make these decisions are the miners and mining pools rather than the average user of bitcoin (who probably just downloaded the first bitcoin client they found after a Google search).

The decision (to switch mining back to 0.7 version) was heavily influenced by the userbase. Most of the userbase are probably unaware currently that they are effectively voting on the definition by their choice of bitcoin client.

I do not feel they should be voting at all. Bitcoin's integrity is the responsibility of the miners, not the users. The miners should not be influenced to the extent they were by the users nor the developers of any client, in my opinion. Granted the miners depend heavily on the skill (and they are skilled) of the developers and need to work in close co-operation, and to ensure that the the mining is done using as similar code as they can manage and that it performs as closely to the white paper. The miner's have a responsibility to check that the code they are using keeps to the integrity of the white paper also.

The 0.8 version of the mining software adhered more closely to Satoshi's white paper than 0.7 did. They should have stuck with 0.8 for this reason alone.

Secondly, the miners have a responsibility to maintain the integrity of bitcoin. This means doing whatever possible to ensure that transactions are not reversible. Their decision to revert to 0.7 broke this fundamental rule. They should never do this again if bitcoin is to retain any credibility.

It is understandable that they have been so far following relatively blindly the advice of the core development team, but I think it is time for this to stop, given the recent situation. They need to think far more critically and recognize their responsibilities. There are going to be politics involved in the evolution of bitcoin. There is going to be influence and pressure from governments on all parties involved - the developers and the miners in particular. Anyone developing or mining bitcoin who is not anonymous is touchable.  (Read http://www.dgcmagazine.com/the-old-radical-how-bitcoin-is-being-destroyed/ to better understand why I mention this).

Staying mining on 0.8 would have been the safer option because 0.7 clients already were alerting the users to their being a longer chain. Users of 0,8 weren't being alerted until at least 11 (21 by some reports) confirmations had passed on their fork so during those confirmations all transactions were not trustworthy. Trust in transactions is the primary importance in bitcoin. Although some failure for alerting the users to this is the fact that most client don't alert the user to the event that another chain is catching up - they only alert when another chain is longer, and even then, only when by at least 6 blocks.

There will probably be events in the future where the miners and the developers disagree, and the miners disagree with other miners about the future of bitcoin, but I would like to think that the decisions will be based on what bitcoin was meant to be. This will often be subjective, but for me personally, the true bitcoin will always be the one mentioned in the Satoshi White Paper, and that paper defines the maximum block size as 1Mb. The currently running bitcoin is therefore not really bitcoin, and won't be until a hardfork is done to set this to the correct number. 0.8 did that - the miners were running with it and had a majority, until March 12.

I'll admit I don't know all the details behind the decision to switch back to 0.7 and to something less-bitcoin like. I'm aware that mtgox and blockchain.info were still on the 0.7 fork but they could have fixed this and arguably this was their fault for not keeping up to date. Although on the other hand, the miners may have switched to 0.8 without sufficient testing and notice. Mtgox's software would surely have noticed the longer chain and automatically switched to a safe mode where no transactions were accepted until resolved, so they'd not have lost any money, but it would have been a headache for the site maintainer to install the patch needed to switch to the 0.8 fork, admittedly. Still, I think this is what should have been done instead.

So, I've yet to hear a strong argument still for the decision. I'll keep looking though, and thanks in advance to anyone who can enlighten me.

I'm noticing patches going into bitcoind/bitcoin-qt that encourage transactions fees to raise. e.g. the free tx rate-limiter feature.

There are features that could be implemented which would encourage transaction fees to lower. e.g. a rate-limiter for blocks that have excluded free txs.

In order to leave the power to influence the market and future of bitcoin with the node operators, rather than the developers, I propose that features that both raise and lower tx fees should be included, with such features disabled by default, but easily enableable using the command line or bitcoin.conf.

Would anyone else be interested in seeing a "greedy miner" block relay limiting feature added, (in a similar same way to the free tx relay limiter), to even up the playing field?