|
Then less miners will mine, difficulty will drop and the remaining miners will make higher profit or more likely the exchange rate will rise and the network will be larger despite the value per block being lower. The point I was trying to make is exactly what you described a miner's costs are in USD so the nominal BTC value of a block is partially offset by a rising exchange rate. The nominal value of BTC block is likely to perpetually decline for decades to come. Fees will go up but not as much as the subsidy declines so the average BTC per block is probably going to be lower 5 years from now, 10 years from now, 20 years from now. However if the exchange rate rises then a smaller block reward can still support a larger network.
As an example today annually miners collect ~$1B in mining revenue (25.5 BTC * 6 * 24 * 365 * $700)
That is based on 25 BTC subsidy and 0.5 BTC in fees or 25.5 BTC total. In three years the block subsidy will decline to 12.5 BTC and lets assume that quadruples between now and then. So we are looking at 12.5 BTC in subsidy + 2.0 BTC in fees or 14.5 BTC total. So a decline from 25.5 BTC to 14.5 BTC.
Does that mean the network will get smaller? Probably not if Bitcoin is more popular. The exchange rate would only need to rise 25.5/14.5 = 75% to $1,230 USD per BTC for miners (collectively) to make the exact same ~$1B in annual revenue they do now. That is just with a 75% rise in 3 years. If it is more than 75% then the network will probably be bigger than it is now despite the block reward being lower (much like the network is 700 million times larger now then when the block reward was 50 BTC).
|
|
|
|
BTC Guild has been using a max size of 500KB and min size of 150KB for months (the only gap being when we had the 0.8 hardfork event and had to wait a few months to give everybody time to upgrade before allowing another potential hardfork block due to the bug in 0.7 and earlier versions).
Orphans are a concern for all pools, but my experience has shown that these sizes did not materially affect orphan rates, and actually reduced stale shares for users. The minimum size helped our nodes clear out the memory pool faster, which is the biggest slowdown when a new block is found and bitcoind recalculates the priority of everything in the memory pool to build it's new blocks.
Great. Thanks for the quote. I am going to try and see if we can get similar info from other pools. If we know what pools are doing then users and merchants can make more intelligent decisions. Also 150KB for free txs per block? Awesome that is pretty generous. Looking through the memory pool a significant portion of the "really delayed" (>1 hour) paying transactions are ones that have unconfirmed inputs. "child pays parent" patch can't come soon enough. |
|
|
|
Pools have an incentive to keep their blocks small so that they propagate fast, reducing their chance of being orphaned. There is certainly no incentive to include free transactions, and low-fee transaction are probably also a negative prospect. eg. adding an extra 500KB to a block for 0.1BTC might not be worth it : it adds 0.4% more returns to the 25BTC base reward, but if that means 3 seconds extra propagation time then it adds a 0.5% extra chance of being orphaned, so it would not be worth doing.
I've just made these numbers up based on my own assumptions of transaction size and propagation times, but hopefully you see the point. Maybe it's the case that some pools have recently done the math and tweaked their thresholds to optimise their returns.
Well if a pool was looking to maximize the short term revenue, block with the highest possible net revenue is one with no transactions (other than the coinbase). A miner would simply mine only empty blocks and ignore all transactions even paying ones. The best estimate (with current protocol) is that the orphan cost is about 3.3 mBTC per kB. Paying tx are ~0.1 mBTC so the inclusion of any tx is a net loss of revenue. That being said hopefully miners and pool ops realize that having a lot of coins doesn't do you much if you cripple the growth of Bitcoin. 2% less coins which are each worth 10x as much because you helped grow the adoption of Bitcoins is a pretty good deal. One thing Gavin pointed out, is that if all miners have higher orphan rates they don't lose any revenue. What matters is RELATIVE orphan rates. If you have an orphan rate of 2% and the network on average has an orphan rate of 1% then you are losing 1% revenue. However if you have an orphan rate of 5% and the network on average also has an orphan rate of 5% you aren't losing anything. 5% of your blocks are orphaned but so are everyone elses and as a result the difficulty is 5% lower. The big miners should sit down and discuss mutually raising block sizes. Even if you can't get everyone onboard the orphan costs can be reduced if miners agree to all raise block sizes. Getting 50%, 60%, 70% of hashpower in agreement should seem possible as honestly that is just what getting the top 6 or 7 pools and major solo miners to find common ground? Longer term a more efficient method of block propagation is possible which should reduce that orphan cost. Today when a block is broadcast it all the tx inside the block are also broadcast as part of the block message. Most nodes already have these txs so it is just wasted bandwidth. One could instead include just the tx hash in the block message and that would cut the size of a block message by up to 80%. For larger savings a reduced length hash could be used instead. Collisions here are not a security risk and would still be incredibly rare and that would allow reducing the block message size (and thus propagation delay) by 95% or more. Still don't want to be all doom & gloom, even if nothing is done over time Moore's law will mean higher bandwidth at lower costs which will reduce the propagation delay. Also the block subsidy being cut in half again in ~3 years will reduce the "distortion" that the large subsidy has no fee pricing. |
|
|
|
Why does bitaddress.org use uncompressed pubkeys for paper wallets? Is there a reason or is it just an oversight? At this point all services should be encouraging the use of compressed pubkeys and support for uncompressed pubkeys should just be for backwards compatibility. Can anyone think of a reason other than just it being an oversight for generating new paper wallets with uncompressed pubkeys? As an example, Bitaddress > PaperWallet > Generate Private Key:
5JgfcLRNEASqdrLKktL8Ygcftj9S7DTvSFYnMUtdd5Bmn8G9oYz
Address:
1Lux7wJ4cyoVqG3N3oWuitYmGpxZaK8nM3
Using the private key 5jgf... produces the following PubKeys (compressed & Uncompressed): 0x02 4649935EA7EB7A0B39021F07B41F20E12324CF2329569117157536C2A416FDA70x04 4649935EA7EB7A0B39021F07B41F20E12324CF2329569117157536C2A416FDA7971262798AFAB30BC060C03540E5E7451170256C4DC77C4C0CF7F3A1FAD75FF6 Addresses: 1F2NCcW4LCe7FebbqL89NpZKZ6gPNEDWzT (from the compressed PubKey) 1Lux7wJ4cyoVqG3N3oWuitYmGpxZaK8nM3 (from the uncompressed PubKey) Note that the bitaddress paper wallet option outputs the 1Lux address. Why waste blockchain space? |
|
|
|
dont worry about 2140. worry about 2017, when the reward halves. consider the current calculations for ROI on mining tools, i don't see the increases in efficiency of mining making it that far. the reductions in die size of ASIC's are not going to keep step reducing power, manufacturing and support costs of running miners. the value of Bitcoin has to rise substantially to cover this shortfall. maybe it will, but that an increasingly risky proposition without a fundemental upsurge in use of bitcoin for trade, rather than speculation or paying for mining equipment.
Well the good news is that difficulty adjusts. We saw it lots of times in the GPU era. If the value of block in USD falls (either because exchange rate radically collapses or due to the subsidy being cut) then the margins for miners will be squeezed. The most marginal miners (least efficient rigs and higher electrical cost) will be forced into a negative operating margin ($1 in electricity to produce <$1 in BTC) and idle their rigs. When they do difficulty will fall and the margins will improve for the remaining miners. |
|
|
|
How do you guys know that transaction fees will be enough? Right now it's less than 1% per block. I don't see how the income from fees could increase at least 100-fold. If we increase the base fee per transaction, then Bitcoin becomes even less suitable for microtransactions, and just becomes too expensive in general. If we don't then as block rewards drop with time, you'll see less and less miners, which means the difficulty will drop, which endangers the security of the network.
If Bitcoin goes up in value (USD:BTC) by 10x and the BTC subsidy gets cut in half you would expect less miners? Hint: In 2009 the block subsidy was 50 BTC and the network difficulty was ~1. In 2014 the block subsidy was 25 BTC and the network difficulty was ~700,000,000. By your logic shouldn't difficulty be <1 right now? If you are thinking tx fees need to rise to 50 BTC per block well no, that is never going to happen. It also doesn't need to happen. |
|
|
|
I sorta understand the concept of mining. But how exactly do miners mine for transaction fees? I don't quite understand who GETS these fees, why they get them, etc.
Users include fees (normally 0.1 mBTC) when creating txs. It is possible to send some tx without a fee but lately free tx confirmation times have been long. When miners include txs into a block they collect all the fees from the tx they include and also collect the block subsidy (which was initially 50 BTC and is now 25 BTC). |
|
|
|
|
Blocks are nowhere close to full. The 1MB limit is ~4 to ~6 tps that is 340,000 to 520,000 transactions a day. We are barely 20% of the way there.
Tx fee is 0.1 mBTC per kB that is $0.05 USD at current exchange rates. The dust limit is roughly half that or 2.5 cents. For $1 to be dust would require the exchange rate to up by a factor of 40x to say ~$20,000 USD per BTC and the min mandatory fee to not be lowered. Dust it not hard coded it is set at 54.3% of the min fee to relay.
|
|
|
|
|
Well it is a theory. A dubious one best on wishes and hopes but it is a theory. Read again, BTC miners aren't being greedy it just doesn't make sense to radically expand block sizes. Average fees on paying Bitcoin txs have actually gone down over the last two years. The issue is the large number of free tx and a reluctance on miners to expand block sizes especially for free tx only to have them lose money to higher orphan rates.
Miners actually have very little pricing power. If one miner won't accept a paying tx then another one will and the first just makes less money. With pools it means the first pool is less profitable and miners switch to pools which accept more paying txs.
|
|
|
|
|
And the LTC miners won't be greedy?
It actually isn't greed on the part of BTC miners. The orphan cost for a BTC miner is 3.3 mBTC per kB of block size. Most tx pay less than that. Miners are reluctant to make significantly larger blocks because it means they actually lose money. If you get 0.1 mBTC per kB of block size and lose 3.3 mBTC per kB of block size due to increased orphans it doesn't make much sense to increase the block size.
LTC has the exact same economics. It just so happens right now it is used for absolutely nothing and thus blocks have a negligible amount of txs. If its tx volume grew it would be looking at the exact same outcome.
|
|
|
|
|
You kinda just imagined up a non answer to fit your always stated conclusion.
It has to stick to large tx or it will become to unuseable? too expensive?
Why would including smaller tx make it unuseable? Why would incuding more transaction and thus having a lower cost per tx make it more expensive?
|
|
|
|
|
I wouldn't change all that on the command line at once at startup.
Start bitcoind.
If you are using windows open a NEW command prompt window and type
bitcoind settxfee 0.0001
To verify type:
bitcoind getinfo
To send a tx type:
bitcoind sendtoaddress
The tx fee is per kB and the size is rounded up to the next full kB If your tx is 5 kB it will be 5 x 0.1 mBTC = 0.5 mBTC.
Most tx are 1 kB but if you have a lot of low value inputs (i.e. spending 50x 0.00001 BTC outputs vs spending 1x 0.005 BTC output) then the tx can be much larger is size. Size not value is what matters.
Also if the tx is low priority, has outputs less than 0.01 BTC or is larger than 10KB you have no choice but to pay the min mandatory fee of 0.1 mBTC per kB. This is a spam prevention mechanism.
|
|
|
|
But in the future things could and would change quickly as the number of transactions grows, the fee has to be raised to make it to the top of the list. So my expectations for the next 1-2 years are that LTC will take the niche of micro-payments, whereas BTC will grow into a more heavy-weight category.
Why would LTC take the niche of micro-payments? The EXACT same economics of orphan rates vs block size apply to LTC. It would be any lower cost for miners to make large LTC blocks as they do for BTC blocks. In theory one could design a micro tx with the stated goal of having a low processing cost and designed around micro transactions. Nobody has done it, but it could be done. LTC is no better suited for micro transactions than BTC is. |
|
|
|
I have always wondered about this:
Would it be possible in step 4b) instead of modifying the header do the following
Add some more transactions to the block that have come in since the last header creation
Do the step needed now that the new transactions are in the block
Zero the nonce
Continue
Or is that too much work?
It seems that they may be able to pick up some good paying transactions into the block "on the fly" that way and the new transactions will modify the header for the new nonce cycle.
Technically 4b can be completed by changing the tx set. Essentially you just need to make any change to the blockheader and changing the tx set works for that. It probably doesn't make sense to do it on each new transaction and there are methods for pool workers to make a change locally (like incrementing the timestamp) which saves a round trip to the server but any change to the blockheader (including changing the tx set works). Pools are highly customized but I would assume they strive for a balance between reacting to changes in the memory pool and having miners make timestamp changes locally to reduce server load. Computing a new tx set may seem like a lot of work but the tx are already validated before they are in the memory pool so you are just looking at 2x the # of transactions in SHA-2 hashes. Even for a large block a single CPU core can do that in a millisecond (or less). |
|
|
|
Recently BTC transaction fee that guarantees normal confirmation time has been around 0.0005, which is roughly $0.30 at current price. So, litecoin fee is already lower than the practical BTC fee.
Nonsense. Take a look at a recent block count the number of tx which pay 0.5 mBTC per kB. While there might be one or two out of hundreds of thousands of txs it is utter fud to say 0.5mBTC is needed. The min fee of 0.1mBTC is sufficient. Tx which don't confirm usually have other issues (like having dust outputs, unconfirmed inputs, no fee, fee below the 0.1mBTC threshold, etc). As an example here is a recent large block. It was mined by Eligus which does not include any free tx. It is 608kB and contains 677 transactions https://blockchain.info/block-index/441261/00000000000000036af9c03ac779286f3f8ce922b9aa1f8c2c51909c1d89cc67~2% of tx contain a fee of less than 0.1 mBTC per kB ~82% of tx contain a fee between 0.1 mBTC and 0.11 mBTC per kB ~2% of tx contain a fee between 0.12 and 0.19 mBTC per kB ~5% of tx contain a fee between 0.2 and 0.49 mBTC per kB ~0% of tx contain a fee of 0.5 mBTC per kB or more (there are 3 of the 677 tx) may not add up to 100% due to rounding. Bitcoin is ill suited for micro transactions and it is still cheaper (~$0.05 per kB) than LTC now (~$0.16 per kB) and after the fee reduction (~$0.08 per kB) |
|
|
|
If a block gets orphaned, it means another viable block was added to the chain while the miner was adding transactions to the orphan block, right? Does that mean the miner doesn't get neither the 25 coins nor the transaction fees? If so, what's the point of adding bigger transaction fees as a safeguard against having the block orphaned?
Miners don't add tx to a block after they find one. Simplified mining process 1) Miners select tx from the memory pool for inclusion in a new block (the number, method, and criteria is up to the miner) 2) Miners construct a merkle tree from the tx in step #1 3) Miners create a block header with the merkle tree, prior block hash, version, timestamp, and nonce 4) Miner will hash the blockheader. If it is a solution go to step 5. 4a) Miner will increment nonce and go to step 4. If nonce range is exhausted go to step 4b 4b) Miner will modify another element in blockheader, reset nonce range back to 0 and go to step 4 5) Miner has found a block. They broadcast it to peers. So once a miner finds a block they are done. All the work for deciding tx comes BEFORE solving a block. |
|
|
|
Selfish mining wouldn't change the number of tx confirmed.
I agree, but I think that it could still push up the average time to confirm. Transactions that were not yet available when the selfish pool found a block solution cannot be added to that block, but would likely be found in the public block. Then if the selfish pool releases their hidden block, any transactions that made it into the public block but not the selfish block would have to re-enter the transaction queue. But then there would be a delay, as most miners that accepted the public block would have already removed those transactions from their queues, and can't replace them until after that particular mining node had already discarded the public block as an orphan. What we are seeing here could be a side effect of selfish mining put into practice. Gotcha. That is an interesting angle. I don't think that is the case but it might be a good way to design a "selfish miner" warning system. The average doesn't tell the whole story but a distribution would. If the move from ~10 minutes to ~18 minutes is due to selfish miner what we should see is a reduction in the 0-10 minute times and an increase in the longer but relatively short times say 11-30 minutes. My guess (and just a guess at this point) is that isn't what the distribution would look like. What I think is we have a minority of very very old tx which bring up the average so it would look something like 90% of tx have a confirmation time in the 0-30 minute range and then you have and increased amount of tx in the long tail with confirmation times ranging from 31 to 1000 minutes. |
|
|
|
|
BFL was up to 11 months late on delivering hardware. Many customers who thought they would make a fortune ended up making a tiny fraction. Rerun your numbers and assume you get the card in June. Now run them again and assume you get the card in Jan 2015. That is the risk you are looking at.
|
|
|
|
|
Show Posts
