The first time, yeah. After a few times you'll start wondering who is this Bitcoin fellow who keeps collecting money for you.

To continue the analogy, if that man on the street told you that he's got some bitcoins for you and that it's really easy to claim them, you'd say "ah, ok, you see that man over there? He'll be happy to hear all about this..."

Returning to the subject matter, we can argue about which way is better for proselytizing Bitcoin, but there's no question that conversion to USD is better for actually donating to the charity. And, if this service helps utilizing the power of Bitcoin to donate to charities more efficiently, then in the end this is better for Bitcoin than playing hard-to-get with charities.

Mining rewards mature after 120 blocks, and it seems reasonable if they change during that time. Though how to do this technically might be a challenge.

But you don't need SEPA transfers...

If you need to sell 1K BTC then you need to sell 1K BTC. There's nothing stupid about it. The overall price may be better if you do it in a few smaller increments or a limit order, but it might not be, and you're taking a risk which is what you wanted to avoid. A ~1% slippage isn't that terrible.

The trading strategy needs to take fees into account. Seems like what you should have said is "it really didn't work and it generated some 0.3% loss".

My impression is that if they do come back it will be months from now.

If they repay my deposit now I'll have no problem trusting them in the future.

Bitcoinica was a very important platform and the Bitcoin world took a serious hit now that it is gone.

It's true that day-traders add price stability and depth, which is beneficial to everyone involved in Bitcoin. But that's not the only thing Bitcoinica did.

Let's start with short-selling. People think of it as a speculative bet (against the currency), and it can be that. But it can also be the opposite - it can be used as a hedge to avoid speculating. Suppose a service takes Bitcoin payments and pays with bitcoins, but in between it doesn't want to be exposed to currency risk. They will need some Bitcoin reserve to operate smoothly, and they can lose if those bitcoins decrease in value. With a margin trading platform, they can take a short position that exactly negates the bitcoins they're holding at the time. This way they have bitcoins to use but don't care at all what the price will do.

They don't need to want a neutral position necessarily. Personally my overall BTC position is long, but within reason; and I have use for more bitcoins than my position. So I bought bitcoins on one hand, and took a short position on Bitcoinica on the other; this way I had bitcoins available to be used, but with not as much risk.

Even when short-selling and leveraged buying are used speculatively, it can be as a long-term investments. People who don't believe the current Bitcoin price is justified can signal this with a short position; this helps prevent bubbles as the one we saw in June 2011. People who do believe in the future growth of Bitcoin can take a leveraged long position; this allows more money to enter the Bitcoin economy, which eventually finds its way to the establishment of new Bitcoin businesses.

Put differently, even if Bitcoinica is a "zero-sum game", it's a game where value flows from the wrong people to the right people. If Bitcoin needs to succeed, the platform moves money from the people who don't understand it to the visionary people who can use the money to further build it; if Bitcoin needs to fail, the platform moves money from the crazy people who are obsessed with it to more reasonable people who will use the funds to create actually necessary businesses. So whatever the fate of Bitcoin is, margin trading (and other "speculative" instruments) are a net positive for the world.

I think the rewards can be split between the referenced blocks one way or another.

I agree. The fact that how to solve this problem is a hotly discussed topic suggests that people expect the limit to be relaxed. And the fact that there are proposed solutions suggests that this does not prohibit relaxing the limit.

The Bitcoin software is just that, software. It changes to adapt to the problem it is set out to solve.

I didn't say it's unarguable, I said the argument is off-topic for this thread.

If you look at this thread you'll see many people, including Gavin, not even talking about whether the block size limit should be relaxed, but taking it for granted and figuring out how to do this dynamically. Mike Hearn is known for having analyzed how can Bitcoin be scaled to thousands of tps, and theymos has recently made a comment favorable towards a limit change. Apparently Satoshi was in favor too, but I can't find a source.

I didn't find any comment saying that 1MB should be the limit forever, so it seems that in fact you are of a minority opinion. Anyway, again, whatever we want the tradeoff between scalability and ease of running a node to be, the proper way to achieve it isn't a block size limit, it's a transaction fee structure.

I specified the dates during which I will have limited availability, we're not there yet.

Good point about withdraw limits, but barring unforeseen circumstances, you should be able to withdraw the coins over several days. You don't ever need to move fiat into or out of the exchange, so I don't understand your transfer time point.

They do it for BTC-denominated loans, not for USD-denominated loans.

It's not about being risk-aware and brave. By taking BTC and agreeing to return their current USD equivalent they are lengthening their BTC position, and presumably it is already as long as they want it. If you want them to lengthen their position they will charge for the service, more or less as much as it would cost you to sell on the exchange.

I am not sure you understand how this works. (And I'm not sure I understand how it works either). Some bots will sell in response to your trade, some will buy. Anyway you are greatly overestimating the effect of 1500 coins, to you it seems like a lot but tens of thousands of coins are traded every day. You are not going to destroy Bitcoin's price stability by doing this.

Functionally, preserving the fiat equivalent means selling and then buying. There can be other instruments that are equivalent to this but mechanically work differently, but since those markets are underdeveloped they will end up costing more. Mtgox exists precisely to buy and sell and is the largest volume exchange, so if you're worried about the effect this will have on the market, you are not going to find someone on the forum that will handle this volume at a lower cost. Maybe you'll find someone to do this at a similar cost but without some of mtgox's other problems.

Sure, if maintaining a neutral position isn't worth 3% to you then by all means, keep the bitcoins.

It's really simple. If you want to preserve the USD value of your proceeds you sell them now. Depending on your wire costs, you should consider keeping the USD on the exchange and buying bitcoins when it's time to pay.

Any other option is basically a combination of this with some other instrument. You may want to try your luck gaining some interest making a USD-denominated loan/deposit (whether payment is with bitcoins or something else) but that's not as common here as a BTC-denominated loans.

It's as technically difficult but not as economically/socially difficult. People signed up to Bitcoin knowing the limit is 21M and changing this would destroy the Schelling point. The same cannot be said about the block size limit.

CC and PayPal and stuff process thousands of transactions per second; do you really want to limit Bitcoin to 3 transactions per second so people will have to resort to centralized services like CC and PayPal if they want to pay with their bitcoins? That would be destroying decentralization.

You can have thousands of transactions per second, and keep the hardware requirements low enough that it will be done by thousands of interested parties around the world - if they are properly incentivized.

Anyway, this is all not my opinion, it is my understanding that this is established consensus; arguing it is going to be a long and off-topic discussion.

Also, it is exactly my point that instead of placing arbitrary limits to make it easy to operate a node, you monetize it and let people sending transactions pay for the resources - which will encourage people to operate nodes. If the fee is high enough (and correspondingly, network traffic not excessive), it's possible that even at-home users will buy a dedicated high-end machine to run as a node for added income.

I don't understand. I didn't talk about hiding miners, I talked about difficulty in being connected to every computer in the world. If it's easy to connect to all miners / all clearinghouses then the system isn't decentralized enough.

What are you referring to as "the absolute maximum rate supported by the Bitcoin system"? If it's 1MB per block then obviously this limit will be relaxed in the future. The maximum rate is determined by the resources put in it, so we want to incentivize putting in resources.

It's a low cost per transaction, but with the current architecture, you either operate a full node or you don't. Operating a node that handles all transactions will be expensive, and without incentivization it won't be done.

That's a good point, but maybe validation costs can be reduced with something like MAVEPAY.

I can't speak for the authors but to me it seems this doesn't break the system. You can take your peer's hashrate into consideration when deciding how much of the chain length to consume - if the hashrate is low or none, you'll consume as little as possible in hopes he will propagate it further, if it is high, you'll consume more to maximize your profits if he mines it itself.

I don't think that conceptually, everyone should know everyone in a p2p network. I don't agree with a system that relies on being able to identify your targets and communicate with them directly. If there are so few miners (more generally, block-constructing agents) that you can send to them all directly, we have a problem.

I didn't say it solves the problem completely. Anyway, as far as I understand the miner eventually ends up with just the parts relevant to the path through which the transaction got to him, he doesn't need to know what was sent to the other peers.

Depends. In this case I'd say a resource consumption increase of about x10 is justified by a clear incentive structure for those providing it.

I've spoken to the authors and they seem confident that the proof can be extended to other graph structures.

This is a special case. If the resources to verify, broadcast and store transactions were in infinite abundance, we wouldn't have to worry about denial of service. But they're not, and DoS attacks work by consuming the limited resources. Hence, tx fees exist to make sure the demand for these resources (whether for a legitimate purpose or an attack) doesn't exceed supply, meaning, to pay for the resources.

Anyway, I am much less concerned about what tx fees are used for now, than about what they will be used for in the future.

Military reserve duty, also known here as "miluim".

As I mentioned, the Red Balloons paper goes some way into rewarding propagating nodes. Also, I expect that in the future full network nodes will offer a set of for-pay services to lightweight clients and pooled miners. So if we can incentivize miners, this should seep into nodes.

Expected payout is one thing, variance is another, maturity time is another. Expected payout is the most important and easiest to calculate, and it's safe to refer to it as the amount owed.

A measure of the miner's intermittency would also be good to have.
 
It's fairly explicit in section 7.4, "Heterogeneous pools".

Variability in pool hashrate is in a sense equivalent to variability in miner hashrate, which I think should be included. One issue is that the specific form of variability will be different, but perhaps it is possible to encode it approximately with a single value.

There has been talk here about doing pretty much this. Maged has a few ideas how it would work. It would be interesting to see how to combine the ideas of dynamic block times and a different graph structure for the blockchain.

It should be possible to create a dataset by running for various parameters, and then interpolating for all other values. Then each pool can show values or graphs for their chosen parameters, and allow the user to set his hashrate with a slider to his how specific results. I have reason to believe that the variance is affine in the miner's hashrate (at least approximately), so that simplifies things. If the interpolation can be done easily enough, maybe the pool can also give sliders for seeing the results for various DGM parameters.

By the way, in AoBPMRS I mentioned that it's not strictly necessary that all miners in a pool will have the same parameters. So it could be possible for miners to choose their own parameters based on their desired performance metrics.

I see, I interpreted "expected payout" literally. I use the term "performance metrics" for the entire range of payout details.

One problem is that I don't know of a simple calculation that will give the variance and maturity time as a function of the parameters. Also, there is more than one kind of variance. If there is demand for this I'll try to work on some approximations or charts or something. For now there's the variance for a single share in the OP, it's relevant for very small or intermittent miners, and as you can see it's a mouthful.

You shouldn't join a pool which hides information. Fortunately, the only pools doing that are the ones you shouldn't be joining anyway.

Your expected payout is the same in every hopping-proof pool with 0 fee (assuming the same number of invalids), and it is equal to p*B per share.

Oh, it's much worse than either. But probably not as bad as what may be your next guess.