Prepare for a "Cyprus shave", looks like last moment tests  /tinfoil hat off It's the Wild West, no need for tin foil. My take: - They're testing to see how fast the hype spreads.
- And/or 'programming' people to expect more crap from their banks, so that next time when balances get reduced to zero, it'll be at least 3 hours (or around that) before anyone panics.
... Why aren't there any Zerohedge articles on this? When it's a European bank, it's f*cking "news of the day"... |
|
|
|
I hear there going to rename the "white house" "non specific colour unrelated to any ethnicity house"
 Don't shoot the messenger! I was just mentioning it because I think Litecoin gives Bitcoin some much-needed competition, and I don't want it to see it get shot down for something so silly. Who knows, maybe "Bitcoin" sounds like "vagina" in Vietnamese? But we'll never know unless someone points it out. |
|
|
|
Is this racist??
I don't know. Is it?  Obviously I'm not implying that anybody or any 'coin' is racist, just pointing the possibility for awkwardness if it gets popular and then the mainstream media has a field day, potentially attacking them from a completely ridiculous angle. E.g.: I heard that in France the Toyota MR2 had to be renamed so that it didn't sound like one of their local swear words |
|
|
|
Ł = a Polish letter which sounds just like a "W". Hearing about "white coin" = ++ungood. Just sayin'.  |
|
|
|
You are mistaken. It's not a public good -- a 'block' is the private property of the miner/whatever entity who discovered it. Selling pieces of that block to interested parties (who want to make transactions) is the whole point.
That's like saying that public park is private property of the construction company who was commissioned to build it. A block does NOT behave like a private good. It behaves like a common good. It needs to be stored, at a cost, by ALL miners and ALL full nodes for all eternety. Not just by the original miner. Otherwise it is completely useless to the buyer. OK, good point. Related question: Are "full nodes" really needed if they're not mining? I don't really understand their purpose. Because if full nodes are really needed for something, maybe there should be a separate fee paying them to stay on-line? Block reward vs block-chain... I'll have a think about that. |
|
|
|
price discovery.
You are aware that price discovery does not work with public goods? This! Also see Tradegy of the commons. What does the original poster suggest? That it should be cheap to spam the network?! You are mistaken. It's not a public good -- a 'block' is the private property of the miner/whatever entity who discovered it. Selling pieces of that block to interested parties (who want to make transactions) is the whole point. |
|
|
|
tx fee should be a VERY SMALL % (I suggested 2%) of the total Input of the transaction! So I want to send 0.1 BTC, but only have a 100 BTC unspent output... I have to pay 2% (2 BTC) just to move 0.1 BTC?! Also 2% is not "VERY SMALL" at all, I can receive credit card payments for less fees. Taking into account the source address. Not the transaction after it has been lumped together with many other transactions...... When a transaction is created client side and the fee is requested, It has not been added to the blockchain and sent along with other transactions at that point. If the cost of sending 5c by snail-mail is 45c, does that mean it shouldn't be allowed? If you control prices by calling them 'fees', you limit miner income, which reduces competition and network security. If you allow the market to determine prices, miner income is maximised, which maximises competition and network security. ...At least that's my theory. I would also prefer a 'bidding' process, but apparently that would be "multiple-spend attempts" and some vendors rely on transaction requests being as-good-as real signed transactions on the block-chain. |
|
|
|
Goals
...
Make sure transaction spam is expensive for would-be spammers
...a market where "supply meets demand"... If we want the network to be successful then what we want is not a specific outcome (high fees or low fees, big blocks or small blocks), but rather an efficient mechanism for price discovery. Nobody can calculate ahead of time how much hard drive space, bandwidth, and cpu time the miners, pool operators, and owners of full nodes are willing to devote to the network for a given amount of revenue. Likewise nobody can calculate the tradeoff between speed and fee percentage all the users of Bitcoin are willing to pay. Instead of attempting to calculate the incalculable and impose a central plan on the network, the best strategy is to design a market for transaction processing that will find the right answer on its own. Thanks! Price discovery was the jargon I was looking for, but my mental block. So I stuck in "supply meets demand" hoping to convey similar thoughts. I guess you were also referring to the pruning? Point taken. In that case, perhaps a good way might be simply drop the priority/"old coins" incentive and allow miners to optionally prune according to rules that are kept as simple as people are able to make them. Even without artificial incentives, miners should still do it to save themselves disk space. This might also make bitcoins slightly more fungible. |
|
|
|
Hi, I've been looking at Gavin's blog updated a few days ago, hoping to learn more about the "fee model", so I've got some questions, critiquing, and a couple of ideas to run past everyone. Goals
In rough order of priority:
Create a self-regulating market for transaction fees between miners and merchants/users
Smoothly transition from the rules we currently have in place to the new rules; transactions from users running old versions of Bitcoin should get confirmed reasonably quickly under the new rules.
Make sure transaction spam is expensive for would-be spammers
Replace compiled-in constants with dynamic, market-determined values
Pre-emptive intervention as a design goal? This may be nitpicking, but I would have thought that in a market where "supply meets demand", transaction spam would no longer be relevant. Miners would tend to simply sign "winning bids for transactions" in order of profitability and the problem would sort itself out. (Supply and demand might be chaotic but it's not Voodoo.) Should the priority calculation be changed?
As the total number of transactions grows, transaction pruning schemes that "forget" old, completed transaction become more and more important. Pruning is possible when all of a transaction's outputs are spent, so a transaction that takes 10 inputs and combines them into 1 output is good for the network.
The transaction priority calculation could be modified to prefer transactions with a high ratio of inputs to outputs. However, we need to be careful and make sure that there is still an incentive to use 'sendmany' instead of creating dozens of single-in/single-out transactions; a 1-input-10-output transaction should not have one-tenth the priority of a 1-input-1-output transaction.
To give a mild preference to transactions with fewer/smaller outputs than inputs the priority formula could be modified to be:
priority = (sum(value*age)/size) * (1000 + size of previous txouts) / (1000 + size of this txn's txouts)
My question is: should priority calculation exist at all? Pruning generally seems like a sensible idea, but pre-emptively intervening and hard-coding the decision into the protocol seems like unnecessary bloat. Why not get rid of it altogether and provide miners with an economic incentive instead? E.g.: "reward miners who prune old blocks by giving them optional extra new blocks (without the coin reward of course)". Of course that might only work if block-space were already a reasonably scarce resource. Anyway, just an idea -- no idea if it's feasible. maximum block size : The maximum size block that can be created. If not set, it will default to the same as the target block size. Miners can increase this to make room for more fee-paying transactions.
--The controversy never ends At the moment I'm favouring an algorithm where each time a block is discovered, the miner can reference the previous block's maximum size and vote it 'up', 'down', or 'no change'. The question is how much should the vote count? E.g.: a 2^(+-1/2016) change? (E.g.: doubling or halving every 2 weeks with that example). To me this seems like a relatively simple algorithm that alleviates 3 problems: 1) miners all having different opinions on exactly how much capacity blocks 'ought' to have, 2) minimising some potential problems with rogue miners/merchants/ anyone DOSing transaction requests, 3) of course scaling. Lastly, one thing I'm unable to find anywhere, and perhaps someone could point me to it -- where are "unconfirmed transactions" kept? Presumably this memory heap is itself a scarce resource, and ought to be treated as such? It seems that some merchants et al. are using this memory heap in lieu of a low-cost messaging system. Does Bitcoin already have a messaging scheme for data other than transactions? |
|
|
|
How serious is this please. Double spends I thought were impossible .  Was only an issue while there were two chains; ie, for a couple hours last night. The possibility was well-known, which is why it was recommended that merchants, exchanges, etc, stop taking payments/deposits until the issue was resolved, which it now is. Yep, I guess strictly speaking it's "single-spend in 2 currencies". But of course, having multiple chains is ideological anathema, therefore there seems to be no infrastructure to handle it. |
|
|
|
Hmm OK, so I guess that that's not so controversial then  Never underestimate how much semantics affect people's ability to think clearly. Your suggestion is extremely valuable, in my opinion, and there are quite a few other misnomers in the Bitcoin world and especially surrounding the blocksize issue. Using accurate terminology is crucial for arriving at sound judgments. ...
Currently most clients in the network will block/not relay this second transaction though.
And rightly so. If clients relayed double-spend transactions, it would make 0-conf transactions (which are used in things like digital download services) utterly useless.However, I'd like to think that a particular set of rules could be created to allow relay of transactions with the same inputs and outputs, but it wouldn't be easy. The possibility of additional inputs in light of a higher fee has to be considered, as well as a differing change address or a differing amount going to the change address. Perhaps changing the bid after the fact is not the correct approach. Is there enough information under control of the Satoshi reference client -- what do we call this, just bitcoind, SRC, or what --- to predict how many blocks later the transaction will be processed, based on work already in the queue? Not at all, because each mining pool has different rules by which they include or disclude transactions. And if higher-priority transactions are created at any time while the transaction is waiting, they take precedence. There isn't any sort of queue, only priority. Any sort of estimate wouldn't be at all reliable. Hmm, this is getting more interesting... (And incidentally I'm starting to feel bad for some of my responses to Mr Bigg's Satoshi-Dice-spamming threads recently. Sorry Mr B!  ...) Zangelbert, I'm guessing that one of those other misnomers might be "0-confirmation transactions", when they're really just transaction requests? And some services operate by using these TX requests as a rudimentary messaging scheme in its own right (and they don't care about the actual payload)? I think I used the term 'queue' earlier, when it seems more like a heap, is that correct? I recall from other threads that the memory size for these TX requests is essentially unlimited. Something doesn't sound quite right there. - If the memory and bandwidth really is unlimited, maybe someone could (at least in principle) painstakingly build a UDP layer on top of Bitcoin, treating the TX requests as individual bits, and create an extremely inefficient file-sharing network?! Clearly there must be some cap on the memory and bandwidth, even if it's quickly growing.
- Based on the responses here so far, a proper bidding process for transactions is possible, but it would require multiple TX requests -- a multitude of those so-called "double-spend" requests. Apparently this is incompatible with some existing services, whose behaviour relies on treating TX requests as the real deal.
- It seems the "memory heap" part of the system might be a bit loosely described at the moment, and tightening that definition could cause some problems for some people...
|
|
|
|
After reading all the replays, I understand the following (and please do correct if I am wrong):
I was under the impression that there is no central authority on Bitcoin (like banks on dollars).
Now, it appears, there is: the miners. They can decide the amount of the fees We all pay.
+1 Agreed. That's partly why "centralisation" is a sensitive topic for some people. Miners do have a lot of power, and there's a limited number of things keeping that power in check, e.g.: - Competition among miners (faith in humanity as a whole).
- Ease of breaking into the market and becoming a miner yourself.
- Ease of creating "alt-coins" and competing from the outside, because FOSS.
- Being a developer and trying to promote the development process in a certain direction.
- Discourse.
|
|
|
|
Here are some of my thoughts regarding the block size limit. I don't know all the technical issues, so I may have missed out some important stuff about orphan blocks, for example, but I hope a kind of market analysis might add to the debate from a different perspective.
In an efficient system, the price of transactions should converge towards the cost of processing those transactions.
For miners at the moment, the block reward covers their overheads in terms of hardware and electricity and so on. While there are relatively few transactions taking place, the cost of processing each transaction is negligible, or not worth calculating.
In the future, transaction fees will have to be covering both the cost of processing and also mining overheads as well. That means the most efficient miners will be those with the lowest total costs per transaction processed. In other words, they will be competing on bandwidth costs as well as electricity costs and hashing power.
So when transaction fees are making up a significant proportion of miner's income, the measure of a miner's efficiency might be something like transactions per second per dollar of costs instead of Mhash per dollar. Given the average rate of transactions on the network, a miner will be able to estimate the transaction fee per transaction in order to break even. Even if there were no block size limit, they could choose to reject all transactions offering a lower fee than their break even point.
An efficient miner will be able to process a larger number of transactions with a lower fee per transaction. This will bid down the average fee size. An inefficient miner will not be able to find enough transactions with a sufficient fee so they will drop out.
If the block size is limited, then miners lose out as well, because conceivably, transactions with a big enough fee to be profitable will have to be ignored, because it will take them over the block size limit.
Some of those points need further thinking, but the important thing is to work out how to calculate the cost per transaction. That changes the thinking from wanting fees to be simply as big as possible to wanting them to be at least above your break even point. Also, instead of worrying how to keep transactions scarce, you can see that bandwidth limitations make transactions scarce, and therefore higher priced on their own without needing an additional block size limit.
Hi Pteppic, Thanks for your reply! While I disagree on some points, I appreciate the thoughtfulness. As I see it, some mining costs are semi-fixed or sticky: hardware, scheduled maintenance etc. Some mining costs vary, e.g.: electricity per block created. That variable cost is essentially based on a bubble. It's a game of supply and demand, where a "limited resource" is being supplied by the protocol, and Bitcoin users 'demand' that resource. The limited resource is a combination of two items: new coins, and block ledger space where transactions are signed. (Ignoring the new coins for now), block space is like "bandwidth for SMS messages" -- there's a limited supply, and people find it useful so they're willing to pay in order to get some. In the future, transaction fees will have to be covering both the cost of processing and also mining overheads as well. That means the most efficient miners will be those with the lowest total costs per transaction processed. In other words, they will be competing on bandwidth costs as well as electricity costs and hashing power. True, but their aggregate costs are dictated by Bitcoin's popularity. Let's say the markets are hitting $45 per BTC. Discounting future investment and general betting, if a miner isn't breaking-even and getting at least $45-worth from their efforts, it's not worth doing. Thus the price regulates the "difficulty" of the hashing game, and since it's a competitive game it's no surprise that the system is constantly evolving. Inefficient miners get left behind, and the remaining competitors push the relative costs higher and higher until it's barely worth doing. An efficient miner will be able to process a larger number of transactions with a lower fee per transaction. This will bid down the average fee size. An inefficient miner will not be able to find enough transactions with a sufficient fee so they will drop out. I like to think of block space as a precious item that the miners want to sell for as much money for as they can get. E.g.: prime water-front real estate. Thus, high bids get high priority, and vice versa. And expensive requests (transactions with multiple I/O) also cost more. However, it's also a race against time because some other miner might also discover a block. Therefore only the bids that have already queued up are considered. If there's any unsold space at the end of the auction, some of the remaining space might be given away for free -- depending on the miner's politics. E.g.: one reason to reject free transactions could be to encourage users to "bid higher next time". Let's look at 2 alternate scenarios: 1) Block space is extremely abundant and there's always enough for everyone. Why pay? Even if 100 miners keep rejecting transaction requests to encourage users to cough-up higher bids, the 101st miner might sign all the 'free-loaders' regardless. Since the network difficulty must match the "resource reward" (made up of new coins and winning bids), low rewards would tend to force the difficulty down. 2) If block space is too scarce, basically the opposite happens. Miners get rewarded with higher and higher bids... until Visa and Mastercard et al. start looking competitive again. Bitcoin doesn't operate in a vacuum so it should take its environment into account. So how does one find the right level of scarcity to maintain a multi-dimensional balance of: D1: high network security D2: 'optimum'(?) exchange rate D3: competitive transaction costs ?? By a fixed algorithm? E.g.: the Bitcoin protocol automatically adjusts block size as well as difficulty. Or by a human-influenced market? E.g.: miners competitively pull block-size up or down. I think both options are likely to have flaws, and it seems like an extremely difficult problem to model. Since Bitcoin will likely always have external influences (competing currencies and payment systems), and those externalities may behave irrationally, I'm leaning towards allowing a human-controlled evolutionary algorithm for finding that balance. |
|
|
|
Yeah sorry they're fees plain and simple. Called fees in the client, it's a transaction fee. It's fine if you want to 'think of them as bids' whatever, but no they're fees
But that's just it: a 'fee' is something you have to pay in exchange, e.g: for an item with a fixed price, and if you don't pay then absolutely without a doubt you will. not. get. that. item. So, they're not fees. Different word, different concept. How has this been going on for so long? I thought it was correct! |
|
|
|
If they were called bids, then I would assume that I could increase my bid at any time - which would actually be pretty cool. If I'm not seeing my 0.0005 BTC "bid" getting through in 30 minutes or so and I'm getting kind of frustrated, I could double or triple my bid to increase the likelihood of it going through in the next few minutes.
Create a double spend transaction with the same inputs and outputs, but a different "confirmation urgency bid" Currently most clients in the network will block/not relay this second transaction though. From a user perspective this is incomprehensible. Although I don't expect the classic "full node" to start implementing lots of additional GUI functionality, I would expect that the light-weight GUI clients make the bidding process convenient, or at least functional. |
|
|
|
If they were called bids, then I would assume that I could increase my bid at any time - which would actually be pretty cool. If I'm not seeing my 0.0005 BTC "bid" getting through in 30 minutes or so and I'm getting kind of frustrated, I could double or triple my bid to increase the likelihood of it going through in the next few minutes.
Then I guess we need to have this discussion! It's my understanding that the bitcoind client automatically rebroadcasts transaction requests if they don't go through. At first glance it seems like it shouldn't be that hard to allow users to increase their bid, as you say. It shouldn't require any modification to the protocol, just a better GUI that gives more control over the bid size that gets rebroadcast. |
|
|
|
Change in semantics here might lead to a change in behaviour.
First of let me say how much I like the general idea of what
is commenly know as fees to be called bids.
Thanks for that! I don't imagine for a moment that I could sway everyone single-handedly, but I hope this discussion helps! Until recently I wasn't 100% certain about the 'fees' really being bids -- perhaps there was some special trick or unique behaviour that made them different? But it never added up -- a 'fee' that you could alter or choose to not pay altogether, and then the request might or might not not get accepted regardless?? So now I've made this thread and hope that as many people as possible start using the more standard terminology. All the information's publicly posted, so I don't see why it would be too difficult for a client to pull this information.
Yep. Scraping data from the block-chain / blockchain.info etc. I think I've already seen a site that shows a bid vs confirmation time scatter-plot, so I think it would be nice to have something along those lines integrated into a wallet client. It should be noted that a .0005BTC bid is not equal among miners, core rules ignored for a minute. Certain pools create certain allowances, bans, and modifiers for different transactions, as well as perhaps certain entities. The SDice patch is a good relevant example. The worrisome spat of no-tx blocks a while back is also a good example of "the rules" being modified - because the rules are more default settings than rules, as I understand it. If you made Luke-Jr really mad, for instance, he may have Eligius ignore all transactions coming from addresses known to be yours., and IIRC, Eligius is known for having irregular bid rules.
Thus, there probably isn't particularly accurate information on whether or not the particular tx you send out will be included in the next block. But, you could get a fuzzy idea using simple information, assuming everyone uses the default bid weight settings.
I guess people could even investigate individual Pools' pricing policies, so that you end up with per-pool price indicators... It just all requires time and effort, I guess. I wonder when this becomes the rule - will the day of bitcoin state of the art come when we have special developed clients for each "nolonger called mining- but now payment announcementpool" so that we bid in there personally held auction? Quite possible. With multi-sig transactions starting to come out, I can imagine all kinds of cool possibilities e.g.: miners gain loyal customers who have their transactions cleared exclusively through them. It's just that calling bids 'fees' so confusing! |
|
|
|
Hmm OK, so I guess that that's not so controversial then Following up on that: is it supposed to be part of Bitcoin's core functionality to manage this "block-space bidding" market? Price history -- core Bitcoin thing or 3rd-party widget/add-on? Is it possible to withdraw bids? -I suspect it is, but is there a user interface for it? Is it possible to see what others are bidding for the same block? Maybe I'm just behind the times and some of the light-weight clients provide more bidding features than bitcoind? |
|
|
|
When one pays a so-called "fee" for a transaction, it's not really a fee at all. It's a bid! It's simply bidding for space in the next available block. So-called miners are the entities auctioning block-space to the highest bidders. I've been wondering why there has been so much confusion surrounding the whole "increasing the block-space" thing, and I think it at least partly boils down to a highly misleading nickname. They're not fees, they're bids! The way I understand it, every time a new block is discovered, an auction occurs and individual kilobytes of that block are auctioned off to the highest bidders. However, at the moment there's a problem because it seems like such a crappy opaque process with very little market transparency. This needs to be improved. Before requesting any transaction, I want to know the "going rate" and the estimated delivery time depending on how much i BID. Agree? Disagree? Please discuss. |
|
|
|
|
Transaction 'fees' are really just bids that people offer when they want to buy block-space. Miners are basically auctioning off a limited amount of new block-space and they don't have to accept low fees if they don't want to. Thus there's a market with buyers and sellers.
It sounds very crappy at the moment with very limited ability to find out what the "going rate" is apart from trying it out repeatedly, until one day your transaction requests start going through. However, now that more people are figuring out how it works, the process should start getting better.
Incidentally, this is partly why there is so much commotion regarding block size. Some people think (including me) that if block capacity is expanded without regard for 'scarcity', the miners won't be able to sell it. Imagine this: if there is "excess" capacity and miners can't reduce it, all it takes is one rogue miner giving away 1000s of free transactions for the whole system to fall apart.
|
|
|
|
|
Show Posts
