1 2012-09-02 00:14:47 <kreal> ageis, made it work with proxy_pass
2 2012-09-02 00:14:48 <kreal> thanks.
3 2012-09-02 00:14:53 <ageis> ahh
4 2012-09-02 07:18:35 <L00P> Hello
5 2012-09-02 07:19:18 <L00P> Is theae any tool that allows ro repair damaged blockchain in orginal bitcoin client?
6 2012-09-02 07:20:53 <Ernesto_Juarell> does the verify command do it?
7 2012-09-02 07:21:12 <L00P> Due to system failure i damaged blockchaim, most probably the last part so I'd like to delete last ~1000 blocks to restore it
8 2012-09-02 07:21:27 <L00P> I'll try
9 2012-09-02 07:27:19 <L00P> I got "Bitcoin: Error loading blkindex.dat"
10 2012-09-02 07:38:28 <Eliel> L00P: blkindex.dat most likely doesn't survive if you cut something out from blk000x.dat files.
11 2012-09-02 07:38:49 <Eliel> or, more like, survives but the data no longer matches
12 2012-09-02 07:50:56 <Varan> Does anyone know why i get this NullPointerException using bitcoinj: http://pastebin.com/Wa7WYuse
13 2012-09-02 07:51:21 <Varan> I just try to do peer discovery using dns and downloading the chain
14 2012-09-02 07:56:55 <L00P> Thx Eliel
15 2012-09-02 07:57:05 <L00P> I've been afk
16 2012-09-02 08:49:08 <YasminOmar> hi
17 2012-09-02 08:49:47 <YasminOmar> I am willing to developm based on Bitcoin I want to know how to start new alternative bloackchain
18 2012-09-02 08:50:03 <YasminOmar> what is the simplest way to start doing that?
19 2012-09-02 08:52:30 <FabianB> YasminOmar: what's wrong with btc?
20 2012-09-02 08:52:51 <YasminOmar> I need to develop somthing similar
21 2012-09-02 08:53:09 <YasminOmar> I need to fork from Bitcoin like namecoin
22 2012-09-02 08:53:45 <YasminOmar> I have read a lot about alternative block chains but dunno from where to start
23 2012-09-02 08:54:25 <FabianB> YasminOmar: different economics?
24 2012-09-02 08:55:02 <YasminOmar> different currency
25 2012-09-02 08:55:20 <YasminOmar> mmm () related to green-cards some-how
26 2012-09-02 08:56:39 <FabianB> YasminOmar: did you look at the source code yet?
27 2012-09-02 08:57:14 <sipa> why do you need a different currency?
28 2012-09-02 08:57:30 <YasminOmar> Yes , do you mean Bitcoin code? yes i worked on it last year as trial to port it from c++ to c
29 2012-09-02 08:57:54 <YasminOmar> and I compiled it recently under windows the Qt version
30 2012-09-02 08:58:51 <YasminOmar> sipa lets say I need to do new trading platform that keeps traders privacy
31 2012-09-02 08:59:29 <sipa> there have been people thinking about such things
32 2012-09-02 09:00:14 <YasminOmar> mmm I am supposed to use this in feild that till now not so much people explored
33 2012-09-02 09:00:20 <erska> YasminOmar: instructions at end of the thread: https://bitcointalk.org/index.php?topic=10278.0
34 2012-09-02 09:00:26 <YasminOmar> its my master thesis now
35 2012-09-02 09:00:28 <sipa> but you'll need a bit more infrastructure than just bitcoin
36 2012-09-02 09:00:45 <YasminOmar> like what?
37 2012-09-02 09:02:10 <YasminOmar> what are the other infrastructure look like?
38 2012-09-02 09:02:19 <YasminOmar> thanx erska
39 2012-09-02 09:04:33 <wumpus> don't forget to take a look at opentransactions
40 2012-09-02 09:06:35 <YasminOmar> wumpus .. Can you give me a useful link about open transactions?
41 2012-09-02 09:09:58 <Diapolo> wumpus: What about replacing all Q_WS_ occurances by Q_OS_ as Qt5 removes Q_WS_ while Q_OS_ will also work with 4.X.
42 2012-09-02 09:11:50 <Diapolo> this could be done juzt after 0.7 and is of no harm I guess
43 2012-09-02 09:13:20 <Diapolo> it's all Q_WS_MAC special casing for UI stuff ... I greatly dislike that parts anyway ^^
44 2012-09-02 09:13:33 <wumpus> re:opentransactions, I know what they're doing in global terms but I don't know anything about the details
45 2012-09-02 09:14:05 <wumpus> Diapolo: yes, if you can increase 5.0 compatibility without breaking anything for 4.x that's always good
46 2012-09-02 09:14:38 <wumpus> but a big point of ot is private anonymous trades/transactions, they have a irc channel here too #opentransactions
47 2012-09-02 09:22:31 <Diapolo> wumpus: Did you read my last comment on my Reset pull? Even if it's not for 0.7, I would like to know how we can achieve a consensus with it :).
48 2012-09-02 09:33:18 <wumpus> Diapolo: I haven't really had time to think about that yet
49 2012-09-02 09:34:27 <wumpus> anyway I think any solution that doesn't change the behavior of OptionsModel::data from the current one is preferable
50 2012-09-02 09:35:12 <Diapolo> that's okay, I'm out for now
51 2012-09-02 09:35:25 <Diapolo> ^^
52 2012-09-02 09:37:20 <babalu> Hi
53 2012-09-02 09:37:52 <babalu> I've a problem using bitcoind api with php
54 2012-09-02 09:38:03 <babalu> because if i use this command to get balance $bitcoin->getbalance($username, 6); print_r($user_balance." ???");
55 2012-09-02 09:38:16 <babalu> it return just an integer 0
56 2012-09-02 09:38:41 <babalu> while the real balance is 0.005
57 2012-09-02 09:39:31 <babalu> any suggest on how to solve this?
58 2012-09-02 09:39:54 <denisx> maybe an integer problem?
59 2012-09-02 09:40:05 <denisx> test it with more than 1 bitcoin
60 2012-09-02 09:40:37 <babalu> lol i don't have one bitcoin :/
61 2012-09-02 09:43:01 <babalu> ah
62 2012-09-02 09:43:02 <babalu> solved
63 2012-09-02 09:43:07 <babalu> my fault
64 2012-09-02 09:43:29 <babalu> just have to settype($user_balance, "float");
65 2012-09-02 09:43:56 <denisx> yeah, thought so
66 2012-09-02 09:44:34 <babalu> is there a type better than float that should i use?
67 2012-09-02 09:45:34 <denisx> I don't know php, but in c there is also double which is more precise than float
68 2012-09-02 09:47:30 <babalu> denisx: using double now
69 2012-09-02 09:47:32 <babalu> Thank you :)
70 2012-09-02 09:48:54 <keverw> Hey! I noticed gettransaction does not show a from address. :/ Is it possible to get this? Not sure if the new 0.7 might have it...
71 2012-09-02 09:53:44 <kreal> with php and/or mysql always use decimal
72 2012-09-02 09:53:47 <kreal> 15,8
73 2012-09-02 10:01:14 <keverw> Is there a BitcoinQT 0.7 yet? I want to install on my TestNet VM and see if the raw tx api will do want I need.
74 2012-09-02 10:12:35 <sipa> keverw: there is a release candidate
75 2012-09-02 10:17:54 <wumpus> in general, there is no 'from address' for bitcoin transactions
76 2012-09-02 10:19:44 <sipa> keverw: bitcoin transactions do not have a from address; they have previous outputs being spent, and one or more of those previous outputs may have a recognizable address they were previously sent to, but there is no guarantee that the sender of a transaction accepts coins there (or even that it belongs to him)
77 2012-09-02 10:20:57 <keverw> hmm. Well I know that one dice game does it this way??? Would the RawTX api tell me that or would I need a third party?
78 2012-09-02 10:21:25 <keverw> PS. I'm not making a dice game. Working on something that's accountless so want to pay the same way.
79 2012-09-02 10:27:44 <sipa> keverw: what do you need an input address for? for refunds?
80 2012-09-02 10:28:10 <keverw> refunds and some other things.
81 2012-09-02 10:28:56 <Joric> what's the reason of satoshidice if you may martingale it? 0.001 to 250 it's 19 orders of magnitude
82 2012-09-02 10:29:00 <Joric> i believe satoshidice now effectively works as a self-sustaining ddos machine
83 2012-09-02 10:29:01 <keverw> and I put a disclaimer to only use wallets that allow you to receive bit coins from the same address.
84 2012-09-02 10:30:49 <keverw> hmm, maybe I should build a wallet system in to my software??? kinda don't want to but I could I guess.
85 2012-09-02 10:38:56 <sipa> keverw: just ask customer for a refund address
86 2012-09-02 12:15:40 <MC-Eeepc> why is it called ultratrune if its not about pruning
87 2012-09-02 12:31:37 <sipa> MC-Eeepc: it is about using a pruned database for block validation
88 2012-09-02 12:31:57 <sipa> MC-Eeepc: (and it supports pruning, but that's not implemented yet)
89 2012-09-02 12:44:13 <OneEyed> Did Eligius get its logic wrong? 1024 transactions in the last block (http://blockchain.info/block-index/277197/000000000000019e0f9e773f119845416707852e9080eaf1f836e386a81107d0) and only 0.001 in transaction fees :/
90 2012-09-02 12:50:50 <MC-Eeepc> this ultraprune is choking like a $15 whore on this last 4000 blocks
91 2012-09-02 12:53:43 <MC-Eeepc> did some sort of horriffic new chain spam start in the last month or so
92 2012-09-02 13:05:52 <sipa> MC-Eeepc: after the last checkpoint (at block 193000), signature verification is enabled
93 2012-09-02 13:06:21 <sipa> perhaps that's what you notice?
94 2012-09-02 13:06:38 <MC-Eeepc> i dont know whatthat means
95 2012-09-02 13:07:00 <sipa> after block 193000, signatures are verified (and this uses more cpu)
96 2012-09-02 13:07:30 <MC-Eeepc> what are verified signatures
97 2012-09-02 13:07:37 <sipa> before block 193000, signature are not verified (and this uses less cpu)
98 2012-09-02 13:08:15 <sipa> bitcoin transaction contain a cryptographic signature to prove that it is the owner of a coin that sends it
99 2012-09-02 13:08:29 <sipa> full nodes verify those signatures
100 2012-09-02 13:08:52 <sipa> but the software contains checkpointed blocks, and before the last checkpoint, signatures are not verified
101 2012-09-02 13:09:14 <MC-Eeepc> but verifying signatures sounds important
102 2012-09-02 13:09:22 <sipa> it is
103 2012-09-02 13:09:41 <MC-Eeepc> and checkpoints are the will of a handful of guys, and not the hashpower
104 2012-09-02 13:10:01 <sipa> partially true, but the chain is still verified
105 2012-09-02 13:11:09 <MC-Eeepc> wait so if sig verifying was turned on all the way, ultraprun would be no faster?
106 2012-09-02 13:12:25 <MC-Eeepc> ive been impressed with the speed so far but it depends on the compromises made
107 2012-09-02 13:12:31 <MC-Eeepc> which ive been told are not a big deal
108 2012-09-02 13:51:57 <gavinandresen> gmaxwell: to reproduce the error in valgrind, you need a 'move' transaction, then listtransaction ''
109 2012-09-02 14:31:37 <BlueMatt> gavinandresen: ok, the script that runs is at https://github.com/TheBlueMatt/test-scripts/blob/master/build-script.sh if you wanna give running valgrind a try
110 2012-09-02 14:35:05 <BlueMatt> or gmaxwell if you wanted to do lcov
111 2012-09-02 15:38:35 <BlueMattBot> Project Bitcoin build #53: STILL FAILING in 41 min: http://jenkins.bluematt.me/job/Bitcoin/53/
112 2012-09-02 15:51:23 <Joric> is it possible to encrypt/decrypt message using address keypair?
113 2012-09-02 15:53:20 <gmaxwell> Joric: do you mean to ask 'a pair of addresses' ?
114 2012-09-02 15:53:34 <Joric> well, or that
115 2012-09-02 15:53:36 <gmaxwell> If so, the answer is no.
116 2012-09-02 15:54:38 <BlueMatt> is it possible to encrypt/decrypt anything with ecdsa? -> no
117 2012-09-02 15:55:39 <Joric> 'encrypt-decrypt in ECC can be done using El Gamal Encryption over an Elliptic Curve'
118 2012-09-02 15:56:21 <BlueMatt> if you want to take your private key and re-purpose it for an entirely different algorithm...have fun, but...well thats just stupid
119 2012-09-02 15:57:54 <BlueMatt> but, note, I doubt there would be a way to go from ecdsa pubkey associated with a given privkey -> el gamal pubkey from the same priv key
120 2012-09-02 16:06:08 <sipa> Joric: yeah, El Gamal over EC can be used for encryption, but for some reason that's rarely used, afaik
121 2012-09-02 16:06:35 <sipa> ECDH + AES is more common (which uses AES with an ephmeral key to do the actual encryption)
122 2012-09-02 16:06:47 <gmaxwell> Joric: This is why insisted on the address clarification.
123 2012-09-02 16:06:55 <gmaxwell> Joric: You can not do any of these things using _addresses_
124 2012-09-02 16:08:15 <sipa> MC-Eeepc: well you have to trust the source code anyway, no? or at least have faith that people do look at the source, and do verify that the distributed binaries are built from that source (and you _can_ verify this, through gitian)
125 2012-09-02 16:09:07 <gmaxwell> 08:11 < MC-Eeepc> wait so if sig verifying was turned on all the way, ultraprun would be no faster?
126 2012-09-02 16:09:19 <gmaxwell> Ultraprue and regular bitcoin are identical in this respec.
127 2012-09-02 16:09:22 <gmaxwell> re resepect.
128 2012-09-02 16:09:52 <sipa> MC-Eeepc: the checkpoints are similar, but even weaker, as all they can do is prevent you from accepting the right chain; they can't make your node accept a false chain (though making you go accept a valid fork is possible)
129 2012-09-02 16:11:19 <sipa> MC-Eeepc: and indeed, as gmaxwell says: the "no sig checks before last checkpoint rule" was added somewhere in 0.5 iirc; that's not where ultraprune gets its speed advantage
130 2012-09-02 16:11:52 <Joric> what's that major september's announcement? not finished yet?
131 2012-09-02 16:13:29 <MC-Eeepc> so there has been no true self verification of chain since .5?
132 2012-09-02 16:14:22 <MC-Eeepc> how long would that take at this point
133 2012-09-02 16:14:53 <sipa> on my laptop, around 1 hour of extra CPU time
134 2012-09-02 16:15:16 <sipa> (i7-2670QM 2.2GHz)
135 2012-09-02 16:15:33 <killerstorm> I can haz testcoins? moEaekk95oJrdH6JWb7KYEtJEyksKy7Hs1
136 2012-09-02 16:15:39 <MC-Eeepc> i jsut realised bitcoin depends on intel and AMD not going out of business
137 2012-09-02 16:15:42 <gmaxwell> killerstorm: you're running testnet3?
138 2012-09-02 16:16:00 <killerstorm> yup
139 2012-09-02 16:16:12 <gmaxwell> MC-Eeepc: "no true self verification" please don't hype things.
140 2012-09-02 16:16:19 <gmaxwell> MC-Eeepc: It's going to earn you a /ignore from me.
141 2012-09-02 16:16:38 <gmaxwell> MC-Eeepc: bitcoin does all the verification to prevent inflation on install.
142 2012-09-02 16:16:56 <sipa> well he has a point; the deeply buried part of the chain history has not been _completely_ verified by recent clients for a while
143 2012-09-02 16:17:07 <gmaxwell> MC-Eeepc: it's just skipping the ecc sig checks on the deep chain, because they're cpu expensive and not needed to prevent inflation.
144 2012-09-02 16:17:10 <MC-Eeepc> dont get touchy
145 2012-09-02 16:17:12 <kjj_> but it still couldn't change because of the hashes
146 2012-09-02 16:17:29 <gmaxwell> kjj_: yes, but it's not a self validation.
147 2012-09-02 16:17:46 <sipa> indeed, so we've marginally given up zero-trust for SPV-trust regarding the signatures in a deeply buried part of the chain history
148 2012-09-02 16:17:49 <kjj_> agreed
149 2012-09-02 16:18:04 <gmaxwell> kjj_: But It's also irrelevant to inflation.
150 2012-09-02 16:18:44 <gmaxwell> e.g. I'm a new node, I care very much that the rules were followed so that magic coins didn't come out of thin air in the past. I don't care if other people got robbed in the past.
151 2012-09-02 16:20:07 <kjj_> add a flag or RPC call to do a full verify?
152 2012-09-02 16:20:23 <sipa> i wouldn't mind having such a flag, actually
153 2012-09-02 16:20:37 <sipa> (though i'd make it a config option)
154 2012-09-02 16:20:48 <gmaxwell> an RPC call doesn't make much sense.
155 2012-09-02 16:20:51 <kjj_> I think I'd rather have it as a RPC call
156 2012-09-02 16:21:07 <sipa> you can't do an RPC call before the node is fully running
157 2012-09-02 16:21:17 <sipa> and at that time, you'll already have downloaded blocks most likely
158 2012-09-02 16:21:30 <kjj_> then again, I'd also like a RPC call that quiesces the databases for a copy without having to shut down the node
159 2012-09-02 16:21:45 <gmaxwell> What I tried to get gavin to do initially was just may it randomized. E.g. check 1 in N blocks at random. N could be set high enough that there is basically no performance impact.
160 2012-09-02 16:23:44 <sipa> at least providing the ability to set the software in a mode that fully verifies history would give some extra confidence in the chosen checkpoints, imho
161 2012-09-02 16:24:16 <sipa> of course, if one can mess with the checkpoints, one can mess with the software too
162 2012-09-02 16:24:26 <BlueMattBot> Project Bitcoin build #54: STILL FAILING in 40 min: http://jenkins.bluematt.me/job/Bitcoin/54/
163 2012-09-02 16:24:43 <kjj_> sipa: I agree that most people's needs would be met by just checking at startup.
164 2012-09-02 16:25:06 <gmaxwell> kjj_: I think you're confused about something but I'm not sure what.
165 2012-09-02 16:25:11 <kjj_> sipa: but I'd rather keep my node running and issue a RPC call once a week or month or whenever to check everything
166 2012-09-02 16:25:33 <gmaxwell> oh! you want a checkblocks rpc?
167 2012-09-02 16:25:47 <sipa> kjj_: that's technically not possible really; re-checking would mean resetting the index and re-importing it again
168 2012-09-02 16:26:14 <sipa> the only point at which you can do a completely full validation is when blocks get connected
169 2012-09-02 16:26:33 <gmaxwell> sipa: well it is possible just insanely expensive. E.g. You spin up a background tasks that builds a new index. And when it catches up you compare them.
170 2012-09-02 16:26:51 <sipa> gmaxwell: sure, it's a technical problem, not a theoretical one
171 2012-09-02 16:27:04 <sipa> with the current database layout it would actually be possible to re-connect
172 2012-09-02 16:28:06 <MC-Eeepc> what about that thing where you said you wee shooting for a cleint thats usable right away, but brings itself up to speed gradually too
173 2012-09-02 16:28:45 <sipa> initial headers-only mode? yeah that'd be ncie
174 2012-09-02 16:29:30 <MC-Eeepc> would it be possible to have some sort of hybrid client thats starts out thin, and gradually turns itself into full in the background. And uses a random other full node in the network as its chainserver in the meantime
175 2012-09-02 16:29:39 <MC-Eeepc> or even several at once
176 2012-09-02 16:30:22 <MC-Eeepc> so it starts off not zero trust but usable, but with a random P2P server
177 2012-09-02 16:30:41 <kjj_> if we wander very far down this road we end up with three parts, the blockchain daemon, the network daemon, and the wallet/UI process
178 2012-09-02 16:30:41 <MC-Eeepc> then gradualy becomes zero trust and in turn does the same for other brand new nodes
179 2012-09-02 16:30:55 <sipa> that's a possibility, but i don't think that's what i'd like the reference code to be
180 2012-09-02 16:31:15 <MC-Eeepc> is it a stupid idea tho
181 2012-09-02 16:32:15 <MC-Eeepc> i think it would only work with majority deployment in the network, not a handful of niche clients
182 2012-09-02 16:32:58 <sipa> kjj_: make that blockchain server (store blocks and serve them), verification server (validate and relay transactions and blocks, keep txouts and chain data), wallet process
183 2012-09-02 16:33:29 <kjj_> sipa: I'd want the verification closer to the storage
184 2012-09-02 16:33:35 <sipa> why?
185 2012-09-02 16:33:46 <sipa> they are almost entirely independent
186 2012-09-02 16:34:04 <kjj_> I want the software that stores blocks to check them first
187 2012-09-02 16:34:23 <sipa> well the chain server could be put behind a validation server
188 2012-09-02 16:34:59 <kjj_> I don't want the chain server to trust anything. if the validation server gives it gargage, it should be ignored
189 2012-09-02 16:34:59 <sipa> but there's for example no need for every node inside a trusted network of a large organisation to store blocks; one big block server suffices
190 2012-09-02 16:35:19 <sipa> not sure what you mean
191 2012-09-02 16:36:07 <kjj_> well, what you said wasn't a full description of the protocol between the parts, but it sorta suggests that the storage server accepts whatever is given to it
192 2012-09-02 16:36:49 <sipa> i'd say it stores any block with valid PoW and connectable to the block tree (just like bitcoin does right now, by the way)
193 2012-09-02 16:37:23 <kjj_> it also has to enforce the system's other rules
194 2012-09-02 16:37:29 <sipa> what for?
195 2012-09-02 16:37:46 <kjj_> so that it doesn't store a double spend, for example
196 2012-09-02 16:37:56 <sipa> that's almost inevitable
197 2012-09-02 16:38:00 <sipa> we DO that right now even
198 2012-09-02 16:38:07 <sipa> such a block won't get served, obviously
199 2012-09-02 16:38:26 <sipa> as it won't become part of the active blockchain
200 2012-09-02 16:38:47 <sipa> maybe i shouldn't call the first component "blockchain server" but "block server"
201 2012-09-02 16:39:06 <MC-Eeepc> mfw no one gives a fuck about my idea :(
202 2012-09-02 16:39:09 <kjj_> if it is just storing arbitrary blocks, that makes more sense
203 2012-09-02 16:39:34 <kjj_> MC-Eeepc: it is hard to do. and people will ignore the warnings that their node is unsafe
204 2012-09-02 16:39:53 <freewil> MC-Eeepc, it sounds like a good idea, but i just dont think it's high priority right now
205 2012-09-02 16:40:02 <sipa> MC-Eeepc: sure people do; a client that does lightweight/SPV/full/archive in stages would be very nice; i'm just saying that i don't think it's what the reference client should be
206 2012-09-02 16:40:04 <freewil> bitcoinjs started doing this, a bunch of separate modules/processes
207 2012-09-02 16:40:25 <freewil> exitnode, p2p, wallet
208 2012-09-02 16:40:45 <MC-Eeepc> ha i came up with a good idea for once
209 2012-09-02 16:41:07 <sipa> MC-Eeepc: it's been suggested before
210 2012-09-02 16:41:33 <kjj_> the fun part is that with a split client, the backend block or chain server could do other things, like ask 8 peers for the same block and if they agree, pass it to the next layer
211 2012-09-02 16:41:33 <sturles> When db.log says: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
212 2012-09-02 16:41:38 <sturles> Is that even possible?
213 2012-09-02 16:41:43 <MC-Eeepc> would it be that unsafe considering using multiple totally random p2p nodes as chainservers during the lite phase
214 2012-09-02 16:41:44 <kjj_> sturles: which database?
215 2012-09-02 16:42:02 <sturles> blockhain, I suppose.
216 2012-09-02 16:42:05 <sipa> MC-Eeepc: all depends on which attack model you use
217 2012-09-02 16:42:07 <MC-Eeepc> unles someone knows an IP is about to fire up a new client and surrounds it, but that sounds unlikely
218 2012-09-02 16:42:08 <kjj_> MC-Eeepc: not totally unsafe, but less safe than the current model. and safety is important here
219 2012-09-02 16:42:34 <kjj_> MC-Eeepc: it isn't that unlikely when you consider that an attacker may, in many situations, be able to force that to happen
220 2012-09-02 16:42:38 <sipa> MC-Eeepc: but if you assume the longest chain is always valid anyway, you don't need more than an SPV client
221 2012-09-02 16:43:02 <sipa> MC-Eeepc: the reason to run a full node is exactly because you want to be able to prevent even cases where that assumption is wrong, however unlikely they are
222 2012-09-02 16:43:52 <kjj_> MC-Eeepc: for example, my cable company could totally fuck with all of my home node's bitcoin peer connections
223 2012-09-02 16:44:10 <MC-Eeepc> yes then its all about the non zero trust risk window
224 2012-09-02 16:44:23 <kjj_> MC-Eeepc: and they might not know that I'm going to run bitcoin, but they could safely assume that someone on their network will
225 2012-09-02 16:48:40 <MC-Eeepc> yeah your ISP dicking with you is a harse threat model
226 2012-09-02 16:48:56 <MC-Eeepc> by ISP i suppose we really mean the govenment
227 2012-09-02 16:49:31 <kjj_> that's actually the weakest threat, something a bored network admin would do to pass time on a slow day
228 2012-09-02 16:51:02 <MC-Eeepc> someone doesnt want thier job anymore
229 2012-09-02 16:51:36 <MC-Eeepc> no wait comcast did it to bittorrent and bothing happened
230 2012-09-02 16:51:43 <MC-Eeepc> well tey stopped when people found out
231 2012-09-02 16:58:47 <maaku> did they? i thought that was still a persistent problem
232 2012-09-02 16:58:54 <maaku> one of the reasons for net neutrality and all that
233 2012-09-02 16:59:53 <MC-Eeepc> yeah they stopped because it was blatant
234 2012-09-02 17:00:05 <MC-Eeepc> forging fucking reset packets
235 2012-09-02 17:00:14 <MC-Eeepc> how is that not wiretapping
236 2012-09-02 17:00:22 <MC-Eeepc> but others still throttle and shit
237 2012-09-02 17:48:47 <ThomasV> gmaxwell: care to explain https://bitcointalk.org/index.php?topic=104647.msg1146476#msg1146476 ??
238 2012-09-02 17:49:11 <ThomasV> "value could be understated" <- what do you mean?
239 2012-09-02 18:15:21 <MC-Eeepc> any way to work out the total number of hashes expended on the chain
240 2012-09-02 18:15:29 <MC-Eeepc> since blk0
241 2012-09-02 18:16:09 <sipa> it's written to debug.log
242 2012-09-02 18:16:27 <sipa> search for 'work='
243 2012-09-02 18:17:19 <MC-Eeepc> i dont even hae a client thats up to date here lol
244 2012-09-02 18:19:10 <MC-Eeepc> height=193389 work=423645534661737495844 tx=5838875
245 2012-09-02 18:19:13 <MC-Eeepc> welp
246 2012-09-02 18:19:22 <MC-Eeepc> is that really in hashes
247 2012-09-02 18:20:07 <sipa> yes
248 2012-09-02 18:20:18 <sipa> measured in expected number of double SHA256's
249 2012-09-02 18:20:45 <MC-Eeepc> im gonna call that 42 gorrillian hashes
250 2012-09-02 18:20:55 <Luke-Jr> ???
251 2012-09-02 18:22:14 <sipa> it's 42 quintillion, according to wikipedia
252 2012-09-02 18:22:17 <Luke-Jr> it's already 423 exahash
253 2012-09-02 18:22:24 <sipa> no, 42
254 2012-09-02 18:22:28 <sipa> oh, wait!
255 2012-09-02 18:22:31 <Luke-Jr> ???
256 2012-09-02 18:22:33 <sipa> yes, you're right
257 2012-09-02 18:25:22 <sipa> 4 hectoquintillion bihashes!
258 2012-09-02 18:28:59 <Diapolo> wtf ^^
259 2012-09-02 18:29:49 <sipa> ACTION will stick to 4*10^20 hashes for now
260 2012-09-02 18:29:59 <Luke-Jr> 4e20 is nicer at least
261 2012-09-02 18:30:03 <Luke-Jr> <.<
262 2012-09-02 18:30:37 <sipa> still, 4 hectoquintillion bihashes sounds more impressive
263 2012-09-02 18:30:40 <Luke-Jr> :p
264 2012-09-02 18:44:06 <Diapolo> sipa: For which not limited networks is SetNameProxy(addrProxy, 5); allowed? I mean onlynet=IPv4, IPv6, Tor ...
265 2012-09-02 18:44:42 <sipa> Diapolo: that's independent from the network
266 2012-09-02 18:45:20 <sipa> it's just for hosts which are reached by name; the resolution is left to the proxy for them, so it's not relevant or known which network they belong
267 2012-09-02 18:45:46 <Diapolo> okay, but to understand the sense of e.g. -onlynet=IPv6 I think that should disable IPv4 and Tor proxies, right?
268 2012-09-02 18:45:55 <denisx> my bitcoind is running with ipv6, but how can I test if it really works?
269 2012-09-02 18:46:27 <sipa> Diapolo: i wouldn't ever let -onlynet influence the name proxy
270 2012-09-02 18:46:43 <Diapolo> sipa: that is fine, but the other proxies
271 2012-09-02 18:47:10 <sipa> denisx: try to connect to it?
272 2012-09-02 18:47:18 <Diapolo> Is that a true condition:
273 2012-09-02 18:47:40 <denisx> sipa: shouldnt simply some other bitcoin daemons connect to it?
274 2012-09-02 18:47:45 <denisx> the port is open
275 2012-09-02 18:47:57 <sipa> denisx: maybe, but there are almost no ipv6 nodes on the network compared to ipv4 ones
276 2012-09-02 18:48:12 <Diapolo> denisx: try to add -onlynet="IPv6" as command-line parameter and see if it connects ^^
277 2012-09-02 18:48:25 <sipa> Diapolo: not sure -onlynet should prevent setting proxies
278 2012-09-02 18:48:31 <sipa> Diapolo: it won't harm
279 2012-09-02 18:48:48 <sipa> and what if you do -onlynet=ipv6 -proxy=blabla -addnode=<someipv4address>
280 2012-09-02 18:49:02 <sipa> i think the reasonable expextation is that that addnode happens through the specified proxy
281 2012-09-02 18:49:16 <Diapolo> sipa: I think it's a matter of consisteny, but I want to be sure ... that's why I ask
282 2012-09-02 18:49:40 <denisx> Diapolo: cool, that worked
283 2012-09-02 18:49:55 <Diapolo> sipa: which options is higher in priority
284 2012-09-02 18:50:00 <sipa> denisx: -onlynet controls which networks the P2P peer selection mechanism connects to and listens on by default
285 2012-09-02 18:50:03 <sipa> eh, Diapolo
286 2012-09-02 18:50:20 <sipa> but there may be other connections, if they are requested explicitly
287 2012-09-02 18:50:24 <denisx> sipa: and what is the default?
288 2012-09-02 18:50:38 <sipa> denisx: default for what?
289 2012-09-02 18:50:53 <denisx> sipa: when I don't use onlynet
290 2012-09-02 18:51:04 <sipa> then all networks are acceptable
291 2012-09-02 18:51:57 <Diapolo> sipa: well I would expect that a blocked network should not be reached, because that is why I blocked it by hand?
292 2012-09-02 18:52:18 <sipa> well it's a matter of opinion, i guess
293 2012-09-02 18:52:26 <sipa> and it would be a confusing example no matter what
294 2012-09-02 18:53:28 <Diapolo> indeed ... it seems I'm currently network-part interessted and work there ^^
295 2012-09-02 18:53:47 <Diapolo> there are quite many possible combinations
296 2012-09-02 18:54:09 <sipa> i'd prefer not to have onlynet influence proxies
297 2012-09-02 18:54:50 <sipa> best case: someone uses -proxy X, and -onlynet=Y, so SetProxy gets called for the blocked networks, and nothing further happens because no connections to those networks are attempted anyway
298 2012-09-02 18:55:09 <sipa> worst case: people expect an error, and instead they get a connection through the proxy
299 2012-09-02 18:55:57 <Diapolo> could there be a privacy problem when leaving things as they are? leak of IPs or something
300 2012-09-02 18:56:49 <sipa> we're talking about the case where someone says "no connections to network X", and then manually specifies a connection to network X
301 2012-09-02 18:57:18 <Diapolo> so -onlynet=x really prevents network traffic to network x but allows an manual override
302 2012-09-02 18:59:29 <Diapolo> Okay, I'll not include any IsLimited() checks for proxy settings :).
303 2012-09-02 18:59:43 <sipa> there are a few already
304 2012-09-02 19:00:32 <Diapolo> yes for IPv6
305 2012-09-02 19:03:24 <Diapolo> oh damn ... yes there ARE already checks in the code for IPv4 AND IPv6, I did a wrong diff ... argh
306 2012-09-02 19:04:09 <Diapolo> sipa: seems like the current default behavior IS to not set a proxy for blocked networks ^^
307 2012-09-02 19:04:13 <sipa> indeed
308 2012-09-02 19:04:15 <sipa> also, i'm beginning to wonder whether -onlynet preventing listening to specified bind addresses is correct
309 2012-09-02 19:04:35 <sipa> i may well want to listen to certain addresses, but not connect to it
310 2012-09-02 19:05:08 <sipa> certainly it should disable listening to default to the blocked network
311 2012-09-02 19:05:22 <denisx> I have never seen a IPv6 connection without onlynet=IPv6
312 2012-09-02 19:05:33 <sipa> i do
313 2012-09-02 19:05:38 <denisx> sipa: ok
314 2012-09-02 19:06:19 <sipa> hmm, only incoming ones though
315 2012-09-02 19:06:42 <sipa> i think it will just be a while before there are sufficient ipv6 addresses being forwarded on the network
316 2012-09-02 19:06:55 <Diapolo> sipa: which line in init.cpp is that code you ware talking about
317 2012-09-02 19:07:15 <sipa> Diapolo: first line of Bind in init.cpp
318 2012-09-02 19:07:48 <denisx> ah, now I see one even without onlynet
319 2012-09-02 19:07:57 <denisx> now I'm relieved ;)
320 2012-09-02 19:08:38 <sipa> denisx: well, having run with -onlynet=ipv6 helped getting your peers.dat filled with recent ipv6 addresses
321 2012-09-02 19:10:20 <Diapolo> sipa: got it, but it's the same discussion for listening or? one could argue onlynet should block and one could say (as you did in your example) I want to listen to that address
322 2012-09-02 19:11:31 <Diapolo> What I like about current behaviour, there is less special casing for things that would be nice to have for <net>, even when I have blocked it.
323 2012-09-02 19:13:41 <denisx> sipa: my daemon is running 24/7 for month now, hope it helps to use ipv6 too
324 2012-09-02 19:16:53 <denisx> btw. 0.7rc1 did compile without any change on the source on freebsd
325 2012-09-02 19:18:31 <sipa> oh, nice
326 2012-09-02 19:22:27 <Diapolo> sipa: another strange thing, when using -onlynet="Tor" the -listen does not work as IsLimited is true for IPv6 and IPv4 then, which prevents us to listen on any address
327 2012-09-02 19:23:57 <sipa> logical result, but not what people expect probably
328 2012-09-02 19:25:22 <Diapolo> I wanted to test a Paranoid-setup
329 2012-09-02 19:26:20 <sipa> that's probably a good reason to not make -onlynet prevent binding to explicitly specified addresses
330 2012-09-02 19:27:17 <Diapolo> sipa: as Tor is on top of IPv4 / IPv6 it should listen to be usable ... I would expect -onlynet="Tor" to use the (Tor) proxy for in/out connections
331 2012-09-02 19:27:40 <sipa> you can't use a proxy for incoming connections
332 2012-09-02 19:27:53 <Diapolo> damn I always forget that ...
333 2012-09-02 19:28:20 <sipa> the point is that "listening for tor" implies listening on some place where the tor daemon will contact you (127.0.0.1, typically)
334 2012-09-02 19:28:30 <sipa> which is IPv4
335 2012-09-02 19:28:36 <Diapolo> ... for nor
336 2012-09-02 19:28:38 <Diapolo> now
337 2012-09-02 19:28:40 <Diapolo> yes
338 2012-09-02 19:29:57 <sipa> thanks for working on the network-config part, by the way
339 2012-09-02 19:30:05 <sipa> gives me some time to spend on other things :)
340 2012-09-02 19:30:34 <Diapolo> I really love to make things better, I'm no inventer ^^
341 2012-09-02 19:31:23 <Diapolo> inventor
342 2012-09-02 19:37:59 <Diapolo> sipa: To reflect -onlynet="Tor" should allow -listen to Bind() to inaddr_any and I need to take care of the IsLimited() check in the Bind() function, correct?
343 2012-09-02 19:38:48 <sipa> Diapolo: i think that the perfect do-what-i-mean behaviour would be quite complex, and probably hard to explain
344 2012-09-02 19:39:22 <sipa> i'd say -onlynet=X means: by default, do not listen by default on anything but X
345 2012-09-02 19:39:33 <sipa> but still allow an explciit -bind to listen on it
346 2012-09-02 19:40:11 <Diapolo> sounds good, so I could allow -bind=127.0.0.1 to use Tor hs
347 2012-09-02 19:40:29 <sipa> indeed
348 2012-09-02 19:41:27 <Diapolo> I have my homework for tomorrow and you can work now, as I'm leaving ;).
349 2012-09-02 19:41:37 <sipa> do-what-i-mean would probably imply making -onlynet=tor listen by default on 127.0.0.1, but i think that's a special case too much
350 2012-09-02 19:43:01 <Diapolo> n8