|
Another thing that would help bitcoin adoption:
python, perl, php libraries and common code for interfacing with bitcoin.
For example, Perl or Python code that verifies that "17NdbrSGoUotzeGCcMMCqnFkEvLymoou9j" is a valid bitcoin address, and "098123409813lkjasdflkjasdflk" is not, would be useful to anyone wishing to implement a bitcoin web interface.
|
|
|
|
So you support people taking your code, modifying it to skim bitcoins off the miner, and then releasing the binary without releasing the modified source code?
That's one obvious consequence of MIT licensing, and has been going on for decades. I doubt it is a surprise to satoshi, or anyone else. Either MIT or GPL, both licenses are fine. MIT has been working great for *BSD and X11; there's no reason why MIT would be problematic for bitcoin. GPLv3 adds some helpful patent language, that's about it. Bitcoin's patent problems are in the area of linked libraries (openssl's EC-DSA), not with bitcoin itself, so that does not seem like a large concern here. Speaking only for myself, as a programmer who has created or worked on dozens of GPL'd projects, including some of the largest in the world (kernel, gcc). |
|
|
|
Is there a way to open BerkeleyDB exclusive?
What is your intended goal? If it is to prevent two bitcoin clients from actively using the same database, you'll need to employ application-level protection. Crude methods of this include a lockfile or "lock" database entry. If the intention is to prevent all other access, I'd suggest giving up on that goal  It is highly useful to permit db4 tools to access db4 databases: db46_archive db46_deadlock db46_load db46_stat
db46_checkpoint db46_dump db46_printlog db46_upgrade
db46_codegen db46_hotbackup db46_recover db46_verify and just as useful to permit read-only accesses by tools such as gavin's bitcointools. |
|
|
|
|
Great, thanks! Removing DB_PRIVATE should enable useful tools like gavin's bitcointools.
|
|
|
|
Some things I think bitcoin needs for success: - Payment processor, well supported, with sandbox, and a shopping cart interface similar to this or this or this. mtgox and gazoakley (bitcoinpay.com) both have some merchant tools, but they need to be "fleshed out."
- More businesses accepting bitcoins. (see payment processor, above) If you cannot convince a business to accept bitcoins, start one of your own! We need legitimate, trusted businesses that cater clients other than wholly-anonymous ones.
- Exchange with major currencies (USD mostly there; EUR barely there; needs more asian currencies)
- More generating nodes. Too easy for someone with US$100,000 to own the entire network. We should encourage generation for the sake of network health, not money. It's not worth it to simply make money generating coins.
Note that this list does not include casinos, prediction markets, HYIPs, etc. Most people use cash because it's widely accepted by businesses and individuals, not because cash is [mostly] anonymous. |
|
|
|
Real-time streaming activity (bids, unbids, asks, unasks, trades, confirmed trades) from Bitcoin Market now in #bitcoin-market thanks to jgarzik for writing a server, dwdollar for hosting, and nanotube for helping to provide the data in IRC channel. Mt. Gox market real-time activity will come soon as mtgox becomes available after moving/settling in to new country.
Feel free to take advantage of this information service @ freenode #bitcoin-market
Really, dwdollar gets credit for writing the server. I wrote a prototype in Perl, and dwdollar rewrote it in Python. |
|
|
|
You should benchmark all implementations (using cpu time, not realtime) and choose the fastest and while benchmarking check whether the algorithm actually works.
+1 agreed. It's not difficult or time-consuming for each user to do this at startup. |
|
|
|
Does this patch work for you guys? http://yyz.us/bitcoin/patch.bitcoin-bindaddrThe patch adds four command line parameters, -bindaddr=W.X.Y.Z Bind to address W.X.Y.Z, instead of 127.0.0.1. Supports bind-any modes via "*" and "0.0.0.0" addresses. -bindport=X Bind to port X, instead of 8332 -rpcaddr=W.X.Y.Z Connect to address W.X.Y.Z, instead of 127.0.0.1 -rpcport=X Connect to port X, instead of 8332 Because of the way bitcoin works, all command line parameters may be specifed in the config file. Therefore, the above would be added to the config file like this, bindaddr=W.X.Y.Z
bindport=X
rpcaddr=W.X.Y.Z
rpcport=X
|
|
|
|
Alright, I have a cheap Pentium III 500MHz headless box running bitcoin 24/7. It's only generating 146 khashes/s. So is it correct that even though it can only process so much there is still a probability of it completing a block at anytime and I could still generate a profit through luck? How does that probability increase with more computing power?
Probability just means it is unlikely to generate a block. But it remains possible that the machine will hit the jackpot and generate 100 blocks in a row. |
|
|
|
In the future, if we add more templates to the existing 2 types of transactions, we can change the "rather not work on nonstandard transactions" test to accept them.
Won't older clients will reject non-standard transactions, even if newer [future] clients are updated to generate them? |
|
|
|
I rent out a VPS for $5.95 a month and it uses two shared Xeon E5620 processors. Would it be unethical for me to be running Bitcoin on it? Do VPS providers have good CPU throttle methods so I don't bog everybody on my node down?
It entirely depends on your provider's Terms of Service and Acceptable Use Policy. Some providers, especially "cloud" providers, are happy to let you use as much CPU as your VPS permits. Other providers will terminate your account if it consistently uses 100% CPU. |
|
|
|
|
Patch updated for SVN r147, which introduces trivial breakage w/ listtransactions. (see start of thread for URL)
|
|
|
|
|
To accurately reflect that processing a transaction has certain resource costs across the network, I propose that tx fee be required for every transaction after X datetime (where X is a few months in the future).
|
|
|
|
|
Bitcoin Store now supports GlobalDigitalPay's three currencies, GDP-USD, GDP-EUR, and GDP-GBP, as payment methods.
GBP is a first for bitcoin, I think.
|
|
|
|
I set up a new wallet for this client. Starting balance is zero, so it can only be a net win regardless of what the code wants to do.
Stealing your BTC isn't the only thing a closed-source client might do. Make sure you don't have any personal information stored on the computer running the client, no bank account numbers etc. And monitor the network communication to make sure it only communicates with other bitcoin P2P clients, and not other botnets as well. It would be too easy to hide a key-generation botnet client inside something appearing to be a bitcoin client. |
|
|
|
|
Thanks to all our customers, for making the launch a success. We've sold over 20k BTC since opening!
|
|
|
|
|
Ordered bitcoins received just now, inside the promised 24 hour deadline.
|
|
|
|
|
I am (finally) out of Pecunix.
Thanks to all who responded!
|
|
|
|
|
Sounds good, though I think anonymous SSL + passwords + IP security will be sufficient for most.
|
|
|
|
|
Show Posts
