I'm hoping silver hits $27.34 soon. I've had my eye on a particular purchase for a while now, and now that it is on sale for 25% off (not really, I know, but still), I'm just waiting for a couple bucks lower to hit the next big round number.
lets see; 29.84/49.82=.5989 OR 41% off? It only makes sense to take the absolute peak as the baseline for calculating the discount if you either made the decision to buy at that moment, or if that was when the opportunity first presented. Neither is correct, but silver has been hovering near $40/oz for several months now, and it is down roughly 25% from there to the vicinity of $30/oz. |
|
|
|
|
I'm hoping silver hits $27.34 soon. I've had my eye on a particular purchase for a while now, and now that it is on sale for 25% off (not really, I know, but still), I'm just waiting for a couple bucks lower to hit the next big round number.
|
|
|
|
That assuming SHA256 is a perfect hashing algorithm. Besides the coin destruction problem still exists.
No hashing system is perfect, but we keep getting better at it. MD5 was pretty good. SHA is much better. And even if the distribution of outputs from SHA256 is only a tenth as good as perfect (which we totally would have noticed by now, but whatever), that just means that the next collision will happen in a mere 100 million years rather than a billion years (as per my totally exaggerated example from before). Coin destruction certainly exists, but it isn't a problem. So far, no one but you seems to have taken any offense to it. Why do you think it is a problem? In that case, you probably don't really understand what scripts are or what they do. In my opinion, they are the most important feature of bitcoin for the long run.
Please explain what could be done in a script than couldn't be done if each client had a set of known methods to sign a transaction and a simple varint was included in a transaction to identify which method to use. At the moment scripts add a large amount of size to the block chain for little purpose. Peter gave the big picture. Let me give an example of a specific scenario that can be done with the scripting system, but not with simple signatures. You want to protect your wallet. You use a secure offline computer to generate a bunch of keys and print them out for safekeeping in a bank box. You also sign up with an online service that gives you a series of keys (or just one key, or a seed to generate a sequence yourself, whatever). You create another set of keys yourself, and then combine them with a script that can be satisfied under the conditions (A and B) or C, where C is one of the keys in your safe, A is one of the keys from the service, and B is just an ordinary key. In that way, whenever you want to spend coins, you sign it with your B key and forward it to your online service. The service consults a set of policy rules associated with your account and sends a SMS to your phone asking for verification. You reply to the SMS, and the service signs the transaction with their A key, and broadcasts it to the network. Since the transaction has both A and B keys, the script can be completed, and the transaction will spend as usual. Someone that gets access to your computer can't spend your money unless they can also get the key from the service. Also, someone that gets access to the service can't spend your money unless they can also get your keys. If the service is attacked and you lose faith in it, or if they shut down, or if you lose your B keys, you go to the vault and pick up your stack of paper, so that you can transfer your funds to a new safe location by using just the C keys that you printed earlier. All of this can be done using the scripting system, and without anyone in the entire network having to update their client to allow it specifically. Do you understand the value now? |
|
|
|
The "bug" you described is a collision in SHA256(SHA256(x)). If such a thing can be made, we have much bigger problems than someone overwriting a coinbase with a transaction.
It could be a collision with any previous transaction hash, so the odds are increased the bigger the chain grows. I still think it's better not to leave things to chance, when it can be patched fairly easily. In general, we expect a collision in the hash output once every 2 128 hashes. That is 3.4*10 38. That means that 100 billion people, each generating 100 billion hashes per second for 1 billion years will generate on average one collision. Miners (or anyone) can also destroy coins irredeemably by sending generated coins to "OP_FALSE" or to any other script that can never return true.
This is a design flaw which can't be fixed, the other issue can be. I must admit it seems to me like scripts create a lot more problems than they solve. In that case, you probably don't really understand what scripts are or what they do. In my opinion, they are the most important feature of bitcoin for the long run. |
|
|
|
There is no way you can be a 100% sure that nobody owns the private key of a particular address, so you don't know for certain if they are destroyed or not. There is also the possibility that in future a collision maybe generated and the coins reclaimed. With this this method you can be 100% certain that the coins are destroyed and there is no way they can possibly be reclaimed.
To fix the (rare but not impossible) bug i described either CheckBlock() should allow blocks with no coinbase at all or coinbase transaction hashes must be unique.
The "bug" you described is a collision in SHA256(SHA256(x)). If such a thing can be made, we have much bigger problems than someone overwriting a coinbase with a transaction. |
|
|
|
|
Oh, and there has already been discussion about setting the stock client to reject blocks that don't contain enough transactions known by the node. It was proposed in the context of a miner not including charity (zero fee) transactions, but can easily be extended to deal with this scenario.
As in, if a mining cabal wanted to mess with the system by producing an unending stream of empty blocks while transactions piled up in memory pools, the network could reject the hostile blocks and operate as usual.
|
|
|
|
You are all forgetting the withdraw limits. MtGox and similar have 100BC a day (bitcoin7 has 50BC a day and I think one has 500BC a day). MtGox and most have $1000 a day with $10,000 max a month Let's say you have 20,000 bitcoins that you want to sell right now and you don't care how low the price goes. 1) You make accounts with each trading site. 2) You make a dwolla account and confirm it to your bank account. 3) You transfer in enough coins to make it worth $1000 without going over, which at most prices is 180 coins. 4) Then you sell on each site. 5) Then you withdraw the coins. 6) Then you withdraw dwolla to your bank account. Okay now you got more coins. 7) Change your IP address. This takes 2 minutes.  Repeat step 1. Do step 2 but with a fake name and phone # and a different bank account (keep your real first and last name). Do steps 3-6. 9) Repeat step 7 and 8 about ten more times to get 20,000 coins sold and transferred out. You might run out of bank accounts so you will either have to open new ones or wait till the next day and likely you will just end up waiting. The result is it takes a long time so no one is going to sell 20,000 at once to cash out for use. Why not skip all the trouble and just ask mtgox to increase your limits? |
|
|
|
But the essential point is that traders should not be competing with producers for capital in a single unbiased market. Right?
Not exactly. They will still be competing with producers. But money holders won't have the "insurance for free"/protection against uncertainty/potential profit from uncertainty (or need for trade) privilege they have. Traders will still need cash. Merchants will be paying demurrage costs instead of interest (hopefully the basic interest will drop to zero despite producers and traders are still competing for funding in the financial market) but the final product they sell will be much cheaper because of what we save in concept of capital yields, that are included in the costs of production. Traders will have to know in advance (like investors) what they want their money for before lending. There would be far less gambling and speculation (not all the speculation is arbitrage, much of it is based on rumors, misinformation of other investors and the like). People would think twice before selling their stocks because money wouldn't be a safe heaven. Ok, so traders have the advantage that they can ride out a bad market by cashing out and waiting. They can do this because their ratio of overhead to stock is very low, while producers have a very high ratio of overhead to stock, and really can't. You want to level the playing field by adding artificial overhead for a trader sitting on the sidelines. Just as an aside, your comments about gambling are irrelevant. Regardless of the method used, a trader that doesn't get results will not be able to afford to continue. |
|
|
|
Why would anyone do that ? But it's a good question.
We may discover that the hashing power of BTC drops once inflation slows or ends, and the whole tx fee thing doesn't support enough hashing power to make all us BTC holders feel secure from a 51% attack. Thus to incentivize more mining, we may slow the inflation rate to something small, i dunno maybe 1%/year or so. Would still make BTC a very strong currency, but also keep blocks clipping along. Maybe this is off topic. But why don't they change the block generation from 50 BTC every 10 minutes to 5 BTC every minute? That would cut the tx time and quicken the flow of confirms. I know some of the alt chains tried this. Does it work, and why can't we do this with the mainline client? It is a trade off. If you shorten the cycle time, you gain in one place, but lose in another. 10 minutes seems fairly well balanced, but no choice will make everyone happy. There is more to it than just the confirmation time. |
|
|
|
You are saying that trade and production are competing for the same pool of capital, and that the interest rate in total is higher than it would be for either of them individually. And because of this, society loses out on production that would have been profitable if not for trade.
Your solution is to change the rules so that borrowing money for trade is no longer profitable, so that loans for construction don't have to compete with trade for capital.
Am I right? Is that a good summary of your argument?
Yes, that's kind of what I'm saying. But trade would still be profitable (the merchant will keep "his wage"), with free-money. What happens is that the costs of commerce in concept of interest are eliminated. Wares have storage costs, perish and are by definition a thing its producer doesn't want to hold. So to be exchanged for money (which is cheap to hold, doesn't perish and is like a wildcard) he must "pay the interest". The merchant can't simply sell the products for the costs of production plus his labor, he pays for the liquidity he needs to move wares around. The main point is that capital-money (scarce and everlasting) prevents capital yields from dropping to zero. But the essential point is that traders should not be competing with producers for capital in a single unbiased market. Right? |
|
|
|
|
The current system is based on reducing DOS attacks on the system by making them expensive. The envisioned future system will be market based, with miners competing for transactions by setting their own policies, and spenders competing for miners by setting their own fees.
Setting a target fee level based on recent activity isn't needed for either system, nor for an intermediate step in the evolution from here to there.
|
|
|
|
Hang on a second. Why are interest rates 4% in your model? I know you just made up 4% as a stand-in for X%, but why does X have whatever particular value it has?
The interest does not only depend on growth and potential profits from investments. There's a minimum yield that can be obtained "from the wares". The advantage of money over barter make it be able to profit directly from trade, and that's the source of the basic interest/liquidity premium: http://www.community-exchange.org/docs/Gesell/en/neo/part5/3.htmNo, no links. Make your own arguments. In your own words, what causes the minimum level of interest? Since you can profit from liquidity by "renting it to the people who need it to trade", you won't lend your money unless the borrower gives you at least that same profit in concept of interest. If the products don't include the basic interest in their selling price, they're not sold, because money demands to be payed for the service it provides (it is a convenient tool for trade). Even without innovations and profits, there would still be capital yields and interest. A wrote an islands story about interest here: https://bitcointalk.org/index.php?topic=28497.msg392389#msg392389I can link to my own posts, right? The last time we had this debate, I got lost reading the books you linked, and forgot to get back to the thread. I'm trying to prevent a repeat of that. You are saying that trade and production are competing for the same pool of capital, and that the interest rate in total is higher than it would be for either of them individually. And because of this, society loses out on production that would have been profitable if not for trade. Your solution is to change the rules so that borrowing money for trade is no longer profitable, so that loans for construction don't have to compete with trade for capital. Am I right? Is that a good summary of your argument? |
|
|
|
Hang on a second. Why are interest rates 4% in your model? I know you just made up 4% as a stand-in for X%, but why does X have whatever particular value it has?
The interest does not only depend on growth and potential profits from investments. There's a minimum yield that can be obtained "from the wares". The advantage of money over barter make it be able to profit directly from trade, and that's the source of the basic interest/liquidity premium: http://www.community-exchange.org/docs/Gesell/en/neo/part5/3.htmNo, no links. Make your own arguments. In your own words, what causes the minimum level of interest? |
|
|
|
|
I don't think anyone has ever coded such a thing. There is no reason to.
|
|
|
|
I thought about this. It has the side effect, that one can analyse 256 bit -> 256 bit function SHA256(x) (x: 256 bit) in order to find correlations between input and output bits.
If somebody cared, the amount of computed hash is so big that it should be give some statistical correlations at this time. Who owns this information can take advantage on mining, because after the first x = SHA256(block) calculus, may be she can decide to perform or not the next step SHA256(x) depending on statistical probability to get a share.
We believe no such statistical correlation to exist. |
|
|
|
The market would decide - the bitcoin block chain would fork and you could choose to go with the new fork or stick with the old one. If you have bitcoins you would almost certainly stick with the original one.
I see what you're saying. Seems like a design flaw when you look at future acceptance. With multiple block chains wouldn't every vendor at that time need to then accept 2 or more systems of exchange with different rates? I can see why there would be a fight at that time to leave the system alone but can also see the need to make a decision to change it now while it can have a more limited effect. This is why there won't be multiple chains. And also why we don't have to worry much about the rules changing. |
|
|
|
Why would anyone do that ? But it's a good question.
To be clear, not anyone could do it. Sure they can. They just download the source, edit the function GetBlockValue() in main.cpp, and recompile. And if they only comment out the line that shifts nSubsidy, it'll still work fine for another 60,000 odd blocks. |
|
|
|
1. Government money can be printed and issued as a guaranteed minimum income (GMI).
3. Since governments already provide a limited GMI, obviously most people would still rather support government currencies than use Bitcoin.
Government can print money, but it can't print the things that you buy with money. This is called inflation, and it usually ends with massive bloodshed. |
|
|
|
Oh, btw gold and silver are ON SALE! Perfect time to load up  $1635/Oz right now  Sorry for the stupid question, but why does gold go down in risky times? The same thing happened in Oct 2008 as well. That's really counterintuitive for me. During good times, people use leverage. During bad times, they have to sell whatever they are holding to pay things off. Gold is always pretty liquid, so it is easy to turn it into cash quickly. |
|
|
|
|
Show Posts
