There's a post somewhere in my 3000 posts where I describe the code when new transactions are added to the next block that is being hashed by Bitcoin. Without a quick search finding my post, essentially a new merkle tree and candidate block is created from the current "best" transactions in the memory pool every minute by Bitcoin, and that is what is hashed when mining. (edit - found the post:) Bitcoin maintains a memory pool of all valid transactions that are waiting for a block. This contains all transactions that are valid and at least meet the minimum anti-spam fee rules. It also includes "orphan" transactions, which are not yet funded by a payment in the blockchain. These are relayed to other Bitcoin nodes when first seen. When mining, Bitcoin assembles a sub-set of the memory pool transactions into a block (there may be some or many memory pool transactions that won't fit in the structure of the current block with the miner's rules), and keeps mining the same block data until there are new transactions and it's been over 60 seconds, if 4 billion hashes are done, or if a new network block is announced. Main.cpp // Check for stop or if block needs to be rebuilt
boost::this_thread::interruption_point();
if (vNodes.empty())
break;
if (nBlockNonce >= 0xffff0000)
break;
if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)
break;
if (pindexPrev != pindexBest)
break; Only when these conditions happen is a new Merkle tree built and a new block assembled with another set of transactions (if the block is full, transactions can be bumped out of the temporary block by newer ones with higher priority or more fees). A flood of transactions won't create a CPU denial-of-service attack (for OP here). The transactions (and other block data) that would be included in a block by your Bitcoin is available for your viewing with the Bitcoin RPC command getblocktemplate. When mining for a pool, their Bitcoin assembles blocks the same way (although they may have tweaked the rules). The only difference is pools have an additional layer of software that assigns work to specific miners and keeps track of what miners are working on, and will reject unassigned work submissions. Deepceleron's razor #17: If something is worth saying to a noob, deepceleron has probably already said it.
|
|
|
|
widget?  I posted the php source for this a few posts back in my history. |
|
|
|
|
Namecoin is more a community coin than any other; there are no "official" developers, it is open to contributions from all. This makes it hard to suss out what the best binary client is to use even after perusing the Namecoin forums. Right now I would say the most legitimate build is that on namecoin.info - namecoin_win_vQ.3.72.
The community status also means it won't die, like other alt-coins do when the original "developer" quits after doing their pump-and-dump.
Getting such a new version is required because of a flaw revealed several months ago of a vital signature check not being done by older clients when verifying name updates.
|
|
|
|
When downloading, get the version from github, and then verify the hash with that given on the site. Unfortunately the releases are not signed, so it is conceivable if the whole site was hacked, replacement of the original site could be hard to detect. Here is a paper wallet generator written in Python with some liveCD boot notes in the first post. https://bitcointalk.org/index.php?topic=361092.0 |
|
|
|
|
I've looked through the site and can't find any abuse contact info; in fact their TOS doesn't have anything about no abuse allowed. Irresponsible to allow unfettered content from anony users and have no abuse contact. Possibly the most efficient way to have it killed is to have someone with any copyright standing for any similar code (or that used behind the scenes such as vanitygen) issue a DMCA takedown request, which Google will have to comply with to maintain safe harbor.
|
|
|
|
so i've just gottne back to my charting pc, and triedthe new exe. on launch it throws "the program can't start because python27.dll is missing from your computer."
i'm assuming i could just install python to fix that, but if i can avoid doing so, i prefer to keep a tidy ship.
Uploaded a new exe made the same way as before with dlls included. |
|
|
|
*** Loading data file /xe/_4mkt/2data/bitstampUSD-p4.scid importing /xe/_4mkt/2data/bitstampUSD.csv - No CSV history file found for bitstampUSD, skipping - (Download manually from http://api.bitcoincharts.com/v1/csv/) - (unzip to /xe/_4mkt/2data/bitstampUSD.csv) Request bitstampUSD from 2014-02-15 09:47:20 Got 2014-02-15 09:47:20Z to 2014-02-15 09:47:20Z: 1 trades (43 bytes in 0.208534 sec) -------------------------------------------------------------------------------------- There is a bunch of these cvs.imported files instead in the dir. Why they aren't recognized then? If the csv files have been renamed by sierrachartfeed to ".imported", then all the data in them is already in the Sierrachart SCID file; the ".imported" files and ".csv.gz" files should be deleted after successful import (unless you have a specific reason you might use them again soon; they are obsolete after four days). You can ignore the "no CSV history file found" message - it is not an error in this case, just a normal procedural message. You will get the big *danger* error message (like four posts above) when there is an actual problem that requires you to re-download a new CSV (because the bitcoincharts API only has five-day-old and newer data). The csv files inside the gzips actually start with a period, like ".bitstampUSD.csv". I've done a few tricks to look for the csv either with or without a period at the start. |
|
|
|
|
No, nobody knows how to make a script.
BTW, altcoin spam.
|
|
|
|
Only one of the broadcasted transactions will make it to the blockchain. The malleable copies stay in the memory pool of miners for a while until they are deleted to make way for new transactions. Nothing to worry about.
Shouldn't the miners drop the malleable copies immediately upon receiving a solved block that spends the same inputs? Not just miners, for everybody. Once UXTOs are spent in a blockchain-included transaction, any other transaction spending them are invalid. All non-useable transactions will be flushed upon receipt of the new block. The blockchain only contains blocks, which are the accepted version of transactions that will likely be permanent. |
|
|
|
How often are the csvs updated? I'm away from my charting / mining rig.
nightly |
|
|
|
Okay, it's fixed again, discarding about 100 lines of new code I had written to auto-resume using CSV data. First post updated. You can now manually download and extract the complete zipped history CSVs to the SierraChart data directory, but won't be prompted to do so if it is a new install or if you specify a new ticker symbol you previously hadn't downloaded. It will simply give you five days of history. You also won't have to get CSVs as long as you run sierrachartfeed and have been keeping your local ticker data updated. If you have already run sierrachartfeed to download ticker data and are more than five days behind, the software can't automatically catch up. You will get a dire warning from sierrachartfeed that you need to re-download these CSVs manually: > scfeed.exe -s mtgoxUSD
*** Loading data file C:/SierraChart/Data/mtgoxUSD-p4.scid
importing C:/SierraChart/Data/mtgoxUSD.csv
- No CSV history file found for mtgoxUSD, skipping
- (Download manually from http://api.bitcoincharts.com/v1/csv/)
- (unzip to C:/SierraChart/Data/mtgoxUSD.csv)
Request mtgoxUSD from 2014-01-10 11:49:29
*** Danger! ***
Your saved mtgoxUSD history is 640 hours older
than that available from history website
*** Continuing download will create an unrecoverable gap in trade data ***
Press [c] and [enter] if you want to continue:
- For trades older than 5 days, manually download a new CSV file from
http://api.bitcoincharts.com/v1/csv/You can proceed by typing the letter "C" and pressing enter; in my example above, I just pressed enter, so the program quit and gave info. Happy charting. |
|
|
|
Once again major unannounced API changes at bitcoincharts have broken software. Sierrachartfeed gets CSV data from this URL (this is the only source for trades older than five days): http://api.bitcoincharts.com/v1/csv/As documented here, it was individual nightly CSV files containing all historical trades for each exchange, about 300MB files for the top exchanges. Sierrachartfeed maintains a local copy of the CSV and "resumes", adding new data to your existing CSV file. Now the remote data files are zipped. That means that any previous CSV data that was downloaded is useless. The old file names have changed, the files are now, for example, "mtgoxUSD.csv.gz". This file cannot be resumed, as it is compressed data wrapped in a header and footer. I would need to write gzip-aware software that can strip out the gzipped stream from the current file and rebuild it with added data, and of course unzip to import the new trades. And that's if bitcoincharts doesn't screw up the data contents again - one bit in one early trade changing will change the entire gzipped archive. I don't know if the proper response is to say fuck it and not use data from that site any more, or to show that regardless of their contempt for users and software developers, we can make it work. |
|
|
|
|
CRC32 has 32 bits. Even if there was only one difficulty target of "0" it would be significantly lower in difficulty than bitcoin difficulty 1.
An insecure hashing algorithm such as MD4, as long as it has enough bits for a realistic difficulty, would still provide the same protection against attack as SHA256, there is no specific aspect of the "insecurity" that makes it practically less secure as a block hash. They still have as much practical avalanche and unpredictability. The demonstrated attacks that lead us to call them insecure are, for example, the creation of two datas with a hash collision by researchers, which should instead be computationally infeasible; they do not demonstrate ease of making a 0000f hash of non-user data + nonce in blockchain time scale.
If there was a significant breakthrough in finding target hashes, it could be disruptive if known by only one party to mount 51% attack. If known by all, it would simply create a higher difficulty as long as there are difficulty bits to burn.
For address hash-masking CRC32 would mean only 4 billion addresses could exist, finding keys to spend every address would be easy. MD5 gives 128 bits of addresses (compared to 160 bits of addresses for RIPEMD160) and is more practical and still outside the limits of imaginable attack or collision.
|
|
|
|
|
What is significant about this is that actual victims that have had bitcoins stolen by actual thieves in felonious quantity have been given the complete brush-off by law enforcement, but here they are buying currency from a single individual who is not defrauding anyone, where there is and would be no victim, just to indict.
They can tack on any story that they want to the Bitcoin exchange "he said he got the bitcoins from selling drugs...", "we said we wanted to buy drugs and he sold to us anyway", even if such verbal exchange never happened, and can still harrass people through the plea-bargain or bankrupt you + 20 years jeopardy game. Why did these lawkeys decide that bitcoin currency exchangers were going to be their quota-makers?
|
|
|
|
|
Your computer time needs to be within two hours of block times, and block times need to be within two hours of network consensus time. This likely means your computer's real-time clock is set to local time instead of UTC for linux, or your timezone is set incorrectly.
|
|
|
|
|
Bitcoin has it's own record of all transactions you have made in your wallet.dat; if it didn't, it wouldn't be able to tell you your balance without scanning the whole blockchain every startup or every new transaction.
A wallet file of 2MB is miniscule in comparison to the blockchian. Eventually the size does affect performance, but only when magnitudes in size larger. As a pool, the only thing coming in will be 50 BTCs and the only thing going out will be payments to miners; these two should be separate anyway. The payment wallet can have it's balance sent to a new empty wallet if it begins taking too much processing overhead.
|
|
|
|
|
If it was truly a mistyped address, you would get an invalid address error from the Bitcoin client and not be able to send. The chance of accidentally typing a valid address is one-in-four-billion.
The money was sent to some address, you should examine your transaction history to see what that address was - if it is not yours, you might appeal to the address owner to return the accidentally-sent funds. It is probable that it is some address that you have had interactions with before.
|
|
|
|
|
The best testing option would be no bitcoin.conf file. Just start bitcoin-qt with the -testnet command line option - this will look for data and config files from the Bitcoin/testnet3 directory exclusively, and should ignore your normal bitcoin.conf file in the mainnet directory.
|
|
|
|
|
You should completely rename the .bitcoin hidden directory in your home, then start up Bitcoin-Qt. Bitcoin then should make a new .bitcoin directory with a blank wallet and start downloading the blockchain. If this works, then close Bitcoin and put your backup wallet.dat in that directory. If you get the error again, your wallet file is corrupted.
You can attempt to recover the wallet.dat file in-place by starting bitcoin-qt with the -salvagewallet command-line option, but it would be better to locate an uncorrupted wallet backup.
|
|
|
|
|
Show Posts
