Bitcoin Forum
July 07, 2015, 05:35:06 PM *
News: ♦♦♦ If you are using any wallet other than Bitcoin Core 0.10.x or 0.9.5, then you should not trust incoming transactions until they have ~30 confirmations. More info.
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 [49] 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 ... 162 »
961  Bitcoin / Bitcoin Discussion / Re: [ANN] Bitcoin blockchain data torrent on: June 10, 2013, 06:02:28 AM
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.
962  Alternate cryptocurrencies / Altcoin Discussion / Re: The .bit chrome extension beta is now available for download on: June 09, 2013, 10:21:36 AM
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 .bit domains check out:
To register your own domains that you are in control of for 0.02 NMC, use the Namecoin client.
963  Economy / Service Discussion / Re: Simple but powerful feature request for and other wallet apps on: June 09, 2013, 09:54:57 AM
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.
bitcoind sendmany "FromAccountName" "{\"1BiTCoinSNU2BMzf2cN2TK4yzPUA6CnTAd\":.001,\"1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU\":.002}"
964  Economy / Goods / Re: Bitmit promotion: FREE potato on: June 05, 2013, 08:56:51 PM
I'm late...

What's the difference between a potato clock and the internet? The potato clock is a series of tubers.
965  Bitcoin / Development & Technical Discussion / Re: Orphan blocks on: June 03, 2013, 12:15:33 AM
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.
966  Bitcoin / Bitcoin Discussion / Re: [ANN] Bitcoin blockchain data torrent on: May 29, 2013, 01:30:53 PM
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


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.

-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)

-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.dat

7-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.
967  Bitcoin / Technical Support / Re: Searching old HD's on: May 29, 2013, 12:58:42 PM
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.
968  Economy / Trading Discussion / Re: SierraChart bridge - Realtime Bitcoin charts [v0.5] (MtGox, Intersango, ...) on: May 27, 2013, 10:18:53 PM

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 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: (requires github source files also)
(new version available)/sierrachartfeedUTC-0.6.020.exe (Win32)

a163db9dc95a5352bac68f4e223d0250 *sierrachartfeedUTC-0.6.020.exe

History files are also updated to today's date; refer back to this full post for sierrachart instructions:

SCID full history files:
from first trade 2010-07-17 23:09:17, to 2013-05-26 23:59:59 (UTC, tick accurate, precision 2):
(extract to C:\SierraChart\data\ before starting SierraChart) (19.9MB/200MB) (12.0MB/128MB)
969  Bitcoin / Development & Technical Discussion / Re: Current transaction fee criteria (0.8.1+)? on: May 16, 2013, 07:41:03 AM
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.
970  Bitcoin / Technical Support / Re: HELP: accidentally deleted software authenticator for Gox on: May 16, 2013, 06:48:45 AM
Just in case you can't log in:

Quote from: the Mt.Gox Security Center
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.

971  Bitcoin / Legal / Re: Did Karpeles lie? on: May 16, 2013, 06:06:25 AM
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.

972  Bitcoin / Press / Re: 2013-05-15 [ARStech] Feds reveal the search warrant used to seize Mt Gox account on: May 15, 2013, 04:22:58 PM
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.
973  Bitcoin / Press / 2013-05-15 [ARStech] Feds reveal the search warrant used to seize Mt Gox account on: May 15, 2013, 04:12:27 PM

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:

The 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.
974  Economy / Gambling / Re: - The World's Most Popular Bitcoin Game on: May 15, 2013, 01:54:03 AM
Given infinite time (so long as you keep playing regularly) there's no possibility that you'll lose every 50/50 bet you make, due to the nature of infinity.

Given infinite time, both you and Satoshidice will go broke, and you will also have an infinite number of infinitely long losing streaks, due to the nature of infinity. This is why you can't divide by zero, because then you can make any statement you like; when 1/x is simultaneously -infinity and +infinity at zero, I can prove that dogs are cats.  The number pi does actually contain Shakespeare's complete works and every child porn image that will be created, but when infinity is applied to time, it makes no sense, as there is no reason to assume time is infinite when our the laws of our universe have only existed for 14 gigayears.
975  Bitcoin / Technical Support / Re: Is BitCoin forever broken!? WTF IS THIS SHIT on: May 15, 2013, 01:12:21 AM

Good, I hope your wallet never works again.

PS This guy is doing the same thing to other people's wallets, and has been trying to create the most blockchain bloat and dust possible for the least amount in fees with his scam "faucet" ad sites.
976  Bitcoin / Technical Support / Re: May 15 omg what do I do? on: May 15, 2013, 01:08:59 AM
Additionally, you may also remove your hash power from any pools that do not have a stated policy of limiting blockchain bloat and let them know why.

This won't affect any user until a miner/pool creates a block big enough to break older clients again and repeat the fork. It is very easy for a pool to say "We don't need to manually alter the default 250k blocksize of Bitcoin again to purposefully create big blocks".
977  Economy / Scam Accusations / Re: Post-count pumpers (soon to be scammers?) watchlist on: May 13, 2013, 02:14:23 PM
Watching BitshireHathaway - Wait for the scams to begin, this guy is posting uselessness in a thread every minute, 400 posts in 20 days.;u=104984
978  Bitcoin / Development & Technical Discussion / Re: Vanitygen: Vanity bitcoin address generator/miner [v0.22] on: May 13, 2013, 01:19:27 AM
OK. So i attempted using the -X 48 flag and for the prefix I did Light and it just showed the help list of the tags. I'm using oclvanitygen. It isn't working.

Alphabetically "Light" is past the range of possible lightcoin (network 48) addresses. Valid addresses are generally in the range: LKDxGDJ-LiZZFKc7

You could search case insensitive, since "LiGHT" is still valid.

D:\Bitcoin\vanitygen-0.22-win>vanitygen -X48 -i Lightco
Difficulty: 1138380
Pattern: Lightco
Address: LiGHTcoirUn9XjtBqZWGyTf4o91RGerLZQ
979  Other / Beginners & Help / Re: Sent btc from Blockchain android app w 0 miner's fees = stuck in limbo land on: May 13, 2013, 12:54:40 AM
The reason is because sometimes these companies have agreements saying in exchange for including blocks with fees you also need to complete any blocks without fees in order for those orders to not get stuck. It would stink if someone accidentally sent something without a fee and it got stuck so neither party could access it.

What manner of nonsense be this??

I understand this is bc the miners require an incentive to include it in their blocks, so no fee means btc purgatory.  But why is this not a problem when sending from the standard bitcoin app?  The amt was 3.91 so it's not microtransaction.

A transaction is a message transmitting a desire to send money. The money isn't someone else's until it is included in the blockchain, also known as "being confirmed". Technically it's still in your wallet.

A transaction that doesn't include the minimum relay fee will be retransmitted by very few other nodes on the network. The message will be essentially blocked if it resembles spam. Most of these do find their way to some miner that includes them, although it may take hours or days.

A fee isn't always required, but even if it's not, not including one will likely delay blockchain inclusion. I just search my posting history to find an appropriate quote of a quote...

The age of the coins and the amount you are sending will determine whether you can send for free. Sending without the minimum fee when it is required will cause you headaches later, and the Bitcoin client won't let you do it.

First, recognize that a transaction is made of:
- inputs - the funding source(s), the individual payments you previously received, and
- outputs - the amount(s) you are sending to different addresses. Typically only one or two outputs, but you can send to many people in one transaction if you want.

The baseline calculation for "when it becomes free" is 1 BTC after one day. If the input of your transaction is a single 1 BTC payment you received over a day ago (144 confirmations), then Bitcoin-qt won't require a fee, even if you are only sending .1 BTC to someone else (the other .9 is also sent, but it's sent back to your wallet as another output). Likewise, if your balance is from a single 0.1 BTC, a transaction using that payment would be free to send after 10 days of confirmations.

The above examples are when your transaction is made of one input. Often a transaction will be made of many smaller previous payments to you, put together by Bitcoin in whatever way it calculates will minimize the change that needs to be sent back to you. Therefore, it can be harder to know if you will need a fee without actually attempting to send the transaction. No "warning, requires a fee" message? That means a fee was not required, and only your optional fee (if set above 0) will be included.

If any output of your transaction is less than 0.01 BTC, a minimum fee is required regardless, to keep people from cheaply spamming the blockchain by sending the same money over and over.

A transaction sending 0.4 BTC with 100 confirmations is not high enough priority to send with no fee.

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

((0.4 * 100,000,000) * 100) / 258 = 15,503,875

Transactions need to have a priority above 57,600,000 to avoid the enforced limit. I would recommend ANY payment include a fee even if it would qualify to be free, as "free transaction" space in blocks is limited, and profit-motivated miners have no incentive to include free transactions over those with fees.
980  Bitcoin / Development & Technical Discussion / Re: Vanitygen: Vanity bitcoin address generator/miner [v0.22] on: May 12, 2013, 11:56:34 PM
Is there a way to specify for it to generate a short address, perhaps as short as 27 characters? The limit for the length is anywhere from 27 to 34. 34 by far the most common.

I have yet to see a Bitcoin address under 34 characters. I don't think it is possible at all.

It is absolutely possible at all:

Addresses shorter than 33 characters will start with one or more "1"s. A leading 1 in a Bitcoin address represents a direct encoding of a leading 00h byte in the underlying hash. The reason all Bitcoin addresses start with 1 is because the network ID byte of Bitcoin is 00.

I just made some 32 character addresses:
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 [49] 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 ... 162 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!