Bitcoin Forum
September 26, 2017, 05:41:15 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
  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 / Development & Technical Discussion / Re: Need help to get raw block data to analyze orphan rates variation over time on: September 18, 2013, 07:09:20 PM
I have re-downloaded and sanitized my blockchain of that cruft several times. What you are asking, to clarify, is someone that still has a Bitcoin client around, with the original blockchain as-downloaded, that was also running continuously (not running continuously = inaccurate record of blocks seen on network). Also remember that duplicate block numbers seen after the first are ignored, not stored, only people that originally believed an orphan would have a chance of still having it.
962  Bitcoin / Bitcoin Discussion / Re: Please review my Security explanation for non-tech users on: September 18, 2013, 02:40:10 AM
Do not run PDFs linked from bitcointalk by unknown users, unless you like to be exploited.

The first feedback is nobody needs to click on a PDF here. There are more holes through Acrobat Reader than there are licks to the center of a tootsie pop.

http://nakedsecurity.sophos.com/2013/09/12/adobe-has-patch-tuesdays-too-a-reader-reminds-us/

963  Bitcoin / Bitcoin Discussion / Re: SHA-256 has no backdoors =/= Bitcoin has no backdoors on: September 16, 2013, 04:11:26 PM
Many of you seem to be lost in translation.


SHA-256 HAS BACKDOORS.

LIKE WINDOWS OS HAS BACKDOORS. That means NSA works with Windows to plant backdoors to access any system. NSA purposely weakens software and plants backdoors in it, SHA-256 is no exception.


It's worse than you think.  All they need is 8 BITS of a SHA-256 message digest and they can backdoor their way to reconstructing your arbitrary length message.  Incidentally this is the same tech they use to store a full year of global telecoms traffic on a thumb drive.
Now you've gone full retard. How about I give you the first 32 bits of every Bitcoin block hash and you reconstruct the message (hint: they are all 0x00000000h).

If I have a SHA256 hash, it will likely correspond to collision with two 257 bit messages, four 258 bit messages, etc. The "arbitrary length message" of Bitcoin is a never-before-seen merkle tree of 256 bit hashes; the information in the hash cannot possibly be used to derive the ~250KB of data per block.
964  Economy / Trading Discussion / Re: SierraChart bridge - Realtime Bitcoin charts [v0.5] (MtGox, Intersango, ...) on: September 16, 2013, 06:34:50 AM
I posted a long post that was eaten by a forum database error. Essentially the bitstamp stream API that other services like bitcoincharts use is broken: https://bitcointalk.org/index.php?topic=38711.msg3124043#msg3124043

Bitstamp has an API for getting historic trades directly, however the request method (by trade number) can't easily be used to resume Sierrachart SCID data (using the last-seen trade timestamp).
965  Bitcoin / Development & Technical Discussion / Re: And the next code line is: ? on: September 14, 2013, 12:13:09 AM
Original Bitcoin code is decently commented compared with many commits these days. What is missing is a script and protocol overview and design document.
966  Other / Off-topic / Re: my face when I looked at satoshis white paper on: September 12, 2013, 04:10:51 AM
Satoshi's brain when he looked at a white paper.


967  Other / Off-topic / Re: Some films that are bit longer than usual on: September 12, 2013, 04:05:48 AM
Hamlet (1996) - 242 minutes

There are many pages and lists elsewhere devoted to this discussion; this is too off-topic for "off-topic".
968  Bitcoin / Development & Technical Discussion / Re: Random number generators used by clients? on: September 11, 2013, 05:44:54 PM
So, again, my question is, can someone who knows about the client code confirm that it's ultimately using /dev/urandom?
The ultimate source of random data for keys is OpenSSL's rand_lib.c. This is where the build options will cause the answer to diverge; when you build Bitcoin, the answer is ultimately dependent upon build config options such as OPENSSL_FIPS (use the FIPS140 engine) and platform.

One would need to investigate the gitian-reproducible Bitcoin builds to give an answer about the official binaries; I've read enough OpenSSL code for this answer that I'm not gonna do this...
969  Bitcoin / Technical Support / Re: Cold storage problems on: September 11, 2013, 03:11:53 PM
Address: 1GRaviTaB5kizyHpt1SUSmwjTJkude8FfE
Privkey: 5JvVieeJr7aq1E7B1sy2y7sZE6m91w62ACvU6UpuUmockSb8MQs

Looks like 51 digits to me. You would get a useful response if you said what you are attempting to do and what non-bitcoin-qt software you are using to create a "wallet".

If that's too much for you, the (less secure) mini-private-key format used on Casascius coins could be adapted to LTC. https://forum.litecoin.net/index.php?topic=2968.0
970  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.
971  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.
972  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."
973  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.
974  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
975  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...
976  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.
977  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.
978  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
979  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
980  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?
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!