|
Your bitcoins may not be sent from the address you think they are.
1. I get 10 BTC paid to 1myFirstAddress
2. I send 1 BTC to someone, but the unspent remainder is sent to a 1UnshownChangeAddress of mine behind the scenes in my wallet.
3. I send 2 BTC to someone, you look up 1myFirstAddress and won't see it
Bitcoin makes it hard to identify user's addresses and which payments are to other individuals. Blockchain info sites also can't figure out what all of your addresses are in your wallet. Your wallet has many addresses in it, and with the correct etiquette when you receive or request payments, will never use the same address more than once. Stop looking at these sites to watch your transactions or determine your wallet balance, similar questions have been asked dozens of times on the forum.
|
|
|
|
|
The power has been not in the hands of users, but in the hands of pools, for a long time. ASICs are just a technology miners use, it has not fundamentally changed the distribution of hashrate between pools. ASIC users are free, however, to vote to distribute their horsepower to pools in a way that it does not centralize power or give it to those with anti-Bitcoin transaction inclusion/exclusion rules.
"Centralization" is a non-issue, unless one entity gains a majority hashrate AND decides that breaking Bitcoin is worth more than 1800 BTC a day.
The growing difficulty is a good thing, it makes for a higher computational price-of-entry for attack. A determined entity (a three letter agency of a nation state, for example) could have made ASICs long ago, now they would have to overpower all the GPU, FPGA, and ASIC miners currently in existence.
|
|
|
|
|
You will find correct statistics on few gambling strategy sites. People who are competent in math don't gamble (unless it's gamble or death - let's say the mob will kill you if you don't pay back $100,000; if you gamble the $10,000 you do have, there's a 10% chance you won't be murdered). They also don't waste the time making strategy guides.
To answer a question whether it is better to bet one large or many small amounts, that depends on your goal. If you gamble for entertainment, the goal would be to extend your entertainment, not bet your bankroll on one roulette number - a 36 in 37 chance your fun is over in 30 seconds. Play bingo, it wastes all your time for little money. If your goal is to win money, then you should invest in this site's bankroll or open your own casino.
Just like interest compounded daily earns you more than interest compounded monthly, more bets of the same player bankroll earns the casino a compounding return.
Strictly speaking, one large bet has a better probability of a given return vs bust, if the goal is the single bet win payout.
What do I mean by "the goal" - this takes some explanation. Let's take the roulette table, with 2/37 house edge (5.26%). If my goal is to make 35x my bankroll, betting 100% of my bankroll on a number gives me a 2.6% chance of meeting my goal. Betting 1% of my bankroll on a series of number bets until I meet my goal or go bust is a near 100% chance of bust.
If your goal is simply to come out ahead after a set number of bets (where you have enough money to not go bust until you've placed all the bets):
A. the chance you will meet this goal betting a single number with one bet is only 2.6% - although it has a bigger payoff potential, there is a 97% you leave down (actually busted). However, if you bet 100 times on the single number, the chance you will leave the table ahead is 49.1%.
B. the chance you will meet this goal betting once on a color is 47.4%, but after betting 100 times in a row on a color you only have a 26.5% chance of being up at the end.
(If you place the 100 bets in sequence and bet more than 1/100th your bankroll on each bet, there is a chance you go bust before the bet sequence completes, and this further lowers your chance of ending ahead.)
Similarly, if I state my goal is either to double my money or go bust on just-dice, the chance that I double my money with one bet is 49.5%. If I bet 1/10th of that on the same bet until I either double my money or go bust, the chance is higher I go bust (not going to waste my time in R to tell you the odds...)
I'll add a conclusion to my post: gamblers like variance. People buy lottery tickets not because the house edge is 50%, but because there is miniscule chance of millionaire status. The more you bet, the more you reduce variance. If I have 10,000BTC and bet it once on double my money, 49.5% chance I double my money. If I bet 1000000 0.01 BTC bets, the variance is gone and payout approaches the house edge, I might as well be sending 10000 BTC to a site that pays 9900 back.
|
|
|
|
Well, thats a way i understand instantly  downloaded the whole chain over night but next time ill know what to do, thx but maybe someone who is bored could explain whats ment above, i like to get more knowledge im the kind of person that needs to know anything i didnt understood greetz from germany A little searching might get you the explanation (which links here), I'll post this linking there: https://bitcointalk.org/index.php?topic=51456.0 |
|
|
|
Question: Why does the vanityminer only search for 1 specific address from the bounty pool? Wouldn't it be better if it were to compare the calculated address with all the ones requested in the pool?
They must be hashed independently per pool customer due to the key of the customer being part of the generated address, so only the customer can spend from the vanity address. From a glance-through read, it would appear that one would only be able to generate addresses for a single client at a time. Am a wrong, that the hashing and checking will find an address that would work for just one client. Currently, you hash once and see if the public address has any matches from an arbitrary list.
This is a challenge... |
|
|
|
You should run H2 test on the USB sticks. It is a program that writes a pattern to the full reported storage space and reads it back, it will find bad flash or especially counterfeit flash memory with a fake size: http://www.heise.de/ct/Software-zur-aktuellen-Ausgabe-5460.htmlThen you should re-format them FAT32 with full surface check (not quick format). |
|
|
|
That's the 30 day volume. I am maintaining sierrachartfeed so I have the full set of all historical trades, I wrote a python script to extract and sum all individual trades. Tradehill took USD from both sides of the trade, but mtgox takes one half of the trade fee in BTC. |
|
|
|
I just happen to have some data. As of now, the total of all USD trades since the start of mtgox: 5,872,449 trades 50,541,892.44 BTC $1,416,389,568.96 USD MtGox charges a 0.3% to 0.6% commission on both sides of trades depending on the trader's monthly volume. So at 0.3% minimum, revenue would be: 151,625.68 BTC and
$4,249,168.70 USDup to near double that. The real money is in the BTC, valued at over $15m now if they didn't liquidate them. They also suffered a Wells Fargo and Dwolla account being seized - when you do the numbers, they might be able to afford it. There was a period of reduced fees after the hack/outage also. This is just for the USD currency, other currencies are traded separately. They have a large staff to pay too, $30k/yr * 10 employees? BTW repeat of this thread: https://bitcointalk.org/index.php?topic=117478.0 |
|
|
|
SD Profit before fees: 78338.14457765 BTC (1.940%)
Cumulative Fees Paid: 4741.45937500 BTC
SD Profit after fees: 73596.68520265 BTC (1.823%)
Pending Liabilities: -4.63054380 BTC
Final SD Profit: 73601.31574645 BTC (1.823%)
Profit This Month: -3449.13326689 BTC
----
Since Satoshi Dice started, there have been:
Blockchain Tx: 18470736 : SatoshiDice Tx: 10017229 (54.2%)
Blockchain MB: 8139.8 : SatoshiDice MB: 4139.9 (50.9%)
SD Profit before fees: 79432.10509565 BTC (1.963%)
Cumulative Fees Paid: 4757.63777500 BTC
SD Profit after fees: 74674.46732065 BTC (1.845%)
Pending Liabilities: -26.16408998 BTC
Final SD Profit: 74700.63141063 BTC (1.846%)
Profit This Month: 1089.17786380 BTC
----
Since Satoshi Dice started, there have been:
Blockchain Tx: 18574794 : SatoshiDice Tx: 10046036 (54.1%)
Blockchain MB: 8185.4 : SatoshiDice MB: 4151.8 (50.7%)
Somebody's a big loser... or did a big win just roll out of the "this month" period? |
|
|
|
https://i.minus.com/iwmmJsMV3BQnU.pngYou have the memory available. This is likely LevelDB using caches and write buffers to speed things up. Some may want Bitcoin to minimize it's RAM usage, while others may want Bitcoin to run as fast and low latency as possible, so there is no right answer; the default LevelDB memory parameter options are used.
dbcache is set to 25 mb by default, so this can't be the cause. Where? Write buffer=max 4mb (per file), 129 sst files currently... src\src\leveldb\include\leveldb\options.h -> // Amount of data to build up in memory (backed by an unsorted log
// on disk) before converting to a sorted on-disk file.
//
// Larger values increase performance, especially during bulk loads.
// Up to two write buffers may be held in memory at the same time,
// so you may wish to adjust this parameter to control memory usage.
// Also, a larger write buffer will result in a longer recovery time
// the next time the database is opened.
//
// Default: 4MB
size_t write_buffer_size;
// Number of open files that can be used by the DB. You may need to
// increase this if your database has a large working set (budget
// one open file per 2MB of working set).
//
// Default: 1000
int max_open_files; a quote There are other sources of memory usage:
8MB - the default cache
4MB - write buffer (though should only build up if you do 4MB worth of writing)
very large - Unix buffer cache usage for opened files (they are mmapped). If you want to trim this, try tweaking MmapLimiter in leveldb/util/env_posix.cc so it initializes the "allowed mmaps" to 0 instead of 1000. Though this is mostly an accounting issue. The files will be sitting in the buffer cache regardless I think.
I think Bitcoin instantly became one of the largest data sets of LevelDB, with 10GB x a lot of users. |
|
|
|
Instead of an elliptic curve, imagine the curve of this river:  I can describe a position on the river between mile 0 and mile 7 by using both X and Y coordinates, much like a private key describes an X and Y coordinate on the elliptical curve. You will see however that if I only tell you the X coordinate, you can still figure out where on the river you are. This would be the "compressed" river coordinate, telling it to someone would take half as much data. |
|
|
|
|
You have the memory available. This is likely LevelDB using caches and write buffers to speed things up. Some may want Bitcoin to minimize it's RAM usage, while others may want Bitcoin to run as fast and low latency as possible, so there is no right answer; the default LevelDB memory parameter options are used.
|
|
|
|
the file format is invalid for meatstock importer
The file format I created is not specific to any program. You'll have to convert the format/columns yourself. A newer source of exchange data is here: http://api.bitcoincharts.com/v1/csv/ |
|
|
|
What's your suggestion for back up period?
After you have done 50 total of these or any actions which deplete an address from the key pool: - Manually create a new address in Bitcoin - Send money to someone |
|
|
|
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, if 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. 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. |
|
|
|
|
If you are a noob and someone is PMing you out of the blue, chances are it's a spam or a scam anyway.
|
|
|
|
|
"Alternate cryptocurrencies" (with the exception of Namecoin and it's novel namespaces) offer nothing. It's just a bunch of [ANN] SHITCOIN! threads where somebody else thinks they'll get rich by conning losers into their recompile of Bitcoin with a few constants changed. If they didn't break the code themselves with ill conceived ideas, it will be attacked or abandoned anyway. A complete waste of my time. A complete waste of the Bitcoin forum's time.
Profile ->
Ignore Boards Preferences ->
☑ Alternate cryptocurrencies
|
|
|
|
buy some aspics and mine!  |
|
|
|
|
My 1995 Win95 computer had 8mb ram, a 512mb hard drive, and a Pentium 75. So much of Bitcoin - the block chain, mining, verifying transaction signatures, indexing balances - is way beyond the computational power of common computers at the time. If you were to start Merkle tree and signature verification of the current blockchain on such a computer now, it is likely it would never catch up. It is possible that if launched with the birth of the popular internet, it may have had small and slow adoption that technology could keep up with - and 93% of the bitcoins would already be mined.
In addition, the cryptography in Bitcoin wasn't available; it would be based on then state of the art DSA with SHA-0, SHA-1, and/or MD5. However, the digital cash and proof of work research done by many all the way up to the time of Bitcoin's launch still never put the pieces together, and the software tools and libraries were not there; I can't imagine writing crypto and database libraries fit for the job from scratch in 16 bit Borland C++. You would have a better chance of making a working light bulb and generator for the Pharaoh than a practical working Bitcoin 18 years ago.
|
|
|
|
|
Show Posts
