Hrm, it occurs to me that any miner charging a lower fee would be able to collect higher fees in addition to lower fees, so between two miners with equal hashing power, the one with the lower fees will make more money.

The main problem arises directly because of the subsidy. If a merchant is doing a significant transaction and wishes to ensure a fast verification, then the customer must pay for it. When a miner gets a block reward, both the customer and the merchant are paying for it.

1: Because of the subsidy, a miner with significant hashing power could charge impossible fees and still get paid virtually 100% the same amount. The advantage of doing this is limited, but not zero, and generally reduces the use-value of BTC as a whole. Mystery has already demonstrated a good reason for doing this.

2: If the miner in question was a 51% attacker, they could legitimately charge impossible fees on purpose in order to DoS the network. If someone had the resources and the intention, perhaps a government, then virtually nothing could be done about it.

3: If 50%+ of a miner's income is coming from tx fees, then only the situation of the 51% attacker would really be relevant, since miners that did include txs could easily out-earn and outhash a miner smaller than that. If, on the other hand, the exchange value of BTC increases at a rate faster than the subsidy decreases, then charging more than a token fee is stealing. Unless, of course, the costs of running a mining rig increase faster than the value of the subsidy, which seems fairly unlikely since the cost per unit of power or storage decreases exponentially.

I would assume that your average merchant, from time to time, might want a transaction confidence rate of at least 75%, and 80-90% or higher would be ideal for sensitive, high value transactions. If a large miner is charging more than 100 times the amount than for a 50% confidence tx, then 100% confidence, or only 2:1 the value, is costing 100 times as much, or more. The cost to value for using bitcoin as a currency then becomes something like 1/50 as much or worse in that case. In the competitive case, this wouldn't matter much, but in the current case there really is no competition since any reasonable tx fee will be an insignificant source of income to any miner for the foreseeable future. A miner who includes tx doesn't, and can't, make enough money to employ more hashing power than one who charges enough that no tx are included, so a lower cost service has no advantages at all.

The only advantage of lower fees at the moment is that, if all miners charge a 1 bitcent tx fee, bitcoin dies tomorrow and all their earnings from mining become worthless. However, for someone who only trades their BTC for fiat, this risk is almost totally externalized and can't be corrected by the market.

I think the disadvantage of floating price control is far outweighed by the advantages of keeping high-confidence verification costs at least half-reasonable, and by the resistance to a 51% who tried to DoS by excluding every tx by using an unpayable fee. Also, if you publish the fee along with the block, then it becomes very easy to verify that the expected tx for that fee have actually been included, so working the system a la mystery becomes virtually impossible. If the network becomes flooded with idiots like D&T who demand both hefty taxes AND a welfare check, then the network will fail even if their claim is "legit", so the disadvantage is really moot.

Except then you've killed de-centralization, and added more costs between customers and merchants, and as has been mentioned, between customers and their own private addresses. Also, if the network as a whole doesn't guarantee against double spends, then the security isn't high enough for a merchant to be confident using it in the first place.

The miners don't deserve to be throwing that much weight around, as it just loads costs onto the coin without providing any value that isn't available by cheaper and more reliable means.

I think per-byte or per-kb fees are reasonable, but there has to be some way for the market to regulate fees, or else a single large miner charging 100 times as much as everyone else could cause tx to become so unreliable that the currency is choked out of existence. For example, if "mystery" included txs, but charged 1BTC to do it, just getting over 85% confidence rate that your tx will commit would cost 1BTC.

Certainly 100% commit should be more expensive than 50%, but the blockchain is a tragedy of the commons type problem for one, and for two you don't need tx fees to operate, and you probably won't need them until 2025 or later, if BTC even survives that long.

I would say, every block should have the fee rate of the producing miner published with it, and if the fee is > 2 orders of magnitude greater than 50% confidence, or if the miner doesn't include the tx expected for the fee they charge, then the block should be excluded. The only problem with doing it that way is that, since currently most tx are free (which I think was a bad decision on satoshi's part), there's no comparable fee at the 50% confidence mark. Using max(MinFeeCharged, 50% confidence) instead could probably get around that. With that system, if 50% confidence or MinFeeCharged is 0.0001 BTC, then you could charge up to 0.0999 BTC and still get published, with no penalty for charging less or nothing.


You get paid a subsidy, idiot. You aren't subject to the laws of supply and demand, any more than mystery is dependent on including tx for his income. Also, there is little/no room for competition of service in this market; there's only one quality of service and the only variation is how much time it takes to verify a tx. The only thing a greedy miner can accomplish by charging an excessive fee is to slow everyone's tx down so that BTC is less competitive as a currency.

Based on current interest rates and the usual amounts of currency that are exchanged, yes .01 BTC is exorbitant, and would kill the market if everyone used it. The fees you're suggesting are in fact higher than much of the business that is done, and are multiplicative since any business transaction will generally involve several re-organizations of coin by each party. That's exactly the sort of thing that needs to be prevented.

Compare your fee of US$0.05 with the usual tx fees charged by a stock exchange router: US$0.0005 or less, which is even less than the current spam fee and they don't even get subsidies.

Nevermind, I can see how % rates are unworkable now.

I think pay-per-KB or per byte or whatever is reasonable, but I think it needs a little more tweaking so the whole network can be informed about what fees miners are charging. I think that a per-KB fee should also make spam fees obsolete.

The only problem that I can see is that, as per the scenario you outlined, fees might vary by several orders of magnitude, which might make it a huge pain for a client to decide on a fee. Is it possible for a client to determine what % of hashing power is charging what? If you can figure that out, then you could create a "confidence scale" to match a minimum fee with a minimum confidence rate.

Lol, well then my resources stay in fiat or PMs.


How are market values determined? Except by what the miners who control the majority processing power arbitrarily decide? In any other economic situation the trade between price and willing customers would necessarily lead to fair market prices, but here if a miner creates a block, then they basically get to decide the network's fee policy for the next 10 minutes all to themselves. That might be somewhat reasonable at a 0% subsidy, but at current that could easily kill the network if a majority of miners happen to be stupid (which is guaranteed in the long run). With no way for a fair market price to be determined by supply and demand, miners become parasites who decide on their own welfare checks, and users become orphaned trying to discover what fee will reasonably get their tx pushed.

".01 BTC" is not a reasonable fee, period. Here's why.

I lend 1BTC to someone for 1 day, interest paid is 1%, total 1.01 BTC due.

I pay him the 1BTC loan, there's 0.01BTC paid to you.

He spends his 1BTC on whatever it is he wanted, there's 0.01 BTC paid to you.

He trades cash for 1.01BTC to pay me back, another 0.01 BTC paid to you.

He sends me the 1.01BTC, there's another .01BTC paid to you.

The interest on the loan was 0.01 BTC, total interest paid to me = 0.01BTC, interest paid to you just for the tx, .04 BTC, or 4 times the interest the loan was worth. This sort of 1BTC/1% transaction happens regularly on the lending forum.

I should point out that western union does indeed charge based on how much you send, although it's a flat rate for up to a certain amount, but that's pretty irrelevant. I would say a "Fair" rate is more like 0.05%, maybe 0.025%, with a spam fee that increases exponentially per digit below the spam threshold, say 20% to send 0.001BTC, 50% for 0.0001BTC, 100% for 0.00001BTC, and doubling forward. Of course, since this was very poorly thought out before client was released, figuring out how to reach any kind of consensus between miners and clients is not going to be easy.

I won't spam up this thread anymore, but I think what you are proposing has serious flaws. Since the blockchain is a "tragedy of the commons" type of problem, unless all miners and all clients agree to what a reasonable fee is, there's going to be serious conflicts at some point. Either significant numbers of empty blocks, no way for a client to determine what a "good" fee is, and if enough people get tired of that behavior, you might end up on your very own blockchain fork one day. Of course, for the protocol to change at all, and for any reason would generally end up producing large forks, which is a major downside of the BTC system, and of the fact that it's experimental.

Just sort of a relevant comment while you're on about this, but what about making fees proportional to the amount being sent? ie charging 0.1% as a fee rather than a nominal BTC amount. You could just use a higher % for extra small tx.

The main reason I would suggest doing it that way is since the trade value of BTC fluctuates so much it may be impractical on the user end to deal with fees set in nominal terms, whereas %s scale automatically and are simple to understand.

Well, unfortunately things aren't so simple. The main issue with the USD is that because it's used as a reserve currency (see: oil) the US can export it's inflation to other countries. As a result, we only see a small amount of that inflation in the states. Until everyone throws their dollars back at us, prices will rise faster everywhere else than they do here.

A common (although colloquial) method of gauging this is the "Big Mac Measure". Ie, the price of a Big Mac in various countries over time. In other places like Australia and South America (many south american countries basically use the USD as their official currency, or unofficially by backing their currency 100% with USD), the price of a Big Mac has skyrocketed, although unfortunately I no longer have those particular numbers available.

Technically that means that if you make more than the "nominal" inflation rate in interest, if you cash out quickly enough you can keep your gains and avoid being crushed by the sudden inflationary backlash that is coming, but that's catching a falling knife to say the least.

There are a few other reasons that apparent inflation is relatively low, mainly to do with the unnecessarily complicated way in which the banking system works, and the interactions between inflationary lending and deflationary paying back of the loans. Price inflation is non-linear, which is why "economic bubbles" happen rather than all prices going up evenly. When the bubble "pops", the price of the bubble asset moves back towards a fair market value, and anyone who had financial securities in the bubble asset goes shit broke, a la the whole financial industry in 2008.

Bubbles have occurred in college tuitions (most people graduate with literally a mortgage worth of debt today), automobiles (subprime auto loans) and houses, just naming the main ones. All are a result of artificially low interest and easy money policies (a la robosigning). The general chain of events goes something like:

Easy money policy -> Artificial demand -> Rising prices -> Stagnation -> Insolvency -> Government Bailouts

Rinse, repeat.

http://www.shadowstats.com

Government issued inflation numbers say exactly what the government wants them to say, even if it means excluding energy, mortgage payments and anything else important they feel like excluding from CPI numbers. Inflation can't actually be derived from CPI anyway, since it depends on how much money is issued by the Fed, the Treasury, and inflationary reserve banks.

That said, I overstated a bit, it's more like ~6%, although it varies. That's still more than you'll make in any US based savings account.

There are two ways in which "deflation" could occur.

One is that people start dumping their fiat for BTC at an obnoxious rate, leading to rapid currency appreciation. If the money that jumped into BTC decides to randomly jump out, this could cause major disruptions to the BTC economy, as inflation rates might jump up and down and even be forced below zero for periods of time. If the fluctuations are at least somewhat predictable, intelligent business owners could deal with it adequately.

The other is that the rate of currency destruction exceeds that of currency creation. Eventually (100+ years, probably) this would lead to a loss of fungibility of BTC, and the smallest unit of coin would end up buying more than the smallest items you would want to buy. As long as the rate of currency deflation is slow enough, and as long as people don't suddenly lose huge chunks of coins (ie maybe 10% of the coinbase disappears overnight), this will have virtually zero effect on the BTC economy. Interest rates will remain low to reflect the appreciation of the currency, and that is all.

Compare to USD, where the rate of inflation is 8% and the usual interest rate is under 5%. If you have USD in a savings account, you're losing money. With BTC, you still make < 5% interest, but since the currency is increasing in value you're actually making more than what the interest rate reflects.


Austrian economics doesn't say "human nature cannot be predicted", it only makes that assumption to simplify the effects of various economic events. Also, Churchill's failure with trying to return to the gold standard occurred for one reason and one reason only (I had to look this up, thanks a lot):

Full Article

If the US government put a price fix on gasoline at say, $0.50, nobody would be able to sell gasoline in the US because it would cost more to procure than what they could sell it for. If that happened it would be a disaster. Do the same thing to your currency, and you get the same result.

Since BTC is immune to this sort of manipulation, that sort of economic disaster basically cannot happen to BTC. Governments today can even control the price of gold and silver through fraudulent futures contracts and by stealing bullion from other countries (*cough*Libya*cough*). Again, they have very little ability to steal BTC, although if BTC were traded on major stock exchanges they could try to push the value down by naked shorting futures in the same way that they do with gold and silver. If you take a quick peek at the price of gold, you can see how well that's working out for them.[/list]

Several reasons.

1: The block reward may drop in half come 2013, however if the value of 1BTC doubles, then nothing has been lost. That leaves him fully secure to continue ignoring tx until at least 2017.

2: He isn't actually contributing to security, since he's only generating blocks off the previous hash without validating anything. That means if an attacker starts throwing down invalid blocks, our friendly botnet might blindly build right on top of them and give them a nice helping hand.


Also, it depends on which method is used. Gmaxwell's proposal would not affect legitimate miners in any way. Any proposal which excludes blocks that are "too empty" would have unintended consequences, but in the event of an attempted 51% empty-block DoS attack, the ability to screen empty or cheap blocks would severely limit the damage they could do.

We've been over this like 50 times =\.

There have been other proposals for things like this for BTC already. I'd say if your block generation rate is every 10 minutes like BTC, then a checkpoint every 144 blocks makes sense (24h).

Checkpointing can be done via a ledger to save space, and if done well it can save roughly 93% vs the blockchain. See this thread for more details on that.

If you want to increase the security of your checkpoints, you might use Meni's Proof-of-Stake system. It adds several advantages for stability of the main blockchain, helps protect against 51% attacks, and allows the checkpoints to be well agreed upon for historical purposes, esp for vendors wanting secure confirmation that a payment is absolutely final. Once a checkpoint block has been agreed upon and signed, the chances of it being reversed are virtually nil, especially if there were no competing branches at the time of signing. Relevant link.

That's similar to what Gavin and Revalin proposed, the downsides of which have been discussed at length .

Gmaxwell's proposal should achieve the same effect without the downsides of a threshold-based approach. The main advantage of an approach like yours is that if the bot owner finds a way to include verification without including current tx, he still gets shut out for non-cooperation.

I think if you were to do it that way, a much lower threshold would suffice. AFAIK our mystery miner only includes a single token tx in his blocks, or none. With ~80tx average per block, a 5% threshold would neatly wipe them out. At that rate, miners have little to complain about, and the likelihood of a fork is lower. At 50%, a pool might end up having an otherwise valid block excluded if they happen to charge on the high end of fees. At 5%, a pool charging enough to get excluded would not be providing anything extra to its users (if any).

Both of the proposed implementations of PoS (Cunicula's and Meni's) are combined with PoW. In Cunicula's system, difficulty is adjusted by stake, such that a miner with a higher stake gets to use a lower difficulty for PoW. Meni's system uses straight PoW, but PoS is used independently to verify certain checkpoint blocks that the whole network can fall back on in case of a dispute.

The main disadvantage of Cunicula's system is that only a single miner signs each block, which makes it hard/impossible for decentralized pools to contribute. Also, the way his system weighs stake doesn't allow for the "trustworthiness" of signatures to be gauged based on how many blocks they have contributed or any other relevant figures. It also has the unintended side effect that having a larger stake leads to a higher chance of generating a block (and thus collecting the coins from it).

The main disadvantage of Meni's system is that signature blocks can be signed by anyone with a stake, so each checkpoint block might end up with millions of signatures. This also makes it hard to provide any incentive for signing.

I had the idea to have the contributors of each pool sign the blocks it creates, and then only signatures that appear on previous blocks can be used on checkpoint blocks, each weighted by, say, the number of blocks the sig appears on and the amount of BTC in the signing account. That would prevent a 51% attack unless the attacker both had 51% of the computing power and a huge stake, and it would take a considerable amount of time for their signatures to gain the weight needed to overthrow the main blockchain. The main problem is figuring out how to keep the size of signatures down as in Meni's system.

Another thing that occurs to me is that, in the thread on tx replacement, it was briefly mentioned that a new protocol rule could be included that would invalidate any block containing a double spend attempt. If there is any conceivable way that a 51% or other forking attack could be used to effect a (very large) double spend, then a protocol rule would invalidate that chain automatically even if it does happen to be longer. They would be limited to DoS, or they would have to put most of the other miners out of business before the network would accept their attack (if at all). In that case, the network (and bitcoin) would probably be destroyed (if the clients still throw flags) before a double spend would succeed. As long as there's some contingency for a major DoS attack, it shouldn't be a major issue, however.

D'oh.


gmaxwell's solution might provide #1. If D&T is correct, then since gmaxwell's solution requires a miner to use the previous block's tx inputs (rather than just the hash) as verification, this would force mystery to either run more complete versions or bow out. The disadvantages are that it requires a change in protocol, and would increase the size of each block by an unknown amount.

For #2 it's been proposed to replace the blockchain with an acyclic directed graph, but I don't know enough about that to compare it in any way. Apparently this would make tx inclusion cheaper, although I have no idea how that would work, or how the filesize compares to the blockchain.

#3 unfortunately is probably not going to be viable for several years, maybe a decade. When the average number of tx increases by a large amount (maybe to 10k+) then even a small tx fee would generate substantial income, but as of right now, and for at least a few years yet, the block reward is much more significant, and has currency appreciation supporting it.

*sigh*, well if that's true then either someone is charging a ridiculous fee, or there's a bug in some version of the miner software. If the difference in load and everything else between including tx and not including tx is basically insignificant, then there should be no reason for anyone to be purposefully excluding them.

On the other hand, if an empty block is really ~1/55th the size of a block with lots of tx, then it might really be someone trying to cheap out on bandwidth while still getting paid.

Either way, it ought to be stopped.

Right, I figured that much out. However, I don't know that anyone has created a mixer thus far, so it's pretty moot. It would be one of the main design considerations for a mixer, though.

If what you're saying is true, and I'm not knowledgeable enough about the various BTC miner software versions to know, then gmaxwell's proposal would not work at all, and would be a huge pain since it requires a protocol change.

It seems to me that if you're right, then it's most likely a bug, since it's inconceivable that anyone would purposefully omit tx unless as T&D stated it was to maybe to reduce server loads on an already stretched system. Unless "mystery" steps forward, assuming it's even one person, we couldn't know their intentions.

Also, if this is the case, then the method proposed by Gavin/Revalin would be necessary. If a block has far fewer tx than the average, then it gets delayed, and if it has only 1 or none it may be excluded altogether.

There are several reasons why the "I'm entitled to charge whatever I want" argument has no weight.

1: I can charge $1million USD for a single grain of sand on ebay. Nobody will buy it (I would hope), but I still have to pay for posting it at auction. In BTC if you do the same thing you still get paid, at the expense of everyone using the system.

2: Gavin/Revalin's system still gives miners a good deal of room in choosing what they want to charge. As long as the threshold for delay isn't too restrictive, and the miner is charging a reasonable enough fee that they actually get some business, they shouldn't be excluded or delayed. Unless your business model is crap, there's no penalty. Also, since it's not actually part of the protocol, there's no obligation of any party to delay or reject a block, nor any obligation to accept any block, and it could potentially be adjustable by the user. I think, however, that the sentiment of most miners is that they also are not interested in supporting cheapskates.

3: The blockchain is 2 fucking gigabytes, and climbing at an absurd rate. If I have to download a 2GB blockchain, and 15% (or more) of all the blocks are empty or nearly empty, then why have I wasted my time downloading 300MB+ of that? The only purpose of the blockchain is to be able to securely verify transactions that have occurred, and empty or nearly empty blocks add filesize without contributing to the purpose of the data. At the rate things are going it's already going to take further development just to figure out how to keep the size reasonable, and the last thing we need is a bunch of retards being paid in inflation to spam it up faster.

Finally, if it is just a bug in one of the clients rather than someone trying to take shortcuts, then implementing a screening system would make it obvious to the users of that client that something is wrong. In that case it probably wouldn't take long for it to be fixed. If nothing is done, then we have no way of knowing.

While it's possible that it's some minority client malfunctioning, 1.8m users and/or 16% of the total network processing power is pretty extreme. The potential advantages for running a stripped down botnet make that the most likely scenario, and whether or not that's the case 16% of the network isn't contributing to the rest while collecting all the benefits.

Also, I think people are still misunderstanding what has been proposed. While Gavin and others have proposed systems which would omit or delay "cheap" blocks, gmaxwell's proposal is simply that in order for a block to be valid they have to prove that they have access to the blockchain. It doesn't mean they have to include any tx if they don't want to, just that they have to prove that they've seen recent valid tx that have been posted to the chain.

This would be trivial for legitimate clients, official or otherwise, but for a botnet running without having the blockchain it would be impossible to fabricate, so they'd be forced to shut down or play fair. The only time "tx lists" would even be used at all is if:

1: Some other miners wanted to "lazy mine" with no blockchain, and are willing to trust full nodes to provide valid tx for them to mine.

AND

2: Miners willingly want to give up their tx to others, or have tx they don't want, and would like a facility for dumping them on lazy miners.

However, while this feature isn't necessary for booting a botnet, it would weaken security since it requires that the "dumb nodes" blindly trust full nodes, so "dumb nodes" could be used to forward an attack. For a normal, fully equipped miner, tx forwarding would be basically useless unless they have a major incentive to dump tx.

I agree that we don't need to centrally control all of the miners, and that we don't have any business telling them which/how many tx to include or not. However, I think there's plenty of good reasons for preventing someone from sitting around doing getwork without actually having the blockchain, but it's easy to prove whether this is the case or not without putting restrictions on including tx. Revalin's suggestion (or similar) would only be relevant under very different circumstances, which are much more unlikely to occur than someone freeloading with an anonymous botnet.


The problem here is that the "Attacker" most likely isn't malicious in the sense of trying to take the network down. They just want free money from stolen computing power, and so far they're getting it. The real problem is that 15% of the BTC that would be going towards miners who actually maintain their rigs are going to someone who more than likely does not.

The other problem is, how the hell do you "block" 1.8 million unconnected stolen computers? If I started manually doing that now, by the time I was dead I'd still be nowhere near caught up. Requiring proof that you've seen the blockchain recently would automatically exclude anyone trying to cheat (at least via that route). Alternatively, if other people start figuring out they can make free coin by running a botnet sans the blockchain, pretty soon "mystery" will make up more like 30% of the network, and even more funds will be diverted from maintaining the legitimate side of the network. At the moment the reward for parasitic mining outweighs any potential losses from not including tx, and that's not likely to change much for at least 10 years.

Checking to see that a miner is using the blockchain is fairly trivial. If they're actually running the blockchain then there's no incentive for them to exclude tx (at the moment), and no need to babysit them to make sure they include some minimum number of tx, either (that's their choice, however arbitrary). The problem is the incentive for running without it, pure and simple.

Yeah, nevermind that. I figured it out after reading another thread on anonymity. It's a bit complicated as-is, and it's difficult to scramble your coins between your primary funding addresses and your one-offs or special addresses (such as an addy for linking to a bank account). I'm not even sure if there are any services for doing this, although there's some talk of possible techniques on the dev list.

True, although it probably won't be next year. Currently what I said does hold true for "spam" tx, and next year the same will probably hold true for all tx. However, if the 0 fee txs are passed to bots, then the penalty for not including a fee ends up falling on the legitimate miners, who could otherwise extract a higher fee and from a larger number of tx.