This instant deposit feature is great, but you might want to wait until the funds clear before letting people withdraw it back out again.
I thought this wouldn't be an issue, but I'm not so sure anymore. I use the "account" feature of bitcoind and every wallet has its own account. My understanding was, that this will mean that the coins being sent are limited to the account as well. In that case it doesn't matter if the funds end up not confirming, because it will also invalidate the withdraw transaction. But maybe bitcoind uses coins from other accounts as well sometimes? Has someone here more insight into this? It is definitely an issue-- the account code doesn't keep track of where the coins it is sending out came from, so if you accept 0-confirmation coins you're vulnerable to double-spending attacks (see, for example, the discussion of the "Finney attack" in these forums). Seeing coins show up right away is a fantastic feature, though, so I'd suggest getting the 0-confirmation balance and a 3+-confirmation balance, allowing only 3+ confirmed coins to be withdrawn, and displaying the difference as 'waiting confirmation'. |
|
|
|
bitcoin vault service run by computer security experts would probably only need need 1/10th of the employees as an equivalent sized bank, and it would probably offer superiour security at that.
But they won't have the experience jumping through all the banking system regulatory hoops, or experience dealing with currencies other than bitcoin. I expect lots of successful bitcoin vault services, and I expect one or more of them to be purchased by one or more banks and made a part of the banks' money services business. If they see bitcoin vault services making big profits, they'll want to own one. My predictions are frequently wrong, though. Maybe US banks will fight bitcoin tooth-and-nail, or maybe the legal issues will be too unclear for any bank to risk getting involved. |
|
|
|
|
Fantastic idea!
My only suggestion would be a "copy to clipboard" icon/link next to the funding address (I need to do that for ClearCoin, too-- haven't looked into how to do it yet, but github does it so I know it can be done...)
|
|
|
|
hmm, with new version i can't send 0.01 BTC without fee
0.3.20.2 works fine
You're running into the "very low priority transactions require a fee" rule. Priority depends on the value of the transaction (fewer bitcoins == lower priority) and how long ago you received the bitcoin(s) (older == higher priority). That rule was in place for 0.3.20.2, but only for most miners. Most would not include very-low-priority transaction in blocks until they were old enough to have a high priority. The result was a big backlog of very-small transactions starting to build up. With 0.3.21, the rules are the same for miners, for relaying transactions across the network, and for the user interface-- if your transaction is very-low-priority, it won't get relayed and the user interface will insist that you pay a fee if you really want it transmitted RIGHT NOW. If you really really really need to send 0.01 bitcoins right now, then you'll have to pay the fee. If you're willing to wait a while, you'll find you can send it without a fee after it is old enough and has enough priority. All of this is to discourage people from "penny flooding" -- constantly sending pennies back and forth to themselves without a fee just because they can. Footnote: if you don't upgrade, you can send that 0.01 bitcoins without a fee. But as everybody else upgrades, you'll find that it will take a long time for that transaction to get confirmed. |
|
|
|
0.001 BTC at today's exchange rate is uncomfortably close to the estimated network-wide cost of processing a bitcoin transaction (which is about 0.001 US dollars). The danger is a flood of micro-transactions that keep everybody's CPUs busy, driving up that hidden cost and, eventually driving people to stop running bitcoin because the costs aren't worth the benefits. Also: lets not confuse the "how many free transactions" with "what is the smallest transaction amount you can send." |
|
|
|
(BTW this ignores the fact that banks have huge political influence and will support any political attempts to block the advance of bitcoin.)
I think there's a good chance (mmm... 65.3%) that within 4 years one or more of the largest 1,000 US banks will support currency exchange to/from bitcoin for their customers. Why would bitcoin be a threat to banks? They're really good at securely handling currency; that's a valuable service, whether the currency is dollars or euros or bitcoins. |
|
|
|
|
We got a request a couple days ago for somebody to do an interview with a Brazilian radio station about bitcoin.
Any volunteers?
|
|
|
|
Doesn't Gavin already live on the east cost of the US? I thought he was only originally from Australia.
Yep, I live in Amherst, Massachusetts; my family moved to the US when I was 5 years old. I will be visiting Australia (Sydney for a couple of days then Tasmania for a couple weeks then Cairns for a week or two) in July. |
|
|
|
The "slave" talk is rubbish. I'm calling on him to say what he'll do with the money
Me and my good friend Charlie will spend it on hookers and blow, of course. |
|
|
|
|
RE: Mac builds: what BlueMatt said. Despite using a Mac as my development machine, I am not a Mac developer-- I'm an old Unix developer at heart. I learned enough Windows "Win32-api" programming to create a couple of products, and I know a lot about web development, but I'm a newbie when it comes to making applications for the Mac.
RE: wallet encryption: I want encryption of wallet private keys (requiring you to enter your password to send coins) to be part of the next release, and I think that is a big enough feature to bump the next release version to "0.4".
RE: x86-64 client: for the Windows? or for Linux? 32-bit should work find on 64-bit Windows, there's no real reason to do a 64-bit version. For Linux, there should be a bitcoin in bin/64/
RE: bitcoind not forking by default any more: yes, that is intentional, and I forgot to mention it in the release notes. When the mac binary is done I'll update the README. Run bitcoind -daemon (or put daemon=1 in the bitcoin.conf file) and you'll get the old behavior.
|
|
|
|
Wow, I new this would generate discussion... but wow! A couple of quick notes: noagenda nailed it-- I was contacted specifically by In-Q-Tel, the CIA's "look for interesting/promising new private technologies and then invest in them" spin-off. I get the impression they organize the conference. This year the conference is about money. They are serious about security; there will be no recording, and I will not be allowed to bring any electronic devices with me. I am planning on posting my talk, and if I get my act together in time I'll try to post it before I give it so y'all can give me feedback. I'll be signing an agreement that I, or my company, will not use my appearance for publicity purposes. So please, no unofficial "from the bitcoin community" press releases about this. If talking to them makes y'all trust me less... then good! I'd like to see more careful code review, and, as others have pointed out, if bitcoin can be destroyed by one person, or requires the leadership of one person, then it has failed to be the strong, decentralized system that I think it is. RE: me == satoshi: here's some C++ code I wrote 15 years ago: http://oss.sgi.com/cgi-bin/cvsweb.cgi/inventor/apps/demos/revo/RevClass.c%2B%2B?rev=1.1.1.1I have a very different coding style from Mr. Nakamoto. And I don't know nearly enough crypto to build something like bitcoin by myself. And one final note: the US government is a really, really, really big organization. Like any big organization, different parts have different motives and goals. I hope I'll get a little tiny glimpse into what one part of that big organization thinks about bitcoin. |
|
|
|
Are you going to put the source on SourceForge SVN?
Yup. I think this might be the last release I do that, though... EDIT: Done, svn revision 251. |
|
|
|
|
I want to get this out in the open because it is the kind of thing that will generate conspiracy theories: I'm going to give a presentation about Bitcoin at CIA headquarters in June at an emerging technologies conference for the US intelligence community.
I accepted the invitation to speak because the fact that I was invited means Bitcoin is already on their radar, and I think it might be a good chance to talk about why I think Bitcoin will make the world a better place. I think the goals of this project are to create a better currency, create a more competitive and efficient international payment system, and give people more direct control over their finances. And I don't think any of those goals are incompatible with the goals of government.
I'm only very slightly worried that talking about bitcoin at the CIA will increase the chances they'll try to do something we don't want them to do. I think accepting their invitation and being open about exactly what bitcoin is will make it less likely they'll see it as a threat.
PS: Full disclosure: I'll be paid a one-time fee of $3,000 to cover expenses and pay me for my time. I don't want any "Gavin is on the CIA's payroll" rumors to get started, either...
As always, comments and questions and discussion welcome. I'd really rather not hear any conspiracy theories about how they'll secretly implant a mind-control chip in my head while I'm there, though....
|
|
|
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Binaries for Bitcoin version 0.3.21 are available at: https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/Changes and new features from the 0.3.20 release include: * Universal Plug and Play support. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the - -upnp=1 command line switch or using the Options dialog box. * Support for full-precision bitcoin amounts. You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. However, sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so you can send 1.0001 bitcoins without a fee, but you will be asked to pay a fee if you try to send 0.0001). * A new method of finding bitcoin nodes to connect with, via DNS A records. Use the -dnsseed option to enable. For developers, changes to bitcoin's remote-procedure-call API: * New rpc command "sendmany" to send bitcoins to more than one address in a single transaction. * Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests. * -logtimestamps option, to add a timestamp to each line in debug.log. * Immature blocks (newly generated, under 120 confirmations) are now shown in listtransactions. SHA1-checksums for the binary files are: 54254cba039b02a2f49fdc98b8fe820d0fd4e410 bitcoin-0.3.21-linux.tar.gz 3f94d6a8b08c455a7886561089270247eaada7b4 bitcoin-0.3.21-win32-setup.exe f9a39404433b01b5a22225855f42275c1c902c26 bitcoin-0.3.21-win32.zip (mac version should be ready soon) Thanks to all those who contributed to this release: Dan Helfman Dan Loewenherz devrandom Eric Swanson gjs278 Jeff Garzik Luke Dashjr Matt Corallo Matt Giuca Nils Schneider ojab Pieter Wuille sandos Santiago M. Mola Sven Slootweg Gavin Andresen gavinandresen@gmail.com-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAk24UbsACgkQdYgkL74406jQlwCeOPf1avdfugmzfiVtuT0hUacm 4DEAoJcAR0ha8VKQ8Mu6QoG9ywDLvwjI =DRxu -----END PGP SIGNATURE----- |
|
|
|
i am clicking the Copy to Clipboard in the client and pasting directly into mtgox. also tried the Notepad recommendation above but it didn't work.
What operating system? This sounds like a wxWidgets or bitcoin client bug that needs fixing. |
|
|
|
If an attacker can force you to sign arbitrary messages, that's certainly a security flaw. The solution is to take good care that you approve of whatever content you are thinking of signing whether it be cheques, loan agreements, wills or numbers.
So: the danger isn't revealing private keys (I mis-remembered), the danger is a naive developer will see the signmessage RPC command, not realize that signing arbitrary data can be dangerous, and put up a web page that lets somebody enter arbitrary data to be signed with one of the developer's public keys. This might just be a documentation issue, although if signmessage was changed to sign a hash of the passed-in message instead of the message itself then it would be completely safe. |
|
|
|
|
To steal your bitcoins by breaking crypto (as opposed to getting your private key), somebody would have to:
1. Break RIPEMD160. Because your bitcoin address is a RIPEMD160 hash... AND
2. Break SHA256. Because your bitcoin address is a RIPEMD160 hash of the SHA256 hash... AND
3. Break the ECDSA elliptic curve encryption signature algorithm, to figure out the private key that corresponds to the public key that they got from breaking (1) and (2).
That's assuming that you don't re-use bitcoin receiving addresses (your public key is revealed the first time you spend coins that were sent to that address). If you do re-use the same receiving address, then they just need (3).
I don't spend any time worrying about whether or not the NSA (or anybody else) can break ECDSA.
|
|
|
|
RE: other weird variable type requirments: sendmany's second argument is a JSON Object, with string keys and number (float) values. I think the equivalent in PHP is a PHP Array (indexed by string). Several routines take boolean arguments. All the rest are strings or numbers. |
|
|
|
I've deployed a -testnet version of ClearCoin, at: https://testnet.clearcoin.appspot.com/It is fully functional, so feel free to creates some escrow transactions and get some testnet bitcoins from the the testnet faucet (which I will eventually move to testnet.freebitcoins.appspost.com). For anybody else developing on App Engine, here's what I did to make it work: In my main.py: # Set testnet namespace
if 'test' in os.environ['CURRENT_VERSION_ID']:
set_namespace('testnet')
CURRENT_VERSION_ID is the version of your app that's running, and is set by App Engine. set_namespace makes all subsequent datastore and memcache operations read/write from a different database. So almost all of the code for ClearCoin doesn't care whether it is handling testnet coins, it just works. The only other change needed was a check for 'test' in os.environ['CURRENT_VERSION_ID'] when deciding which bitcoind server to use. I run the -testnet bitcoind for ClearCoin on a different machine than the production bitcoind, so experiments on the test net won't affect the production ClearCoin at all. If you're not running on App Engine, you should think about building in the equivalent of CURRENT_VERSION_ID and 'set_namespace' so deploying test and production versions of your application is easy. |
|
|
|
|
Best thing I've bought: Boston Red Sox tickets (from a friend who has season tickets).
Second best: my alpaca socks.
And I've bought three or four lunches with bitcoins so far (also from friends-- they pay, then I repay them in BTC).
I really wish I had a use for Golden Mean Calipers, they look nifty.
|
|
|
|
|
Show Posts
