1 2014-06-04 00:00:16 <justanotheruser> NameError: global name 'SECP256k1' is not defined
2 2014-06-04 00:00:46 <maaku> but if it still doesn't work, see the workaround in the file I posted (starting line 23)
3 2014-06-04 00:00:54 <justanotheruser> ok will do in a few
4 2014-06-04 00:04:14 <phantomcircuit> sipa, is there no way to cache the GetHash result in CTransaction?
5 2014-06-04 00:04:49 <sipa> that's too easy!
6 2014-06-04 00:05:18 <sipa> imho, we should have a CBlockValidation class or something, which maintains all state related to block validation
7 2014-06-04 00:05:25 <sipa> and similarly for transactions
8 2014-06-04 00:05:32 <sipa> the hashes could be cached in there
9 2014-06-04 00:05:53 <sipa> (it's ugly that CBlock maintains its own merkle tree even imho, it's not part of the block, just cached computation)
10 2014-06-04 00:06:06 <phantomcircuit> sadly it seems like there is not since everything directly accesses vin
11 2014-06-04 00:06:51 <gmaxwell> a fun thing to try to record a backtrace every time a duplicte hash is run. you can do this easily if running under valgrind with VALGRIND_PRINTF_BACKTRACE or just backtrace_symbols() in glibc.
12 2014-06-04 00:09:11 <phantomcircuit> gmaxwell, valgrind is sooooo slow
13 2014-06-04 00:09:14 <phantomcircuit> it takes ages
14 2014-06-04 00:09:41 <gmaxwell> yea so? who cares? you sleep sometime, right? ... but thats also why I mentioned backtrace_symbols. :)
15 2014-06-04 00:21:36 <phantomcircuit> gmaxwell, psh
16 2014-06-04 00:21:37 <phantomcircuit> sleep
17 2014-06-04 00:21:57 <warren> Does anyone ever use RPC sendfrom? The fromaccount doesn't actually limit the inputs to that fromaccount.
18 2014-06-04 00:23:49 <phantomcircuit> gmaxwell, lol no symbol names
19 2014-06-04 00:26:39 <Luke-Jr> maaku: no patches are needed to bitcoind to merge mine
20 2014-06-04 00:27:07 <Luke-Jr> warren: accounts don't have coins
21 2014-06-04 00:27:12 <Luke-Jr> warren: works as intended
22 2014-06-04 00:28:43 <phantomcircuit> warren, the accounts system is an accounting system built, it does not control the coin selection
23 2014-06-04 00:29:54 <phantomcircuit> sipa,
24 2014-06-04 00:29:55 <phantomcircuit> lol
25 2014-06-04 00:29:56 <phantomcircuit> ==10522== by 0x21DE57: CTxMemPool::remove(CTransaction const&, std::list<CTransaction, std::allocator<CTransaction> >&, bool) (txmempool.cpp:94)
26 2014-06-04 00:29:56 <phantomcircuit> ==10522== by 0x264066: CTransaction::GetHash() const (core.cpp:77)
27 2014-06-04 00:29:56 <warren> then why does sendfrom have a "fromaccount" parameter?
28 2014-06-04 00:30:50 <Luke-Jr> warren: it deducts the value from the named account
29 2014-06-04 00:31:00 <Luke-Jr> warren: there is no such thing as a from address, you should know this
30 2014-06-04 00:31:08 <phantomcircuit> so so many duplicates
31 2014-06-04 00:31:39 <warren> Luke-Jr: it's picking inputs from seemingly random other accounts
32 2014-06-04 00:31:50 <Luke-Jr> warren: no such thing
33 2014-06-04 00:32:00 <Luke-Jr> warren: accounts are just numbers
34 2014-06-04 00:32:02 <warren> and it doesn't use the fromaccount
35 2014-06-04 00:32:05 <Luke-Jr> it does
36 2014-06-04 00:32:20 <warren> the fromaccount contains only a single input
37 2014-06-04 00:32:27 <phantomcircuit> gmaxwell, can i do something horrible like change CTransaction:vIn to a method returning a const
38 2014-06-04 00:32:36 <Luke-Jr> warren: accoutns don't contain inputs, period.
39 2014-06-04 00:32:59 <phantomcircuit> then anywhere that vIn is actually being updated change to a different method which returns a non const
40 2014-06-04 00:33:09 <phantomcircuit> that way everything can be safely (? maybe) cached
41 2014-06-04 00:33:17 <phantomcircuit> Luke-Jr, opinions on above?
42 2014-06-04 00:33:30 <warren> Luke-Jr: setaccount <address> <accountname> where address has a single input, then sendfrom <accountname>
43 2014-06-04 00:33:55 <Luke-Jr> warren: addresses don't have inputs either.
44 2014-06-04 00:33:55 <phantomcircuit> warren, fromaccount is merely an instruction to debit that account the amount sent
45 2014-06-04 00:34:19 <Luke-Jr> setaccount and sendfrom have no relationship.
46 2014-06-04 00:34:40 <warren> listunspent shows <address> is part of <accountname>
47 2014-06-04 00:34:43 <Luke-Jr> warren: bitcoind listaccounts; do a sendfrom, then listaccounts again
48 2014-06-04 00:34:50 <Luke-Jr> warren: the account will be N less after sendfrom
49 2014-06-04 00:35:14 <Luke-Jr> warren: yes, addresses are tied to an account. so when you send to the address, that account gets credited.
50 2014-06-04 00:35:28 <Luke-Jr> neither addresses nor accounts are related to UTXO entries
51 2014-06-04 00:35:28 <phantomcircuit> which is the full limit of the link
52 2014-06-04 00:36:02 <Luke-Jr> I have no idea why listunspent tells you an address or account, that seems unexpected/strange
53 2014-06-04 00:36:06 <warren> OK, so you can't use sendfrom as a dumb way to avoid using createrawtransaction. Got it.
54 2014-06-04 00:36:16 <warren> listunspent does
55 2014-06-04 00:36:54 <warren> In this dumb shell script I'm spending a particular output for the purpose of automating a reorg tester.
56 2014-06-04 00:36:59 <warren> double-spent tester actually
57 2014-06-04 00:37:39 <Luke-Jr> warren: there is a misguided spendfrom script in contrib/
58 2014-06-04 00:38:05 <Luke-Jr> (that IMO we should delete..)
59 2014-06-04 00:39:54 <warren> True listunspent doesn't give addresses, but it does show what account an input is part of as set by setaccount.
60 2014-06-04 00:40:02 <warren> If that's useless then it shouldn't display that.
61 2014-06-04 00:41:19 <phantomcircuit> gmaxwell, oh god, too much data
62 2014-06-04 00:41:22 <Luke-Jr> inputs are NOT part of any account.
63 2014-06-04 00:41:36 <warren> Luke-Jr: listunspent makes it seem like they are
64 2014-06-04 00:41:45 <Luke-Jr> well, I'd ACK a PR to remove it
65 2014-06-04 00:41:50 <Luke-Jr> because that seems stupid
66 2014-06-04 00:41:56 <Luke-Jr> otoh, 0.10 is probably removing accounts entirely
67 2014-06-04 00:41:58 <Luke-Jr> so.
68 2014-06-04 00:42:24 <warren> good
69 2014-06-04 00:58:41 <phantomcircuit> fun
70 2014-06-04 01:01:58 <gwb3> â
71 2014-06-04 01:10:21 <phantomcircuit> gmaxwell, any idea how to get symbols w/ backtrace?
72 2014-06-04 01:24:22 <gmaxwell> I thought backtrace_symbols() resolved symbols. ... but last time I did this I just used valgrind.
73 2014-06-04 01:25:44 <PLM3> Hello. Question. bitcoin-cli. Is there a way to nicely get a list of all transactions (with confirmation counts) for a particular address ?
74 2014-06-04 01:25:58 <PLM3> that address isn't foreign address
75 2014-06-04 01:26:34 <PLM3> something like "listtransactions", but for particular address, not whole account
76 2014-06-04 01:29:25 <phantomcircuit> gmaxwell, it does, but it's only doing it correctly for libc
77 2014-06-04 01:29:40 <phantomcircuit> the valgrind thing works but prints directly to stdout
78 2014-06-04 01:29:53 <phantomcircuit> so i cant count them
79 2014-06-04 01:31:29 <gmaxwell> so redirect stdout to a file.
80 2014-06-04 01:32:01 <gmaxwell> if you're only printing repeats, you could also print the repeat count to stdout.
81 2014-06-04 01:32:02 <phantomcircuit> gmaxwell, bah but then i have to parse
82 2014-06-04 01:50:09 <jgarzik> phantomcircuit, hehehe, if you are a programmer who dislikes parsing, it sounds like trucking is a good profession ;p
83 2014-06-04 01:50:31 <phantomcircuit> jgarzik, it's a giant mess
84 2014-06-04 01:54:14 <gmaxwell> jgarzik: no, audio and video codecs are a good profession, or DSP work in general. Not a string in sight. :)
85 2014-06-04 01:54:55 <phantomcircuit> jgarzik, it's 800MB of stacktraces...
86 2014-06-04 01:56:18 <posita> Does anyone here have any exposure to pycoin?
87 2014-06-04 01:56:20 <jgarzik> I'll see that and raise you a multi-gigabyte pile of PCI-Express bus traces (kernel driver debugging)
88 2014-06-04 01:58:42 <posita> One should not expect to see two different Bitcoin addresses from the same private key, correct?
89 2014-06-04 01:59:22 <posita> Meaning if bitcoinj says the mainnet address for key X is XXX and pycoin says the mainnet address for key X is YYY, one of them has to be wrong, no?
90 2014-06-04 01:59:42 <phantomcircuit> jgarzik, i'd honestly prefer that...
91 2014-06-04 02:03:12 <posita> http://pastebin.com/4KitNPGL
92 2014-06-04 02:03:52 <posita> (Forgive the jython, it was just easier to experimentâ¦.)
93 2014-06-04 02:17:34 <phantomcircuit> ha success
94 2014-06-04 02:17:35 <phantomcircuit> http://pastebin.com/raw.php?i=GZjLTPUq
95 2014-06-04 02:18:01 <phantomcircuit> as suspected the merkle tree generation stuff is the most expensive
96 2014-06-04 02:18:16 <gmaxwell> but whats most redundant?
97 2014-06-04 02:18:26 <phantomcircuit> gmaxwell, more or less all of it
98 2014-06-04 02:18:43 <phantomcircuit> if vin was const it would be trivial to cache the value
99 2014-06-04 02:18:45 <phantomcircuit> :(
100 2014-06-04 02:19:07 <gmaxwell> we might want to do a dedicated merkle tree generator... since they could use SIMD SHA2 that computes four at a time.
101 2014-06-04 02:19:23 <gmaxwell> (IIRC it's more than a 2x speedup)
102 2014-06-04 02:19:51 <phantomcircuit> ==19885== by 0x21DDE7: CTxMemPool::remove(CTransaction const&, std::list<CTransaction, std::allocator<CTransaction> >&, bool) (txmempool.cpp:94)
103 2014-06-04 02:19:51 <phantomcircuit> ==19885== by 0x263FC6: CTransaction::GetHash() const (core.cpp:77)
104 2014-06-04 02:19:55 <phantomcircuit> that's probably the most silly one
105 2014-06-04 02:20:06 <phantomcircuit> the hash cant change once it's in the mempool anyways
106 2014-06-04 02:27:17 <phantomcircuit> gmaxwell, actually wait the merkle tree shouldn't appear in there at all
107 2014-06-04 02:27:25 <phantomcircuit> this is only the duplicate calls
108 2014-06-04 02:35:13 <phantomcircuit> gmaxwell, actually the first two are duplicates of each other
109 2014-06-04 02:35:31 <phantomcircuit> AcceptBlock causes the merkle tree to be calculated twice
110 2014-06-04 02:48:30 <gwb3> Alright story time, I have to vent - just almost certainly got fired from my job for being a Bitcoin contributor.
111 2014-06-04 02:49:06 <gwb3> I work for a company that has around 100 employees and 8 offices.
112 2014-06-04 02:49:28 <justanotheruser> gwb3: is it a company that in competes with bitcoin?
113 2014-06-04 02:49:44 <gwb3> I am a web developer for them, but they choose to oursource the hosting to a third party that offers "managed service hosting" - so my only responsibility is to handle the stack of what is the website, nothing on the backend that is the hosting.
114 2014-06-04 02:49:48 <gwb3> No.
115 2014-06-04 02:50:04 <justanotheruser> gwb3: so they specifically said "for being a bitcoin contributor"?
116 2014-06-04 02:50:26 <gwb3> The hosting company setup two servers, a staging server and a production server and put the website that I service on them, and then another website that is handled by another company.
117 2014-06-04 02:50:26 <justanotheruser> I think there are quite a few companies that might hire on those grounds :)
118 2014-06-04 02:51:08 <gwb3> Their default SSH port was 22, there was no RSA authentication, and no firewall.
119 2014-06-04 02:51:20 <gwb3> I setup logwatch so I could monitor my application for PHP errors, etc.
120 2014-06-04 02:52:00 <gwb3> Last Wednesday the server crashed because someone hacked into it via one of the user accounts and setup a bitcoin mining process.
121 2014-06-04 02:52:20 <maaku> ah
122 2014-06-04 02:52:51 <gwb3> Apparently it was the 4th time it happened, whoever did it setup a cronjob to download the Bitcoin core software from Bitcoin.org (where I am a contributor) so that they could run a mining network on hacked computers to try to make money.
123 2014-06-04 02:53:32 <gwb3> Since I post regularly about Bitcoin on LinkedIn and Twitter the finger is getting pointed at me.
124 2014-06-04 02:54:01 <gwb3> Despite the fact that logwatch shows dozens of brute force attempts from many different companies and IPs, as well as incorrect login attempts on multitudes of different user accounts.
125 2014-06-04 02:54:17 <maaku> gwb3: this won't help your situation but ... these don't sound like good people to be working with
126 2014-06-04 02:54:21 <gwb3> ./end rant
127 2014-06-04 02:54:27 <gwb3> yeah just frustrating
128 2014-06-04 02:54:47 <gwb3> there's what pays the bills, and then there's bitcoin
129 2014-06-04 02:54:56 <maaku> aint that the truth :(
130 2014-06-04 02:55:18 <gwb3> they are like, "Garland, we see the server logs, and there is a process that connects to Bitcoin.org, you work on that site, right?"
131 2014-06-04 02:55:28 <gwb3> ACTION facepalm.
132 2014-06-04 02:55:41 <gwb3> anyhow whatever
133 2014-06-04 02:55:43 <gwb3> just had to vent
134 2014-06-04 02:55:52 <gwb3> feel better now, i know you all can appreciate what bullshit that is
135 2014-06-04 02:56:40 <gwb3> on to the next job i guess
136 2014-06-04 02:57:00 <gwb3> i'm basically on paid leave now
137 2014-06-04 02:57:08 <Luke-Jr> [02:54:02] <gwb3> Despite the fact that logwatch shows dozens of brute force attempts from many different companies and IPs, as well as incorrect login attempts on multitudes of different user accounts. <-- this is fairly normal :p
138 2014-06-04 02:57:38 <gwb3> Luke-Jr: yeah, agreed
139 2014-06-04 02:58:08 <gwb3> Luke-Jr: Hence the, "He works on Bitcoin.org, he must have something to do with it" argument.
140 2014-06-04 02:59:16 <gwb3> Luke-Jr: although if you have fail2ban installed you wouldn't be seeing 300+ brute-force attempts from the same ip in China
141 2014-06-04 03:03:05 <gwb3> sometimes in life you're the windshield, other times in life you're the bug
142 2014-06-04 03:05:03 <maaku> you should see our logs from the NASA public network - we couldn't bring a fresh windows machine online because it'd be rooted by someone at a chinese IP before it'd have time to patch & reboot
143 2014-06-04 03:07:07 <gwb3> I can imagine.
144 2014-06-04 03:08:31 <justanotheruser> Has anyone here ever used pybitcointools for ec point addition?
145 2014-06-04 03:10:24 <gwb3> Sorry to get sappy here for a sec, but everyone here, always listen to your heart in life - let that be your compass. My heart says to work on Bitcoin.
146 2014-06-04 03:10:29 <gwb3> Onward. :)
147 2014-06-04 03:10:45 <justanotheruser> gwb3: If you contribute to bitcoin core, I don't think a job should be too hard to find :P
148 2014-06-04 03:14:21 <gwb3> justanotheruser: I'm not involved in that, but appreciate where your kind words come from.
149 2014-06-04 03:14:52 <justanotheruser> gwb3: oh? What project then?
150 2014-06-04 03:15:06 <gwb3> justanotheruser: Bitcoin.org
151 2014-06-04 03:15:27 <justanotheruser> gwb3: oh cool
152 2014-06-04 03:15:38 <gwb3> justanotheruser: ::thumbs up::
153 2014-06-04 03:16:21 <gwb3> Goodnight all, hope it wasn't too much of an inconvenience to have a rant for a few minutes, just stunned that bullshit happened to me today and had to put it somewhere. Hope you all have great rests of the week.
154 2014-06-04 03:16:26 <gwb3> ACTION goes back to idling.
155 2014-06-04 03:31:04 <sipa> posita: compressed and noncompressed address?
156 2014-06-04 03:50:07 <posita> sipa: exactly
157 2014-06-04 03:50:28 <posita> My apologies. Richard Kiss helped solidify my embarrassment.
158 2014-06-04 03:50:42 <posita> I've been smacking my forehead a lot lately....
159 2014-06-04 03:51:01 <posita> I forgot to post back here.
160 2014-06-04 04:25:32 <mus1cb0x> what's wrong with blockchain.info?
161 2014-06-04 04:26:06 <mus1cb0x> https://blockchain.info/address/1KQR42DR9UP7WGrS98fcTpkgYPYxqwMZeu doesn't show the transactions to/from the address like it used to
162 2014-06-04 04:26:32 <justanotheruser> mus1cb0x: someone in #bitcoin was having problems too. use blockexplorer.com
163 2014-06-04 04:27:54 <mus1cb0x> it's also laggin, wtf
164 2014-06-04 07:47:23 <gdm85> devrandom: first I'd like to properly reproduce it/narrow it down, then yeah I think I could try something. but no ruby expert here
165 2014-06-04 08:18:23 <warren> wumpus: tx pull remains unreliable for you, and you need to tx pull -f instead?
166 2014-06-04 08:21:15 <wumpus> warren: wut?
167 2014-06-04 08:21:41 <wumpus> oh wait, yes
168 2014-06-04 08:21:50 <wumpus> I've added a script that does that for me, contrib/devtools/update-translations.py
169 2014-06-04 08:22:06 <wumpus> it pulls all translations, and postprocesses for a nicer diff
170 2014-06-04 08:23:03 <wumpus> (as well as to get rid of invalid characters)
171 2014-06-04 08:23:30 <warren> I filed a bug on that and e-mailed the author. Crickets.
172 2014-06-04 08:23:53 <wumpus> I intend to add some other sanity checks, too, for example that %x formatting characters as well as html stay the same in the translation
173 2014-06-04 08:25:08 <t7> whats the difference between a prime field and a binary field?
174 2014-06-04 08:25:33 <t7> (in the context of elliptic curves)
175 2014-06-04 08:25:34 <wumpus> warren: well, thanks for trying, guess we're on our own
176 2014-06-04 08:27:28 <wasobot> hello ? :)
177 2014-06-04 08:28:38 <Polyatomic> "/BitCoinJ:0.11.1/RelayNode:stable salamander/" <-- is this a bluematts public relay node?
178 2014-06-04 08:29:35 <t7> also why do you have to count the number of points on a curve when generating a new curve?
179 2014-06-04 08:29:50 <t7> well i can see why i guess but shouldn't it be nearly impossible todo?
180 2014-06-04 08:30:09 <t7> maths gives me headaches
181 2014-06-04 09:04:31 <wumpus> hm does anyone perhaps know of a way to get the list of people that contributed to the translations on transifex starting from a certain time? it'd be nice to include them in the release notes credits as well
182 2014-06-04 09:09:03 <runeks> Is it bitcoind's fault or my setup's fault that all new block files are created with 600 permissions?
183 2014-06-04 09:24:53 <fanquake> ;;blocks
184 2014-06-04 09:24:53 <gribble> 304172
185 2014-06-04 09:34:32 <plaprade> How did this transaction end up in the blockchain ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767? It has an output script that is advertised as lenght=1 but the script is of length 2 (the opcode is 0x01 so it should consume 1 byte)
186 2014-06-04 09:36:35 <sipa> from the block validity rules, scripts are byte arrays that can contain anything
187 2014-06-04 09:36:49 <sipa> it's only when spending that they are parsed and evaluated
188 2014-06-04 09:37:36 <plaprade> Oh ok. So bitcoind just assumes the script is of size 1 and ignores the content until it gets spent.
189 2014-06-04 09:38:22 <sipa> not "assumes"; it is of length 1
190 2014-06-04 09:38:36 <sipa> but indeed
191 2014-06-04 09:39:07 <plaprade> ok, thanks for the clarification
192 2014-06-04 09:47:26 <runeks> sipa: Would you accept a patch that adds an option that, when enabled, skips setting the umask to 077 in init.cpp (https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L425)?
193 2014-06-04 09:54:57 <sipa> as an option, sure
194 2014-06-04 09:55:09 <sipa> but it does sound dangerous, for the wallet
195 2014-06-04 09:58:06 <runeks> sipa: I only intend to use it when bitcoind isn't managing the wallet (but Armory is), but I'm not sure if we should make sure that people don't do something stupid. That'd be a lot more work (selectively writing the wallet with a 077 umask). I have a 12-line diff that just skips setting the umask if an option is enabled right now.
196 2014-06-04 10:07:31 <fanquake> runeks Probably best to just submit a pull request, then everyone can look over/discuss what your proposing
197 2014-06-04 10:13:21 <runeks> fanquake: Cool. I'll do that.
198 2014-06-04 10:14:10 <wumpus> runeks: just forbid the option when the wallet is enabled
199 2014-06-04 10:14:36 <wumpus> (so, only allow it in combination with -disablewallet or if it is a wallet-less build)
200 2014-06-04 10:14:51 <dsnrk> just to give some forewarning, the developers are probably going to get a little flood of questions about a paper posted on reddit, "Deanonymisation of clients in Bitcoin P2P network".
201 2014-06-04 10:15:26 <runeks> wumpus: Good idea. That should solve it. Hope that isn't too tricky.
202 2014-06-04 10:16:23 <wumpus> runeks: in general I'm all in favor of options that make the block chain data more accessible, as long as it doesn't require lots of extra code or indices
203 2014-06-04 10:17:50 <gmaxwell> wumpus: The Ashley Holman commit recently to abort if a block was missing from the disk moved blockreading into an assert side effect.
204 2014-06-04 10:18:05 <wumpus> gmaxwell: ugh
205 2014-06-04 10:18:30 <gmaxwell> (I was aware of this, I've just been too slammed to PR the 10 character fix. :P)
206 2014-06-04 10:19:05 <wumpus> ok I can do the fix, no problem
207 2014-06-04 10:19:11 <gmaxwell> yea, trivial.
208 2014-06-04 10:19:22 <gmaxwell> I was happy to see the decision to refuse to compile otherwise validated, sad I missed it in review before it was pulled.
209 2014-06-04 10:20:05 <runeks> So if ENABLE_WALLET is not defined it's a wallet-less build?
210 2014-06-04 10:20:18 <wumpus> luckily it's not in 0.9.2
211 2014-06-04 10:20:21 <wumpus> runeks: yes
212 2014-06-04 10:20:25 <runeks> OK
213 2014-06-04 11:21:39 <runeks> OK. Done. Let me know what you think: https://github.com/bitcoin/bitcoin/pull/4286
214 2014-06-04 11:33:46 <t7> _ is a valid function name?
215 2014-06-04 11:44:07 <jtimon> sipa: it seems I will get that error after the rebase as someone else has used the TestNet() global function there that I have deleted in #3824
216 2014-06-04 11:44:45 <jtimon> if I can find the PR that introduces that it may be simpler to find yet another name for a flag variable...
217 2014-06-04 11:45:20 <jtimon> well, probably using the networkId directly will do it
218 2014-06-04 11:46:11 <jtimon> (details.network() == "test" && !TestNet()))
219 2014-06-04 11:46:11 <jtimon> if ((details.network() == "main" && TestNet()) ||
220 2014-06-04 11:46:11 <jtimon> // Payment request network matches client network?
221 2014-06-04 11:46:11 <jtimon> seems like regtest is ignored there though:
222 2014-06-04 11:50:51 <jtimon> yeah, this commit broke my PR: https://github.com/bitcoin/bitcoin/commit/bdc83e8f450456c9f547f1c4eab43571bac631c2
223 2014-06-04 11:53:42 <jtimon> what values can details.network() take? only "main" and "test"? should regtest always fail in the payment protocol?
224 2014-06-04 11:54:13 <sipa> hearn: any opinion about payment requests in relation to -regtest?
225 2014-06-04 12:02:52 <jtimon> (details.network() != "test" && details.network() != "main" ))
226 2014-06-04 12:02:52 <jtimon> (details.network() == "test" && Params().NetworkID() != CChainParams::TESTNET) ||
227 2014-06-04 12:02:52 <jtimon> if ((details.network() == "main" && Params().NetworkID() != CChainParams::MAIN) ||
228 2014-06-04 12:02:52 <jtimon> // Payment request network matches client network?
229 2014-06-04 12:02:52 <jtimon> what about this?
230 2014-06-04 12:04:23 <jtimon> (details.network() == "regtest" && Params().NetworkID() != CChainParams::REGTEST))
231 2014-06-04 12:04:23 <jtimon> (details.network() == "test" && Params().NetworkID() != CChainParams::TESTNET) ||
232 2014-06-04 12:04:23 <jtimon> if ((details.network() == "main" && Params().NetworkID() != CChainParams::MAIN) ||
233 2014-06-04 12:04:23 <jtimon> or this:
234 2014-06-04 12:04:23 <jtimon> // Payment request network matches client network?
235 2014-06-04 12:07:56 <jtimon> I could also create a netwrokStr param that contains "main", "test" or "regtest" and do something like:
236 2014-06-04 12:07:56 <jtimon> if (details.network() != Params().NetworkStr())
237 2014-06-04 12:13:57 <sipa> perhaps even more specific: Params().GetPaymentProtocolNetworkName() ?
238 2014-06-04 12:16:01 <jtimon> yeah, maybe
239 2014-06-04 12:18:19 <jtimon> although I think I would have liked something more generic that is used elsewhere (although the payment protocol using "test" instead of "testnet") seems a barrier to that approach...
240 2014-06-04 12:18:39 <jtimon> is there a reason why "test" is used over "testnet"?
241 2014-06-04 12:21:20 <sipa> i don't think anyone cared enough :)
242 2014-06-04 12:21:41 <wumpus> what does it matter, any unique string will do
243 2014-06-04 12:22:21 <sipa> using something like GetPaymentProtocolNetworkName() would discourage using it for other purposes
244 2014-06-04 12:22:47 <sipa> which is good imho, you shouldn't ever check for the presence of a particular network, only for properties of it
245 2014-06-04 12:23:05 <wumpus> I'm not sure it should be there at all: payment protocol stuff is specific to the GUI
246 2014-06-04 12:23:31 <sipa> fair enough, but how would you solve it otherwise?
247 2014-06-04 12:23:39 <wumpus> a mapping from CChainParams::networkID to payment request network in the payment server code would do just as well
248 2014-06-04 12:24:10 <sipa> sounds ok
249 2014-06-04 12:24:19 <wumpus> no need to centralize everything :-)
250 2014-06-04 12:24:26 <sipa> agree
251 2014-06-04 12:25:13 <jtimon> mhmm, whare should that map be? directly in PaymentServer::processPaymentRequest ?
252 2014-06-04 12:26:08 <wumpus> PaymentServer::mapPaymentProtocolNetworkNameToChainParamsID :p
253 2014-06-04 12:26:41 <jtimon> oh I see, not a map structure, just a method
254 2014-06-04 12:26:41 <wumpus> OrPreferablySomethingShorter
255 2014-06-04 12:26:56 <jtimon> ok
256 2014-06-04 12:27:42 <wumpus> well, it could be either, I mean creating a QMap for two entries makes little sense, unless you expect to load them from a file or so at some point
257 2014-06-04 12:28:06 <jtimon> I think I like a maping from the chainparamsId to the payment protocol network name
258 2014-06-04 12:28:18 <jtimon> and any of them will do it
259 2014-06-04 12:28:37 <sipa> what is more likely: a network name that corresponds to multiple networks, or a network with multiple names? :)
260 2014-06-04 12:28:48 <sipa> </bikeshed>
261 2014-06-04 12:29:06 <jtimon> yeah, I'll go with the simple map
262 2014-06-04 12:30:09 <jtimon> I guess both testnet and regtest could correspond to the same "test" name, no idea if it makes any sense but doesn't seem like the other way around makes sense at all
263 2014-06-04 12:34:08 <wumpus> hmm, I don't know, I suppose it needs a BIP change but defining an identifier specifically for regtest makes sense to me
264 2014-06-04 12:35:35 <wumpus> it's a string field, it's not like we'd run out of possible values any time soon if we'd assign a network name for regtest
265 2014-06-04 12:37:40 <KuDeTa> So gavin seems confident mining won't be an issue in the future. Why is that?? Moor's law? Clearly with the switches from cpu-gpu-asic there was a lot of room for change and competition, but once we hit the fabrication limits of asics (19nm?) then the pace of growth in the tech should slow down to approximate Moore's Law right?
266 2014-06-04 12:41:05 <KuDeTa> I guess the competition will be about price by that point. But what if instead of shaking up up the playing field, companies take it in house on a big scale and mining becomes totally centralised without us even knowing
267 2014-06-04 12:49:50 <jtimon> I still don't see why we can't have a general network string that is used everywhere (don't see the need for a specific network name for the payment protocol at all)
268 2014-06-04 12:53:47 <sipa> that would have been a nice thing to realize before the payment protocol was written
269 2014-06-04 12:53:53 <sipa> i don't think it's important enough to bother with now
270 2014-06-04 12:54:18 <wumpus> jtimon: that's just how things go in reality, if you have distributed development
271 2014-06-04 12:54:55 <wumpus> there is no central planning commission deciding single network name strings to use everywhere
272 2014-06-04 12:55:16 <sipa> namespacing will always be hard
273 2014-06-04 12:55:48 <wumpus> yes indeed, though in this case it isn't even a problem; scoping the names to a single protocol is fine
274 2014-06-04 12:56:13 <sipa> see the nice discussion about how to identify networks in bip32/bip43/...
275 2014-06-04 12:57:07 <wumpus> at least with strings there isn't the problem that there is a limited number of options and a large chance of conflicts, like with the address byte
276 2014-06-04 12:57:39 <jtimon> I think I remembe that, I think a hash of the genesis block would be a great id (which is altcoin proof, though nobody seems to care about that)
277 2014-06-04 12:58:14 <sipa> ACTION mentions zooko's triangle
278 2014-06-04 12:58:48 <jtimon> yeah a hash is not memorable, so what?
279 2014-06-04 12:59:01 <jtimon> afk, going to eat
280 2014-06-04 13:00:32 <sipa> it's more that there are already so many independent netowrk identifiers out there, you won't "fix the world"
281 2014-06-04 13:01:34 <sipa> there's address versions, private keys, network magic, bip32 versions, payment protocol names, ... to an extent even the default P2P port (as that is presumed to be the way to reach DNS-provided peers)
282 2014-06-04 13:02:32 <wumpus> right, picking a new way will never 'fix the world', better to encourage new developments to use one of the existing identifiers instead of invent new ones
283 2014-06-04 13:09:50 <Zoop_> http://www.reddit.com/r/Bitcoin/comments/27a3eb/deanonymisation_of_bitcoin_clients/
284 2014-06-04 13:10:09 <Zoop_> linking IP's to transactions?
285 2014-06-04 13:10:59 <SomeoneWeird> sigh
286 2014-06-04 13:11:26 <wumpus> Zoop_: just use TOR if that is a problem for you
287 2014-06-04 13:11:52 <Zoop_> aparently, tor doesn't save you either
288 2014-06-04 13:12:36 <wumpus> probably not if your opponent can snoop all internet connections on the world at the same time
289 2014-06-04 13:13:57 <Zoop_> "this requires only a bit of sophistication on the part of the attacker and is very cheap to mount."
290 2014-06-04 13:14:13 <Zoop_> i'm just wondering if devs know about this new paper
291 2014-06-04 13:14:27 <Zoop_> i have no intentions of flaming anything
292 2014-06-04 13:14:45 <KuDeTa> We also show that using Tor and other public proxies is an inefficient countermeasure and can be bypassed
293 2014-06-04 13:14:56 <wumpus> so, how do they bypass tor?
294 2014-06-04 13:17:18 <Zoop_> ral countermeasure of using Tor or other anonymity services
295 2014-06-04 13:17:18 <Zoop_> We also show that a natu-
296 2014-06-04 13:17:19 <Zoop_> and have been experimentally verified. We propose several
297 2014-06-04 13:17:19 <Zoop_> bitcoin network. Our attacks require only a few machines
298 2014-06-04 13:17:19 <Zoop_> can be cut-off by abusing anti-DoS countermeasures of the
299 2014-06-04 13:17:19 <Zoop_> countermeasures to mitigate these new attacks
300 2014-06-04 13:17:37 <Zoop_> err... sorry for so many lines
301 2014-06-04 13:17:41 <wumpus> please stop pasting from the paper
302 2014-06-04 13:20:40 <wumpus> oh, seems they attempt to get tor nodes disconnected by mounting DoSes from tor, would that work at all?
303 2014-06-04 13:20:56 <sipa> no, known bug
304 2014-06-04 13:21:03 <wumpus> tor connections come from 127.0.0.1 and AFAIK that never gets blocked
305 2014-06-04 13:21:08 <sipa> indeed
306 2014-06-04 13:21:19 <Jouke> They are talking about tor exit nodes
307 2014-06-04 13:21:29 <wumpus> so I don't see how their method would work at all
308 2014-06-04 13:21:38 <wumpus> Jouke: so they forget about hidden services
309 2014-06-04 13:21:46 <Jouke> something like that
310 2014-06-04 13:22:24 <wumpus> even if they mounted their attack and got all the exit nodes banned, there would still be the hidden services
311 2014-06-04 13:22:33 <dsnrk> for what it's worth, I actually tried connecting a node up to a broken SOCKS proxy and recorded the packets sent by bitcoind. nothing was leaked and no non-SOCKS connections were made outbound.
312 2014-06-04 13:23:41 <wumpus> dsnrk: right, a large number of people use it behind Tor so I wouldn't really expect issues there
313 2014-06-04 13:24:14 <Zoop_> They claim the cost of the attack on the full Bitcoin network to be under 1500 EUR/month too
314 2014-06-04 13:25:15 <wumpus> dsnrk: just be sure to use a socks4a or 5 proxy, not socks4, as that doesn't allow DNS lookups and thus you'd still leak those
315 2014-06-04 13:25:54 <dsnrk> wumpus: normally I listen on IPv4/6 so there's no expectation of privacy. I read this paper and wanted to see if the things in it were correct.
316 2014-06-04 13:28:48 <dsnrk> wumpus: I personally don't believe much of it because they 1) think checkpoints are a security feature 2) think that anonymous nodes should "authenticate" with each other.
317 2014-06-04 13:29:19 <jtimon> sipa wumpus : https://github.com/jtimon/bitcoin/commit/b1c9012451313a4c0b4db88f26f339cbce5f51fc
318 2014-06-04 13:30:02 <wumpus> well I'm sure there is a kernel of truth in there, it makes sense to read what they found and what solutions they propose, but it's not exactly a reason for panic
319 2014-06-04 13:31:28 <wumpus> jtimon: I don't like putting the emit message(tr("Payment request rejected"), tr("Unsupported networkID."), CClientUIInterface::MSG_ERROR); inside the mapping function
320 2014-06-04 13:31:33 <dsnrk> their proposed solution is authentication between nodes to prevent DOS. that absolutely can't happen just due to how cheap it is to make an identity.
321 2014-06-04 13:31:59 <wumpus> jtimon: just make it a pure mapping function, and do the error handling at the call site
322 2014-06-04 13:32:10 <jtimon> wumpus: so returning "" should be enough?
323 2014-06-04 13:32:13 <wumpus> dsnrk: sounds like overkill
324 2014-06-04 13:32:15 <wumpus> jtimon: yes
325 2014-06-04 13:32:21 <jtimon> ok
326 2014-06-04 13:32:42 <dsnrk> wumpus: out of interest did they contact the developers in private with their DOS bug?
327 2014-06-04 13:32:51 <wumpus> dsnrk: what I like about P2P networks is that there is no need for peers to authenticate themselves, they're all interchangable
328 2014-06-04 13:33:40 <wumpus> dsnrk: which DoS bug?
329 2014-06-04 13:34:21 <dsnrk> in the conclusion they mention they found a memory exhaustion bug they think can be used to cause a netsplit.
330 2014-06-04 13:34:22 <jtimon> wumpus: done https://github.com/jtimon/bitcoin/commit/f0a83fc256023f68cc046bd096de69f16ce9d394
331 2014-06-04 13:34:55 <dsnrk> wumpus: oh it's just the addr message packing bug
332 2014-06-04 13:35:22 <dsnrk> nice that they attacked the real network using it though
333 2014-06-04 13:35:29 <wumpus> dsnrk: we did fix a possible memory exhaustion bug related to addr messages in 0.9.2
334 2014-06-04 13:36:34 <dsnrk> wumpus: https://i.imgur.com/VvNS8ut.jpg < sound the same to you?
335 2014-06-04 13:36:53 <wumpus> yes, it's the same
336 2014-06-04 13:37:33 <dsnrk> convenient
337 2014-06-04 13:39:22 <wumpus> jtimon: great!
338 2014-06-04 14:11:55 <kostaz> Hi guys
339 2014-06-04 14:12:54 <kostaz> I can't find operator>> for CMessageHeader to explain "hdrbuf >> hdr" in CNetMessage::readHeader().
340 2014-06-04 14:13:00 <kostaz> Can anyone help?
341 2014-06-04 14:28:12 <andytoshi> that is the >> operator on hdrbuf, which is a member of CNetMessage of type CDataStream
342 2014-06-04 14:29:39 <andytoshi> it is defined serialize.h:1082; it's a template which just calls Unserialize on the CMessageHeader.. this is defined by the IMPLEMENT_SERIALIZE macro
343 2014-06-04 14:48:13 <Dizzle> Is there a good guide to having multiple instances of bitcoind or bitcoin-qt on the same machine? Looking to build head of master, but don't want it touch my regular release cycle wallet.
344 2014-06-04 14:50:04 <wumpus> Dizzle: just provide different -datadir=xxx
345 2014-06-04 14:50:09 <jgarzik> Dizzle, what are you trying to do? simulate a network? google for "bitcoin test net in a box"
346 2014-06-04 14:50:27 <jgarzik> Dizzle, in general, that is discouraged, because the network tries harder to ignore your node
347 2014-06-04 14:50:38 <Dizzle> wumpus: thanks
348 2014-06-04 14:50:58 <Dizzle> jgarzik: probably won't have them running at the same time, but this test net in a box sounds really useful for playing around, thanks!
349 2014-06-04 14:51:52 <wumpus> regtest is even better for playing around
350 2014-06-04 14:53:27 <gavinandresen_> Dizzle: see qa/rpc-tests/ for some examples of running multiple nodes in regtest mode on the same machine
351 2014-06-04 15:21:45 <chichov> how come that Multisig transactions are limited to n-of-3?
352 2014-06-04 15:26:45 <chichov> I see the explanation that the signature + pubkey size is approx 145 bytes; this times 3 and it builds an upper bound for the 500 bytes
353 2014-06-04 15:27:02 <chichov> however, do the signatures have to be necessarily accompanied by their corresponding public keys?
354 2014-06-04 15:31:27 <sipa> how could you otherwise verify them?
355 2014-06-04 15:32:58 <chichov> sipa: according to BIP11 these are provided in scriptPubKey
356 2014-06-04 15:33:28 <sipa> for raw pubkey transactions yes
357 2014-06-04 15:33:39 <chichov> thus, you could stuff scriptSig with at most 500/80 =~ 6 signatures
358 2014-06-04 15:34:21 <chichov> mhm, I see, so you also take into consideration pay-to-pubkeyhash transactions here?
359 2014-06-04 15:34:33 <sipa> oh, you're asking why only up to 3 was made standard?
360 2014-06-04 15:34:43 <chichov> yep
361 2014-06-04 15:34:46 <sipa> no technical reason, just being conservative
362 2014-06-04 15:35:32 <chichov> can you also provide pay-to-pubkeyhash addresses?
363 2014-06-04 15:35:49 <sipa> try to work out how that could work :)
364 2014-06-04 15:35:56 <chichov> I don't see a way, heh
365 2014-06-04 15:36:09 <sipa> note that the script language does not have a concept of 'addresses'
366 2014-06-04 15:36:16 <sipa> addresses are just shorthands for particular scriptPubKeys
367 2014-06-04 15:36:18 <chichov> well, there is one, but it's a bit difficult
368 2014-06-04 15:36:34 <sipa> it's possible yes, but there is little benefit
369 2014-06-04 15:36:52 <sipa> the one constructing the multisig address should have the public keys anyway in order to spend
370 2014-06-04 15:38:14 <chichov> hm, do you mean the pay-to-scripthash transaction in combination with multisig when you say "multisig address"?
371 2014-06-04 15:39:57 <chichov> nevermind, I'm a bit fresh in that respect and will read up on it
372 2014-06-04 15:42:34 <sipa> by multisig address i really mean p2sh with embedded multisig script
373 2014-06-04 16:42:41 <kostaz> andytoshi, thank you! I got it. :-)
374 2014-06-04 17:03:45 <chichov> how's it possible to make a m-of-n multisig with P2SH for n > 3 if scriptSig is limited to 500 bytes?
375 2014-06-04 17:04:24 <sipa> scriptSig is only limited to 500 bytes by standardness
376 2014-06-04 17:04:37 <sipa> you can already do 5 or so
377 2014-06-04 17:04:41 <chichov> could you elaborate on that?
378 2014-06-04 17:04:47 <sipa> 33 byte pubkeys, 72 byte signatures
379 2014-06-04 17:05:02 <sipa> there is no size restriction on script sizes in the consensus rules
380 2014-06-04 17:05:20 <sipa> it's only a policy rule not to relay/mine too large scripts
381 2014-06-04 17:05:30 <sipa> which afaik git master weakens
382 2014-06-04 17:06:11 <chichov> so the reference client's policy doesn't allow relaying/mining of too large scriptSigs (beyond 500 bytes)
383 2014-06-04 17:06:31 <chichov> whilst other nodes don't necessarily have to enforce that rule?
384 2014-06-04 17:06:39 <sipa> right
385 2014-06-04 17:06:52 <chichov> it's still a problem if the majority uses the reference client
386 2014-06-04 17:07:05 <sipa> well git master doesn't have that restriction anymore
387 2014-06-04 17:07:11 <sipa> so 0.10 likely won't
388 2014-06-04 17:07:22 <chichov> 0.10?
389 2014-06-04 17:07:27 <chichov> oh
390 2014-06-04 17:07:30 <sipa> the next major release
391 2014-06-04 17:07:48 <chichov> so it has been taken out, nice
392 2014-06-04 17:07:56 <chichov> then bigger m-of-n multisigs will be allowed
393 2014-06-04 17:07:58 <sipa> not out, just relaxed
394 2014-06-04 17:08:05 <chichov> to how much?
395 2014-06-04 17:08:17 <sipa> enough for up to 15 iirc
396 2014-06-04 17:08:31 <sipa> at which point you hit the limit of p2sh script sizes
397 2014-06-04 17:08:34 <sipa> which is consensus rule
398 2014-06-04 17:08:44 <sipa> (520 bytes of script push)
399 2014-06-04 17:09:00 <sipa> as you can't pack more than 15 (or was it 16) pubkeys in there
400 2014-06-04 17:09:11 <chichov> I believe 15 pubkeys was the limit
401 2014-06-04 17:09:24 <sipa> "was" ?
402 2014-06-04 17:09:27 <chichov> 15*33 bytes
403 2014-06-04 17:09:36 <sipa> there's a push in front of each
404 2014-06-04 17:09:46 <sipa> yup, 15
405 2014-06-04 17:09:52 <chichov> + pushes, yep
406 2014-06-04 17:10:25 <chichov> I see the maximum scriptSig size is now 1650 bytes
407 2014-06-04 17:10:46 <chichov> exactly enough for a 15-of-15 P2SH multisig
408 2014-06-04 17:11:00 <sipa> yup
409 2014-06-04 17:11:08 <chichov> nice
410 2014-06-04 17:12:32 <chichov> where in the code can I find the restriction to 3 pubkeys in a standard multisig transaction?
411 2014-06-04 17:14:38 <chichov> nevermind, found it in script.cpp
412 2014-06-04 17:15:29 <chichov> how come that hasn't been relaxed as well? to enforce a non-space-wasting transaction type?
413 2014-06-04 17:16:47 <sipa> if we'd design bitcoin today it would be p2sh only :)
414 2014-06-04 17:17:00 <chichov> hehe, I see
415 2014-06-04 17:17:34 <sipa> lower usage of UTXO space, better privacy, no need for the sender to know the full script (which is the receiver's business), ...
416 2014-06-04 17:17:55 <sipa> a marginal security improvement too (though only compared to raw pubkeys, not compared to pubkeyhash)
417 2014-06-04 17:41:42 <moarrr> can anyone help me
418 2014-06-04 17:41:46 <moarrr> im building bitcoin core from sources
419 2014-06-04 17:41:59 <Luke-Jr> moarrr: #bitcoin
420 2014-06-04 17:42:00 <moarrr> i think ive installed all the dependancies desribes in doc/build-unix.md
421 2014-06-04 17:42:04 <moarrr> oh ok
422 2014-06-04 17:57:15 <ajweiss> if i notice a potential issue in an open PR, is it best to comment directly on the PR or is it better to bring it up in here first?
423 2014-06-04 17:58:05 <sipa> i see no reason for not commenting on the PR directly
424 2014-06-04 17:58:15 <sipa> unless you're very uncertain, and want some other opinion first :)
425 2014-06-04 17:59:18 <ajweiss> so PR3640 doesn't fix the fact that you can't run bitcoind -conf=blah where the config file specifies the datadir and the default datadir is unwritable
426 2014-06-04 18:02:08 <ajweiss> it seems to me that you'd want to read the config file first before checking the data directory
427 2014-06-04 18:02:38 <sipa> feel free to comment :)
428 2014-06-04 18:03:50 <ajweiss> i'd consider submitting a patch, but i assume since it's an already open PR that probably makes things messier
429 2014-06-04 18:34:05 <wumpus> there are just too many ways in which the various datadir/conf/etc options can interact
430 2014-06-04 18:35:26 <wumpus> but indeed, my fix is wrong too
431 2014-06-04 18:35:31 <wumpus> it assumes that the config file is in the datadir
432 2014-06-04 18:35:38 <wumpus> which is not necessarily true
433 2014-06-04 18:36:28 <wumpus> I'm kind of tired of it (that's also why I haven't merged it yet -- I'm not certain of it), so if you want to take over the PR, that's fine with me
434 2014-06-04 18:40:07 <wumpus> it may make sense to first document clearly what the intended behavior should be (don't forget it's even more complex for the GUI, which allows setting the datadir in the registry), then test the implementation against that
435 2014-06-04 18:47:41 <jgarzik> wumpus, IMO, if you see a datadir directive in the config, throw an error.
436 2014-06-04 18:47:53 <jgarzik> wumpus, that will document by showing
437 2014-06-04 18:50:03 <wumpus> right
438 2014-06-04 18:51:41 <wumpus> though I think it can be useful in some cases, just to be able to do bitcoind -conf=/etc/bitcoind.conf without having to set the datadir explicitly as well as it's set in the configuration file
439 2014-06-04 18:51:44 <ajweiss> yeah i was thinking about that, does the config file neccessarily live in the datadir
440 2014-06-04 18:52:07 <ajweiss> it's somewhat unspecified
441 2014-06-04 18:52:18 <wumpus> no, it does not, that's why -conf exists
442 2014-06-04 18:54:19 <ajweiss> i would think it would be nice to be able to keep the datadir in the config file
443 2014-06-04 18:54:56 <wumpus> but I suppose: only if the conf option is provided
444 2014-06-04 18:55:20 <ajweiss> imagine a binary distribution for a linux distro... they might stick the config file in /etc/bitcoind/bitcoind.conf
445 2014-06-04 18:55:24 <wumpus> if the configuration file is read from the default location in the datadir, it makes no sense to specify a datadir
446 2014-06-04 18:55:41 <ajweiss> i'd want to be able to go there to change the datadir, rather than messing with init scripts
447 2014-06-04 18:55:47 <wumpus> (not sure what the behavior there is right now, but it's easy to create chicken-and-eggs problems)
448 2014-06-04 18:56:16 <ajweiss> yeah it seems that historically datadir served as the primary way to change configurations
449 2014-06-04 18:57:38 <wumpus> yes it was a bad design in the first place to expect everything in the same directory, in many OSes there are clear rules about where to put configuration, mutable data, etc, but alas we inherited it
450 2014-06-04 18:57:59 <wumpus> and now how to move away from it is not clear-cut