Aren't copyright notices required or else information is in the public domain? If there are no notices then from my limited knowledge I would guess it was in the public domain legally.
According to US law... Q. Do I have to register with your office to be protected? A. No. In general, registration is voluntary. Copyright exists from the moment the work is created. You will have to register, however, if you wish to bring a lawsuit for infringement of a U.S. work. See Circular 1, Copyright Basics, section “Copyright Registration.” From http://www.copyright.gov/help/faq/faq-general.html |
|
|
|
There are zero bitcoin auditors. however there is a lot of talented people. It is kinda a pet hate of mine (people misusing the word audit).
Existing auditors probably do have experience in websites, databases, public key-signed messaging and avoiding data theft. |
|
|
|
|
Absolutely, the diff can be changed. Just a couple constants, and an additional check.
|
|
|
|
Some of the reasons why I avoided bitcoinica with a ten foot pole, which were obvious right from the start: - The big one -- Zero hard evidence they actually had all the funds claimed, or could produce funds if outsized events (big selloff, big withdrawal, etc.) occur
- Opaque ownership structure
- Zero independent source code auditing or visibility
- Zero proof of any experience at securing wealth from virtual and physical threats
- Zero appearance of adhering to any regulatory structure
Can't you apply most or all of these items to pretty much every bitcoin business available? AFAIK, none of the exchanges had their source code audited, for ex. The difference is in degrees. Each is not a binary choice. MtGox, for example, has been forced by circumstance (trial by fire?) to develop good legal and technical defenses. Even so, I never trusted any exchange and unknown website -- MtGox included -- to store any significant wealth for any period of time. That's what paper wallets and bank safety deposit boxes are for. |
|
|
|
Some of the reasons why I avoided bitcoinica with a ten foot pole, which were obvious right from the start: - The big one -- Zero hard evidence they actually had all the funds claimed, or could produce funds if outsized events (big selloff, big withdrawal, etc.) occur
- Opaque ownership structure
- Zero independent source code auditing or visibility
- Zero proof of any experience at securing wealth from virtual and physical threats
- Zero appearance of adhering to any regulatory structure
Therefore I was not surprised when bucket shops were mentioned. what is the difference between mtgox and bitcoinica, from your point of view? Everything except source code visibility is different. |
|
|
|
Some of the reasons why I avoided bitcoinica with a ten foot pole, which were obvious right from the start: - The big one -- Zero hard evidence they actually had all the funds claimed, or could produce funds if outsized events (big selloff, big withdrawal, etc.) occur
- Opaque ownership structure
- Zero independent source code auditing or visibility
- Zero proof of any experience at securing wealth from virtual and physical threats
- Zero appearance of adhering to any regulatory structure
Therefore I was not surprised when bucket shops were mentioned. |
|
|
|
So Ayn Rand using Medicare and social security is not a case of hypocrisy because... ?
It is never hypocrisy to live in the real world, while trying to change it. |
|
|
|
Did the developers reach an agreement on how to prune the blockchain?
sipa has been working on his "ultraprune" branch at github. It is discussed on IRC. |
|
|
|
2) "Oh, they won't change their mind anyway, so let's skip this little detail right here and insert this little factually incorrect statement over there..."
See also http://evoorhees.blogspot.ca/2012/04/bitcoin-libertarian-introduction.html: You only need to back up the wallet file once at the beginning (you don't need to do it every day or week, etc) I'd much rather see true statements than comfortable ones when having to chose between the two. I agree, the above needs changing. The size of the pool of reserved keys -- the keypool -- is 100. By default, you absolutely must backup every 100 transactions, or risk opening a window in your backups where keys may be missing. A wise person backs up much more frequently than that, say every 25 transactions or so. However, it is standard practice to increase the keypool size to 1,000 or 10,000 ("-keypool=10000"). Merchants would definitely want to do this. |
|
|
|
A merchant starting out using bitcoin might have 2% or 0.005% or whatever of its sales come from bitcoin transactions. Thus, no -- the low risk possibility of a 51% attack (i.e., has never happened in bitcoin's history) is not material to that merchant. (i.e., coherently weighing the risk, the rational merchant wouldn't change her mind after being informed of the risks associated with the 51% attack.)
1) Risk has nothing to do with precedent. 2) "Oh, they won't change their mind anyway, so let's skip this little detail right here and insert this little factually incorrect statement over there..." And please, ... let's consider how things work in the real world. Merchants don't do business anonymously. They know who their customer is. Any transaction that is large enough to harm the company if there is a payment problem will probably have been been reviewed at multiple levels.
"Even if it happens, it'll be a small transaction, so they won't lose that much money. Let's not mention the possibility of it happening." The standard recommendations for all bitcoin users includes waiting for 6 confirmations, before spending your coins. This is why a transaction appears as "unconfirmed" in the original Satoshi client until such time. One presumes a merchant will follow the standard recommendations, unless they have a specific reason to increase their risk by accepting fewer confirmations. The chance of a 51% attack reversing your confirmed transactions is astronomically low. |
|
|
|
That's exactly what I was going for with my OP.. Any suggestions how I can edit it to make it clearer?
The thread title is thoroughly misleading. There is, in fact, zero proof that pirate runs a ponzi. (however, as you and others have pointed out, there is zero proof that it is not a ponzi also) |
|
|
|
checking for pg_config... no
no
./configure: line 5740: syntax error near unexpected token `,'
./configure: line 5740: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
someone help? Your curl-devel (or libcurl-dev or whatever) package is missing the requisite autoconf macros needed to properly regenerate the configure script. |
|
|
|
after discussion and argument and nit-picking and revision
What happens if I already submitted the pull request and then commit a fix to my patch, so there are now 2 commits in that pull request. Am I supposed to squash the commits into one? Do I need to re-submit my pull request afterwards? You do not have to resubmit the pull request. Squash the commits into one, and then "git push --force" to "rebase" the branch. |
|
|
|
Alterna-coins are a natural outgrowth of bitcoin introducing a new idea into the ideasphere; the fact that it is open source makes cloning the idea trivial. Alterna-coins were always inevitable. If someone can come up with a better bitcoin than bitcoin -- that's great! Humanity benefits from the competition. Speaking as a developer, though, contributing patches back upstream would be nice  |
|
|
|
|
Good stuff. I'll test a T-Mobile refill.
|
|
|
|
|
This new service is a welcome addition to the community.
|
|
|
|
|
The preferred "fixes" for Red Hat, CentOS, Fedora systems are, if you want to do it yourself,
1) Download SRPM
2) Download associated source code from openssl.org
3) Edit SPECS/openssl.spec,
a) replacing source tarball filename with the downloaded one
b) comment out all references to source1
c) remove the "no-ec" stuff from the configure line
4) rebuild with "rpmbuild -ba SPECS/openssl.spec" or similar
5) install build rpms found in RPMS/
|
|
|
|
I also notice it is the first time that the name of Butterfly Labs CTO is disclosed in full: Nasser Gh Moeini. A little more transparency from BFL, like disclosing names of executives, would help increase trust...
+1,000 |
|
|
|
Will coincontrol be merged into this version too?
Certainly not in 0.6.x. We're working on 0.7 which will have many new features and improvements, but 0.6.x only gets bugfixes now. About coincontrol itself: there are still a few implementation problems with it. Technically speaking, gavin's raw transaction API gives full coin control. I agree it is not the same as being implemented in the UI, but it's possible. |
|
|
|
|
Show Posts
