1843
|
Bitcoin / Development & Technical Discussion / Re: Development process straw-man
|
on: January 03, 2011, 05:20:44 PM
|
I do not see any point in moving the discussion of some bitcoin changes to a special place outside the forum. Discuss changes on the forum just like we've always done, regardless of whether that change is a proposal, a patch, or a pull request.
The forum is perfectly adequate for discussions.
OK. Lets talk here.
|
|
|
1844
|
Bitcoin / Development & Technical Discussion / Re: Development process straw-man
|
on: January 03, 2011, 05:08:49 PM
|
I'm interested in the project and have developed a patch and until I found this email I had no clue how to submit it. Can I suggest that a development overview page be created wiki https://en.bitcoin.it/wiki/Main_Page to house this sort of instructions. Maybe something like https://en.bitcoin.it/wiki/Development with links from the wiki Main_Page and the main website. Done. Please feel free to make it better. Another thing to point out is where tickets should be opened. I tried for quite a while to find ticket tracking on the sourceforge site. There should probably also be a link from the sourceforge site to github.
Good idea.
|
|
|
1846
|
Bitcoin / Development & Technical Discussion / Re: Bitcoin Application Limits
|
on: January 02, 2011, 05:02:11 PM
|
How many <account> and <bitcoinaddress> can one client handle in a server environment?
It aught to be able to handle hundreds of accounts and thousands of addresses, although (as far as I know) nobody has done scalability/stress testing with that many (simulated) users. The listtransactions method scans through all wallet transactions (and then sorts them by time), so if you've got thousands or tens of thousands of accounts with millions of transactions and you're using listtransactions to show customers their account histories, that might be a bottleneck. However, I wouldn't be at all surprised if something ELSE becomes the bottleneck if you had that many accounts-- for example, there is only one RPC thread handling requests, and some requests (like a send bitcoins request) can take seconds to process. I've been writing code long enough to know that I can't look at code (even code I've written) and figure out where the performance problems are lurking-- you've got to actually measure or simulate real-world behavior.
|
|
|
1847
|
Bitcoin / Press / Re: Bitcoin press hits, notable sources
|
on: December 31, 2010, 08:06:09 PM
|
This was an extremely good interview. I didn't really entirely get how bitcoin really works until now after reading this interview.
Thanks! It was the first interview I've ever done via IM/chat, and it worked well. I was surprised to see how little editing/reworking was done; I guess they were happy with what I wrote, too. Gavin, you mention that you use VPSes for your bitcoin apps. May I ask which VPS providers you use? I am currently looking for VPSes for my own bitcoin apps.
Sure. I run two instances of bitcoind on a "Linode 512" running Debian (sign up using this URL and I'll get a $20 credit). They're used for the TEST and regular Bitcoin Faucets. I also use that system to compile bitcoin/bitcoind. I've been very happy with Linode. The bitcoind for ClearCoin is running on an Amazon EC2 "micro" VPS instance, also running Debian, using an encrypted EBS filesystem. I'm extra paranoid about security and reliability for ClearCoin because I'm handling other people's money.
|
|
|
1849
|
Bitcoin / Technical Support / Re: why it doesn't show from what address bitcoins came?
|
on: December 30, 2010, 11:55:12 PM
|
I agree it is natural to want to know who sends you the money. That would be a nice feature to add to Bitcoin.
Showing a 'from' address in bitcoin as it is now won't give you that feature, it will give you something that kind-of, sort-of, maybe-most-of-the-time works like that feature.
And it's not obvious how to implement a "where did these bitcoins come from?" feature.
|
|
|
1851
|
Bitcoin / Bitcoin Discussion / Re: A "real" Bitcoin
|
on: December 30, 2010, 05:12:09 PM
|
Yeah, cool!
Could you punch a couple of holes through the B? I like topologically interesting money.
And if you want to make it the absolutely coolest coin in the world, generate a new bitcoin address, send 1 bitcoin to it, and then engrave that address on the coin.
Then you have physical currency that the owner can independently check to make sure the bitcoin backing it hasn't been spent.
|
|
|
1852
|
Bitcoin / Bitcoin Discussion / Re: Password, what password?
|
on: December 30, 2010, 04:42:24 AM
|
Playing devil's advocate for a moment:
"Security theater" is popular. It makes people feel safer. Bitcoin-the-program will probably be more popular if it asks for a password before sending and there is a bullet-point on the feature list: "State of the art AES-256 encryption."
I believe TrueCrypt is open source; maybe it would be easy to use their password handling / encryption code in bitcoin. Anybody here looked at their code?
|
|
|
1853
|
Bitcoin / Technical Support / Re: why it doesn't show from what address bitcoins came?
|
on: December 30, 2010, 04:31:20 AM
|
There really is no "from" -- there is just 'where the coins were sent last time they were sent somewhere.'
If that 'somewhere' was a shared wallet (like a mybitcoin account) where all the incoming transactions get mixed up, knowing what address they were sent to previously is worse than useless information. You might decide it is a good idea to try to refund bitcoins to that address and end up sending them to some random mybitcoin user, and NOT your customer.
Adding possibly-worse-than-useless features to the bitcoin GUI is a bad idea. Am I missing some other reason for wanting to see the last addresses to which the coins you received were sent?
|
|
|
1854
|
Bitcoin / Bitcoin Discussion / Re: Password, what password?
|
on: December 30, 2010, 04:11:32 AM
|
An absolute must. It's only a matter of time until trojans start going for wallet.dat
If you have a trojan on your computer you've already lost. The trojan could easily log your keystrokes and send your password along with the encrypted wallet.dat to the bad guys.
|
|
|
1855
|
Bitcoin / Development & Technical Discussion / Re: Any Javascript/JQuery/YUI/Dojo hackers in the house?
|
on: December 29, 2010, 11:40:51 PM
|
Can we include a small HTTP server (for .html + .js) into bitcoin? JSON-RPC will only work on same domain + port.
No, definitely not. But if somebody implements a nice Javascript GUI I'll volunteer to teach bitcoin to spit out JSONP in addition to plain JSON to get around the same origin policy... RE: GWT: I'd prefer a non-Java-to-Javascript-compiled solution (shipping compiled, not-human-readable .js files makes me nervous; do we have to add all the GWT compilation mechanism to the build process? Or do we have to trust that you provided valid, not-messed-with, already-compiled .js files?)
|
|
|
1856
|
Bitcoin / Development & Technical Discussion / Any Javascript/JQuery/YUI/Dojo hackers in the house?
|
on: December 29, 2010, 09:28:13 PM
|
I'd love to see a pure-Javascript front-end GUI for bitcoind developed.
I'm tempted to write one myself, but I've got a lot of other things on my TODO list right now. Here's what I'm imagining:
+ Open source, pure JavaScript interface to bitcoin that communicates with a running bitcoin/bitcoind using the JSON-RPC api.
+ Open up the index.html page that is the GUI and you'd be asked for the host:port (default: localhost:8332), username and password.
+ From there, you'd have a nice Javascript/HTML GUI showing all your wallet transactions (using RPC listtransactions).
+ And it'd show your default receiving address, have a Send Bitcoins button, etc.
+ And it'd poll bitcoin/bitcoind every, oh, minute or so to look for new transactions.
I'm imagining shipping a webGUI/index.html (plus associated CSS/javascript/etc) as part of the bitcoin(d) source package.
|
|
|
1857
|
Bitcoin / Development & Technical Discussion / Re: Instant New Way to Send Bitcoins
|
on: December 29, 2010, 09:18:14 PM
|
I think of this as a subset of the "I want to move N bitcoins from my wallet to a USB stick that I'll put in my safe deposit box so it cannot be hacked", "bitcoins as a long-term store of value" feature: https://github.com/bitcoin/bitcoin/issues#issue/2A solution should: + Make accidental double-spending impossible (or at least, very hard) + Remove the private keys from your wallet so if the wallet is stolen they coins are safe + Be as close to 100% safe as possible, even if your computer gets hit by lightning at exactly the wrong time. That last one is the tricky bit.
|
|
|
1858
|
Bitcoin / Development & Technical Discussion / Re: Development process straw-man
|
on: December 29, 2010, 09:12:11 PM
|
Requests get discussed (where?
Yes - where? I found that an email list was nearly ideal for such work when in the Linux kernel (the famous lkml list.) Let's try using the github Pull Request system for discussing pull requests: https://github.com/bitcoin/bitcoin/pullsThat ties the discussion to the proposed code changes, is a natural way to create separate 'threads', and will be a convenient place to point to in release notes. And lets talk about potential code changes (pre pull request) here in this forum. I'd rather not introduce Yet Another Place (we've already got these forums, IRC chat, and github) to talk about bitcoin development.
|
|
|
1859
|
Bitcoin / Bitcoin Discussion / Re: Protecting: Deep packet inp, Anon vs Open switch, Decentral dev, other languages
|
on: December 29, 2010, 08:58:04 PM
|
Anything we could/should do to prepare for deep packet inspection?
I don't think that belongs in Bitcoin-- I like solutions like i2p or ssh tunneling that put encryption down at the lower network layer (where it belongs, in my humble opinion). Decentralised development. Perhaps a mirror to freenet might be good. Also, getting into other languages in different countries is important; completely separate development there too. If USA gets shut down perhaps .ru continues because most English speakers are ignorant to Russian, for example.
Are you worried about SourceForge and GitHub (the two 'official' trees) being forced, or deciding, to drop bitcoin? At this point lots of developers have their own copies of the source code, I'm sure if that happened another site (maybe a hidden monotone repository inside the anonymous i2p network) would spring up. They can't stop the signal...
|
|
|
1860
|
Economy / Economics / Re: Money laundering
|
on: December 29, 2010, 08:21:02 PM
|
There's bitcoinlaundry.com, but I'm not sure it is effective. All the transactions are still in the block chain, so you could just compare timestamps and amounts. Am I wrong?
You need a service that will let you send multiple, random-looking amounts at different times, and then, some time later, send an amount to the destination. And then refunds any extra you sent (and you should send extra). And if you're really paranoid, it should allow you to give several refund addresses, and random amounts of coins get refunded to each. Then you need to trust that service, which is the really big security hole. What better way to catch money launderers than to setup a money laundering service for them? You're probably better off doing what has been suggested several times-- move coins between 'shared wallet' services like MyBitcoin or MtGox (and/or ClearCoin) or just between two machines of your own that are both running bitcoin.
|
|
|
|