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. |
|
|
|
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. |
|
|
|
|
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".
|
|
|
|
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.
|
|
|
|
|
A simple search for the member name says no. Random PMs are almost always scams, give them the address where they can pay first.
|
|
|
|
a separate question, please:
how can one avoid data gaps when not online? I am using the new bridge.
Also, how can one use the historical data and then continue with the bridge data. when I tried, it does not add the new data at all.
thanks you
I had the same problem! What I did was; I downloaded the mtgoxUSD.scid from here Then I made a new text file and named it scUTC.cmd. I edited this file with this start sierrachartfeedUTC.exe --history=13 I used 13 because as of writing (12-5-2013) the last record in the mtgoxUSD.scid file is over 12 days ago. The default is 7 days, so it skips the 6 days before it creating the hole Once you have all historical data, it does "opening streaming socket..." I added the history command-line option, and set the default to just seven days, to discourage abusing the API server to catch up a full three year history by default. This also makes SierraChart useable for recent trade analysis in just a few minutes instead of hours or never. When you start sierrachartfeedUTC.exe, it will resume downloading from the last timestamp, unless it's been over seven days since you last ran it (or if you are starting with my complete history file that's now 12 days old). The history option sets the maximum number of days back that will be resumed. If you have already downloaded the full SCID file or might not use bridge for over a week, you can then use the history option like above, setting it to 200 days for example, and it will still resume just where it left off when you last ran bridge (not downloading more data than needed). I will update the history SCID download in a bit. This file is made with modified code that downloads history just to a certain checkpoint and doesn't pollute data with live stream, so it is a 100% true record of historical trades. As of now, does Sierra works flawlessly with MtGox API or are there some problems? This gets its data from bitcoincharts.com; mtgox API doesn't have a feature to retrieve past trades. |
|
|
|
You know that you can cut & paste from a console window, right? There is no need to post big repetitive images. You should eliminate (or move into the next group) addresses that are alphabetically higher than 1QLbz7, as these are 58x higher difficulty, and can only be constructed with a 33 character address, equivalent in difficulty to an additional vanity letter. You will also find success in using case-insensitive search by reducing the number of addresses down to ~5000-10000. A case-sensitive search starts at 260 times harder for a 10-character. #vanitygen 1ABCDEfghij
Difficulty: 170408517192794400
[359.39 Kkey/s][total 276224][Prob 0.0%][50% in 10422.0y]
#vanitygen -i 1ABCDEfghij
Difficulty: 654563965779613
[362.34 Kkey/s][total 455680][Prob 0.0%][50% in 39.7y] I suppose I should also point out that the reason you see the error messages in the screenshot I quoted above is that you have lines that duplicate a shorter expression, such as I have demonstrated below: #oclvanitygen.exe -d 0 -i -f 11-14.txt
Prefix '1ABCDEabcdeFG' ignored, overlaps '1ABCDEabcdeF'
Prefix '1ABCDEabcdeFGH' ignored, overlaps '1ABCDEabcdeF'
Prefix '1ABCDEabcdeFGHi' ignored, overlaps '1ABCDEabcdeF' |
|
|
|
Deep celeron, sign your earliest address so OP can put it in there for longest vanity so far. The most remarkable / cool addresses (*) found in the blockchain will be listed below.
It's in the blockchain, he just hasn't "found" it... |
|
|
|
Just trying out SierraChart now. I'm inexperienced and trying to figure out how to get data before <2011/06/26 for gox? For some reason that's as far back as it goes. I used the "Bitcoin Data (MTGOX)" feed that came with the default install. I never tried the "MtGox Bitcoin Trading (under development)" option. Am I doing it wrong?  It sounds like you are using the new Mtgox data direct from SierraCharts, and not the bridge. It may not have a complete history. Try this: 1. Go to menu -> Chart -> Chart Settings, and set "Days To Display" to 1100 or more, 2. Set Bar period to 1-0-0 (1 day per bar), 3. Scroll to the left and see how far back it goes. If they don't have older history, you can follow the instructions for using the sierrachartfeed above, using the mtgoxUSD SCID file, which has all history trades. |
|
|
|
I'm down with adding a ripplescam signature, but I would write it a bit more eloquently. I think their medium-term plan is to get people to transfer them real money to fund their IOUs before they disappear, not just to have a 100% premine coin. Having that message in my signature would make my plan of disposing of those scamcoins on suckers/believers harder though  . |
|
|
|
Hello everyone,
So I am new to Bitcointalk, haven't felt the need to register (can usually find answers to most of my questions just by searching, although now that I am registered I will likely be getting more involved) but I recently became aware of Ripple via stackexchange.
Be aware that there was a flood of Ripple questions and answers on stackexchange, posted and answered by various sock puppets of opencoin, basically using that site as advertising. Take nothing there about ripple as anyone having a real question, nor interpret an answer being an honest one. |
|
|
|
Yes cause they censored them, either conform to our standards or don't do business anymore.
You sure like that word. I thought I did too ... too bad you're well on your way to destroying its meaning. What the heck are you talking about? How was anyone censored? Or are you just happily making up stuff?  The only thing censored is by me hitting the ignore button on the OP and anybody else posting stupid stuff here. Plonk! |
|
|
|
|
Yes, if you want a new driver to work, you can ask (with BTC) a miner kernel developer to rewrite the kernel you have chosen in guiminer to support whatever the newest driver and SDK has done to break OpenCL applications. This will benefit few, as dedicated miners already run the appropriate driver to give them not only working but the fastest hashing, and don't use guiminer.
|
|
|
|
|
2013-05-04 11:50:03 received block 00000000000000ff4aaa342f804a2731bb9f39a784a7f1d86685b35f144cd73a
2013-05-04 11:50:03 InvalidChainFound: invalid block=00000000000000ff4aaa342f804a2731bb9f39a784a7f1d86685b35f144cd73a height=234477 work=1131399971692442463964 date=2013-05-04 11:47:02
2013-05-04 11:50:03 InvalidChainFound: current best=0000000000000051e75ec922ddfed09dc3ca0a72f0e8bbc875d7b3fb370d7524 height=234410 work=1128500345104905542838 date=2013-05-04 01:24:51
This is the crux of the problem, your local blockchain database is corrupted and the client can't build on that. It doesn't have the intelligence to try to get the block 234410 again from the network and replace your screwed up version with the correct one.
You will need to delete the blocks and chainstate directories from your bitcoin data directory and attempt to resync the blockchain from the start. Typically this kind of random corruption indicates bad hardware, such as a bad sector on a hard drive or bad math from an overheating or overclocked CPU.
|
|
|
|
|
The amount of heat generated by 1 kilowatt worth of computer (about four 200W video cards + system + 900W power supply inefficiency):
1kWh = 3,412 BTU
So we need 3400 BTU of A/C to remove that much heat generation.
The the next question is how much power will that cooling require. We must look at the the energy efficiency of air conditioning, which is typically given as SEER (seasonal energy efficiency ratio), which we must translate into an actual efficiency measure.
COP = 3.41214/EER
As a low-water benchmark, lets look at a 5000 BTU window AC unit ($110 on lowes.com website)
Specs: EER=9.7, Watts=515 (calculated efficiency multiplier: 2.84)
So this particular model moves 1462W of heat with 515W. A central AC will be more efficient, so 3000kW * 2.84+ = at least 8000 watts (but nothing left to actually cool your house against summer temperatures).
Real miners don't use AC though, why reduce profitability? Put the units in a closed room with a window fan, or in the garage.
|
|
|
|
|
Bitcoin gives you all you can eat addresses for free! Just put keypool=10000 in your bitcoin.conf file, now your wallet has 10,000 pregenerated addresses in it (you'll have a backup that never becomes obsolete).
There are 1461501637330902918203684832716283019655932542976 possible addresses. That's enough for 100x the world's current population to have 1826877046663628647754606040895353774 addresses each.
There will be a maximum of 2100000000000000 Bitcoin base units (a satoshi, or 0.00000001 bitcoin).
Even if every single base unit that will ever be created were put in a different address, there will still be 1461501637330902918203684832716280919655932542976 empty addresses. The chance of you generating an address that has a satoshi in it will be 1 in 695953160633763294382707063198230.
So in other words, it doesn't matter if you create lots of addresses and delete them. If you never use them, the network doesn't even know they exist.
|
|
|
|
|
Show Posts
