I think that Bitcoin is not the Satoshi code, that merely proved the concept, we all bought into.
Not true. We are stuck with the bugs found in early Satoshi code. We must faithfully reproduce these bugs, to avoid splitting the network. Examples include but are not limited to: - Genesis block is not spendable
- CHECKMULTISIG requires an OP_0 to work around a bug
- Some transactions' hashes duplicate earlier transaction hashes, effectively making those earlier transactions unspendable. Your code must similarly do the same.
You might be furious about this statement, but if that code would be suitable to all, then why on earth did you create BitcoinJ or jgarzik picocoin and pynode, to name a few with likely more credit in your eyes?
picocoin and pynode both carry "under construction, alpha quality, do not trust with money" warnings because they are incomplete and risk splitting the network because they do not follow the reference client 100% yet.
|
|
|
Trying to build bitcoin on an Amazon EC2 instance. I'm using git cloned source.
It compiles fine until this, [...] Cannot continue now after several attempts. Seems to be tool problem as this did build on my other vps also 12.04.
My tools installed like this: sudo apt-get install git htop build-essential libssl-dev libboost-all-dev libdb5.1++-dev
Anyone have ideas how to get around this? thx.
As Luke guessed, this is the compiler running out of memory. You can always compile elsewhere, and copy the 'bitcoind' binary to the VPS for running. There is no requirement that you compile on the same host that will run bitcoind.
|
|
|
Here is another reason NEVER to form partnerships with other people.
That's sorta like saying "trust no one." Follow that rule religiously, and you will lead a barren, lonely life. Funny you say that since bitcoin is based on zero-trust between its participants. Bitcoin trusts no one. Bitcoin is lonely. Incorrect. Bitcoin relies on community verification. Bitcoin trusts the bitcoin community.
|
|
|
Here is another reason NEVER to form partnerships with other people.
That's sorta like saying "trust no one." Follow that rule religiously, and you will lead a barren, lonely life. Sure, some humans are fallible and will let you down. But other humans are wonderful and will boost you up.
|
|
|
Can you provide a static, public Bitcoin address from which all received funds will be converted and donated to Wikipedia?
+1 I would donate, if there were a static donations-for-wikipedia address.
|
|
|
Yes. It proves there are way too many naive anarchists in the world.
|
|
|
Ok. I did this but it builds 0.7.1 according help output. How does one build 0.8.0? Is there a makefile flag or something? Thx.
That is normal. The version does not become "0.8" until release day.
|
|
|
I've been digging around in this forum looking for the info to build 0.8.0 of bitcoin. Can't seem to find it. Can someone point me at the thread?
Ask in this thread: https://bitcointalk.org/index.php?topic=119525.0I've git cloned bitcoin but this builds 0.7.1 according to help output. Do I need a different branch or what... or just a makefile option. Hints welcome. Thx.
That is normal. There is no side branch. The main branch is "master" The version does not become "0.8" until release day. My output from debug.log looks like 12/08/12 06:53:41 Bitcoin version v0.7.1-216-g8588702-dirty-beta (2012-12-04 07:18:04 -0800)
|
|
|
Yeah that sounds like a bug everybody inherited from cpuminer, which definitely had rough edges when it came to any target besides the standard difficulty-1.
|
|
|
Typically you can hit the "report to moderator" link, and I will fix any broken subject lines to follow YYYY-MM-DD format.
|
|
|
I don't see a data file that stores address history, or transactions indexed by address for quick retrieval by address unless I'm mistaken.
That is mostly correct. If the address is in your wallet, all transactions related to that are stored in the wallet. Otherwise, address history is not stored. I expect it's not going to be too hard to store the transactions indexed by address. I may be wrong there. Maybe leveldb can be used again and keyed by address?
Yes. leveldb is a generic key/value database. You may store anything you like in there.
|
|
|
Please note that cunicula trolls every thread in this way. His is a minority opinion and his ignore button is colored for a very good reason.
|
|
|
A total lamer here: if I have a private key of a bitcoin address, that has 1 BTC in it, can I spend it with picocoin? Or does it only know about transactions that are broadcast to it? Thank you.
In the future, when picocoin is complete, yes, you can spend it with picocoin. Right now, while picocoin is under construction, that is not yet implemented. picocoin will provide everything a bitcoin client should provide: you can receive and spend bitcoins.
|
|
|
so what happens if bitcoin becomes so popular that 100 or 1000 or 100,000 times as many transactions as we see now begin to take place in a given amount of time? would the devs just have to change that cap from 1 mb to something larger? or is the system capable of self adjusting?
It is economically self-adjusting.
|
|
|
Where exactly is 0.8? I looked everywhere in the bitcoin respository on Github and saw no sign of such a branch.
All development is on the main branch ("master"). What will become 0.8 is what you get when you clone git://github.com/bitcoin/bitcoin.git
|
|
|
so if government were to spend $1 Billion to fuck the bitcoin system they could get the best miners and hardware that would only solve blocks if they included a transaction fee of a specific special number that they give and design people that they wanted to use the bitcoin system
Sure. But... 1) There are plenty of cheaper, easier attacks that would disrupt the bitcoin system anyway. 2) You could just as easily spend $100 million to destroy the market value of bitcoins, by manipulating the free market. 3) The community would want to continue, and so, everyone would agree on a new algorithm, rendering all that expensive hardware useless. There are plenty of reasons why mining attacks cost far more than other, more realistic attacks.
|
|
|
|