1301
|
Bitcoin / Bitcoin Discussion / Re: Use for bitcoin: Hiding assets from government
|
on: May 26, 2011, 08:14:45 AM
|
Then I'd be able to get at my funds once I'm out of prison or running to another country. Right?
Sure. But if They sent you some of the bitcoins that were in that wallet then They might be able to track you down when you use those coins at a Ferrari dealership that is cooperating with or run by Them.
|
|
|
1302
|
Bitcoin / Development & Technical Discussion / Re: Testnet stability (was Lost coins on testnet)
|
on: May 26, 2011, 07:47:14 AM
|
On the other hand, a stable testnet is somewhat important for people that want to debug and test merchant sites.
This time, it took me about two days to generate any coins on the testnet, the coins the faucet sent me never arrived (and still, it insisted it had sent me coins, I wasn't able to repeat it).
For debugging your own sites, a testnet-in-a-box setup is nice and stable, completely under your control, and has a good supply of mature coins to debug with. See http://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/
|
|
|
1303
|
Bitcoin / Development & Technical Discussion / Re: Handling Bad Peers and Net Neutrality
|
on: May 25, 2011, 08:28:10 PM
|
Bad peer code that drops the connection and refuses reconnection seems like a good denial-of-service prevention measure.
My only hesitation is accidentally causing a network (and, therefore, block-chain) split if "bad" turns out to be "my peer is running a newer version of the protocol and is accidentally sending me messages I don't understand."
RE: net neutrality: if you have to worry about your bitcoin traffic being shut down, I think that problem is better solved with TOR or another network proxy solution.
|
|
|
1307
|
Economy / Economics / Re: Demurrage, transaction fees, storage fees & comparison to commodity money.
|
on: May 24, 2011, 08:16:59 AM
|
If processing old transactions becomes expensive, then miners will start charging transaction fees to include them in their blocks.
Speculating about exactly HOW the miners will charge (will they subscribe to an 'old transaction service' or somehow contact the old-transaction-spender for the merkle branch of the old transaction?) is a waste of time, in my humble opinion.
|
|
|
1309
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin Address Collisions
|
on: May 23, 2011, 02:48:29 PM
|
RE: moving to another hashing algorithm for bitcoin addresses:
Did you read what Satoshi wrote?
If you want to make money, you are far, far, far, far, far, far better off using your hardware to generate blocks than trying to find a bitcoin address collision and steal bitcoins. Potential address collisions are not a weakness, and switching to another algorithm would be just busy-work for us developers who should be spending time on REAL weaknesses (like figuring out how to make bitcoin more secure against trojans and viruses).
|
|
|
1311
|
Bitcoin / Development & Technical Discussion / Re: Successful timing attack on ECDSA - maybe it's already time to switch algorithms
|
on: May 23, 2011, 02:29:28 PM
|
If I understood the paper correctly (I skimmed it very quickly), this is a timing attack that requires the attacker send a bunch of things to be signed with the same ECDSA private key. The good news is it they also give a patch to OpenSSL to fix it. The other good news is bitcoin only signs things with private keys when you send coins, and if you have the ability to ask bitcoin to send coins then we don't really care if you can get the private key. We do have a patch in the "pull queue" that adds a RPC command to let bitcoin sign stuff ( https://github.com/bitcoin/bitcoin/pull/183 ), but, again assuming I read the paper correctly, even that doesn't worry me, since if you have the ability to run that RPC command you could either go through all the trouble of the timing attack to figure out the private key... or you could just issue a "send" command to steal all the bitcoins out of the wallet.
|
|
|
1313
|
Bitcoin / Bitcoin Discussion / Public Relations
|
on: May 19, 2011, 03:08:27 PM
|
So with the recent avalanche of press interest in bitcoin, I thought I'd share my thoughts on how I'd like to see bitcoin positioned. I'm not writing this as "This is the Official Bitcoin Organization Position" -- as always, I expect everybody to have, and express, their own views. I'll restate what I see as the goal of The Bitcoin Project: To give us control over our finances by establishing a stable, secure, global, "democratic" currency. I think positioning bitcoin as "revolutionizing the financial system" is the goal-- not more radical statement I've heard (like "destabilizing governments"). Most people either like or are indifferent to their governments (I know, I know, sheeple and all that... lets not go there). I don't think most people get the warm fuzzies when thinking about bankers and Big Corporations; bitcoin as "The People's Money" is the right way to think about it. Also, whenever I talk to the press, I try to be realistic. Bitcoin is still an experiment that has never been tried before; there is still a good chance it will fail, and there is still a lot of work to do to make it stable and secure. I'm excited because bitcoin is a big idea that might change the world for the better, but I also realize that our little project is just a baby compared to the decades-old financial systems that we all use every day. I think it is important to set expectations; I still wouldn't recommend that my mom use bitcoin for anything just yet, because it is not easy enough to use securely. And the road ahead is likely to be bumpy; there will be technical issues that need fixing, there will be legal questions, there will be price bubbles, and there will be scams. I predict that some company using bitcoins to do something illegal will be caught and prosecuted, and that will be mis-reported as "Bitcoin is illegal." I said a year ago that creating solid technology was just the first step in a long road for bitcoin. I'm very pleasantly surprised at how far the bitcoin project has come in a year; the innovation and experimentation and level of interest and excitement is fantastic. Here's an email exchange I had with a reporter yesterday: Specifically, do you agree or disagree that this project is "dangerous"? If you disagree, how would you describe the potential significance of bitcoin in a future Internet economy? New technologies are always at least a little bit dangerous-- they can usually be used for both good and bad (think of gunpowder or ChatRoulette), and are certainly dangerous to the status-quo that they replace (think of cars and buggy-whip-manufacturers). Bitcoin is a really ambitious project; we're trying to let people take back control of their money instead of trusting bureaucrats or bankers or politicians to keep it stable and safe. It is international, decentralized, and completely open to innovation, very much like the Internet. Like the Internet, I expect its early years to be full of amazing successes and spectacular failures, and I don't think anybody will be able to predict in advance what will succeed and what will fail. I think the real question is whether or not bitcoin will appeal to the majority of people who are happy with our current financial system. If it doesn't, bitcoin may fade away or end up as a niche currency used for a tiny percentage of global financial transactions.
|
|
|
1315
|
Bitcoin / Bitcoin Discussion / Re: conjecture about proof-of-work and cryptocurrencies
|
on: May 19, 2011, 04:00:21 AM
|
Well, wouldn't it have been possible to start with a digital currency that had a fixed, unchanging number of units, and used a transaction cost scheme as the incentive structure from the start?
Sure, we'll call it GavinCoin and I get all the coins to start. If you want some, you just send me some of that worthless fiat currency that you have laying around. Sound good?
|
|
|
1316
|
Bitcoin / Development & Technical Discussion / Re: restricting access to nodes bitcoind talks to
|
on: May 18, 2011, 06:37:14 PM
|
Then a "stealth" client is needed, that functions as a dark node unless specificly commanded to connect to a particular peer, or accept a particular peer's requests. In fact, I want this client, portable on a thumbdrive.
That is exactly what -connect does (if I recall correctly; you might need -connect and -nolisten together).
|
|
|
1318
|
Bitcoin / Project Development / Re: Security standards for bitcoin commerce sites and applications
|
on: May 18, 2011, 05:24:25 PM
|
Gavin, your ClearCoin project holds bitcoins on deposits. Can you direct me to the security standards that you are adhering to? Has a 3rd party audit been peformed to ensure that your organization is adhering to those standards? Have you subjected your infrastructure to any kind of penetration tests? If I have 1000 btc in escrow at ClearCoin and an act of God wipes out your server at 2:15PM on a Sunday afternoon, is money safe and recoverable?
No, no, no and yes. I'm planning on making the answers to all of those questions "yes" within the next six months, although I need to look at how many bitcoins are contained at any given time in the ClearCoin wallet; it might make more sense to send double or triple that amount of bitcoin to a publicly verifiable address, prove I own the coins, and guarantee any losses due to ClearCoin getting hacked. (note: I just looked, and right now there are 540 bitcoins in the ClearCoin wallet, so spending $50,000 to protect them really wouldn't make sense). More to the point, how can I or anyone affordably provide the same kind of fault tolerance and data security that a traditional banking institution would?
Yet another bitcoin chicken-and-egg problem that will get solved by investors taking a risk and giving bitcoin entrepreneurs the resources to do security right (or wealthy entrepreneurs stepping up and making the investment themselves).
|
|
|
1320
|
Bitcoin / Development & Technical Discussion / Re: Post-inflation security
|
on: May 18, 2011, 03:00:13 PM
|
Okay I totally don't understand. If the block size is not a limit then why would anybody drop a tx that they had already paid the ECDSA price for?
They haven't paid the ECDSA price. The decision is "I know how big this transaction, how many OP_CHECKSIG opcodes I'll have to compute to verify it, and how much transaction fees it pays. Should I do the work of verifying it or should I just ignore it?" @ribuck: yes, the UI would be much simpler, but internally the client needs a model of what the miners are accepting. Maybe a really simple internal model will work if the UI is really simple...
|
|
|
|