Pages:
Author

Topic: . - page 2. (Read 39116 times)

newbie
Activity: 32
Merit: 0
May 29, 2013, 02:19:14 PM
I can compile blockparser but I have this error when using it:

Code:
user@machine:~/blockparser$ ./parser allBalances

info: starting command "allBalances"
info: analyzing blockchain ...
fatal: Invalid argument: failed to open block chain file /home/user/.bitcoin/blocks/blk00000.dat
Aborted (core dumped)

I'm running 0.8. Is blockparser working with 0.8?

Does this file exist and do you have permission to open it?  Print the output of

Code:
ls -l /home/user/.bitcoin/blocks
legendary
Activity: 1498
Merit: 1000
May 26, 2013, 01:09:21 PM
After interacting with znort987 on IRC I'd advise being very careful in using this software double check any results that you get from it.

I pointed out that he was making some (theoretically and practically) minorly incorrect claims about the analysis this tool produced and his response was confused first failing on technically grounds and then after the technical misunderstand was made clear he became uncivil— calling me and other folks names and such— quite bizarre. While its obviously useful, it's written by someone who apparently hasn't done your thinking for you, so you need to think for yourself.


LMAO more censorship by the Core Dev team, first it was transaction now it is other people software. I mean when does it stop. Honestly power hungry much? So dumb, you, Gavin, and Luke Jr. I really hope another programming team, just takes over and we can be done, this what no competition does in a free market. Creates egotistical, self centered, power hungry people. Know what instead of policing the forum and irc actually make the full node work with a big blockchain instead of putting a band-aid on it. Never saw more power hungry people in my life. Nothing decentralized about bitcoins, it completely centralized with people like this running behind it.
sr. member
Activity: 403
Merit: 251
May 26, 2013, 08:54:01 AM

I'm running 0.8. Is blockparser working with 0.8?

Yes, should definitely work with 0.8.1, just a bit slower than with the older (0.7.x) versions.

hero member
Activity: 637
Merit: 502
May 21, 2013, 09:40:05 PM
I can compile blockparser but I have this error when using it:

Code:
user@machine:~/blockparser$ ./parser allBalances

info: starting command "allBalances"
info: analyzing blockchain ...
fatal: Invalid argument: failed to open block chain file /home/user/.bitcoin/blocks/blk00000.dat
Aborted (core dumped)

I'm running 0.8. Is blockparser working with 0.8?
legendary
Activity: 2940
Merit: 1333
May 21, 2013, 06:59:55 AM
This was most likely because closure (2 inputs being viewed as belonging to the exact same person) is not a 100% measure, as demonstrated some time ago where someone asked others to sign some transactions with him to add his coins to their closure calculation and vice versa.

That someone was gmaxwell.

This seems to be the IRC chat they're referring to:

Quote
--- Log opened Sat Mar 09 00:00:01 2013
12:23 -!- znort987 [~znort987@gateway/tor-sasl/znort987] has joined #bitcoin
12:24 < znort987> ;;gpg eauth znort987
12:24 <@gribble> Request successful for user znort987, hostmask znort987!~znort987@gateway/tor-sasl/znort987. Get your encrypted OTP from http://bitcoin-otc.com/otps/FD5AA2A5E26602B0
12:26 < znort987> ;;gpg everify freenode:#bitcoin-otc:f6c4d80bf1e5f7f84a1cae73581f3a7d824b23838dccc6a8e3715ac1
12:26 <@gribble> You are now authenticated for user znort987 with key FD5AA2A5E26602B0
13:50 <@gmaxwell> "Compute the list of addresses that provably belong to the same person"  = fail.
13:50 <@gmaxwell> znort987: can you fix that claim?
13:50 < znort987> gmaxwell: fail, "how so" ?
13:51 <@gmaxwell> Before your software results in someone getting prosecuted for someone elses crime or other facepalmery.
13:51 <@gmaxwell> znort987: being common authors on an input does not imply common address ownership.
13:51 < comboy> znort987: that was posted probably befoe multisig?
13:51 <@gmaxwell> even without multisig.
13:51 < comboy> without multisig it does not prove that?
13:51 <@gmaxwell> E.g. you can have a transaction where I provide one input and you provide another.
13:52 < znort987> All I'm hearing are claims, and not explanation forthcoming
13:52 <@gmaxwell> wtf.
13:52 < comboy> ah, indeed
13:52 <@phantomcircuit> znort987, let me save you some time
13:52 <@gmaxwell> znort987: wow. I just explained it.
13:52 <@phantomcircuit> if gmaxwell assets plainly that something is true, you can pretty much be sure that it is
13:53 < jouke> gmaxwell: just give him the address :>
13:53 < znort987> phantomcircuit: sure. That still doesn't explain it.
13:53 < Scrat> i've seen gmaxwell make typos. ha ha!
13:53 <@gmaxwell> znort987: Okay, I'm not sure what was unclear there.
13:53 < comboy> znort987: you could probably only assume same author if it was signed by the same priv key
13:54 <@phantomcircuit> znort987, valid transactions can be constructed in which multiple parties sign the input portion of the transaction
13:54 <@gmaxwell> znort987: We write a transaction it has two inputs. 1znort987 and 1gmaxwell.  Each of us respectively sign the transaction for our own inputs. This does not mean we are the same person.
13:54 < znort987> ok, problem is fixed
13:54 <@phantomcircuit> znort987, in short your assumption is wrong
13:54 <+TuxBlackEdo> znort987, when people make bitcoin transactions, sometimes two people that don't know eachother exchange private keys to make a transaction to someone else
13:54 <@gmaxwell> TuxBlackEdo: or just jointly sign
13:55 <@phantomcircuit> TuxBlackEdo, dont need to exchange private keys, just sign the same outputs
13:55 <+TuxBlackEdo> oh yeah
13:55 <+TuxBlackEdo> but still
13:55 <@gmaxwell> People also transfer ownership of privkeys.
13:55 <+TuxBlackEdo> how often does that happen
13:55 < Scrat> what about disassociative mixing? then it will assign ownership toi completely different people
13:55 < znort987> p(keys owned by same person) = count(weird tx assembled by folks who can understand the shit you guys are talking about)/count(all transactions)
13:56 <@phantomcircuit> TuxBlackEdo, often enough that assuming people are linked by same signed inputs is invalid
13:56 <@gmaxwell> E.g. I can take a key with a long history and load in into mtgox. Mtgox will then very likely sign with it in a transaction with keys from other people.
13:56 <+TuxBlackEdo> i am sure one could get in trouble just by being the first relayer of a transaction
13:56 < Scrat> znort987: b.i mixer. used by many people
13:56 < znort987> therefore, fix  = s/provably/very likely/
13:56 <+TuxBlackEdo> "oh you forwarded me a drug transaction, that must mean you must be a drug dealer"
13:56 < comboy> znort987: then s/provably/very likely
13:56 < znort987> Are sphincters relaxing now ?
13:57 <+TuxBlackEdo> ^
13:57 <@phantomcircuit> znort987, no actually because of the mtgox private key load it isn't even likely
13:57 <@phantomcircuit> there are very simple tools to upload your wallet.dat to mtgox
13:57 <@gmaxwell> znort987: It looks like the b.i 'shared send' (replacement for their mixer service) works this way normally.
13:57 <@phantomcircuit> so indeed any correlation is *highly* suspect
13:58 <@gmaxwell> So I wouldn't be surprised if a few percent of txn on the network are like that now.
13:58 <@gmaxwell> But sure, I agree that its likely, though it'll be less of an indicator in the future.
13:58 <@gmaxwell> But seriously, be more careful with the provably in the future. Tongue
13:59 <@phantomcircuit> gmaxwell, i suspect the amount of mixing sr engages in actually makes even current assumptions incorrect
13:59 <@phantomcircuit> i've moved coins through there to find out and i honestly couldn't figure out where they came out
13:59 < znort987> For the anal retentive crowd out there, in general, there is no such thing as a proof in the real world. Just high probabilities.
14:00 < Scrat> phantomcircuit: same goes for gox withdrawals sometimes
14:00 <@gmaxwell> znort987: there are orders of magnitude, however.
14:00 < Scrat> or using the green address
14:00 <@phantomcircuit> znort987, the point is that the probabilities are likely low but even so unknowable
14:02 < znort987> Nope. The point is : is the information extracted that way any kind of useful. I claim that as things stand today, they are, notwithstanding the language lwayers.
14:02 < znort987> *lawyers
14:02 <@gmaxwell> znort987: often we talk about proven when the chances are astronomical absent a mathmatical breakthrough. Your clam was likely invalid for a substantial percentage so of addresses holding coins. (due to your use of the word belong)
14:03 <@phantomcircuit> znort987, forget lawyering, your odds are just plain wrong
14:03 <@phantomcircuit> there is a lot more mixing going on than most people thing
14:03 <@gmaxwell> znort987: 'any kind of useful' sure. Proven absolutely not. Very likely?  eh. maybe.
14:03 <@phantomcircuit> think*
14:03 <@phantomcircuit> a *lot* more
14:04 <@phantomcircuit> gmaxwell, actually i would say the odds are very low unless it's a satoshi dice transaction
14:04 <@gmaxwell> I would not even be surprised if your claim was incorrect for a simple majority of coin ownership weighed addresses, simply due to shared wallet usage.
14:04 < znort987> You guys are in the wrong business. I'm thinking you ought to give a try to fly fucking or classifying dead invertebrates. If there was olympic games for nitpicking you'd likely be in it.
14:04 <@phantomcircuit> most people are really using shared wallets of some kind
14:04 <@phantomcircuit> lol
14:04 <@phantomcircuit> while that was hilarious
14:04 <@phantomcircuit> (im drunk enough that that was funny)
14:04 <+TuxBlackEdo> znort987, i think you need to calm down, these are smart people
14:04 <@phantomcircuit> you're still wrong
14:05 <@gmaxwell> znort987: 'nitpicking' when your claims are objectively incorrect on a substantial number of channels, and could cause people harm? give me a break.
14:05 < znort987> intelligent != smart. A textbook example if there ever was one.
14:05 <@gmaxwell> znort987: how about you behave responsibly with your software, and work on your civility a bit too? enh?
14:05 <@phantomcircuit> gmaxwell, sigh i really want to ban him but i know im too drunk to make such a decision
14:05 <@phantomcircuit> :|
14:05 <+TuxBlackEdo> znort987, the only one with a tight sphincer is you, right now.
14:06 <@gmaxwell> hm. s/channels/transactions/  (this is what I get for concurrently talking and typing)
14:06 <@phantomcircuit> as TuxBlackEdo says
14:06 <@phantomcircuit> my sphincter is very loose
14:06  * phantomcircuit lols away
14:06 <+TuxBlackEdo> phantomcircuit, i know Wink
14:06 <@phantomcircuit> ahahah
14:07 <+TuxBlackEdo> no homo.
14:07 <@phantomcircuit> yeah sure
14:07 <@phantomcircuit> whatever you say
14:07 < znort987> gmaxwell: "responsibly" ? Are you actually dumb enough to believe that someone would use this in a court of law ? You must be living in the US.
14:08 <@phantomcircuit> zomg can i ban him now
14:08 <@phantomcircuit> pleassseeeee
14:08 -!- mode/#bitcoin [+b *!*znort987@gateway/tor-sasl/znort987] by gmaxwell
14:08 -!- znort987 was kicked from #bitcoin by gmaxwell [znort987]
14:08 <@phantomcircuit> HORRAAAYYY
14:08 <+TuxBlackEdo> i thought gmaxwell was from mexico
14:15 <@gmaxwell> tor user, why am I surprised.
14:15 -!- mode/#bitcoin [-b *!*znort987@gateway/tor-sasl/znort987] by gmaxwell
14:15 <@gmaxwell> https://bitcointalksearch.org/topic/m.1603598 FWIW
14:16 <@gmaxwell> I notice he changed it back to " provably belong to the same person"
14:17 < valparaiso> yes, shame really. Anonymity in the hands of trolls...
14:17 < comboy> huh, that escalated quickly, he shouldn't say "provably", especially in bitcoin community, but still he has done really nice work on this parser
14:18 <@phantomcircuit> jesus crist i have 429 posts on the forum???
14:18  * phantomcircuit needs to get a life
14:18 <@phantomcircuit> :|
legendary
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
May 21, 2013, 05:32:11 AM
The code is open source, so it is not hard to find any scams in it... Please be careful with your accusations, maybe this is why he left?!

I am only saying that gmaxwell found this suspicious.
legendary
Activity: 2618
Merit: 1007
May 21, 2013, 04:35:09 AM
This was most likely because closure (2 inputs being viewed as belonging to the exact same person) is not a 100% measure, as demonstrated some time ago where someone asked others to sign some transactions with him to add his coins to their closure calculation and vice versa.

The code is open source, so it is not hard to find any scams in it... Please be careful with your accusations, maybe this is why he left?!
legendary
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
May 21, 2013, 03:20:26 AM
can someone explain why all znort987 posts have been vanished?

Will

It is probably some kind of SCAM, there was a warning on the beginning by a high ranked user (was it grondilu ?).

So use this code with care.

EDIT: Oh yeah, here it is:
After interacting with znort987 on IRC I'd advise being very careful in using this software double check any results that you get from it.

I pointed out that he was making some (theoretically and practically) minorly incorrect claims about the analysis this tool produced and his response was confused first failing on technically grounds and then after the technical misunderstand was made clear he became uncivil— calling me and other folks names and such— quite bizarre. While its obviously useful, it's written by someone who apparently hasn't done your thinking for you, so you need to think for yourself.

legendary
Activity: 2940
Merit: 1333
May 21, 2013, 01:20:28 AM
I saw tons of likely/unlikely in the code, what do they do?

They are hints to the compiler's optimizer, and tell it whether a condition is usually true or false.

Code like:

Code:
if (condition)
  A();
rest_of_code();
exit();

Could be compiled in one of two ways, depending on whether the condition is usually true:

Code:
test condition
if false, goto rest;
A();
rest: rest_of_code();
exit();

or usually false:

Code:
test condition
if true, goto do_A;
rest: rest_of_code();
exit();

do_A:
A();
goto rest;

In both cases, when condition has its expected value no 'goto' is executed and so the code is faster in that case.
hero member
Activity: 637
Merit: 502
May 20, 2013, 09:27:49 PM
I can compile blockparser but I have this error when using it:

Code:
user@machine:~/blockparser$ ./parser allBalances

info: starting command "allBalances"
info: analyzing blockchain ...
fatal: Invalid argument: failed to open block chain file /home/user/.bitcoin/blocks/blk00000.dat
Aborted (core dumped)

I'm running 0.8. Is blockparser working with 0.8?
newbie
Activity: 32
Merit: 0
May 07, 2013, 03:41:01 PM
No more bounty.  I finally successfully compiled.  Turns out I was on a micro instance and running out of memory during compile.  I was able to follow these instructions: https://bitcointalksearch.org/topic/ppcoin-how-to-compile-on-ubuntu-1204-110627 to get it working

Run "dmesg" to make sure its a memory failure.  If so you can create a 1gb swap file like so
Code:
sudo dd if=/dev/zero of=/swapfile bs=64M count=16
sudo mkswap /swapfile
sudo swapon /swapfile

When you're done optionally remove the swap file

Code:
sudo swapoff /swapfile
sudo rm /swapfile

On an unrelated note, before I figured this out I came very close to compiling on a CentOS instance before running into openssl issues found here: https://bitcointalksearch.org/topic/ecdsa-dropped-out-of-openssl-100b-9476  Below are the commands I ran.  They may not all be necessary

Code:
#install dependencies
sudo yum groupinstall "Development Tools"
sudo yum install kernel-devel kernel-headers
sudo yum install openssl-devel
sudo yum install boost-devel

#update sources
sudo yum update

#install wget
sudo yum install wget

#install sparsehash
wget https://sparsehash.googlecode.com/files/sparsehash-2.0.2-1.noarch.rpm
sudo yum localinstall sparsehash-2.0.2-1.noarch.rpm

#update g++ to 4.7
sudo yum install devtoolset-1.0
export PATH=/opt/centos/devtoolset-1.0/root/usr/bin/:$PATH
ln -sf /opt/centos/devtoolset-1.0/root/usr/bin/g++ /usr/bin/g++
newbie
Activity: 32
Merit: 0
May 07, 2013, 04:30:50 AM
.2 bitcoins for anyone who can provide instructions for getting to compile on ec2 ubuntu server 12.04 image.  Been at this awhile now and can't figure out what's wrong.  I've tried installing 32 bit c libs and compiling 32 bit version and that didn't work out.  Tried various versions of g++.  4.7 error may be related to this https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1132899  I tried 4.5 out and it gave me an error of line 80 of dumpTX which I'm assuming is because of newer foreach syntax.  I tried modifying, but this did not seem to help either.  I tried copying my locally compiled version but it just segfaults on the server.  I tried upgrading to 13.04 but kept getting

/usr/bin/ld: cannot find -l-c
collect2: ld returned 1 exit status

hero member
Activity: 767
Merit: 500
May 07, 2013, 02:19:43 AM
can someone explain why all znort987 posts have been vanished?

Will
legendary
Activity: 2618
Merit: 1007
May 07, 2013, 02:03:41 AM
znort what the hell?! Undecided

Why are all your posts deleted + OP censored?
newbie
Activity: 32
Merit: 0
May 07, 2013, 01:01:36 AM
Anyone manage to compile on ec2 ubuntu server?  I tried from a fresh ubuntu 12.04 and 12.10 server and neither worked.  I managed to compile just fine on my laptop running 12.10.  I upgraded g++ to 4.7 from 4.6, but that didn't help.

Code:
$ make
c++ -- cb/allBalances.cpp
c++ -- callback.cpp
c++ -- cb/closure.cpp
c++ -- cb/dumpTX.cpp
c++ -- cb/help.cpp
c++ -- opcodes.cpp
c++ -- option.cpp
c++ -- parser.cpp
c++ -- cb/pristine.cpp
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make: *** [.objs/callback.o] Error 4
hyh
full member
Activity: 182
Merit: 100
1XGKpTag3kNJeeFtsnTYs6TfvWvgG2DtR
April 19, 2013, 12:36:53 AM

Are you using a standard drive or an SSD ?
If the former, the times you are seeing are not really surprising: parsing
8G (the current size of the block chain) requires *reading* 8G of data from
disk. If your disk reads at 20 Mb/s then just the I/O already costs ~ 7mn.


I just tried, when I run the parser, the peak speed is about 56MB/s, although my SSD allows about 250MB/s.

(But that doesn't look like the key problem. It's just the step parseLongestchain(), steps before that takes about 25s, but parseLongestchain() takes about 600s.)
hyh
full member
Activity: 182
Merit: 100
1XGKpTag3kNJeeFtsnTYs6TfvWvgG2DtR
April 19, 2013, 12:19:10 AM
Actually I'm using an SSD... don't know why it is slow.
hyh
full member
Activity: 182
Merit: 100
1XGKpTag3kNJeeFtsnTYs6TfvWvgG2DtR
April 18, 2013, 11:55:57 AM

Are you

   A) On a VM ?
   B) On an encrypted partition ?
   C) On an OS which doesn't generally implement mmap() properly ?



A) No.
B) No.
C) How can I tell? Can you tell me a way to bench mark this, or shall I check the version of some library?
hyh
full member
Activity: 182
Merit: 100
1XGKpTag3kNJeeFtsnTYs6TfvWvgG2DtR
April 17, 2013, 10:45:03 PM

Performance-wise for blockparser, they don't make much
difference anyways (most of the time is spent in I/O).


Actually on my computer most time is spent on parseLongestChain().
It takes about 10 min for my computer to do that.
hyh
full member
Activity: 182
Merit: 100
1XGKpTag3kNJeeFtsnTYs6TfvWvgG2DtR
April 17, 2013, 04:51:24 PM
I saw tons of likely/unlikely in the code, what do they do?

Code:

    #if defined(__GNUC__)
        #define likely(x)   __builtin_expect((x), 1)
        #define unlikely(x) __builtin_expect((x), 0)
        #define ALWAYS_INLINE __attribute__ ((always_inline))
    #else
        #define likely(x)   (x)
        #define unlikely(x) (x)
        #define ALWAYS_INLINE
    #endif


I searched a bit and it says something like make a prediction etc.

Is this the dirty part to make the code fast?

How can I know if it works on my machine or not?

(I mean, how do I know which one is taken in the definition, #if defined(__GNUC__) or #else?)
Pages:
Jump to: