I am interested in doing this movie but there are others that might be interested too. Will this be a competition? If so how will the bitcoins be distributed? Thx.
Each of my prizes can only be won once (first video wins), but different videos can win different prizes. So all nine prizes will eventually be won. There's no time limit. I'm only going to award my "merit prizes" if the point is covered very well. You'll have to devote at least 3-5 minutes of the video to the point. |
|
|
|
What exactly is this 'dust spam' that this 0.01BTC transaction fee "solving"?
It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.
I'm not aware that the network is straining under the weight of the existing transaction volume.
Anyone wishing to send a lot of transactions can already do this by sending x BTC to themselves a lot.
Someone with only one Bitcoin could send 100,000,000 transactions, which might overload the network. This isn't a good solution, though -- the vulnerability will still exist when the limit is lowered because someone will certainly be saving a bunch of Bitcoins. A better solution would be to deprioritize transactions below 0.01 and completely drop them if there are more than 10,000 (or whatever) in the queue. Then these transactions would be slower and less reliable than other transactions, but they would work and not interfere with "real" transactions. |
|
|
|
These two wiki articles explain most of the basics: http://www.bitcoin.org/wiki/doku.php?id=addresshttp://www.bitcoin.org/wiki/doku.php?id=blockTo send a transaction, you say: I was the recipient of this (or these) previously-published transactions. Here's a cryptographic signature to prove it. Change the owner of x coins from my public key to this person's public key. Then they can prove that they own this transaction by making a cryptographic signature, and so on. |
|
|
|
|
Canceled.
If the video makes it to the Digg frontpage, I will pay 1 BTC per digg it gets (max 2000). I'll also pay 500 if it makes it to the frontpage of Slashdot and 500 if it makes it to the frontpage of Reddit.
Even if it doesn't make it on those sites, I will pay 100 BTC per item below that I feel is satisfactorily covered.
- How Bitcoin works technically.
- Why Bitcoin will work economically.
- Why Bitcoin is better than the alternatives (PayPal, Liberty Reserve, cash, etc.)
- How to get started. Won
- (Professional-looking animation and audio.) Won
- (Long-term value for the Bitcoin community.) Won
So you could get a total of 3,600 from me. The video must not contain any major inaccuracies to qualify. I can help answer questions about how Bitcoin works, and there is a lot of info on the wiki.
|
|
|
|
Satoshi posted about this concern: http://bitcointalk.org/index.php?topic=241.msg2071#msg2071Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?
You think people would fail to notice an entire ISP/country/continent falling off the Internet? |
|
|
|
Just because I'm lazy and don't have the code on this machine...
You're saying the hash recorded independently by each node outside the block chain?
Where is the check-point hash stored and how often?
Satoshi includes the hash of a recent block in the code every once in a while. It's not done by each node. Right now, all blocks up to 70,567 are protected from modification. This isn't to prevent any particular attack, but just as a "safety net" that will allow most transactions to be preserved in any possible case. Even without the checkpoints, you would never get ahead of the real chain with this attack. Edit: I added this attack to the wiki's weaknesses article. |
|
|
|
|
It seems that broadcasting your version of block 70,000 or whatever would immediately trigger Reorganize(), which would delete it and make all later blocks invalid. (Assuming I have all the blocks.)
You couldn't modify blocks before ones that are locked in, in any case. (Lockin is at line 1362 of main.cpp.)
|
|
|
|
The block won't be accepted by legitimate users. See ConnectBlock in main.cpp: if (vtx[0].GetValueOut() > GetBlockValue(nFees))
return false; (Line 1089) |
|
|
|
When I upgraded from a version with switch-based passwords to the latest SVN, I ran into a problem: Bitcoin looks for the configuration file in the default "~/.bitcoin/bitcoin.conf" unless I point to any non-existent file. Example: $ ls /home/theymos/bitcoin
addr.dat blkindex.dat debug.log status.sh
bitcoin.conf command.sh debug.log.old.bz2 stop.sh
bitcoind database makefile transfer.sh
blk0001.dat db.log start.sh wallet.dat
$ ./bitcoind -datadir=/home/theymos/bitcoin -conf=/home/theymos/bitcoin/bitcoin.conf && ./bitcoind getinfo
error: You must set rpcpassword=<password> in the configuration file:
/home/theymos/.bitcoin/bitcoin.conf
If the file does not exist, create it with owner-readable-only file permissions.
$ killall bitcoind
$ ./bitcoind -datadir=/home/theymos/bitcoin -conf=/home/theymos/bitcoin/asdf.conf && ./bitcoind getinfo
bitcoin server starting
error: You must set rpcpassword=<password> in the configuration file:
/home/theymos/.bitcoin/bitcoin.conf
If the file does not exist, create it with owner-readable-only file permissions.
Warning: To use bitcoind, you must set rpcpassword=<password>
in the configuration file: /home/theymos/bitcoin/asdf.conf
If the file does not exist, create it with owner-readable-only file permissions.
Bitcoin is using the correct datadir. Hardcoding the path in util.cpp just gives me "error:getinfo" (though maybe I'm not doing it correctly). Removing the "pathConfig.is_complete()" if statement does the same thing. I'm on Linux with glibc 2.10.1. I'm using all of the recommended dependency versions. The only dependency I changed during the upgrade was Boost, which I had to recompile to get the additional libraries that Bitcoin now uses. |
|
|
|
WTF? How did we get on that? AFAIK, the only e-mail is if you tell the forum to do notifications, and I guess the wiki registration. I'd consider turning off the forum notification e-mails, I don't know why we have that.
The PBL blocks all hosts that it believes "should not" be sending mail, without any regard for whether it's actually spamming. Whoever owns the bitcoin.org IP address can request removal here. |
|
|
|
Bitcoin's JSON-RPC deals with floating-point numbers internally, so you need to modify the code to get real precision. Here's a function I wrote to do that: std::string taToString(int64 source)
{
std::string number;
std::string splitnumber;
std::stringstream strstream;
strstream <<source;
strstream>>number;
int ti=number.length()-1;
bool tdone(false);
while(ti>-1 || tdone==false)
{
if(ti==number.length()-9)
{
splitnumber="."+splitnumber;
tdone=true;
}
if(splitnumber.length()==0)
{
splitnumber=number[ti];
}
else if(ti>-1)
{
splitnumber=number[ti]+splitnumber;
}
if(ti<=-1)
{
splitnumber="0"+splitnumber;
}
ti--;
}
return (splitnumber);
} Put that in rpc.cpp and replace all instances of nAmount / COIN with taToString(nAmount). Then you'll get a precise string instead of a double. |
|
|
|
As a follow-up, switching to a completely different ISP (I just created a new "throw away" e-mail account to see what was going on here) I was able to get the registration to be completed. Still, bitcoins.org is on some kind of e-mail blackhole list or at least the ISP that hosts the e-mail server for registration is on one of those lists.
Looks like bitcoin.org is listed on the PBL. |
|
|
|
Stress testing the "test network" is a way to at least not annoy those who are trying to do positive things with Bitcoins. Tests of this nature will naturally be causing more work for others who are not necessarily wanting to be involved in these kind of tests. Those running the test network realize the very experimental nature and don't mind CPU and disk bandwidth being wasted for those efforts.
From a purely ethical point of view, I think it is much better to test on the test network first, especially if it is to exploit something in the communications protocol that you think needs to be strengthened.
The goal (my goal, at least) is to have some working distributed monetary system, not to keep a (potentially) broken system online without interruption. The whole idea of a "test" network is nonsense -- every test should be done on the main network if possible, since real problems that could occur might otherwise be missed. |
|
|
|
Please do these tests on the test network. That's what it's for. Thanks.
You can't get real data from such a small network. Besides, a reliable network must be able to withstand any kind of testing. |
|
|
|
There was a lot of slowdown in the rate of transactions during the second half of the test. If this was a problem with the network, then I would be very worried about future denial of service attacks. Hopefully a bigger test can be organized later. Here is a packet capture of the event (from an "edge" computer with only one connection) if anyone is interested in exact times and stuff. http://www.freefilehostingnow.com/filedownload.aspx?code=6bb2dbeea18e6a419daaadda5798bb05ec6b |
|
|
|
|
- No dependencies.
- A better way of handling "dust spam" than just forbidding those transactions for now. I anticipate problems with this in the future.
- The difficulty should be automatically reduced to the previous level if no blocks are produced for x hours.
- I'd like "complete" documentation: all non-trivial parts of the source code written in English.
I think the existing economic model is perfect.
|
|
|
|
|
Show Posts
