To deal with a surge of buyers due to massive media exposure in Israel yesterday, I'm looking for a quick loan of up to about $10K Mtgox USD for a period of about 1-2 weeks. Bitcoins are available as collateral (I have bitcoins to sell but I don't want to compromise my position). Smaller amounts are also welcome. Preferably it will be done at no interest, though this is negotiable. ripper234 is also interested in receiving such a loan. Confirmed, I'm with Meni on this one (one the same loan, not a separate one). I think it could go either way... I and ripper234 do a lot of internal settling but in this context we can get either one loan we will share, or different loans depending on potential lenders' trust in each. |
|
|
|
To deal with a surge of buyers due to massive media exposure in Israel yesterday, I'm looking for a quick loan of up to about $10K Mtgox USD for a period of about 1-2 weeks. Bitcoins are available as collateral (I have bitcoins to sell but I don't want to compromise my position). Smaller amounts are also welcome. Preferably it will be done at no interest, though this is negotiable. ripper234 is also interested in receiving such a loan. |
|
|
|
Sponsoring the resources required to handling block size is a TotC problem in itself (the fee for including a tx is given to the miner which included it; the burden on the network is placed on all nodes). Which is why I earlier suggested some block size limit (or something equivalent) remains. But I'll be generous and assume the marginal resource cost finds a way to fund itself efficiently (e.g., "grassroots" rejection of large blocks).
This leaves the problem of sponsoring hashing. If the marginal cost of a transaction is C, including a transaction with fee C+epsilon is pure profit. There is no reason for a small miner not to include it.
But I pointed out this isn't true. Including the transaction increases block size and therefore storage costs, increases time to propagate, and increases the chance of some other relay not liking it. I'm disagreeing with the fundamental assumption you're making that it's "pure profit". This is all supposed to be incorporated in C, the marginal cost per transaction. Some of what you mentioned is a bit abstract so there's room fo debate. But it is still the case that the costs you mentioned relate indirectly to the number of transactions; letting it influence the incentives to hash, which is independent, is neither robust nor efficient. Also, whatever the costs are to the network, the fact is they're being borne by the network. If the network can't afford it, the network won't afford it. I haven't seen a convincing (to me) refutation of these points. If something isn't worthwhile people won't do it. If it is, people will. My gut feeling is that the block size limit should be removed, and let the free market reign. It works elsewhere, why not for transaction processing?
It works when there's no TotC (meaning, the business pays for any externalities). When there is one (as we can clearly identify in this case), some method to resolve it is needed. It's not clear to me, as I've tried to explain. Just like producing widgets - if someone can't do it profitably, that isn't a reason to seek out a central authority (here the arbitrary block size limit) to "solve" the problem (by specifying a minimum price in the case of the widget, or maximum block size for a block). They just go bust. Sometimes it works, sometimes not. When incentives are aligned the invisible hand works. But when there's an identifiable systemic reason why some business can't be profitable - and we want these businesses to exist - there is need for some intervention. This is even the case now - clearly block size is not a constraint at the moment, it might as well be infinite, as most blocks are way below the limit, and not even at the point where the reference client makes it "more expensive" to take up more space. And yet the network isn't suffering, and also not every transaction is getting accepted in the immediately next block. Because there are costs, lags, and delays, and that is their way of being expressed. Some people moan, but they're the ones who will stop trying to do it (including qt client users who aren't adding much to the network). If the "market" wants those users to keep doing it, the market will pay a higher fee to ensure they find it worthwhile.
The problem of sponsoring hashing hasn't even begun to manifest itself because of the coinbase, which is still more than sufficient for it. And txs are still few enough that the crude anti-spam rules (required fee for low-priority txs) are enough to keep the nodes from overloading. Hashing is an artificially difficult problem and thus has an additional degree of freedom. Most things aren't artificially difficult; e.g., energy generation really is difficult, and if a more efficient method can be found to do it, people can enjoy cheaper energy. But if a more efficient way to hash is found, it favors attackers and the honest network equally.
By hashing, I was talking about the cost of rebuilding and rehashing the merkle tree, not the cost of hashing the block. Sorry for any confusion; I feel that may have led you to misunderstand my argument. I understood this is what you meant. AFAIK the cost of hashing into the Merkle tree is negligible in comparison to ECDSA verification; and even if not, it's part of what I call marginal cost, as opposed to the amortized cost of hashing block headers. The degree of freedom is exactly as you described: If there's not enough profit, miners will quit. Which is exactly what I'm worried about; with less miners the network will be more vulnerable to hashrate attacks. I want to make sure there is enough revenue to fund the amount of hashing required to secure the network; and I argue that left to itself, the TotC problem will create a race to the bottom with little total revenue and low network hashrate.
There are several suggested solutions. I'm not saying none of them can work, I'm saying the problem shouldn't be swept under the carpet.
I'm not certain an unconstrained block size can work. But I think it's highly likely it can, and I've not read anything to persuade me otherwise. If the market wants something (here, more hashing power) it will pay for it, like anything else. So why not give it a go? If it's a disaster, there will be no problem getting the 50% consensus to put one back, right? In most cases gradual changes are healthier. Switching instantly to no-limit and then back to some limit can be disruptive. I think you're too charitable towards the free market, in those situations where it works it works great, but there are situations where it doesn't - or at least, where the free market works only by deciding to constrain itself to be less free. The study of game theory brings up some examples, especially wherever bargaining is involved. |
|
|
|
Did you learn about the story tonight independently?
Saw it on the Israeli Bitcoin facebook page Yeah, that was me, so no. AFAIK the story is about Bitcoin specifically rather than alternative currencies in general. Is there supposed to be a character cap on the thread title? |
|
|
|
Also (coincidence? I think not!) there is a talk tonight about Bitcoin and alternative currencies in one of Israel's top financial TV shows (Layla Calcali - "Financial Night"). Hopefully Meni's interview will be included :-)
AFAIK not a coincidence, they told me specifically that they decided today to do the story as a response to the calcalist article. I learnt only today I would go there to do the interview. Traffic was a bitch and I didn't sleep too well last night. My interview should be included, I phrased it as a maybe since anything can happen. But the interviewer was pleased, I hope I didn't do anything awkward. Did you learn about the story tonight independently? |
|
|
|
So, today there was a major Israel article ( thread). This prompted a major news channel, channel 10, to do a story about Bitcoin, and I was interviewed for it. As were Josh Harvey and others. It should be broadcast tonight, 23:35 Israel time, on channel 10. Thought I would mention it. |
|
|
|
Why do you believe this (that small self-interested miners will survive)? Why must this be a tragedy of the commons? What is special about bitcoin mining that makes block space the only scarce resource that cannot find a price? Removing the limit doesn't make it a non-scarce resource, as precisely the fact it is a scarce resource is what is apparently scaring so many commenters.
I will say again. Block data size is one cost (storing the data, downloading and uploading it, and it also correlates with number of signature verifications required). Hashing is a completely different cost which is independent of the block size. There is no way to reasonably discuss this without clearly understanding the distinction. Sponsoring the resources required to handling block size is a TotC problem in itself (the fee for including a tx is given to the miner which included it; the burden on the network is placed on all nodes). Which is why I earlier suggested some block size limit (or something equivalent) remains. But I'll be generous and assume the marginal resource cost finds a way to fund itself efficiently (e.g., "grassroots" rejection of large blocks). This leaves the problem of sponsoring hashing. If the marginal cost of a transaction is C, including a transaction with fee C+epsilon is pure profit. There is no reason for a small miner not to include it. This means epsilon will tend to 0 and total revenue from txs will be equal to the resource cost needed to handle them, leaving no revenue to sponsor the very expensive hashing. My gut feeling is that the block size limit should be removed, and let the free market reign. It works elsewhere, why not for transaction processing?
It works when there's no TotC (meaning, the business pays for any externalities). When there is one (as we can clearly identify in this case), some method to resolve it is needed. For the marginal cost of handling transactions, the externality is network burden, and one solution is to limit network burden per block. For the amortized cost of hashing, the externality is dissolving the bargaining power of hashers. One solution is to limit the bitcoins transferred per block. (So miners can still have bargaining power against big senders willing to pay a large fee to have their tx included). You're effectively claiming that some miner can survive and be profitable / just eat the cost by being selfish and adding all transactions no matter how small the fee. Good for her! She must be more efficient than everyone else. If you can't stand the competition, stop trying to compete and get out of the race. If mining is not profitable, miners will drop out until it is profitable, just like happens now. Everyone will benefit from the competition towards more efficient mining setups and lower transaction fees.
Hashing is an artificially difficult problem and thus has an additional degree of freedom. Most things aren't artificially difficult; e.g., energy generation really is difficult, and if a more efficient method can be found to do it, people can enjoy cheaper energy. But if a more efficient way to hash is found, it favors attackers and the honest network equally. The degree of freedom is exactly as you described: If there's not enough profit, miners will quit. Which is exactly what I'm worried about; with less miners the network will be more vulnerable to hashrate attacks. I want to make sure there is enough revenue to fund the amount of hashing required to secure the network; and I argue that left to itself, the TotC problem will create a race to the bottom with little total revenue and low network hashrate. There are several suggested solutions. I'm not saying none of them can work, I'm saying the problem shouldn't be swept under the carpet. |
|
|
|
There _must_ be competition for block space to make fees a viable way to pay for security.
Limiting block space isn't the only way to increase mining fees. Removing/reducing the block reward has the same effect. Once the reward is less than the cost to mine, most miners will require a tx fee. Given this incentive, there's really no reason to limit the block size. It is in the miners best interest to set the limit as high as possible so they can receive the maximum amount of tx fees possible. For this reason alone I foresee the block limit rising significantly. It doesn't really work this way. It costs nothing to include a transaction so a small, self-interested miner will include every fee-paying transaction, even a small fee. In so doing, he sells out the bargaining power of miners; users will see that low-fee txs are included, and will pay less fees in the future. The damage thus done is shared by all miners, but the profit from including the transaction is all his own. This is a tragedy of the commons problem. The common resource here is the bargaining power of miners, which the individual miner will consume at others' expense. This will be alleviated if mining is highly centralized (which we don't want), or if there are other factors such as assurance contract funding or a limit on total bitcoins transferred per block. Meni. What is the degree of this TotC problem? That is to say what percentage of self-interested miners (or I suppose successful blocks solves) would sufficiently degrade the position of a loose affiliation of miners enforcing a sustainable tx fee? That's hard to quantify, especially without empirical data on how much users are willing to pay to get their transactions included faster. But about 40% is the hashrate a cartel needs to perform a profit-boosting attack, so I'd say it might be the overall ballpark for the hashrate needed by a group of miners with an unwritten agreement to reject low-fee txs in order to keep the pressure up. But that's assuming the immediate-profit-maximizers are individually small; if there are only 10 miners with 10% hashrate each, it's probable they will converge to rejecting low-fee txs even if they did not originally intend to. |
|
|
|
There _must_ be competition for block space to make fees a viable way to pay for security.
Limiting block space isn't the only way to increase mining fees. Removing/reducing the block reward has the same effect. Once the reward is less than the cost to mine, most miners will require a tx fee. Given this incentive, there's really no reason to limit the block size. It is in the miners best interest to set the limit as high as possible so they can receive the maximum amount of tx fees possible. For this reason alone I foresee the block limit rising significantly. It doesn't really work this way. It costs nothing to include a transaction so a small, self-interested miner will include every fee-paying transaction, even a small fee. In so doing, he sells out the bargaining power of miners; users will see that low-fee txs are included, and will pay less fees in the future. The damage thus done is shared by all miners, but the profit from including the transaction is all his own. This is a tragedy of the commons problem. The common resource here is the bargaining power of miners, which the individual miner will consume at others' expense. This will be alleviated if mining is highly centralized (which we don't want), or if there are other factors such as assurance contract funding or a limit on total bitcoins transferred per block. |
|
|
|
First, it's a hard fork. Every node right now, to my knowledge, will reject any block coming in at over 1MB. Miners included. ANY kind of hard fork is going to be really hard to implement due to the size of the network. But if a hard fork does benefit everyone, or almost everyone, it could be planned in advance and switched to at some date. As long as most (substantially more than 51%) of nodes switch to the new protocol in a coordinated way, a hard fork change could work. (BTW, has this ever happened? I haven't heard of it but maybe it has?)
In case it's not clear, the advance planning is done in software. That is, if we decide right now it should be changed, we add the line "if blockheight > 270000 then sizelimit = 10MB" to the upcoming software version. Then anyone who upgrades his client within the next half year will automatically switch when the time comes. But in the case of removing the 1MB limit, I don't think the agents involved here will agree. Specifically, the miners. SatoshiDice would certainly be on board for 1GB blocks, as would BitPay, Gox, and I'd imagine most end users. But I think miners have incentive to maintain the 1MB limit. The limit creates an (artificial?) scarcity for what they are providing / selling: inclusion in the block chain. If there's only room for ~4K transactions per block, thus only ~1M transactions a day, a spot in that blockchain is going to be quite valuable if millions of people want in. Transaction fees could be quite high, making only large transfers feasible.
A transition to larger block sizes would thus be resisted by miners. While you might say, "Well, at 10MB / block there's potential for 10X as many transactions, thus 10X the fees" I don't think it would work that way. But in fact, I don't think this will ever be tested; all you need is miners to resist this change due to uncertainty. Some miners might like to increase the size limit, but many won't. Having large groups of miners disagreeing on fundamental protocol aspects sounds like a disaster for bitcoin. Basically, to me, the network of miners IS bitcoin; they provide the power to run the network, and are compensated to do so. If the miners aren't 100% for it, it's just not going to happen.
A limit on the data size of a block isn't the only or even the most efficient way to keep demand for transactions high. The marginal cost of handling the tx size is expected to be much lower than the amortized cost of hashing to secure it, so artificial scarcity in the former to sponsor the latter creates perverse incentives. I favor a structured fee solution that takes into consideration the different costs. A component for storing and broadcasting data (e.g. data size limit); a component for signature verifications (e.g. limit on the number of signatures); and a (much more significant) component for miners' bargaining power in demanding payment for their hashing (e.g. limit on the total amount of bitcoins transferred). Even in case data size limit remains as a rough approximation to encompass all three: Sure, at some point increasing the supply of transaction room will greatly reduce the price and the total revenue. But miners will also understand that if the limit is too low, the usability of the Bitcoin system at large is reduced, which will harm growth and potential total revenues. If a majority cartel of miners decides anyway to reject all blocks with increased size limit, despite this being the new protocol agreed by the economic majority, this is none other than a >50% DoS attack. Whatever tools we come up with to handle that (e.g., moving to a block DAG structure) will apply. |
|
|
|
It's doubtful that anyone will be able to hold the entire blockchain at some point in the future, should Bitcoin become a mainstream thing. Here's some interesting data (from 2006 only for the US) Average daily number of transactions: - 60 Million credit card transactions - 100 Million Interbank ATM transactions - 60 Million ACH transactions - 15 Million SWIFT transactions - 365.000 CHIPS transactions - 521.000 FEDwire transactions - 700.000 CLS transactions So that's a cool 237 Million daily transactions, in the US alone, excluding cash transactions. Let's assume a conservative average of 3 daily cash transactions per person (buying the paper, a hotdog and a pack of smokes). That adds a cool 1000 Million transactions for the US alone right there. Yeah. Better go grab a YottaByte HD real quick. I think it is agreed that most Bitcoin payments won't take place on the blockchain. e.g., with tx replacement you can have one transaction carry multiple payments, and there can be various 3rd party services (I'm using "various" in a mostly positive sense - Bitcoin enables possibilities with good tradeoffs, better than the current banking system) . So 1B daily payments doesn't mean 1B daily transactions. The more transactions can actually make it to the blockchain, the lesser the overall "tax" (in the broadest sense) of using additional layers. |
|
|
|
Why is that BitcoinTalk is the last to get wind of this? Not meant as a diss, but am curious.
I wondered the same. I heard about it on Reddit. 12 hours later, still nothing on the forum. 10 more and still nothing official. This really puts into question the forum's status as the go-to place for staying in the loop. Maybe TBF is just taking the time to troll-proof their announcement  . |
|
|
|
There are many reasons someone would want to edit their post, I don't think editing a post should automatically disqualify it. Making your internal records of who did what (with quotes or whatever) is more reliable. It has been suggested that the blockchain could be used as a timestamping service for arbitrary data, people could timestamp a hash of their play. But the infrastructure for that is not yet fully developed. On the default theme, if they edit their post after a few minutes have passed since it was posted, a dotted line will appear under the time of their post that can be hovered over for more information. I'll edit this post in a few minutes to show you.
Edit: Now edited.
Wow, I didn't know this. |
|
|
|
To my surprise, I didn't find any mention of this on the forum so I thought I'd post about it until an official thread comes along. The Bitcoin Foundation is organizing a Conference in San Jose, California on May 17-19 2013, titled "Bitcoin 2013: The Future of Payments". http://www.bitcoin2013.com/ |
|
|
|
I hear that there used to be some sort of online exchange for these Magic the Gathering cards, but the platform ended up being used to trade something else... not sure what exactly.
You heard wrong. The domain mtgox.com was registered with the intention to use it for a M:tG exchange, but it never was. |
|
|
|
I cannot run Bitcoin-qt during the day because I'm on a tethered 3g connection and do actually need to use most of the available 5-150kbps of bandwidth during the day. The absolute maximum long term average bandwidth pulling the blockchain can take is about 13.3kbit/sec. I'm not sure what the source of your issues is— it may be due to bandwidth used relaying blocks and transactions to other peers, but you do have enough bandwidth to stay synchronized— at least to within a couple blocks of most current. Claims like "I am afraid that any remedy will only push out your timeline running a full node a few months or a year. " are just factually untrue on the data that you've provided. And, if the "business of running a full node, (...) become(s) as serious as it is now to be a mining pool operator" then bitcoin will be dead and pointless, because running a full node has no _business case_ as it can't be directly monetized and there is always an incentive to let someone else take the cost if the cost is great enough to not be inconsequential. If fairly few parties run Bitcoin, then Bitcoin would fail at its purpose of requiring less trust than the commercial banks of democratic nations, as their trust model is stronger. Fortunately, the design of the Bitcoin actually prohibits this loss of decentralization from happening— Blocks have a maximum size (and the size of blocks nodes will create is further artificially constrained by current implementations), and this bounds the cost of running a full node. This size can not be increased without a hardfork of identical technical complexity to changing the supply of coins— so to pull it off it would have to be utterly uncontroversial, and presumably people will always stand up to insist Bitcoin remain practically decenteralized. The maximum cost is still a bit high relative to current hardware, but it won't be in a couple years with a few more cranks of the silicon and storage scaling laws. That said, for a mobile connection— a thin or lite client is the obvious thing to use. Ideally, you could run one behind a full node that you have absolute trust over (E.g. because you own it), and then you don't even need to worry about the potentially reduced trust model involved. But it would still be interesting to figure out why your node isn't keeping up. Yes, increasing the block size limit has identical technical complexity to changing the supply of coins - that is, no complexity at all. Changing the supply of coins has economic/social complexity - people signed up to Bitcoin on the premise that the value of bitcoins are maintained by their scarcity, with a specific inflation schedule. Changing that will destroy the Schelling point and nobody will agree to it. On the other hand, nobody signed up to Bitcoin on the premise of a specific block size limit, so when it becomes necessary the change will be uncontroversial and fairly easy (change the client to have increased size limit starting from block 270,000, giving everyone half a year to upgrade). If Bitcoin is ubiquitous there will be about 10K Bitcoin payments per second. A block size limit of 1MB will allow about 1 transaction per second. This means that 99.99% of payments will be outside the blockchain. So you will have this beautiful decentralized system that everyone can run but nobody can use, they will have to resort to 3rd party alternatives with various trust requirements. There will still be some benefit from having Bitcoin as the foundation, but that diminishes the more expensive it is to actually do a real Bitcoin transaction. It's more likely the block limit will be raised eventually to about 100 MB. People won't be able to run a full node on their cellphones, but any enthusiast will still be able to do it on a PC, and it will allow for 1% of payments to take place on the blockchain. It's still sufficiently decentralized and is now also useful. |
|
|
|
Meni , OK in my wallet I have received the payment from 237bed462683b6b49a7d59b9010bc92e3285a3a8373fced4e16d74e282ed2491 however it still says 0 of 6 confirmations. I looked on the link and my wallet address is in there marked and happy why would my wallet say 0 confirmations? Also the 0.000003 test payment you sent is in there but again 0 confirmations I have transactions after that one that have been confirmed. Any ideas? Naelr It's not just you, these transactions are indeed unconfirmed. It happens that txs take a while to make it into a block, and the fact that these txs are large and low-priority doesn't help. It should be resolved within a few days, if not I will contact blockchain.info support (it was sent from a My Wallet). Update: Seems to be ok now. |
|
|
|
I'm interested in how many BTC were in existence when the price jumped to $30? was it comparative to LTC at the moment?
About 6.5 million. I think the current number of Litecoins is about twice that. |
|
|
|
See Ultimate blockchain compression w/ trust-free lite nodes. It was never intended for every user to run a full node. I haven't followed up on the details of the above suggestion but AFAIK it's viable and, once implemented, allow using an SPV client without need for trust. Also, while people in your situation shouldn't be neglected, I don't think it's the norm. I think enthusiasts will be able to run full nodes for quite a while. |
|
|
|
|
Show Posts
