So, with that in mind, I'd like you to think very carefully about your position. Are you aware of any deflationary episode anywhere in the world at any time during all of recorded history? One that didn't follow closely on the heels of a period of meddling of the sort that Austrians say causes the the effects you are basing your arguments on?
P.S. "Proof" of "Stake" systems don't solve the money supply problem (assuming that there is indeed a money supply problem to begin with). If the devs all got lobotomies and switched bitcoin to POS, and all of the bitcoin users got hooked on crack and followed along with that change, the limit would still cap out a bit short of 21 million.
First, thanks for your response. I appreciate being able to have a rational discussion about this. I am extremely excited about virtual currency and would like to discuss my concerns without being having to combat blind fanboi-ism. I think it's difficult to find an instance of a deflationary episode after 1929, because so much is done (since then) to stop them. It's definitely difficult to find any instance of rampant deflation or inflation that wasn't or couldn't be contributed to an external factor. After all, something always has to start the ball rolling. But we do see them start, and then governments go on money printing sprees to correct them before they get out of hand. You only have to go back to 2007-2009 during the housing bubble burst in the United States to see this. Yes, the most recent US recession was caused by greedy lending and trading schemes that created a price bubble, but the result of this bubble bursting was an influx of personal and corporate debt defaults that caused some banks to close, and virtually all banks to freeze credit. Since the United States money supply is largely generated by debt, this created a deflation in the money supply which is what caused all the problems you can still see signs of today including unemployment, entire industries failing, skyrocketing government debt (to correct the issue), etc. I think your view of the recent bubble/burst is overly simplistic. I hope you don't take it the wrong way when I say that you appear to have swallowed the populist line about greedy bankers hook, line and sinker. That episode was far too complicated to blame on one party (unless that party is government*). Basically everyone in the country was an active participant in that fiasco. It would take a while to sort that whole mess out and identify all of the groups participating, and what they did wrong. The short version is that "greedy lending" takes two: a lender and a borrower. The credit freeze was an overreaction, but a temporary one. No one knew if they were solvent, and no one knew how creditworthy any potential borrowers were. The rules had been on vacation for a long time, and it took a while to adjust when they got back. Lending is once again constrained by the credit demand of creditworthy borrowers, which is a much smaller market than the credit demand of everyone with a pulse. The most important part missing from your description is the malinvestment. During the bubble, the markets were sending the wrong signals to the wrong places. Millions of new houses were built. Everyone and their cat got a real estate license. Home improvement stores sprang from every corner, and the manufacturers of the goods sold in such stores expanded capacity. We ended up with a glut of things that we don't need, and a shortage of things that we do need. We've also made the, erm, "bold" decision to do everything in our power to prevent those malinvestments from clearing. In my opinion, it looks like the deflation was caused by the mess, rather than the other way around. Of course above we're talking about a potential for rampant deflation. One could argue that a small amount of deflation can be just as benign as a small amount of inflation. Of this, I'm not so sure. My hunch would be that hyper-deflation has a more inheritant run-away effect than hyper-inflation. If you like analogies I would hypothesize hyper-inflation is caused by a continual effort from a government to print too much money, or over-value goods and services and thus participate in pushing a hypothetical boulder up a hill. While hyper-deflation would be pushing a boulder down a hill. It doesn't take a whole lot to get it started, and once it's started it's hard to stop. But again, this is just an educated guess. I am not certain, and don't think anyone can be.
Hyper-deflation would probably be horrible. But I can't imagine any realistic way that it could ever happen. So, I guess I'm a Keynesian (I didn't know this). And as a Keynesian, the deflationary nature of bitcoin is worrying. Whether or not this will be an issue, I guess time will tell.
As for POS. What I like about POS is that blocks are generated for saving the currency (as in not spending it). The rate of generation can be controlled at whatever value you like, say 1%. This acts as a built-in Treasury Bill generation to the currency constantly inflating it at a maximum of 1% per year. This pre-defined POS generation rate would also define the prime lending rate, and give the currency room to generate interest for private loans. The community could also agree to raise or lower the POS rate based on economic indicators that would require it. Currently, all implementations of POS try to offset the POS block generation by requiring mandatory transactions fees that become 'destroyed' by the network. But in principle, without these mandatory destroyed transaction fees, POS could guarantee the continual slow growth of a virtual money supply.
The properties you describe don't seem to have anything to do with "stake", assuming that such a thing has meaning. Bitcoin's subsidy decreases to zero because we want it to, not because proof-of-work requires it to. * Government gets special mention for shielding pretty much everyone from individual risk. Since no one had their own skin in the game, they all had incentives to be stupid. In a free market, those that take bad risks end up losing their capital and they have to sit out the next round. |
|
|
|
|
Step 9 is impractical.
If your box is owned already, what's to stop malware from stashing the keys somewhere, waiting for you to reconnect?
With that in mind, this is pretty good, and probably much better than most wallets.
I've been working on an offline wallet generator that I can include in p2pcoin (my bootable p2pool distro). You can burn it to a CD, boot it on a computer with no storage, generate the keys, burn them to CDs, and reboot with fewer opportunities for malware to snoop in on the process.
|
|
|
|
Just create a wallet, send 0.001 BTC to it and wait for anyone to crack it  . I have already put 0.025 BTC in a brainwallet using a variation of my theme a couple of months ago, and it is still safely there. I'll monitor it for a while. Have you read Gavin's stuff on using sentries? Look it up if you haven't. |
|
|
|
|
Yes, probably. Maybe not very soon.
There aren't that many published games. There aren't that many sequences of moves in a game. Your final obfuscation is something that password crackers already check.
|
|
|
|
I'd have to take exception with the following quote: When all 21 million coins are produced, the MoneySupply will be neutral, and the value will continue to increase (prices will decrease, consequently), as long as people continue to exchange in BTC.
I definitely don't want to get into a pissing match with you (like some people seem to be doing in this thread) but perhaps I'd need you to explain this a little better. From what I can reason, when the bitcoin supply stops growing we will have a rampant effective supply deflation due to many factors: - lost/damaged currency - population growth - saving/hoarding Supply deflation also causes other problems which, in themselves, cause more effective supply deflation and price deflation. Ex: - reduction in currency supply causes unemployment, which in turn causes more effective supply deflation - reduction in currency supply causes "effective debt value" to increase which slows credit re-payment and tightens credit availability, which causes hoarding, which causes more effective supply deflation - supply deflation encourages hoarding, over spending, which therefore causes more effective supply deflation - loans with interest go into default since the interest required to repay the loans is never created. This causes an economic downturn and ultimately more deflation. It is for these reasons, and many more, that deflation can quickly become an unstoppable beast, and is therefore a economy's worst nightmare. This is why virtually all central banks across the world try to keep the money supply at a growth rate of 1-3%, and go on T-Bill printing sprees whenever a hint of deflation is detected. And since most fiat currency is generated through credit, this is why a credit freeze is so detrimental to the world economy. Because of population growth, lost currency, and people's desire to save, you can never have a "neutral" money supply. You will always have either inflation, or deflation, and due to deflation's exponential run-away nature it is considered the lesser of two evils to keep a well controlled, very low, supply inflation rate. Furthermore, a low level of inflation determines acceptable interest rates which aid in economic growth and wealth re-distribution. There is also a human psychological element. Supply deflation, or even stagnation, requires continual lowering of prices and wages in the face of economic growth. People typically are more resistant to a reduction in wages and revenues, versus increases. This is the biggest problem I see with bitcoin, and why I favor altcoins that solve this issue with proof-of-stake (like Peercoin). I also see problems with a mining incentive relying entirely on transaction fees. Transaction fees will be completely controlled by "purchasing power" of sorts. The entities capable of providing the lowest transactions fees will invariably be the largest (in terms of infrastructure). This will naturally create transaction titans, and likely a monopoly by cartel, which is the worst thing that can happen for the bitcoin network. Thankfully proof-of-stake solves both of these problems, so I think virtual currency has a future, but I don't believe that future is secured in BTC. Thoughts? Everything you said has been said around here plenty of times. It is kinda the core of Keynesianism, and I promise you that the our problem is not lack of familiarity with his work*. The problem you run into is that you are asserting your conclusion. You are stating a bunch of things as if they were established facts, when they are not. The great depression is generally cited as the evidence to back up your position, but the people that make those claims take a peculiar view of history. They tend to skip over the decades of malinvestment and manipulation that caused the great depression, and pretend that the deflation fairy sprinkled some deflation around, causing the whole mess. A few economists will give the problems from ~1865 to ~1929 a token mention, or call them the instigating factor, but then forget all about them and carry on finding the conclusion they wanted to begin with.** In much the same way, the analyses of that period tend to either ignore or gloss over the insanity pushed by the central banks and the governments. Modern economic theory is that all problems are caused by a lack of meddling. If the people that know better than you can't or don't meddle in the markets, we have a crash. And when we have a crash anyway, the problem is always that they didn't meddle enough. So, with that in mind, I'd like you to think very carefully about your position. Are you aware of any deflationary episode anywhere in the world at any time during all of recorded history? One that didn't follow closely on the heels of a period of meddling of the sort that Austrians say causes the the effects you are basing your arguments on? P.S. "Proof" of "Stake" systems don't solve the money supply problem (assuming that there is indeed a money supply problem to begin with). If the devs all got lobotomies and switched bitcoin to POS, and all of the bitcoin users got hooked on crack and followed along with that change, the limit would still cap out a bit short of 21 million. * And by "his work", I don't just mean his work, but the work of the branch of economics voodoo that bears his name.** At the cost of a few hundred million dead, much of the world has learned, finally, not to give a bunch of power to people just because they say they want it. Now we ask them to come up with good excuses first. "Proving" that giving them power is scientifically necessary is a good way to stay in the club and get your bills paid. |
|
|
|
|
I couldn't figure out what the hell you were asking either.
|
|
|
|
|
It would be pretty easy.
We'd need to bump the version field in the transaction to 2 and extend the width of the value field of each txout (probably to 128 bits).
But, this would be a hard forking change. We haven't established a protocol for hard forking changes the way we have for soft forking. Quite likely, it would be similar, but with a longer support assurance phase, a higher threshold, and a long lag between hitting the threshold and the actual switch.
The hardest part would probably be deciding on the scaling factor for the new width.
|
|
|
|
|
That particular RPC client always claims that it can't access the RPC when it has an error. It is essentially the only error it knows.
You should be calling it from a try/catch block so that you can handle the exception yourself.
P.S. Change your RPC password. If you just noticed this now, it is in your logs dozens or hundreds of times.
P.P.S. It is trivial to patch the bitcoind verifymessage RPC call to return the pubkey of the signature rather than true/false. This patch will never be accepted into the main client because it is unsafe for human use, but it works great for a machine comparison/lookup to identify a user.
P.P.P.S. And by trivial, I mean I posted it here in the forums a while back.
|
|
|
|
|
First, there is absolutely no chance in hell that you remember a passphrase with 160 bits of entropy.
Second, why aren't you just using the published HD wallet spec, using your seed?
|
|
|
|
Thank you for your replies.
So, if the Bitcoin Foundation plays no direct role, what about the Core Bitcoin Developers? I hear tidbits about versions.
5. How do these versions of Bitcoin get implemented?
6. Who has to install these versions?
7. What happens to miners or others who do not use these updated versions? Are they shut out of the system?
The developers are developers because people trust them. Anyone can fork the software and people can choose to use their version or not. Please read gmaxwell's post carefully. He answers most of your questions if you pay attention. There are different versions of the core software because it is under development. But there is only one block chain. So far, there have been no changes to the block chain rules that would exclude any previous versions of the software. No users of the system have ever needed to upgrade (I still run a pre-0.4 node for fun). Miners* need to be more careful and should generally be running fairly current versions since it is possible for them to create a block that other miners will refuse to build on. * And by miners, I mean people that use their node to generate new blocks. Most "miners" are really "mining pool users", and the blocks they work on come from pool operators. The pool operators, of course, use their nodes to generate blocks, so they are "miners" in this sense. |
|
|
|
There is a service that uses bitcoin blockchain to prove that certain data exists at a certain moment of time [link removed] . This is done by generating a bitcoin transaction (unspendable) to two specially crafted addresses.
This is a very inefficient and destructive way to perform this tasks. I would not recommend using or promoting this service. I wrote a system that does the same thing, but without spamming the blockchain with unspendable junk. I never released it. If there is some demand for such a service, I can finish it up and put it online. |
|
|
|
However perhaps that last part of my sentence is a bit hasty... I do wonder if it's possible to insert a block anywhere in the chain if a hash collission was found.
I am not sure what kind of protective measures bitcoin has to protect against block insertion.
If these checkpoints are truely based on single blocks then it won't protect against insertions.
Thus a smarter hash would be a hash computed over the entire blockchain.
Such a hash could be included to protect against insertions. However if the attacker can calculate a hash collission then this would only double his calculation efforts.
However the point is: the more checkpoints, the better.
I think the solution to make it a little bit more secure is simply calculate a hash over the entire blockchain every 2016 blocks and store it.
So, you are assuming that an attacker can find one has collision, but not two? That doesn't make any sense. The way the chain headers are hashed and linked makes bitcoin insanely strong against preimage attacks. MD5 is considered to be totally broken, and preimage attacks on MD5 are rampant. However, if we used MD5 (not even double MD5) as our blockheader hashing mechanism, we would still be totally safe. P.S. I didn't read much past the part that I quoted. I hope you don't take any offense at that. If you had other important things to say, please try to organize your thoughts better. |
|
|
|
http://en.wikipedia.org/wiki/Elliptic_curve_point_multiplicationMultiplication is repeated addition. The pubkey is G * privkey. The catch is that privkey is huge, so doing simple addition privkey times would take forever. The algorithm you see here is an optimized exponential multiplication. Ignore OpenSSL. That way lays madness...
|
|
|
|
Great. The point math and log factoring is unto itself. I am good with this. I am sure when the code simply calculates from a private key to a public point. it is not doing the complete factoring work. I was only seeing if there are some python people out there that can explain the code so that as this should work one can read it. Basically putting what the main function is doing in normal math rather than learning python complete. I am sure that this can be done as someone has compatible code that works with the blockchain relative to open ssl.
The privkey_to_pubkey() function appears to handle several different types of inputs, and provides corresponding output types. I'm not a python guy, but the cases in the switch seem to be: regular number, uncompressed hex, compressed hex, uncompressed binary string, compressed binary string, WIF. Pubkeys can be compressed simply by throwing away the Y value and including a flag indicating which of the two possible values is right. This compressed form has a different hash from the uncompressed form, and thus a different address, so a portable private key needs to indicate which of the two possible addresses is the right one. This is done by including a flag that can be detected simply by noting the extra byte, or two extra hex characters. base10_multiply() just does point multiplication in a very direct way. It is a loop, though it may not look like it. If it is still confusing, you need to learn about EC math to make it clearer. P.S. There is no factoring. |
|
|
|
That's cool, but the key metric for a miner is not percentage of revenue, it's revenue per hour.
It seems to me that this behavior (*) only gains a higher percentage of revenue by lowering overall revenue. It'd be nice for some simulated numbers which shows that, though.
(I'm not sure how you'd even do a simulator though, since this behavior lowers difficulty, which in turn would attract more miners. Does the simulator assume that the SHA256d processing power of the world is static even though in reality it is exponentially increasing?)
(*) Sorry, I still refuse to call it selfish mining, because so far as I can tell there's actually no advantage to doing it.
I think the idea is that if the attack can be sustained long enough for the difficulty to adjust downward to reflect the much higher orphan rates induced by the attack, then that higher percentage of revenue will equate to a higher overall revenue. So the attack indeed assumes that the SHA256d processing power of the world is static even though in reality it is exponentially increasing? And it indeed ignores the fact that a lower difficulty means more miners? The attack assumes a lot of things. My personal favorite is that global block spread can be described by a state machine with percentage chances for state transitions. |
|
|
|
|
You could run listunspent and work backwards from the scriptPubKey.
But why?
|
|
|
|
How is it possible that I a negative value on the default account?
Accounts don't work like you think they should. Lots of threads on this. How come I get so many addresses?
Change. |
|
|
|
If neither of us get to it first, I'm willing to pitch in 1 BTC as a
bounty for building a general bitcoin network simulator framework. The
simulator should be able to account for latency between nodes, and
ideally within a node. It needs to be able to simulate an attacker that
owns varying fractions of the network, and make decisions based only on
what the attacker actually knows. It needs to be able to simulate this
"attack" and should be generic enough to be easily modified for other
crazy schemes.
So far, this does not meet my requirements. Given that it is written in Javascript, I doubt it ever will.* Still, this is really neat work, and I've enjoyed watching several runs of it evolving. I was planning to send him a tip just for that, and I'd encourage others to also. * Note that I can be outvoted on this matter. From the later email, "Also, I don't want anyone to think that they need to satisfy me personally to collect on either of these two bounties. I will pay mine for a product that is generally along the lines I have laid out, if a couple of the core devs (Gavin, Greg, Jeff, sipa, Luke, etc) agree that your work is useful." |
|
|
|
|
Show Posts
