btw I am finding vanity addresses aiming for with lower case are much harder to compute seemingly, 1 out of 58 I generated so far with vanitygen -i are lower first char. I think there maybe a target range miscalculation in vanitygen that is discarding valid finds? Clearly all start strings are possible because 1zzz finds lots and so does 1111. The alphabet is [1-0][A-Z][a-z] and strings before 1QQQ are easier. Except 1111 is harder. I am not really understanding why this is. OpenSSL doco says it uses big endian encoding. And the base58 encoder seems to use the same convention, so you would expect restrictions on the most significant digit. However that doesnt seem to be the case empirically.
The address is encoded as 0x1 || hash(160-bits) || checksum(32-bits) which is 193-bits. Now log(58,2^193) = 32.9465 and 2^193/58^32 = 46.676 however the bignum is encoded big endian
Adam
The change happens at a particular address This is a result of how the 25-byte (50 digit hexadecimal) underlying hashes are converted into Base58 (represented by numbers and letters) addresses, and the different maximum values that can be stored in 25 base256 digits vs 34 base58 digits. The Bitcoin address in it's native binary form (that you never see) is 25 bytes, it's parts are: byte 0: Network ID Byte (0x00 for main bitcoin network) byte 1-20: ripemd160 hash (20 bytes) of sha256 hash (32 bytes) of 0x04+public key (65 bytes) byte 21-24: checksum: first four bytes of sha256 hash of sha256 hash of bytes 0-20 above This would be 50 hexadecimal characters long (base16), with a possible digit value between 0-F - 24 bytes or 48 hexadecimal digits of random hash output, plus the beginning "00" byte. We will ignore byte 0, it is always 0x00, and Base58 conversion always preserves this leading 0 byte by directly encoding it as a "1". That means the "vanity" part of the address is generated by the first several bytes of the underlying ripemd160 hash The minimum this can be is 0000000000000000000000000000000000000000 00000000. The maximum value that this can be is FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ffff ffff(the extra 0s and lower case "f"s are the checksum part.) Here are some sample addresses before and after the "wraparound" of the maximum hash value. See how the 1QL a addresses are full length, but the 1QL c addresses are one digit shorter? That is because the only way to have an address starting at 1QLc or greater is by having a binary address that is 59x smaller. There are 59x less possible hashes that will generate a 33 character 1aaaa address than will generate a 34 character 1AAAA address. |
|
|
|
I want to host the blockchain on a cloud server and then point about 50 raspberry pi's to it. Is there a way to do this?
1. Cloud server - no. To have even marginal performance, blockchain files would need to be on a local network drive. The blockchain database works much better on SSD than rotational hard drive. You would be using something much slower than a standard hard drive and sharing it with 50 computers. 2. Rasberry Pi, no. So much slower than a used $25 craigslist computer. 3. The blockchain torrent can be imported into one system's bitcoin-qt. The complete data directory (except wallet.dat) could be copied to other machines so you don't have import multiple times. 4. Then SOME of the blockchain files that never change could be moved to a network drive and replaced with symbolic links on the client filesystems. The only files that won't be changing are past BLK00001.dat-BLK00064.dat files in the blocks sub-directory. The most recent BLK000xx.dat file must not be copied to network, it will still be added to by the individual client bitcoins and must be local and unique to that bitcoin. Your question appears to have nothing to do with the bootstrap torrent. |
|
|
|
Yes ccTLD has geotargeting but does NOT play a role in ranking.
I provided a link to Google's information page so that you can read for yourself. Click here now: https://support.google.com/webmasters/bin/answer.py?hl=en&answer=62399If your site has a generic top-level domain, such as .com or .org, and targets users in a particular geographic location, you can provide us with information that will help us determine how your site appears in our search results. This will also improve Google's search results for geographic queries. This data supplements our existing information, and setting a geographic target won't impact your appearance in search results unless a user limits the scope of the search to a certain country. See a full list of domains Google treats as generic.
Sites with country-coded top-level domains (such as .ie) are already associated with a geographic region, in this case Ireland. In this case, you won't be able to specify a geographic location. In case you can't parse even the above: 1. The geographic setting helps determine how your site appears in search results, and 2. You cannot change your site's geographic setting for ccTLD's in webmaster tools unless they are on Google's treated-as-generic list. |
|
|
|
so if i want to add extra mining rig, do i have to "download" the synchronizing again?
If you are pool mining, you don't need Bitcoin with a blockchain installed at all. |
|
|
|
The degenerate case where you just want an address appears to only work for Bitcoin.
but certain prefixes. I can't generate Li (hashes a long time when it should easily find it), but I can do LiG easily. For some reason Lig says the prefix is not possible, but it should be, right? See: (lightcoin) Valid addresses are in the range: LKDxGDJ-LiZZFKc7
Base58 ALPHABET = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz" |
|
|
|
When was this last updated?
block 216116, it is 240000+ today I am assuming the compressed bootstrap.dat differs in the headers (1st MB) and whatever is appended at the end. So I guess you need to byte compare the first chunk and the last chunk to check my assumption? A file compressed with 7zip is a solid archive with a very large dictionary. Extracting any part of the file requires the data that came before it; essentially you must have the complete 7zip archive to extract data. A multipart 7zip archive is not independent files, the parts are just a binary split of the whole large archive file, and downloading later parts without the first part is useless. You must have all 7zipped compressed data in order to extract a verifiable bootstrap.dat. A future torrent created with multi-part 7z files instead of one big uncompressed bootstrap.dat means that you could supplement your download or seeding by getting some of the torrent multi-part files off different websites where they might be hosted, and manually adding them to the torrent. I am disappointed that 0.8.2 was released without a new checkpoint. Current block is 240709, I could force the issue by creating a block 0-240,000 bootstrap.dat torrent, if many would choose to adopt and seed such a torrent as a new "official" one. I'll see if Gavin is interested in picking a new checkpoint block yet with a code pull. |
|
|
|
Hey guys I'm happy to announce that the .bit chrome extension beta is finally available for download. This extension allows you with a simple download to browse .bit domains! From what I tested it works perfectly but I'll be giving away 10 litecoins for each bug found with proof.
The first bug is that this is using someone else's DNS server; when you type in "mybitcoinwalletsite.bit" they could have changed it's IP destination to their login-stealing spoofing site. It is not documented what DNS gateway it uses. To register your own domains that you are in control of for 0.02 NMC, use the Namecoin client. |
|
|
|
Yeah, you're right, and I'm proposing the idea that every bitcoin client include, as a standard feature, the ability to paste a recipient list into a text box (without regard for formatting whatsoever, as long as it contains recognizable bitcoin addresses and optional amounts per address).
Optional amounts per address? Huh? There should at least be a little bit of technical ability and at leased a feigned desire to send particular amounts to particular recipients in order to multi-bloat the blockchain. Online wallets, even those that store your bitcoins in your own addresses, may have technical hurdles in moving from an infrastructure built on a one-recipient model; they can't even seem to calculate fees correctly. BTW: Cut and paste your list between the curly brackets below (this is the windows-escaped version). A little GUI could take the pasted list, have a single "amount" input box, and verify addresses and issue the bitcoin RPC command. |
|
|
|
|
I'm late...
What's the difference between a potato clock and the internet? The potato clock is a series of tubers.
|
|
|
|
|
Currently Bitcoin doesn't need a long history of orphan blocks with it's current network activity and hashrate. I don't think there has been a two block orphan chain since the blocksize fork or since the BIP16 forkasco.
Other Bitcoin code-based currencies may have attacks and long fork chains, and it is practical to not have a reorg limit or quickly discard orphans, because an orphan chain may become the new best again, and a flurry of unnecessary p2p activity would occur if clients had to re-download the blocks they had discarded.
|
|
|
|
it's a pity the torrent isn't 7zipped...
could the next iteration of it be compressed?
Feedback on this is welcomed. Generally, not all platforms have an easy time getting up and running with 7zip. Users in the past requested something directly usable with bitcoind. Opinions differ, and maybe if it saves a gigabyte or two, it would be worth it. Some users also complain about the doubling of disk space required -- for both compressed and uncompressed copies. It saves more than 3GB currently; 7zip at optimum settings reduces blockchain data to about 57% of the original size. It would reduce the amount of disk space required; the decompressed copy doesn't need to be kept after an import. The compressed file is seeded from the user's torrent directory, and makes for a good checksummed archive of the blockchain for a user to have as a backup too. I wrote unzip/install scripts that can be included with the torrent for one-click extraction http://(deleted)... .... I am slowly convincing myself even more that a compressed torrent is preferable. Without compression you are downloading the same amount of data as normal p2p. The compressed binary would only be repeatable on the exact xz/lzma/7zip build version and settings, but I think there are probably four people total that have run mkbootstrap anyway, so this is not important. It takes about an hour to smash the blockchain down to 60% the size at the extreme settings I've used over many trials to optimize settings. Compressed-Pros:- 2000+ 3000+ MB of uploading and downloading saved for every user, -2000+ MB less storage used when seeding, -won't cause problems if torrent HDD is FAT32 (another: small split files easier to host/share/download from multiple sources than a single 8GB file) Compressed-Cons:-Not as simple to use, end-user must decompress with third-party utility (although 7-zip is common), -More work creating torrent (doesn't matter to end-users), -Cannot "update" torrent by simply replacing data file with newer version with additional blocks (likely to be a rare practice anyway, I am the only one seeding the old torrent right now). Here is example compression, both require about an hour (but decompress in minutes): xz utils 5.0.4/Win64, 3GB+ RAM required to compress (2,780,285,148 bytes) xz --compress --keep --format=xz --check=sha256 --verbose --lzma2=dict=256MiB,nice=273,mf=bt4 bootstrap.dat7-zip GUI win64 - 6GB+ RAM required to compress (2,769,830,975 bytes) Format: 7z, Compression Level: Ultra, Compression method: LZMA, Dictionary size: 384MB, Word Size 273 A checkpoint of 225430 was added two months ago at the fork. I would guess that this will either be updated to a newer block or another will be added to before 0.8.2. https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp |
|
|
|
|
The correct tool to use is pywallet, it can scan the whole hard drive raw and extract any private keys it finds. There is a thread describing how to do this.
|
|
|
|
Something weird is happening here.
The hist api is up and accessible in the browser.
It doesn't look like any api specs have changed also.
But the lovely bridge can't get historical data at all.
Is this user-agent filtering of some sort or something?
The nginx gateway has become very intolerant of the type of requests that were being sent, or the api server was taking to long to return the result. For some reason the default URL http://api.bitcoincharts.com/v1/trades.csv?symbol=mtgoxUSD returns the most recent 20,000 trades again and again with no error, but when specifying a time range, anything other than a very small amount of data gives a 502 gateway timeout error. I altered the parameters of sierrachartfeed to make many small requests instead of desiring larger data blocks. This seems to be working OK. I also increased the default max history to 14 days:
http://we.lovebitco.in/schart/sierrachartfeedUTC-0.6.020.py (requires github source files also)
(new version available)/sierrachartfeedUTC-0.6.020.exe (Win32)
md5sum:
a163db9dc95a5352bac68f4e223d0250 *sierrachartfeedUTC-0.6.020.exe
History files are also updated to today's date; refer back to this full post for sierrachart instructions: |
|
|
|
|
In testing the patch for 0.8.2 that lowers the default included transaction fee, I have had fee-requiring transactions take from the next block to three hours when sending with the reduced fee over the current Bitcoin network. As pools should not be using 0.8.2 yet (but are free to modify Bitcoin and can implement whatever rules they want), a fee below the default sending minimum of 0.0005 per kB for version 0.3.23-0.8.1, for transactions that require one, are considered to have been sent with no fee by miners and must compete for the small "free transaction" space reserved in blocks.
There is also a minimum relay fee, which is and still will be 0.0001/kB. Standard nodes won't retransmit fee-requiring transactions below this threshold to prevent network DOS.
Priority rules (documented on the wiki) determine when a transaction is eligible to be free based on the number of confirmations and the input value of the coins funding the transaction. Qualifying free transactions must still compete for a limited space, and depending on the number and type of pending transactions, may take significantly longer than if they were sent with a voluntary fee.
|
|
|
|
Just in case you can't log in: Here you can secure your account by linking One Time Password (OTP) solutions such as a YubiKey or Google Authenticator to various account functions.
Please be careful when linking OTP to Extra Security. Once linked, all changes to the Security Center will require a YubiKey or Google Authenticator use. Try: support@mtgox.com |
|
|
|
|
I was just reading the seizure PDF, and the judge is probably a DHS rubber-stamper; if she didn't sign drone strikes, wiretaps, and seizures daily, she would be replaced.
The evidence presented that mtgox is a money transmitter fails analysis. It is an assault on personal property without trial or process. I could make the same statements:
deepceleron has a bank account,
he regularly sends money to paypal account with the moniker gay-love-supplies,
the paypal money is transmitted to customers in exchange for goods,
a confidential informant had money transmitted to him in exchange for one used inflatable sheep. The informant then transmitted the money back to the account holder in exchange for "TSA anal lube".
Therefore based on my training and experience, deepceleron is a money transmitter and the contents of his accounts are subject to forfeiture.
|
|
|
|
So, any info on whether BTC purchased via Dwolla+MtGox are subject to forfeiture?
That's like asking if radio waves being transmitted through houses without a TV license are subject to forfeiture. |
|
|
|
http://arstechnica.com/tech-policy/2013/05/feds-reveal-the-search-warrant-that-seized-mt-gox-account/In the warrant, a special agent with Homeland Security Investigations (HSI), states that there's probable cause to believe Mt. Gox is engaging in "money transmitting" without a license, a crime punishable by a fine or up to five years in prison. The warrant goes on to demand that Dwolla hand over the keys to account number 812-649-1010, which is owned by Mt. Gox subsidiary Mutum Sigillum LLC. PDF copy of seizure warrant: http://cdn.arstechnica.net/wp-content/uploads/2013/05/Mt-Gox-Dwolla-Warrant-5-14-13.pdfThe warrant also indicates that a seizure warrant was issued for mtgox's Wells Fargo account on May 9. The transfers of money to Dwolla by this account led them to go after the Dwolla account also. For those that thought that the "guidance" from FinCEN was a prelude to enforcement, you win: According to bank records, this transfer was completed through the subsidiary, Mutum Sigillum (sp) LLC. This demonstrates that Mutum Sigillum LLC is engaged in a money transmitting business but is not registered as required with FinCen.
|
|
|
|
|
Show Posts
