Bitcoin Forum
August 24, 2016, 06:24:44 AM *
News: When 0.13.0 is released in the near future, make sure that you carefully verify it.
 
  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 ... 166 »
961  Bitcoin / Pools / Re: [22Th]Ozcoin Pooled Mining |DGM 1%|PoT 2%|Stratum+VarDiff port 80 on: September 11, 2013, 02:55:45 PM
Payout threshold reduced to 0.01BTC to help smaller miners.
Please be aware lowering payout threshold below 0.1BTC will likely incur higher fees when you go to spend your coins.

Thanks, I'm still the same GPU miner, but difficulty is now 100M instead of 1.5M of two years ago (this adjustment doesn't even keep up with difficulty)... Just this year:



10 Block Erupters would take nearly a week before earning the old 0.1BTC.
Now BTC0.01  = $1.38 USD = $1.49 AUD = 1.05 = 1 week of $40 ASIC Block Erupter = 1 week of $150 GPU.
962  Bitcoin / Development & Technical Discussion / Re: RNG using Block informations on: September 09, 2013, 12:13:18 PM
I previously published a method using the block hash as a pseudo-random number generator for raffle ticket picking. The block hash is quite random: the only way of manipulating future block hashes is to be a significant miner and discard winning block hashes if they don't meet a criteria, which gives you even less chance of influence than your hashrate would indicate in addition to discarding 50 25 BTCs:

http://we.lovebitco.in/raffle.html

Hey guys,

okay, first of all I'm new to this crypto stuff and I know the issue of "Provably Fair" has been discussed over and over again. Yet I haven't quiet found any definite answer to my approach. What I want to do is make the RNG more transparent by taking the information of the next/current block found (txconf=1).

My approach so far looks like this:

Code:
hmac_sha512($blockhash, $nonce)

Using a 512 bit hash gives the illusion that there is more entropy than there is.

The block hash can be considered as a random number generator, with an even distribution of results between 0 and the current difficulty target, currently 0000000000000031679C00000000000000000000000000000000000000000000. That's currently less than 198 bits of entropy. It would be more appropriate to re-hash the block hash with a secure 160 bit algorithm such as RIPEMD-160 just to be clear in algorithms that that is the depth of the randomness.

A block hash not the best secret for a gambling site, as it not a secret, and your salting method may be discoverable. It is good when a future random number pick will determine a winner and the picking method needs to be verifiable by all.
963  Bitcoin / Bitcoin Discussion / Re: Do u know of any Church thats accepting BTC? on: September 08, 2013, 10:15:50 AM
One night I dreamed I was walking along the beach with the Lord.
             Many scenes from my life flashed across the sky.
                  In each scene I noticed footprints in the sand.
                       Sometimes there were two sets of footprints,
                           other times there were one set of footprints.
 
                                  This bothered me because I noticed
                                that during the low periods of my life,
                             when I was suffering from
                         anguish, sorrow or defeat,
                     I could see only one set of footprints.
 
          So I said to the Lord,
      "You promised me Lord,
         that if I followed you,
             you would walk with me always.
                   But I have noticed that during
                          the most trying periods of my life
                                 there have only been one
                                       set of footprints in the sand.
                                           Why, when I needed you most,
                                          you have not been there for me?"
 
                                 The Lord replied,
                          "The times when you have
                  seen only one set of footprints,
          is when I wasn't getting your money."
964  Economy / Trading Discussion / Re: SierraChart bridge - Realtime Bitcoin charts [v0.5] (MtGox, Intersango, ...) on: September 05, 2013, 05:37:55 AM
It looks like I found another bitcoincharts API bug for you programmers - bitcoincharts doesn't always return the correct 20,000 trades if you only specify the &start timestamp parameter.

Example:
http://api.bitcoincharts.com/v1/trades.csv?symbol=mtgoxUSD&start=1270000000
  - returns timestamps starting at 1279408157 (first trade 17 Jul 2010 23:09:17 GMT)
http://api.bitcoincharts.com/v1/trades.csv?symbol=mtgoxUSD&start=1290000000
 - returns timestamps starting at 1307725482
http://api.bitcoincharts.com/v1/trades.csv?symbol=mtgoxUSD&start=1290000000&end=1299000000
  - returns timestamps starting at 1290001901
http://api.bitcoincharts.com/v1/trades.csv?symbol=mtgoxUSD&start=1320000000
 - returns timestamps starting at 1320000026

edit: seems to be fixed.
edit: and then it's not again.
965  Economy / Trading Discussion / Re: SierraChart bridge - Realtime Bitcoin charts [v0.6.22] on: September 04, 2013, 08:57:48 PM
New version of Sierrachartfeed and direct-download history files, working again

Update 022:
  • Fixed to work again after bitcoincharts API changes,
  • Get all symbols option (--symbols=a) forces immediate history download of known tickers, instead of waiting to discover them only when a trade is seen,
  • Maybe better --help,
  • Error handling changes,
  • Maximum history to catch up default to 30 days.
  • Note, you must have a somewhat correct date/time on your computer or strange things may happen.

and update 023:
  • Days of history option now only enforced for fresh download, will always resume from last date in scid data to avoid creating gaps. (only was an issue because the first API break with 0.5 could have put old dates at end of scid and made downloading go crazy).
  • Fix 1 in 3 chance of not resuming after a long series of "result too big" errors if there were ever 20,000 trades in under 8 seconds. (Simply can't work correctly if there are ever more than 20,000 trades per second due to API limitation)

Code:
Usage: sierrachartfeedUTC-0.6.023.exe [options]

Options:
  -h, --help            show this help message and exit
  -d DATADIR, --datadir=DATADIR
                        Data directory of SierraChart software (default =
                        c:/SierraChart/data/
  -s SYMBOLS, --symbols=SYMBOLS
                        Ticker symbols to download, comma separated. * or a
                        for all. (default = mtgoxUSD)
  -l HISTORY, --history=HISTORY
                        Maximum days if no ticker history previously
                        downloaded (default = 30).
  -y, --disable-history
                        Disable trade history download; get live trades only
                        (default = False)
  -p PRECISION, --volume-precision=PRECISION
                        Multiply volume by this many decimal places before
                        import (default = 2).
  -t, --tickers         List all ticker symbols and exit

note: when using the single-letter option, there is no space between the option and the parameter


Download links:
http://we.lovebitco.in/schart/sierrachartfeedUTC-0.6.023.exe (4.0MB) (windows 32 bit standalone exe)
MD5: 93d1b5930c4f2efae571144920b7e774 *sierrachartfeedUTC-0.6.023.exe

http://we.lovebitco.in/schart/sierrachartfeedUTC-0.6.023.py (python 2.7 source - needs github files also)

SCID full history files (use if your data directory was screwed up by unannounced API changes):
from first recorded trade to Wed, 21 Aug 2013 23:59:59 GMT:
(extract to C:\SierraChart\data\ before starting SierraChartfeed)

MtGox only: http://we.lovebitco.in/schart/mtgoxUSD.scid.UTC.7z (22.6MB/227MB)
  • mtgoxUSD
Other current exchanges: http://we.lovebitco.in/schart/otherALL.scid.UTC.7z (19.0MB/200MB)
  • bit2cILS, bitboxUSD, bitcashCZK, bitcurexEUR, bitcurexPLN, bitkonanUSD, bitnzNZD, bitstampUSD, btcdeEUR, btceEUR, btceRUR, btceUSD, btchkexHKD, btcnCNY, cbxUSD, crytrEUR, crytrUSD, fbtcEUR, fbtcUSD, fybseSEK, fybsgSGD, icbitUSD, intrsngEUR, intrsngGBP, intrsngPLN, justLTC, justNOK, justXRP, kptnSEK, localbtcEUR, lybitCAD, lybitUSD, mrcdBRL, mtgoxAUD, mtgoxCAD, mtgoxCHF, mtgoxCNY, mtgoxDKK, mtgoxEUR, mtgoxGBP, mtgoxHKD, mtgoxJPY, mtgoxNZD, mtgoxPLN, mtgoxRUB, mtgoxSEK, mtgoxSGD, mtgoxTHB, rippleEUR, rippleUSD, rippleXRP, rmbtbCNY, rockEUR, rockSLL, rockUSD, vcxEUR, vcxUSD, virtexCAD, virwoxSLL, weexAUD, weexCAD, weexUSD
Past/retired exchanges (Tradehill, etc): http://we.lovebitco.in/schart/historic.scid.UTC.7z  (3.4MB/32.9MB)
  • aqoinEUR, b2cUSD, b7BGN, b7EUR, b7PLN, b7SAR, b7USD, bbmBRL, bcEUR, bcGBP, bcLREUR, bcLRUSD, bcmBMAUD, bcmBMGAU, bcmBMUSD, bcmLRUSD, bcmMBUSD, bcmPPUSD, bcmPXGAU, bcPGAU, bitchangePLN, bitfloorUSD, bitmarketAUD, bitmarketEUR, bitmarketGBP, bitmarketPLN, bitmarketRUB, bitmarketUSD, bitmeUSD, bitomatPLN, britcoinGBP, btc24EUR, btc24USD, btcexEUR, btcexJPY, btcexRUB, btcexUSD, btcexWMR, btcexWMZ, btcexYAD, btctreeUSD, cryptoxAUD, cryptoxUSD, exchbUSD, freshPLN, globalEUR, globalGBP, globalPLN, globalUSD, imcexEUR, imcexUSD, intrsngUSD, ruxumAUD, ruxumCHF, ruxumEUR, ruxumGBP, ruxumHKD, ruxumHUF, ruxumJPY, ruxumPLN, ruxumRUB, ruxumSEK, ruxumSGD, ruxumTHB, ruxumUAH, ruxumUSD, ruxumZAR, snwcnXRP, thAUD, thCLP, thEUR, thINR, thLRUSD, thUSD, wbxAUD
966  Economy / Trading Discussion / Re: SierraChart bridge - Realtime Bitcoin charts [v0.5] (MtGox, Intersango, ...) on: September 04, 2013, 03:59:04 PM
Bitcoincharts seems to have changed the API again, breaking software (sierrachartfeed might be the only software using it?) It is now returning a list of trades in order from oldest->newest. Epoch time query parameters do strange things:

  • The most recent 20,000 trades are returned if there are no time parameters,
  • If the &start time parameter is used alone, 20,000 trades since the start time are returned,
  • If the &start and &end parameters are used and return > 20,000 results, 20,000 trades since the start time are returned,
  • If the &start and &end parameters are used and return <= 20,000 results, the requested range is returned,
  • If the &end parameter is used alone and if the &end time parameter is after than the first of the most recent 20,000 trades, the most recent 20,000 trades list is truncated to the end time (unexpected/odd)
  • If the &end parameter is used alone and if the &end time parameter is before the first of the most recent 20,000 trades, no results are returned (unexpected/odd)

It would appear that "end" only serves to truncate the results of either the 20,000 trades from "start=" or the most recent 20,000 trades.

Notable is that if you get chunks of 20,000 results chronologically, software can't continue retrieval at the next epoch second after the last trade in the reply - there still might be more trades with the same timestamp. You must request that second again to continue, de-duping or discarding the previous last-second result data, or re-request a smaller time interval (which is what my fixed sierrachartfeed did on the reverse-sorted data). The end of a data request might look like the example below, but there are actually five trades with timestamp 1350659454 - two more trades still to get:
Code:
...
1350659256,11.680250000000,0.970000000000
1350659256,11.699890000000,6.722307690000
1350659287,11.680240000000,0.010000000000
1350659454,11.680140000000,3.000000000000
1350659454,11.680240000000,0.990000000000
1350659454,11.680240000000,1.000000000000

A new download algorithm will need to be written equivalent in work to my first rewrite...
967  Bitcoin / Development & Technical Discussion / Re: New Mystery about Satoshi on: September 04, 2013, 11:14:34 AM
As the extranonces on the Satoshi miner incremented much faster than released code, it is logical to say that not all of the nonce bitspace was searched before resetting the loop and incrementing the extranonce. This is just a small mining code tweak, just significant in that the miner can be identified as not using the "official" release client due to this. Occam's Razor. You can get the same effect by just changing the maximum nonce value at which the loop exits and starts again with a +1 extranonce, as demonstrated in the gmaxwell code above.

You don't need a huge mining farm to make the ~2-4 MHash/s of the baseline miner throughout 2009's difficulty 1. This could even be a prototype multithreading miner, give each CPU thread it's own unique two or three bits of the nonce. The only strange thing is the "gap" of missing nonces, but this may also be from mistaken assumptions leading the methodology of analyzing the bit use.



Figure 1.
968  Bitcoin / Development & Technical Discussion / Re: Vanitygen: Vanity bitcoin address generator/miner [v0.22] on: September 04, 2013, 10:58:51 AM
I installed video driver Catalyst 13.8 beta and it seems to still be working with oclvanitygen on my HD5xxx, going from 11.11.
969  Economy / Service Announcements / Re: Bitmit - Bitcoin shopping mall - Bitcoin market place - Bitcoin auction house on: August 30, 2013, 10:05:17 AM
Users can prevent such XSS attacks themselves with the RequestPolicy Firefox addin. This addon prevents any requests to off-domain sites for content retrieval unless you explicitly allow them on that domain.

This can make some sites that use CDNs broken until you find out which sub-domain is serving the site content or style, but it is a nice feeling to see it blocking 20+ tracking webbugs on common sites like gawker etc. Google, facebook, multiple ad companies, etc don't need to know every site you are visiting on the web, this goes beyond blocking cookies from third parties, it blocks all third-party content.

https://www.requestpolicy.com/security.html
970  Bitcoin / Legal / Re: FinCEN responds to clarification requests on: August 23, 2013, 01:58:30 PM
You can mine and process as much gold as you want and stack it up to the stars, but you are not taxed unless you convert it. I believe Bitcoin will be found to exist under similar principle.

I don't think that is true.  I believe you have to declare the market value at the time you mine it.  I am not sure where people get this notion that nothing is taxed until you convert it.  If you invest in Bitcoin and then make a profit when you sell it you are taxed when you sell it but that is not the same thing as mining or earning Bitcoins for work.  If that were true people would be exploiting that all the time.  Here is a link about bartering income which is related to that issue:

http://www.irs.gov/taxtopics/tc420.html

...along a similar line, catch a baseball, keep it, owe $200,000 in taxes. The tax man is scum.

http://development1.blogspot.com/2007/08/756-irs.html
971  Economy / Service Announcements / Re: Bets of Bitcoin - Bitcoin betting on real world events on: August 23, 2013, 01:24:28 PM
Hmm :
site gives me this error :

Both iceweasel and chromium forward me immediately from https://betsofbitco.in/ to http without warning. Weird indeed. How can I check the certificate in this case?

Code:
$ wget https://betsofbitco.in/
--2013-08-20 01:38:07--  https://betsofbitco.in/
Resolving betsofbitco.in (betsofbitco.in)... 95.211.41.87
Connecting to betsofbitco.in (betsofbitco.in)|95.211.41.87|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://betsofbitco.in/ [following]
--2013-08-20 01:38:10--  http://betsofbitco.in/
Connecting to betsofbitco.in (betsofbitco.in)|95.211.41.87|:80... connected.
HTTP request sent, awaiting response... 200 OK



There is no certificate or encryption, there is likely a htaccess rewrite rule to redirect secure requests to the unencrypted site. Maybe there was a cert/secure site before but they let it expire?
972  Bitcoin / Bitcoin Discussion / Re: On a panel with MasterCard and Visa on: August 23, 2013, 01:07:55 PM
These are problems that are unfixable with credit cards. Until they switch to a something you have + something you know + real crypto that prevents interception or reuse of a payment authorization, guarantee any authorized payment will be instantly and irrevocably paid to the merchant, and quit becoming a better-business-bureau, they will only suck.


Traditional payment networks (...) suffer inherent weaknesses:
  • Some payment fraud is unavoidable,
  • Completely non-reversible transactions are not possible; payment processors are involved in disputes,
  • Identity fraud and remote account takeover using stolen credentials are possible,
  • Payment processors can block funds and freeze accounts,
  • You must provide your credit card or account number to sites, which can be stolen by hackers to spend your money.

Bitcoin has none of these problems:
  • Confirmed Bitcoin payments are absolutely trustable,
  • Payments are non-reversible; money cannot be recalled by the sender,
  • Identity theft is a non-issue - payment recipients don't need to obtain the identity of buyers or store personal information to take payments,
  • Nobody else can interfere with your Bitcoin balance or your ability to send or receive money,
  • You are in control of your money - when you send a payment, the recipient or hackers cannot make other fraudulent withdraws from your wallet.
973  Bitcoin / Bitcoin Discussion / Re: [0.1BTC/domain] Register/host .bit domains with bitcoins on: August 23, 2013, 01:00:44 PM
Thanks for letting others know not to send money to an unmaintained site. Many of the links on dot-bit.org have died without being updated or removed, the site also maintained by khal.

It's better to register .bit yourself with your own namecoins. You only need to remember to frequently do the name_update, there's no reminder that your name will expire after six months or less. If you want someone else to have ultimate control of your domain names, you don't really need a dot bit for that.

http://explorer.dot-bit.org/n/74491
974  Bitcoin / Development & Technical Discussion / Re: How to get transaction info with new client? on: August 19, 2013, 09:20:32 PM
http://bitcoin.stackexchange.com/questions/9147/getrawtransaction-error-code-5
975  Bitcoin / Development & Technical Discussion / Re: Bitoin QT client v0.8.1beta strange balance. on: August 19, 2013, 09:00:21 PM
You paid 0.0065 BTC fees:

http://blockchain.info/tx/63ac32826ea859dcdf38b53b30e5047913bd37c2810bbdd602e10475d0478505

It is because of the transaction size of 12497 bytes from using many small payments:

http://blockchain.info/tx/63ac32826ea859dcdf38b53b30e5047913bd37c2810bbdd602e10475d0478505?show_adv=true

976  Economy / Collectibles / Re: CASASCIUS PHYSICAL BITCOIN - In Stock Now! (pic) on: August 19, 2013, 07:53:30 PM
Einstein once said, "Genius is one percent inspiration, ninety nine percent perspiration." Well, I haven't met Casascius, but I have a feeling if I did, he would be one sweaty guy.
Einstein never said that.
You win, Einstein! Now lets see the mathematical proof he didn't.
977  Bitcoin / Bitcoin Discussion / Re: Isn't a paper wallet less safe/secure than an encrypted wallet on flash drive? on: August 19, 2013, 09:24:32 AM
You can have many paper wallet copies of your private key that can't be stolen from you

ciphertext:

50 shades of gray, hardcover, first edition


Brainwallet = decoding method

start at N pages from front of book
start up M from bottom of page
start in O characters from start of line
retrieve P characters from each page
skip forward in Q page steps
until you have characters from R pages total

SHA256 hash the retrieved characters S times = private key

Replace the Ns with numbers significant to you; even if all the numbers are all "2", just the method obfuscates it beyond retrieval. Something I have (but many have) + something I know.

Nash would enjoy finding the bitcoins sent to spies encoded in the New York Times.

I do not use this method, but if I had a completely different method I actually use, I wouldn't tell you.
978  Economy / Collectibles / Re: CASASCIUS PHYSICAL BITCOIN - In Stock Now! (pic) on: August 19, 2013, 08:50:11 AM
Einstein once said, "Genius is one percent inspiration, ninety nine percent perspiration." Well, I haven't met Casascius, but I have a feeling if I did, he would be one sweaty guy.
979  Alternate cryptocurrencies / Service Announcements (Altcoins) / Re: Single bet is better than a martingale for doubling your money. on: August 12, 2013, 06:56:29 AM
A series of bets with an infinite possible number of bets will always win a single bet unit.

I guess that's the question.  Isn't it possible to lose forever?
If the probability is greater than zero, I can always move forward in the series of bet outcomes until I find a win. In an infinite series of wagers, there are an infinite number of wins yet to be won.
980  Alternate cryptocurrencies / Service Announcements (Altcoins) / Re: Single bet is better than a martingale for doubling your money. on: August 12, 2013, 06:18:30 AM
A martingale sequence, for example a 50% chance to win martingale with a starting bet of 1 btc, zero house edge and no bounds will always result in a profit of 1 btc at the end of the sequence - regardless of the length of the sequence. It won't double or lose any coins. It will have an infinitely better chance of success than an equivalent single bet.

If we can agree on that, I'll get to work on deriving the expectation of a Martingale sequence when there is a house edge (which I think will be a mite trickier).

I don't like it.  Bound it at any finite point and expected profit is zero.  But let it go that extra "little bit" to infinity and the expectation leaps to +1?

The expectation of an n-step martingale sequence is:

E = p(win_any_bet)*1 - p(lose_all_bets)*sum_of_bets
= (1 - 0.5^n)*1 - (0.5^n)*(2^n - 1)
= (1 - 0.5^n) - (1 - 0.5^n)
= 0

In the limit as n->infinity, E=0->0

Where's the mistake here?


A sequence of martingale losses followed by a final win (in a 50/50/double up scenario):

Lose 1+2+4, Win 8 = +1
Lose 1+2+4+8+16+32+64+128+256+512, Win 1024 = +1

A series of bets with an infinite possible number of bets will always win a single bet unit. However in the real world a limited maximum bet or limited gambler bankroll means that the last bet might not be able to be placed - if the last bet above could not be placed, the gambler would bust -1023. The gambler wins many single bet units but is as likely to go broke from an unplaceable final bet as to double their money from many +1s (house edge makes the former more likely).
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 ... 166 »
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!