That might be why the limit is 21 millions. Satoshi would expect 1 million coins to get lost, so the remaining coins in circulation would make a nice round number. Just saying.
That's because on average we have 210384 blocks in every 4 years, and rounding up to 210000. |
|
|
|
I forgot but I also sent a coin to a wallet that cant be accessed. The customer sent a address that they couldnt get to. I lost the coin and they charged back. So I have 5 stuck on a hard drive and 1 that I believe cant be recovered.
Well, the 5 on the hard drive can be recovered so we cannot add to the list. The 1, however, can be added. Use the format as designated in the beginning of this thread to add it...! No, "The customer sent a address that they couldnt get to" does not mean no one could get to that address. |
|
|
|
Also, requiring a total reward of 50BTC means requiring 25BTC in fee NOW. As the typical total tx fee in a block is about 0.25BTC, the fee has to increase by 100x and obviously this will kill the system. How and why would the system be "killed"? The max block size would simply not increase. So you propose that the size will only increase but never decrease? Anyway, the major problem is the choice of total reward amount because change in purchasing power is unpredictable. |
|
|
|
Problem is, how do you measure the number of bitcoins transmitted?...This also opens it up to manipulation...So while I think the “fees as % of transfer” is a nice number to work with in theory, in practice it’s not really available. Whoops! You're right of course, and I was expecting at least a hole or two. Here's an alternative: 1) Block size adjustments happen at the same time that network difficulty adjusts (every 210,000 tx?)2) On a block size adjustment, the size either stays the same or is increased by a fixed percentage (say, 10%). This percentage is a baked-in constant requiring a hard fork to change.3) The block size is increased if more than 50% of the blocks in the previous interval have a sum of transaction fees greater than 50BTC minus the block subsidy. The 50BTC constant and the threshold percentage are baked in.Example: A block size adjustment arrives, and the current subsidy is 12.5BTC. The last 210,000 blocks are analyzed, and it is determined that 62% of them have over 37.5BTC in transaction fees. The maximum block size is increased by 10% as a result. Instead of targeting a fixed percentage of fees (1.5% in my original proposal), this targets a fixed block value (measured in BTC). This scheme still creates scarcity while allowing the max block size to grow. One interesting property is that during growth phases, blocks will reward 50BTC regardless of the subsidy. If transaction volume declines, fees will be reduced. Hopefully this will be the result of Bitcoin gaining purchasing power (correlating roughly to the fiat exchange rate). For this reason, the scheme does not allow the block size to shrink, or else the transaction fees might become too large with respect to purchasing power. Another desirable property is that a client can display a reasonable upper limit for the default fee given the size of the desired transaction. It is simply 50BTC divided by the block size in bytes, multiplied by the size of the desired transaction. Someone could mine otherwise empty blocks with enormous looking fees... which, since they mined the block, they get back, costing them nothing. They could then work to expand the block size for whatever nefarious reason. I believe this problem is solved with the new proposal. If someone mines a block with a huge fee, it still counts as just one block. This would be a problem if the miner could produce 50% of the blocks in the interval with that property, but this is equivalent to a 51% attack and therefore irrelevant. The expected behavior of miners and clients is a little harder to analyze than with the fixed fee, can someone help me with a critique? There is no reason to stick the total reward to 50 BTC because you need to consider the purchasing power. Although we only have 25 BTC block reward at this moment, finding a block now will give you >1000x more in USD than a 50 BTC block in 2009. A future miner may be satisfied with 1 BTC block if it is equivalent to US$10000 of today's purchasing power. However, the purchasing power is not mathematically determined and you cannot put it into the formula. Also, requiring a total reward of 50BTC means requiring 25BTC in fee NOW. As the typical total tx fee in a block is about 0.25BTC, the fee has to increase by 100x and obviously this will kill the system. |
|
|
|
Did the 0.01 bot switch direction today?
It seems so. Is it a bearish sign? |
|
|
|
These are the well-known mtgox loss and already included. |
|
|
|
|
1M MAX_BLOCK_SIZE is obviously an arbitrary and temporary limit. Imagine that bitcoin was invented in 1996 instead of 2009, when 99% normal internet users connected though telephone lines with 28.8kb/s, or 3.6kB/s. To transfer a typical block of 200kB today, it would take more than 1 minute and the system would fail due to very high stale rate and many branches in the chain. If the "1996 Satoshi" used a 25kB MAX_BLOCK_SIZE, are we still going to stick with it till the end of bitcoin?
|
|
|
|
|
Update:
1. 2011-06-09 W. Avg: 29.58
2. 2011-06-08 W. Avg: 27.25
3. 2011-06-10 W. Avg: 24.67
4. 2013-02-06 W. Avg: 21.09
5. 2013-02-01 W. Avg: 20.73
6. 2013-01-31 W. Avg: 20.58
7. 2013-02-05 W. Avg: 20.57
8. 2013-02-04 W. Avg: 20.42
9. 2013-02-03 W. Avg: 20.26
10. 2011-06-13 W. Avg: 20.11
11. 2011-06-07 W. Avg: 19.90
12. 2011-06-15 W. Avg: 19.68
13. 2013-01-30 W. Avg: 19.48
14. 2013-02-02 W. Avg: 19.47
15. 2011-06-14 W. Avg: 19.25
16. 2013-01-29 W. Avg: 19.17
17. 2011-06-16 W. Avg: 18.86
18. 2011-06-06 W. Avg: 18.46
19. 2013-01-28 W. Avg: 18.34
20. 2011-06-19 W. Avg: 17.77
|
|
|
|
Why don't we just let miners to decide the optimal block size?
If a miner is generating an 1-GB block and it is just too big for other miners, other miners may simply drop it. It will just stop anyone from generating 1-GB blocks because that will become orphans anyway. An equilibrium will be reached and the block space is still scarce.
I think this is exactly the right thing to do. There is still the question of what the default behavior should be. Here is a proposal: Ignore blocks that take your node longer than N seconds to verify. I'd propose that N be: 60 seconds if you are catching up with the blockchain. 5 seconds if you are all caught-up. But allow miners/merchants/users to easily change those defaults. Rationale: we should use time-to-verify as the metric, because everything revolves around the 10-minutes-per-block constant. Time-to-verify has the nice property of scaling as hardware gets more powerful. Miners will want to create blocks that take a reasonable amount of time to propagate through the network and verify, and will have to weigh "add more transactions to blocks" versus "if I add too many, my block will be ignored by more than half the network." Time-to-verify also has the nice property of incentivizing miners to broadcast transactions instead of 'hoarding' them, because transactions that are broadcast before they are in a block make the block faster to verify (because of the signature cache). That is good for lots of reasons (early detection of potential double-spends and spreading out the verification work over time so there isn't a blizzard of CPU work that needs to be done every time a block is found, for example). And if there are too many transactions than the available block space, people will pay more transaction fee and miner will have more money to upgrade their hardware and network for bigger block size. |
|
|
|
If you think that the first bubble and the chart aren't "even remotely similar", than you are obviously blind, delusional, or just lying to yourself. Its that lack of awareness that's going to leave you holding the bag by buying at the top of this bubble, just like those fools that bought at $32.
It's just like a fractal. The pattern will repeat itself in different scale. In short-term (1-2 year), the first bubble was a full cycle. In medium-term (3-5 year), it was just a bear trap. In long-term (6-10 year), it was just a glitch in the take off period. |
|
|
|
I know the 1MB is a hard limit which affects both miners and clients. I'm assuming a world without MAX_BLOCK_SIZE at all, both miners and clients.
Miners can ALWAYS drop a valid block if they don't like it, just like ignoring any valid transaction. Currently, miners taking non-standard transaction has higher risks of orphaned block because other miners may not like these block.
If a miner (Bob) sees a new valid block with height N but doesn't like it for whatever reason, he will simply keep mining on top of block N-1. When Bob finds another valid block (N2), he will broadcast to the network and other miners will choose one between N and N2. Here Bob takes a risk of being orphaned because other miners may build on block N. If block N+1 is built on N, Bob has to reconsider the risk and he may decide to keep mining on N+1, instead of N-1 or his N2. However, if Bob (or his team) owns 51% of the network, he will always win and block N must be eventually orphaned. (You may call it a 51% attack but this is exactly how the system works)
Therefore, if the majority of miners do not like 1GB block, building 1GB block will become very risky and no one will do so.
What you are describing is much worse than a mere fork, the only word I can think of for it is a shatter. This is actually happening and forces some miners to drop transactions from Satoshi Dice to keep their blocks slimmer. Ignoring big blocks might not be intentional but big blocks are non-competitive for obvious reason (take longer to propagate) May be I should rephrase it: Therefore, if the majority of miners are unable to handle the 1GB block N timely, they will keep building on N-1 until N is verified. Block N is exposed to a higher risk of orphaning, and building 1GB block will become very risky and no one will do so. |
|
|
|
Why don't we just let miners to decide the optimal block size?
If a miner is generating an 1-GB block and it is just too big for other miners, other miners may simply drop it. It will just stop anyone from generating 1-GB blocks because that will become orphans anyway. An equilibrium will be reached and the block space is still scarce.
Unfortunately it's not that simple for a couple reasons. First, right now clients will reject oversized blocks from miners. Other miners aren't the only ones who need to store the blocks, all full nodes do even if they just want to transact without mining. So what if all the miners are fine with the 1-GB block and none of the clients nodes are? Total mess. Miners are minting coins only other miners recognize, and as far as clients are concerned the network hash rate has just plummeted. Second, right now we have a very clear method for determining the "true" blockchain. It's the valid chain with the most work. "Most work" is easily verified, everyone will agree. "Valid" is also easily tested with unambiguous rules, and everyone will agree. Miners can't "simply drop" blocks they don't like. Maybe if that block is at depth -1 from the current block, sure. But what if someone publishes a 1GB block, then someone else publishes a 1MB block on top of that? Do you ignore both? How far back do you go to start your own chain and try to orphan that whole over-size branch? I think you can see the mess this would create. The bitcoin network needs to operate with nearly unanimous consensus. I know the 1MB is a hard limit which affects both miners and clients. I'm assuming a world without MAX_BLOCK_SIZE at all, both miners and clients. Miners can ALWAYS drop a valid block if they don't like it, just like ignoring any valid transaction. Currently, miners taking non-standard transaction has higher risks of orphaned block because other miners may not like these block. If a miner (Bob) sees a new valid block with height N but doesn't like it for whatever reason, he will simply keep mining on top of block N-1. When Bob finds another valid block (N 2), he will broadcast to the network and other miners will choose one between N and N 2. Here Bob takes a risk of being orphaned because other miners may build on block N. If block N+1 is built on N, Bob has to reconsider the risk and he may decide to keep mining on N+1, instead of N-1 or his N 2. However, if Bob (or his team) owns 51% of the network, he will always win and block N must be eventually orphaned. (You may call it a 51% attack but this is exactly how the system works) Therefore, if the majority of miners do not like 1GB block, building 1GB block will become very risky and no one will do so. |
|
|
|
If space in a block is not a limited resource then miners won't be able to charge for it, mining revenue will drop as the subsidy drops and attacks will become more profitable relative to honest mining. How many business can you name that maximize their profitability by restricting the number of customers they serve? If it really worked like that, then why stop at 1 MB? Limit block sizes to a single transaction and all the miners would be rich beyond measure! That would certainly make things more decentralized because miners all over the world would invest in hardware to collect the massive fee that one lucky person per block will be willing to pay. Why stop there? I'm going to start a car dealership and decide to only sell 10 cars per year. Because I've made the number of cars I sell a limited resource I'll be able to charge more for them, right? Then I'll open a restaurant called "House of String-Pushing" that only serves regular food but only lets in 3 customers at a time. If car dealerships sold cars for however much you were willing to pay, down to and including free, you can bet they'd limit the number of cars they "sold". And I doubt you'd even get 10 out of them. The problem is that we really don't know yet how to operate with the system we have, much less a different one. In a decade or two, when the subsidy is no longer the dominant part of the block reward, maybe then we'll have some idea how to price transactions, and we will be able to think clearly about mechanisms to adjust the block size. Why don't we just let miners to decide the optimal block size? If a miner is generating an 1-GB block and it is just too big for other miners, other miners may simply drop it. It will just stop anyone from generating 1-GB blocks because that will become orphans anyway. An equilibrium will be reached and the block space is still scarce. |
|
|
|
Could we be seeing the "Bull Trap" now? (jan 2013 dip)  In the very long run, the $32 peak is "first sell off", and the $2 dip is the "bear trap". Many early adoptors left because of the bear trap (e.g. the "Bitcoin will never reach $20 again") . We are stilling recovering from the bear trap, not even have any real media attention |
|
|
|
|
Update:
1. 2011-06-09 W. Avg: 29.58
2. 2011-06-08 W. Avg: 27.25
3. 2011-06-10 W. Avg: 24.67
4. 2013-02-01 W. Avg: 20.73
5. 2013-01-31 W. Avg: 20.58
6. 2011-06-13 W. Avg: 20.11
7. 2011-06-07 W. Avg: 19.90
8. 2011-06-15 W. Avg: 19.68
9. 2013-01-30 W. Avg: 19.48
10. 2013-02-02 W. Avg: 19.47
11. 2011-06-14 W. Avg: 19.25
12. 2013-01-29 W. Avg: 19.17
13. 2011-06-16 W. Avg: 18.86
14. 2011-06-06 W. Avg: 18.46
15. 2013-01-28 W. Avg: 18.34
16. 2011-06-19 W. Avg: 17.77
17. 2013-01-24 W. Avg: 17.75
18. 2013-01-27 W. Avg: 17.65
19. 2011-06-11 W. Avg: 17.61
20. 2011-06-05 W. Avg: 17.32
|
|
|
|
I meant "other than"... It's only misrepresentation of English, may be.
那麼你想講的是non-fiat currency, 不是non-government fiat currency. |
|
|
|
比特币其实不是经典意义上的虚拟货币，而是一种 Non-government Fiat Currency。
似乎你不懂Fiat的意思. Fiat就是政府以其權力所指定的貨幣, 可以在法律下償付任何債項且債主必須接受. 例如A和B協議, 以兩頭豬換一頭牛, A收到牛之後卻交不出豬, 他可以用和兩頭豬等值的Fiat償付債項而B在法律上必須接受. 所以"Non-government Fiat Currency"是自相矛盾的概念. 另外, 現時世界上沒有人會被迫接受bitcoin作為債項償付 |
|
|
|
Actually, that thread outlines the way that future PCs (if not smartphones) could conceivably run a full node (or "almost-full" node) even with no limit / floating limit.
There are many merits to etotheipi's writing but what he proposes massive _increases_ the IO and computational cost of running a full node (or a fully validating but historyless node) over a plain committed UTXO set for validation. The increased node burden is one of the biggest arguments against what he's proposing and I suspect will ultimately doom the proposal. I have seen nothing proposed except moore's law that would permit full validation on "desktop" systems with gigabyte blocks. I just can't see why this artificial limit that was intended as temporary from the start should be accepted as an immutable part of the protocol.
There are plenty of soft limits in bitcoin (like the 500k softlimit for maximum block size). The 1MB limit is not soft. I'm not aware of any evidence to suggest that it was temporary from the start— and absent it I would have not spent a dollar of my time on Bitcoin: without some answer to how the system remains decentralized with enormous blocks and how miners will be paid to provide security without blockspace scarcity or cartelization the whole idea is horribly flawed. I also don't think a network rule should be a suicide pact— my argument for the correctness of making the size limited has nothing to do with the way it always was, but that doesn't excuse being inaccurate about the history. Read my calculation above. With each transaction just paying $0.021 as fee, we have more than enough money to pay miners to handle 4000 transaction per second. |
|
|
|
Cryptographic Escrow Super efficient, escrow agent can't steal funds, almost entirely do-it-yourself when the transaction goes as planned. Possibility of paying for dispute resolution services on an as-needed basis. Software is FREE Anyone can be an agent or a trading partner See it in action right now: https://bitcointalk.org/index.php?topic=135914 - Read thread from start to finish to see how participants learn the system and get comfortable enough with it to use with real bitcoins. They discuss a bet, and I show up in post #23 to explain how my escrow system can help with their bet. They are now using it. Why not simply use 2-of-3 multisig? |
|
|
|
In 10-years, a modern smartphone/computer will be able to run the full processing node if the Max_Block_Size remains 1MB. This is a clear economic benefit for Bitcoin: Decentralized Bitcoin verification. In fact in a few years, virtually every computer will be able to process the entire blockchain without issue thus making Bitcoin extremely unique in the realm of payments.
What is the use of having portable devices act as full nodes if you can't (because of fees) use bitcoin for purchasing anything smaller than a house? As I see it, your argument is not valid. With 1MB blocksize limit, even if Bitcoin remains a relatively small niche currency, the limit will act as a hard constraint on the potential utility of the currency. Of course, once we start hitting the limit, it will hurt Bitcoin's public image so much that it's conceivable so many people will move away from Bitcoin that we get few more years of time to fix the issue. Lets not get ahead of ourselves here. I expect that we will have a multi-layered system the vast majority of the transactions being made off-chain. Additionally; who is to say that one wouldn't want to verify their house transaction with a smart-phone. People completely mis-judge the free-market. If you have to use alt-chains because the fees are so high, well isn't that a success of bitcoin already! By no stage has bitcoin failed then. The argument for larger blocks is VALID for a proticol that isn't Bitcoin. However it is a catch 22, for Bitcoin. It only becomes a problem if Bitcoin is a success. If Bitcoin is a success, by definition it isn't a problem. Setup your own Electrum server with your computer at home and verify your house transaction with a smart-phone through it. Therefore you don't need to trust a third party A smart-phone is never designed to run a bitcoin full-node Moreover, the sentence "It only becomes a problem if Bitcoin is a success. If Bitcoin is a success, by definition it isn't a problem." is self-contradicting |
|
|
|
|
Show Posts
