1 2015-01-06 00:06:08 <Eliel> sipa: how much do you think is needed for one block?
2 2015-01-06 00:13:34 <sipa> can be up to 20 MB or so, i'd estimate
3 2015-01-06 01:22:10 <nuttycom> Hi, all, I have a quick question about making json-rpc calls to a local bitcoind running in regtest mode for debugging. Namely, what port do I connect to? Some googling has led me to try 18444, but whenever I try sending requests to that port with curl, I get an empty response. Any suggestions?
4 2015-01-06 01:23:04 <sipa> start bitcoind with -rpcport=N and use whatever you like :)
5 2015-01-06 01:25:51 <nuttycom> sipa: Excellent, that works! I knew it had to be something trivial.
6 2015-01-06 01:26:34 <nuttycom> Out of curiosity, what port does bitcoind -regtest run on by default, do you know?
7 2015-01-06 01:26:52 <sipa> check chainparamsbase.cpp
8 2015-01-06 01:27:07 <nuttycom> Thanks!
9 2015-01-06 01:27:43 <sipa> 18332
10 2015-01-06 01:27:47 <sipa> same as testnet
11 2015-01-06 01:28:53 <nuttycom> Yup, I was just looking at https://github.com/bitcoin/bitcoin/blob/master/src/chainparamsbase.cpp - thanks for teaching me how to find the answers as well as giving me the answer!
12 2015-01-06 01:31:12 <nuttycom> And with that, my application is working on my first try. Yay for Haskell!
13 2015-01-06 01:31:31 <sipa> ooh haskell, nice
14 2015-01-06 01:31:45 <sipa> when it compiles, it usually works :D
15 2015-01-06 01:32:40 <nuttycom> Yep. For my own projects, it's basically all I use these days. And PureScript for the front-end.
16 2015-01-06 04:59:26 <Taek> how does bitcoind handle reorgs?
17 2015-01-06 04:59:55 <Taek> as in, when it needs to rewind a few blocks and apply different blocks, what's the general approach that the software takes?
18 2015-01-06 05:14:34 <gmaxwell> Taek: uh. it rewinds the blocks and applies the new ones. I'm not clear on your question.
19 2015-01-06 05:15:24 <Taek> The other approach I was thinking might happen is that it loads a snapshot
20 2015-01-06 05:15:49 <Taek> The risk of rewinding is that you may rewind incorrectly, if you look at past blocks and figure out how to reverse things from that
21 2015-01-06 05:16:03 <Taek> or, you could store a set of state-diffs at each block so that it's easy to apply them and go backwards
22 2015-01-06 05:17:47 <Taek> I guess my question is, what logic is used to reverse a block? Do you look at the current state, and the block being reversed and derive a diff?
23 2015-01-06 05:19:18 <gmaxwell> Thats not possible to do that.
24 2015-01-06 05:19:26 <gmaxwell> Because the application of a block destroys information.
25 2015-01-06 05:19:36 <gmaxwell> We store reverse diffs when blocks are applied, so they can be undone.
26 2015-01-06 05:20:04 <Taek> ok. That answers my question.
27 2015-01-06 05:20:47 <gmaxwell> The software was originally simpler, and actually did directly undo the change... because all it had to do was undo spentness flags, but that approach was not very scalable.
28 2015-01-06 05:21:03 <gmaxwell> (and it was something like 40x slower at the time we switched, probably much worse now)
29 2015-01-06 05:21:50 <Taek> I feel like storing diffs make it easier to be certain about correctness anyway
30 2015-01-06 05:22:28 <gmaxwell> hard to say, the code is much more complex.
31 2015-01-06 05:23:13 <gmaxwell> But performance eventually is a correctness problem too.
32 2015-01-06 08:22:43 <b-itcoinssg> I want to understand why and how, signing message X with bitcoin address Y can lead to many outcomes Z1,Z2,Z3,Z4 etc. Can you explain or direct me to a resource that helps?
33 2015-01-06 08:23:07 <michagogo> b-itcoinssg: I think someone was discussing that in here yesterday
34 2015-01-06 08:23:18 <michagogo> Maybe look at the logs?
35 2015-01-06 08:23:26 <michagogo> (Link in topic)
36 2015-01-06 08:23:40 <b-itcoinssg> michagogo: ok, I'll try that.
37 2015-01-06 08:24:04 <sipa> b-itcoinssg: define 'outcome'; you mean the signature?
38 2015-01-06 08:24:30 <b-itcoinssg> sipa: yes
39 2015-01-06 08:24:36 <sipa> if so, yes, 2^256 possible signatures; ECDSA uses a random nonce as input
40 2015-01-06 08:26:21 <b-itcoinssg> sipa: I see, and I'm confused how someone can verify the signature just by knowing the 1)signature 2)bitcoin address 3)message and not the nonce. Is this an issue with me not understanding how ECDSA works under the hood?
41 2015-01-06 08:27:06 <sipa> if you know the nonce, you can derive the private key
42 2015-01-06 08:27:10 <sipa> so yes :)
43 2015-01-06 08:27:40 <sipa> b-itcoinssg: you may also be interested to know that message verification uses ecdsa pubkey recovery
44 2015-01-06 08:27:54 <b-itcoinssg> sipa: ok
45 2015-01-06 08:28:10 <sipa> it basically computes for which public key(s) the signature/message combination would be valid
46 2015-01-06 08:28:25 <sipa> and then compares those to the passed address
47 2015-01-06 08:29:17 <b-itcoinssg> sipa: ok, that is helpful
48 2015-01-06 08:29:37 <b-itcoinssg> sipa: what about the size of the message? is there a limit to how big it can be?
49 2015-01-06 08:29:41 <sipa> no
50 2015-01-06 08:29:50 <b-itcoinssg> ok
51 2015-01-06 08:29:55 <sipa> it's hashed before passing to the signature algorithm
52 2015-01-06 08:30:15 <sipa> the actual rpc implementation in bitcoin probably won't accept more than a few mb
53 2015-01-06 08:31:09 <b-itcoinssg> ok, and am I correct in assuming that is a pragmatic limitation that is made rather than a theoritical one?
54 2015-01-06 08:31:21 <sipa> yes
55 2015-01-06 08:31:25 <wumpus> it's very pragmatic - an anti-DoS measure
56 2015-01-06 08:31:37 <b-itcoinssg> ok
57 2015-01-06 08:32:31 <sinetek> 2^256 - C; where C is a small constant
58 2015-01-06 08:32:46 <sinetek> </pedantic mode>
59 2015-01-06 08:34:15 <sipa> sinetek: actually only half of that, given that we limit S to its lower halg
60 2015-01-06 08:34:20 <sipa> *half
61 2015-01-06 08:34:37 <sinetek> ah yes
62 2015-01-06 08:35:00 <sipa> b-itcoinssg: sha256 accept 2 exabytes of input
63 2015-01-06 08:35:20 <wumpus> b-itcoinssg: https://github.com/bitcoin/bitcoin/blob/master/src/rpcserver.cpp#L954
64 2015-01-06 08:35:57 <b-itcoinssg> thank you, btw I appreciate pedantic mode
65 2015-01-06 08:36:09 <sipa> ok
66 2015-01-06 08:36:10 <gmaxwell> b-itcoinssg: you really should not be using signmessage for random large data. Bitcoin is _not_ pgp and it doesn't have the affordances that a good signature system has.
67 2015-01-06 08:36:37 <gmaxwell> Also there have been many non-bitcoin-core implementations of verifymessage that fail for large inputs, due to mishandling of the varint.
68 2015-01-06 08:37:17 <b-itcoinssg> gmaxwell: I understand, I'm just trying to understand the system, if I go about implementing anything I make a point to referring to you guys before I do.
69 2015-01-06 08:39:47 <b-itcoinssg> which reminds me, I'm also learning to appreciate your aversion to resuing addresses. e.g. with the nonce issue. No matter how secure the private key generation process is, using a poor nonce for a transaction totally negates it, right?
70 2015-01-06 08:40:17 <sipa> yes
71 2015-01-06 08:40:44 <b-itcoinssg> I've held back on writing my paper on making bitcoin addresses more human friendly because of it.
72 2015-01-06 08:40:46 <sipa> though my largest problem with address reuse is that it significantly degrades bitcoin's privacy as a whole
73 2015-01-06 08:40:59 <b-itcoinssg> I see
74 2015-01-06 08:44:02 <b-itcoinssg> if exposing the public key reduces security, wouldn't multi-signature addresses be more secure if it was done on the public bitcoin address level, rather than the public key level?
75 2015-01-06 08:44:03 <gmaxwell> Not only privacy, but the fungibility of bitcoins.
76 2015-01-06 08:44:40 <b-itcoinssg> gmaxwell:ok
77 2015-01-06 08:44:59 <gmaxwell> b-itcoinssg: any security benefit there is more or less conjectional... it's not worth overhead.
78 2015-01-06 08:45:24 <b-itcoinssg> ok
79 2015-01-06 08:46:20 <sipa> b-itcoinssg: or just dont reuse public keys for use in multisig addresses
80 2015-01-06 08:46:54 <gmaxwell> sipa: your cosigners will still know your public key, however.
81 2015-01-06 08:47:13 <gmaxwell> which, e.g. if you're concerned about attacks that are slow and require knowing the public key...
82 2015-01-06 08:47:45 <gmaxwell> If it's any consolation, most ways attacking ECC crack _all_ keys with just about the same amount of computation as cracking a single one.
83 2015-01-06 08:50:00 <gmaxwell> (it's also somewhat inaccurate to say that 256 bit ecc has 2^128 security because of that. Against small attacks it has nearly 2^256 security, and amortized average work for an attacker who wants to attack all 2^256 keys is significantly less than one operation per key cracked.)
84 2015-01-06 09:15:14 <astuuu> howdy, folkses!
85 2015-01-06 09:16:22 <astuuu> I'm a bit stuck and would love some help, please!
86 2015-01-06 09:16:25 <b-itcoinssg> hello
87 2015-01-06 09:17:02 <sipa> astuuu: hard to help without knowing what the problem is
88 2015-01-06 09:17:03 <astuuu> i'm trying to sign txs offline using bitcoind's json-rpc using signrawtransaction(). i'm passing everything correctly including priv keys. however, it's choking if I use >10 keys
89 2015-01-06 09:18:48 <b-itcoinssg> multi-sig, or >10 seperate txs with >10 keys?
90 2015-01-06 09:18:56 <astuuu> if i use 10 inputs, correct txid/vout/scriptPubKey, and an array of priv keys, it works great. however soon as I get a larger number of inputs (and priv keys) it gives me no error message but fails
91 2015-01-06 09:19:15 <astuuu> b-itcoinssg: >10 separate txs with >10 keys
92 2015-01-06 09:20:07 <sipa> 10inputs, not 10txn, right?
93 2015-01-06 09:21:22 <astuuu> yessir. one single output. the purpose is to consolidate a bunch of small outputs (with a few large ones) from legacy armory wallets
94 2015-01-06 09:23:32 <astuuu> i'd be pretty over the moon if i could just get a useful error message. else off to core I dive
95 2015-01-06 09:24:31 <sipa> andnit is signing that fails?
96 2015-01-06 09:24:36 <sipa> not sending
97 2015-01-06 09:24:49 <astuuu> sipa: yes correct. signing fails.
98 2015-01-06 09:24:59 <sipa> odd!
99 2015-01-06 09:25:04 <astuuu> thats what i said!
100 2015-01-06 09:25:40 <sipa> does bitcoin-tx work (included in 0.10.0rc1) ?
101 2015-01-06 09:25:59 <astuuu> no idea, i havent tried 0.10.0rc1. shall I give that a whirl?
102 2015-01-06 09:26:09 <sipa> you could
103 2015-01-06 09:26:37 <sipa> bitcoin-tx does fully standalone transaction signing, very similar to signrawtransaction
104 2015-01-06 09:26:46 <astuuu> i was also speculating that the machine just doesn't have enough resources. it's a pretty weak dumb cold storage box. but a useful error msg would be nice
105 2015-01-06 09:27:07 <sipa> except it does not have a wallet, so you need to pass all inputs and keys
106 2015-01-06 09:27:25 <astuuu> sipa: thats fine, i want to do that anyway. i'll give it a whirl. thanks!
107 2015-01-06 09:28:22 <sipa> if it fails in 0.10.0rc1 (either sendrawtransaction or through bitcoin-tx), please file a bug report
108 2015-01-06 09:28:45 <astuuu> i will. thanks for your help!
109 2015-01-06 09:34:51 <warren> btw, what's the state of the pruning support in 0.10rc1?
110 2015-01-06 09:34:59 <wumpus> warren: N/A
111 2015-01-06 09:35:29 <wumpus> pruining isn't even merged to master yet
112 2015-01-06 09:35:33 <warren> ah
113 2015-01-06 09:35:37 <warren> sorry I've been away
114 2015-01-06 09:35:39 <wumpus> first release it could be in would be 0.11
115 2015-01-06 09:37:43 <wumpus> luke-jr has binaries for 0.10rc1+pruning, see https://github.com/bitcoin/bitcoin/pull/4701
116 2015-01-06 09:38:26 <wumpus> that's just for testing though, don't do anything important with it
117 2015-01-06 09:51:06 <wumpus> bluh, we should really have used -wallet=0 / (equiv to -nowallet ) instead of disablewallet, it always breaks my sequence of -no arguments :-)
118 2015-01-06 10:11:38 <wumpus> let's tag rc2 today?
119 2015-01-06 10:13:53 <wumpus> ah, no, #5588 and #5462 are blocking
120 2015-01-06 10:16:12 <Luke-Jr> wumpus: not 5542? :x
121 2015-01-06 10:17:48 <wumpus> Luke-Jr: I don't see how that is a blocker
122 2015-01-06 10:17:58 <wumpus> just a minor optimization of the build system
123 2015-01-06 10:18:36 <Luke-Jr> wumpus: it makes unnecessary external dependencies
124 2015-01-06 10:18:41 <wumpus> also looks like cfields wants to do it differently
125 2015-01-06 10:18:48 <Luke-Jr> eg, boost for libbitcoinconsensus
126 2015-01-06 10:19:13 <wumpus> doesn't autoconf always check for boost at this point?
127 2015-01-06 10:19:40 <Luke-Jr> hmm, it may :/
128 2015-01-06 10:19:40 <wumpus> anyhow I don't disagree it is nice to have, just not a blocker.
129 2015-01-06 10:20:15 <Luke-Jr> guess I should setup a chroot just for testing this
130 2015-01-06 10:20:29 <sipa> wait, afaik the libconsensus builds i have seen do not have boost dependencies iirc?
131 2015-01-06 10:21:28 <Luke-Jr> sipa: the build system uses it
132 2015-01-06 10:21:40 <Luke-Jr> it currently builds every file even when not using them
133 2015-01-06 10:21:47 <wumpus> no, libconsensus does not have a boost dependency
134 2015-01-06 10:21:56 <sipa> ok
135 2015-01-06 10:22:08 <Luke-Jr> I'm testing cfields's suggestions atm
136 2015-01-06 10:22:30 <Luke-Jr> will probably redo 5542 if it works out (and make sure stuff can actually be not-installed)
137 2015-01-06 10:22:46 <wumpus> the point is that the common library is being built always, and that does require boost
138 2015-01-06 10:23:43 <wumpus> and autoconf always checks for boost no matter what optoins are given
139 2015-01-06 10:24:15 <Luke-Jr> fixing that could bring back the "need to know internal deps" issue cfields noted
140 2015-01-06 10:25:14 <wumpus> well, we already do the same for e.g. berkeleydb, that's only required when the wallet is built
141 2015-01-06 10:25:15 <Luke-Jr> maybe a quick hack would be okay until we can properly split everything to its own repo down the road
142 2015-01-06 10:25:44 <wumpus> or for qt, we don't require it when the GUI is not built
143 2015-01-06 10:25:50 <wumpus> so we already rely on knowing internal dependencies
144 2015-01-06 10:26:13 <Luke-Jr> hm
145 2015-01-06 10:26:25 <wumpus> (but maybe not in the sense cfields means it, I don't know)
146 2015-01-06 10:33:58 <Luke-Jr> odd, cfields's patch has different results for the libs
147 2015-01-06 10:34:05 <Luke-Jr> it doesn't need the crypto internallib?
148 2015-01-06 10:35:09 <Luke-Jr> oh, weird - it's using the files independently of it
149 2015-01-06 10:35:35 <wumpus> yes, it uses the files independently, as they may be built with different flags
150 2015-01-06 10:35:43 <Luke-Jr> btw, how should we fix the --with-* stuff being used here?
151 2015-01-06 10:36:08 <Luke-Jr> --with-* is meant to be for external optional dependencies, not "what to build" (which is --enable-*)
152 2015-01-06 10:36:27 <wumpus> let's postpone that to some unspecified future date
153 2015-01-06 10:36:32 <sipa> lol
154 2015-01-06 10:36:52 <Luke-Jr> XD
155 2015-01-06 10:37:38 <justanotheruser> from the hardfork wishlist " Switch to block hashing algorithm secure against block withholding attacks. "
156 2015-01-06 10:37:41 <justanotheruser> Is this just wishful thinking or is there a way to actually do this?
157 2015-01-06 10:37:58 <Luke-Jr> justanotheruser: there have been a couple of ideas thrown around occasionally
158 2015-01-06 10:38:04 <Luke-Jr> none ideal
159 2015-01-06 10:41:29 <Luke-Jr> justanotheruser: bleh, the paper I wanted to link you for a summary isn't published yet :<
160 2015-01-06 10:41:41 <justanotheruser> :P
161 2015-01-06 10:42:01 <justanotheruser> I'm surprised there are even proposals on how to reduce it regardless of the side effects
162 2015-01-06 10:43:06 <justanotheruser> someone in #bitcoin mentioned progressful PoW, do most of the proposals involve that?
163 2015-01-06 10:44:38 <Luke-Jr> justanotheruser: see http://sourceforge.net/p/bitcoin/mailman/message/29361475/ and https://bitcoil.co.il/pool_analysis.pdf 6.2.3
164 2015-01-06 10:49:06 <justanotheruser> Luke-Jr: So the hasher can't have the actual block then?
165 2015-01-06 10:49:12 <justanotheruser> just the work
166 2015-01-06 10:49:53 <Luke-Jr> yes, I suppose it might break the hasher announcing the block
167 2015-01-06 10:50:18 <justanotheruser> The tradeoffs for that are rough
168 2015-01-06 10:51:44 <justanotheruser> yeah, it should work, but incentivizing block creators not to withhold at the expense of variance allows verification
169 2015-01-06 10:53:50 <justanotheruser> If the miner only gets a 5% reward for publishing a block (as is with P2Pool iirc) then they will still get paid 95% on average. If you make that 5% 50% it is pretty costly. This does remove some of the utility of a mining pool though since its entire point is variance reduction.
170 2015-01-06 11:48:02 <bedeho> Is it possible to specify the transaction version number for the bitcoind RPC JSON API?
171 2015-01-06 11:51:30 <wumpus> no, as it doesn't know what transactions with other versions would even look like
172 2015-01-06 12:06:08 <astuuu> hi all. me again!
173 2015-01-06 12:07:33 <astuuu> when signing a tx with signrawtransaction() and passing in private keys and scriptPubKeys (and all other relevant data), why would I get a "missing redeemScript" message if no one output required more than one signature?
174 2015-01-06 12:08:05 <astuuu> using bitcoind 0.10.0rc1 (earlier versions gave me no error at all)
175 2015-01-06 12:08:35 <astuuu> the specific example applies when i am spending more than 10 outputs (to a single destination) and each output has a separate private key. works fine for <10 outputs (and <10 keys)
176 2015-01-06 12:10:05 <gmaxwell> I don't believe there are any numerical limits in the code like that.
177 2015-01-06 12:10:23 <astuuu> i'm not suggesting that it's hardcoded. that is just the behaviour i'm experiencing.
178 2015-01-06 12:11:31 <bedeho> wumpus:thank you
179 2015-01-06 12:12:42 <michagogo> astuuu: can you give a specific example?
180 2015-01-06 12:13:14 <michagogo> (Perhaps generate a bunch of testnet keys, so you can show the command verbatim?)
181 2015-01-06 12:13:26 <sipa> astuuu: if you're redeeming a p2sh output, you need to give the actual scripts too
182 2015-01-06 12:14:11 <michagogo> Oh, is there p2sh involved?
183 2015-01-06 12:14:12 <astuuu> sipa: i'm not redeeming a p2sh output
184 2015-01-06 12:15:03 <astuuu> i'll run a few more tests and come back with more info. dinner time here. thanks for your help, folks!
185 2015-01-06 12:15:11 <michagogo> Hm, do we have any kind of keygen outside of the wallet in any of our tools?
186 2015-01-06 12:15:18 <sipa> nope
187 2015-01-06 12:15:28 <sipa> i want a bitcoin-jey tool
188 2015-01-06 12:15:34 <sipa> bitcoin-key
189 2015-01-06 12:16:00 <michagogo> +1
190 2015-01-06 12:16:16 <astuuu> we've built something like that. lemme see if i can talk my supervisor into opening it up.
191 2015-01-06 12:16:24 <michagogo> It's a natural companion to bitcoin-tx imo
192 2015-01-06 12:16:57 <michagogo> I mean, there's always vanitygen with a prefix of 1 or m :-P
193 2015-01-06 12:17:06 <gmaxwell> astuuu: I wouldn't bother unless it's a patch to bitcoin core or uses libsecp256k1, ... because if you don't care about sidechannel freeness vanitygen works great 'vanitygen 1'
194 2015-01-06 12:17:52 <gmaxwell> (esp since it now generates compressed keys)
195 2015-01-06 12:18:04 <michagogo> Hmm
196 2015-01-06 12:18:05 <astuuu> makes sense
197 2015-01-06 12:18:08 <astuuu> dinner time - thanks folks
198 2015-01-06 12:18:15 <michagogo> Do we not ship bitcoin-tx?
199 2015-01-06 12:18:28 <michagogo> I don't seem to have it in my 0.10.0rc1 install
200 2015-01-06 12:18:34 <gmaxwell> oops
201 2015-01-06 12:19:02 <gmaxwell> must have not gotten included with the install files list? in the automake stuff?
202 2015-01-06 12:19:06 <astuuu> i was going to dig into bitcoin-tx next, on sipa's suggestion. task for tomorrow, in the absence of documentation
203 2015-01-06 12:19:29 <michagogo> gmaxwell: I'd think probably nsis specifically
204 2015-01-06 12:19:51 <michagogo> Because I just looked, it is in the zip
205 2015-01-06 12:20:16 <gmaxwell> michagogo: you run windows?!
206 2015-01-06 12:20:32 <michagogo> um
207 2015-01-06 12:20:33 <michagogo> yes
208 2015-01-06 12:20:53 <midnightmagic> SHUN SHUN
209 2015-01-06 12:21:05 <gmaxwell> midnightmagic: gah no!
210 2015-01-06 12:21:12 <Luke-Jr> O.o
211 2015-01-06 12:21:12 <michagogo> midnightmagic: ಠ_à²
212 2015-01-06 12:21:24 <midnightmagic> ACTION ducks
213 2015-01-06 12:21:48 <gmaxwell> midnightmagic: we must treasure our sacrificial lab rats, rare as it is a person who willingly uses windows while in proximity to people who could help them escape it.
214 2015-01-06 12:22:04 <Luke-Jr> lol
215 2015-01-06 12:22:44 <midnightmagic> michagogo: what version? fwiw, I have an XP image here i use under virtualbox occasionally when I need to run certain software
216 2015-01-06 12:22:54 <michagogo> midnightmagic: 7 Home Premium 64-bit
217 2015-01-06 12:22:58 <gmaxwell> I've had bad luck with other software projects where people show up as windows users and are super helpful testing things... and then stop running windows.
218 2015-01-06 12:23:08 <midnightmagic> lol
219 2015-01-06 12:23:13 <wumpus> midnightmagic: I also have an XP virtualbox image somewhere, but I don't even dare booting it anymore :-)
220 2015-01-06 12:23:23 <midnightmagic> no need to stop running windows, really, there's cygwin
221 2015-01-06 12:23:38 <midnightmagic> only bad thing about cygwin is redhat is *brutal* about their licensing
222 2015-01-06 12:23:43 <michagogo> Heh, I have this habit of fidgeting. Sometimes when I'm at the computer that takes the form of hitting Ctrl and making the cursor highlight, other times I scroll and feel my mouse vibrate (it has this touch panel for scrolling, with haptic feedback). Just now the two combined.
223 2015-01-06 12:23:58 <michagogo> and I suddenly ended up with tons of backlog on my screen :P
224 2015-01-06 12:24:48 <midnightmagic> I have a habit of circling my mouse slightly over its eventual target that I picked up from my Amiga: the mouse cursor was inextricable linked to the current load of the system and so a little mouse-twitching was the best way of sampling system load
225 2015-01-06 12:25:27 <michagogo> If anyone wants to label it, https://github.com/bitcoin/bitcoin/issues/5605
226 2015-01-06 12:25:28 <midnightmagic> so.. never be ashamed of old habits, they are only maladaptive sometimes!
227 2015-01-06 12:26:51 <michagogo> I do have an Ubuntu VM for when I need/want to do something in there
228 2015-01-06 12:27:19 <michagogo> And Cygwin, too, for when I want things like strings, file, other linuxy tools
229 2015-01-06 12:27:52 <wumpus> midnightmagic: cygwin is also fairly slow, at least when doing something that involves creating lots of new processes, e.g. shell scripts
230 2015-01-06 12:28:23 <sipa> even though i know there is still a huge userbase for windows, so few of my friends do that i'm often actually genuinely surprised when i hear about someone voluntarily using it
231 2015-01-06 12:29:04 <michagogo> hehe
232 2015-01-06 12:29:14 <wumpus> midnightmagic: I've used it at my last job to get some sanity even though the UNIX workstations were being replaced by run-off-the-mill DELL desktops running windows :(
233 2015-01-06 12:29:16 <sipa> (not intended in a bad way, you use what you like)
234 2015-01-06 12:29:34 <gmaxwell> yea, no you're a hero. Stay just the way you are.
235 2015-01-06 12:29:50 <sipa> google thankfully had linux desktops by default :)
236 2015-01-06 12:29:56 <gmaxwell> Windows using people are very much needed.
237 2015-01-06 12:30:14 <wumpus> solaris was quite annoying sometimes, but it doesn't compare in pain to windows
238 2015-01-06 12:31:40 <bedeho> does the minimum transaction fee required to relay and mine a transaction depend on anything other than the number of inputs and outputs, e.g. the version of bitcoin core?
239 2015-01-06 12:33:00 <michagogo> bedeho: well, ultimately it depends on exactly one thing
240 2015-01-06 12:33:08 <michagogo> And that's the size of the transaction
241 2015-01-06 12:33:36 <michagogo> (I mean, what's compared is the fee per byte, if I'm not mistaken)
242 2015-01-06 12:33:42 <gmaxwell> bedeho: this is outdated but provides a broader understanding; https://en.bitcoin.it/wiki/Transaction_fees
243 2015-01-06 12:34:06 <michagogo> (Does anything still look at fees per rounded kB?)
244 2015-01-06 12:36:57 <bedeho> gmaxwell: thanks
245 2015-01-06 12:41:11 <bedeho> Perhaps I should just explain what I am trying to do: I am working on a micropayment protocol, and I am trying to decide if the protocol should allow peers to agree on what fees should be used, or if this is redundant. The transaction in question is always of the same size, which the wiki would indicate would always have the same fee, but I dont want the protocol to break with a new version of bitcoin core which may change the rules.
246 2015-01-06 12:41:53 <michagogo> hmmm
247 2015-01-06 12:42:06 <michagogo> for some reason bfgminer doesn't want to connect to bitcoind
248 2015-01-06 12:42:10 <michagogo> (on testnet)
249 2015-01-06 12:42:53 <sipa> bedeho: more than worrying about what bitcoin core will accept, you should worry about what is needed to get the transaction mined
250 2015-01-06 12:43:06 <JackH> hey what is the best faucet for some testnet coins? I am stuck in something and need more testcoins
251 2015-01-06 12:43:17 <michagogo> JackH: http://tpfaucet.appspot.com/ is one
252 2015-01-06 12:43:46 <michagogo> The other I know of is http://faucet.xeno-genesis.com/
253 2015-01-06 12:43:59 <michagogo> though idk why that one is sending such small amounts atm
254 2015-01-06 12:44:07 <bedeho> JackH: that last one has always worked well for me
255 2015-01-06 12:44:08 <JackH> yeah same with other
256 2015-01-06 12:44:10 <michagogo> ACTION prods Luke-Jr
257 2015-01-06 12:44:19 <JackH> check out the xeno, it hardly sends anything any more
258 2015-01-06 12:44:25 <JackH> I have to adjust all my test prices now
259 2015-01-06 12:44:44 <JackH> I bet this is a confused dude thinking its real bitcoins
260 2015-01-06 12:47:34 <bedeho> sipa: I see, thank you
261 2015-01-06 12:51:43 <gmaxwell> bedeho: users really must be able to specify fees, since they may have different requirements on how fast a transaction will confirm. The fees type that is being talking about on the wiki are the _bare minimum_ without which the transation will be ignored (by many).
262 2015-01-06 12:52:04 <gmaxwell> But miners prioritize by fees/byte and so you may need to pay more to get timely processing.
263 2015-01-06 12:52:52 <JackH> since we are talking confirmation time here, anyone remember the time for testnet to confirm?
264 2015-01-06 12:53:18 <JackH> I assume 10 :)
265 2015-01-06 12:54:04 <bedeho> gmaxwell: that makes sense
266 2015-01-06 12:54:12 <gmaxwell> JackH: yes, if people are mining it.
267 2015-01-06 12:54:25 <Luke-Jr> ACTION prods michagogo
268 2015-01-06 12:55:34 <michagogo> Luke-Jr: any idea why bfgminer isn't connecting to bitcoind?
269 2015-01-06 12:55:39 <Luke-Jr> midnightmagic: Cygwin is dead :P
270 2015-01-06 12:55:56 <Luke-Jr> michagogo: nope, just works here
271 2015-01-06 12:56:04 <michagogo> Pretty sure it worked with the same config and everything on my previous computer before I reinstalled
272 2015-01-06 12:56:14 <michagogo> Luke-Jr: on 0.10.0rc1?
273 2015-01-06 12:56:23 <gmaxwell> michagogo: what is your allowip line look like?
274 2015-01-06 12:56:36 <michagogo> gmaxwell: N/A
275 2015-01-06 12:56:58 <michagogo> (no, it's not the wildcard to CIDR change)
276 2015-01-06 12:57:12 <Luke-Jr> michagogo: you have no rpcallowip?
277 2015-01-06 12:57:18 <michagogo> Luke-Jr: correct
278 2015-01-06 12:57:21 <michagogo> so localhost-only
279 2015-01-06 12:57:33 <Luke-Jr> can you telnet to it? :P
280 2015-01-06 12:57:57 <michagogo> by telnet, do you mean raw connection?
281 2015-01-06 12:58:01 <Luke-Jr> yes
282 2015-01-06 12:58:07 <michagogo> yes
283 2015-01-06 12:58:14 <Luke-Jr> how are you trying to use bfgminer?
284 2015-01-06 12:58:39 <michagogo> C:\Users\Micha\Downloads\bfgminer-3.9.0-win64\bfgminer-3.9.0-win64>bfgminer.exe
285 2015-01-06 12:58:50 <michagogo> conf:
286 2015-01-06 12:58:51 <Luke-Jr> with a config file?
287 2015-01-06 12:59:03 <michagogo> https://www.irccloud.com/pastebin/ZSviK3ww
288 2015-01-06 12:59:07 <michagogo> yeah
289 2015-01-06 12:59:25 <michagogo> If I remove the pools block from the config, it asks me in the terminal
290 2015-01-06 12:59:30 <michagogo> And then still fails
291 2015-01-06 12:59:35 <michagogo> oh, derp
292 2015-01-06 12:59:39 <michagogo> I know what's wrong
293 2015-01-06 12:59:48 <michagogo> It's been a while since I've done this
294 2015-01-06 12:59:55 <michagogo> I forgot that I need a coinbase address
295 2015-01-06 13:00:11 <Luke-Jr> that won't cause connection errors
296 2015-01-06 13:00:34 <michagogo> Even with getwork removed?
297 2015-01-06 13:00:55 <michagogo> That was the problem. Added coinbase-addr and it's working now
298 2015-01-06 13:01:05 <Luke-Jr> BFGMiner's default is http://localhost:8332/%s#getcbaddr#allblocks
299 2015-01-06 13:01:28 <michagogo> Luke-Jr: this is for testnet
300 2015-01-06 13:01:38 <Luke-Jr> #getcbaddr calls getaccountaddress for you
301 2015-01-06 13:01:49 <michagogo> getaccountaddress? o_O
302 2015-01-06 13:01:56 <Luke-Jr> yes
303 2015-01-06 13:02:00 <Luke-Jr> so you don't need to manually specify one
304 2015-01-06 13:02:02 <michagogo> Why?
305 2015-01-06 13:02:07 <michagogo> What account does it ask for?
306 2015-01-06 13:02:13 <Luke-Jr> "BFGMiner"
307 2015-01-06 13:02:52 <michagogo> Cool, so I'll add that
308 2015-01-06 13:03:25 <Luke-Jr> O.o?
309 2015-01-06 13:04:22 <michagogo> Luke-Jr: to the config file
310 2015-01-06 13:05:15 <michagogo> (I'm running on testnet here)
311 2015-01-06 13:05:39 <michagogo> Luke-Jr: that doesn't seem to work
312 2015-01-06 13:05:48 <michagogo> Er, maybe I'm on an old version
313 2015-01-06 13:05:53 <michagogo> Where should I get the latest?
314 2015-01-06 13:05:56 <Luke-Jr> bfgminer.com
315 2015-01-06 13:06:01 <michagogo> Okay
316 2015-01-06 13:06:05 <michagogo> (what's bfgminer.org?)
317 2015-01-06 13:07:07 <Luke-Jr> a fan site
318 2015-01-06 13:08:49 <michagogo> Will the 3.9.0 config file work as-in on 5.0.0?
319 2015-01-06 13:13:10 <Luke-Jr> michagogo: should
320 2015-01-06 13:13:16 <Luke-Jr> I think
321 2015-01-06 13:13:23 <Luke-Jr> 3.9.0 is pretty old though
322 2015-01-06 13:14:15 <michagogo> hm
323 2015-01-06 13:14:24 <michagogo> how do I tell it not to use that default?
324 2015-01-06 13:16:00 <Luke-Jr> ?
325 2015-01-06 13:16:09 <michagogo> not to connect to localhost:8332
326 2015-01-06 13:16:11 <Luke-Jr> cfields: our configure doesn't check for openssl/ec.h?
327 2015-01-06 13:16:17 <Luke-Jr> michagogo: --no-local-bitcoin
328 2015-01-06 13:42:15 <Luke-Jr> cfields: wumpus: 5542 rewritten and tested
329 2015-01-06 13:42:31 <Luke-Jr> (including tested on system without boost)
330 2015-01-06 13:46:14 <jonasschnelli> sipa, logdb: did you choose the frame header by random ({0xCC,0xC4,0xE6,0xB0}) or does it make sense somehow? Are 4 chars enough as header?
331 2015-01-06 13:46:58 <michagogo> Did we end up with a command to blacklist a block, btw?
332 2015-01-06 13:47:09 <michagogo> (I don't see it in help, but IIRC there was talk of hiding it?)
333 2015-01-06 13:47:18 <sipa> michagogo: yes, it is in 0.10
334 2015-01-06 13:47:26 <sipa> not listed though
335 2015-01-06 13:47:34 <michagogo> Ah, found the PR
336 2015-01-06 13:47:45 <sipa> invalidateblock and reconsiderblock
337 2015-01-06 13:48:01 <bedeho> Why was it decided that outputs have to be spent entirely? if one could spend them partially, then you could avoid the whole change issue, and it doesnt seem to me that it is any easier to check if an output is unspent versus having enough remaining unspent funds?
338 2015-01-06 13:48:22 <sipa> bedeho: one problem is replay
339 2015-01-06 13:48:37 <bedeho> replay?
340 2015-01-06 13:48:42 <sipa> you could issue the same transaction twice
341 2015-01-06 13:48:57 <sipa> or rather, the receiver could issue it again
342 2015-01-06 13:49:02 <michagogo> Heh, that's interesting to watch in the log
343 2015-01-06 13:49:24 <michagogo> the UpdateTip: new best lines happening backwards
344 2015-01-06 13:49:26 <bedeho> *thinking*
345 2015-01-06 13:49:42 <sipa> bedeho: if a transaction moves 1 BTC from my account to yours
346 2015-01-06 13:49:52 <sipa> and there are 5 BTC left in mine afterwards
347 2015-01-06 13:50:05 <bedeho> yes I get it, Im trying to see if one cant work around it
348 2015-01-06 13:50:25 <wumpus> include the starting amount
349 2015-01-06 13:50:39 <sipa> in additiomln, having atlccounts at the protocol level is horrible for privacy
350 2015-01-06 13:50:43 <sipa> *addition
351 2015-01-06 13:50:47 <wumpus> e.g., 'this transaction brings the balance of output XX from YY to ZZ'
352 2015-01-06 13:51:03 <bedeho> wumpus: yeah that would seem to work?
353 2015-01-06 13:51:07 <sipa> as it would mean being less private is cheaper in terms of fees
354 2015-01-06 13:51:30 <wumpus> but yes, from a privacy perspective it's horrible, and I also remember there were some other race condition issues
355 2015-01-06 13:51:39 <wumpus> it's akin to address reuse every time
356 2015-01-06 13:51:47 <michagogo> And have the inputs be decrement-only? Interesting
357 2015-01-06 13:52:20 <bedeho> wumpus: wouldnt it also work to say that you can never include a transaction with the same hash as an old one?
358 2015-01-06 13:52:32 <Luke-Jr> bedeho: why do you see change as an issue? the issue is address reuse more than change
359 2015-01-06 13:52:39 <michagogo> bedeho: what happens if you *want* to do the same thing again
360 2015-01-06 13:52:46 <wumpus> bedeho: it wouldn't be as trivially correct, ie malleability issues would suddenly allow cheating
361 2015-01-06 13:52:47 <Luke-Jr> bedeho: then all nodes need to store the hash of every transaction forever
362 2015-01-06 13:53:00 <sipa> bedeho: that means keeping track of all transactions ever
363 2015-01-06 13:53:06 <michagogo> And what they said
364 2015-01-06 13:53:07 <bedeho> isnt that already the case?
365 2015-01-06 13:53:09 <sipa> no
366 2015-01-06 13:53:10 <Luke-Jr> no
367 2015-01-06 13:53:12 <bedeho> hehe
368 2015-01-06 13:53:12 <michagogo> bedeho: no
369 2015-01-06 13:53:14 <bedeho> :D
370 2015-01-06 13:53:14 <Luke-Jr> lol
371 2015-01-06 13:53:24 <michagogo> any fully-spent transaction can be forgotten
372 2015-01-06 13:53:33 <michagogo> (well, except for the undo data)
373 2015-01-06 13:53:35 <Luke-Jr> bedeho: besides, Bitcoin has serious privacy problems already; what you're suggesting would make it far worse
374 2015-01-06 13:54:02 <sipa> the current database size is far smaller than even just thay
375 2015-01-06 13:54:05 <Luke-Jr> there's not even any benefit to spending part of an output afaik
376 2015-01-06 13:54:12 <sipa> (the txids of all transactiins ever)
377 2015-01-06 13:54:51 <sipa> it makes sense if you like having the concept of accounts in the protocol, and i guess that simplifies understanding
378 2015-01-06 13:55:11 <sipa> the problem is that just that itself is not actually a good idea
379 2015-01-06 13:55:27 <wumpus> Luke-Jr: slightly smaller transactions, I suppose, as you could do with less outputs. Although on the other hand you'd need another field ('starting balance') per input
380 2015-01-06 13:55:53 <sipa> wumpus: and worse, privacy would come at a higher cost
381 2015-01-06 13:56:30 <michagogo> Oh, right, I was doing all that to test the >10 thing
382 2015-01-06 13:56:33 <wumpus> sipa: oh sure, I'm not arguing it's a good idea, privacy is a much bigger issue at this point
383 2015-01-06 13:56:52 <bedeho> well, in my particular case, I need to have confirmed transactions which only spend a particular quantity into a payment channel, so since this quantity is not known before hand, one must first wait for the confirmation of a tx which creates new such outputs of just the right size, and then wait for the payment channel contract again...
384 2015-01-06 13:57:07 <Luke-Jr> maybe some day, bedeho can make a sidechain with an account-based system, and totally-transparent entities can use that :P
385 2015-01-06 13:57:11 <michagogo> Hmm
386 2015-01-06 13:57:22 <bedeho> :P
387 2015-01-06 13:57:27 <wumpus> right
388 2015-01-06 13:57:37 <michagogo> bitcoin-cli.exe seems to be somewhat broken
389 2015-01-06 13:57:48 <michagogo> It shows "\n" where I suspect there should be actual newlines
390 2015-01-06 13:57:51 <Luke-Jr> bedeho: why? just use the bigger UTXO as the input, and spend the right amount directly into the paymetn channel contract?
391 2015-01-06 13:57:56 <bedeho> well I guess I not asking for accounts exactly, although they would work, this would still be the whole input output model
392 2015-01-06 13:58:25 <michagogo> e.g. in help output
393 2015-01-06 13:58:25 <wumpus> michagogo: that's the exception formatting
394 2015-01-06 13:58:31 <michagogo> oh
395 2015-01-06 13:58:41 <wumpus> exception messages are not pretty-printed, but just smashed into one line in JSON format
396 2015-01-06 13:58:47 <michagogo> Indeed
397 2015-01-06 13:58:56 <wumpus> that's not 'broken' but has always been the case
398 2015-01-06 13:58:59 <bedeho> Luke-Jr: if both people but money in the channel, as they must in my context, then putting a large amount into it leaves you open to extortion if you sign the contract first.
399 2015-01-06 13:59:09 <michagogo> wumpus: yeah, didn't realize that
400 2015-01-06 13:59:13 <wumpus> would be a nice project for a newbie contributor I suppose
401 2015-01-06 14:01:19 <Luke-Jr> bedeho: how? until both parties sign it, you can double-spend it.
402 2015-01-06 14:15:14 <Adlai`> node that ran without trouble (40+ peers) for several days, is now stuck at 8, and reported as down by getaddr.bitnodes.io, I can see the "received version message" in its output, it's still getting blocks, ports forwarded properly... any ideas?
403 2015-01-06 14:15:21 <Adlai`> (short of just restarting bitcoind)
404 2015-01-06 14:15:56 <wumpus> did maybe your external IP change?
405 2015-01-06 14:16:02 <adlai> probably relevant info: my IP has changed from what it was when the ... yes it did :)
406 2015-01-06 14:16:18 <adlai> does this require restarting bitcoind?
407 2015-01-06 14:16:38 <wumpus> what version?
408 2015-01-06 14:16:45 <adlai> 90300
409 2015-01-06 14:16:49 <wumpus> yes, it does
410 2015-01-06 14:17:08 <bedeho> Luke-Jr: yes, but the problem, at least as it appears to me is, the party creating the refund will have to sign the contract last, so in a scenario where both put money in, this party can extort the former by only being willing to spend some funds back to the former. In a regular payment channel, the refund creator is the only one risking funds, and hence cannot extort.
411 2015-01-06 14:17:20 <adlai> righto, ty wumpus
412 2015-01-06 14:17:58 <wumpus> (in 0.10rc1 the get-my-ip-logic changed and IIRC it will start advertising your new IP automatically, if discovery is enabled of course)
413 2015-01-06 14:18:29 <bedeho> if the refund creator signs the contract first, then the other party can do the same
414 2015-01-06 14:34:25 <michagogo> Hmmm
415 2015-01-06 14:34:36 <michagogo> So I just tried creating a 12-input transaction
416 2015-01-06 14:34:41 <michagogo> No problem with bitcoin-cli:
417 2015-01-06 14:34:51 <michagogo> https://www.irccloud.com/pastebin/6jW2GrAS
418 2015-01-06 14:35:16 <michagogo> I'm trying to test with bitcoin-tx now, but this is happening:
419 2015-01-06 14:35:18 <michagogo> https://www.irccloud.com/pastebin/phe95ps5
420 2015-01-06 14:35:24 <michagogo> error: expected prevtxs internal object
421 2015-01-06 14:36:14 <michagogo> Even though I did include this: set=prevtxs:'[{"txid":"b976b38d0344ceab132f414474efd4cb7527650cc9b046b1856b367335bbba4d","vout":1,"scriptPubKey":"76a914553b508811f96b4bb1296d608196bf8a3825ac3388ac"},...]'
422 2015-01-06 14:39:29 <michagogo> https://www.irccloud.com/pastebin/RmynuHnl
423 2015-01-06 14:39:44 <michagogo> erm
424 2015-01-06 14:39:53 <michagogo> same if I try doing it in 2 steps: ^^
425 2015-01-06 14:41:17 <michagogo> Looks like it's this doing it: https://github.com/bitcoin/bitcoin/blob/v0.10.0rc1/src/bitcoin-tx.cpp#L372
426 2015-01-06 14:41:25 <michagogo> Anyone understand what's going on there?
427 2015-01-06 14:58:41 <gdm85> michagogo: is it windows/cygwin specific?
428 2015-01-06 14:58:53 <michagogo> gdm85: oh, hm, interesting question
429 2015-01-06 14:59:01 <michagogo> I'll fire up my VM
430 2015-01-06 14:59:39 <gdm85> I'd try bitcoin-tx myself, but I am currently knee-deep in some refactoring..
431 2015-01-06 15:00:06 <michagogo> (I couldn't get it to work in cmd, probably something to do with quoting. No idea how that works, but no matter what I tried it told me that it couldn't parse the json)
432 2015-01-06 15:06:00 <michagogo> gdm85: Nope, not cygwin/Windows-specific
433 2015-01-06 15:06:16 <michagogo> Identical command on Ubuntu Precise 64, same error
434 2015-01-06 15:13:10 <midnightmagic> gmaxwell: so I can now run the benchmarks with reduced iters and counts, varying the WINDOW_G parameter at runtime (which I guess technically means the parameter could be modified by users of the library now without recompiling) and now I'm going to go see what the full range looks like on the avr32 board. :-D
435 2015-01-06 15:20:02 <jgarzik> heh, cool. paveljanik verf'd a chain on big endian.
436 2015-01-06 15:21:02 <midnightmagic> :-P me too
437 2015-01-06 15:21:27 <michagogo> jgarzik: bitcoin-tx was you, right?
438 2015-01-06 15:21:34 <michagogo> Maybe youc an tell me what I'm doing wrong
439 2015-01-06 15:21:36 <midnightmagic> from: 2014-12-28 01:14:55 to: 2015-01-06 15:14:17
440 2015-01-06 15:21:39 <jgarzik> michagogo, yes.
441 2015-01-06 15:21:49 <jgarzik> michagogo, I saw your report RE bitcoin-tx.exe shipping, thanks.
442 2015-01-06 15:22:05 <michagogo> jgarzik: see my pastes about 45 mins ago
443 2015-01-06 15:22:18 <paveljanik> jgarzik, test only
444 2015-01-06 15:22:28 <paveljanik> so far.
445 2015-01-06 15:23:02 <jgarzik> michagogo, There was a bug fix related to that; was just merged. Did you test HEAD?
446 2015-01-06 15:23:07 <jgarzik> master, I mean.
447 2015-01-06 15:23:22 <michagogo> jgarzik: no, this is with the rc1 gitian output
448 2015-01-06 15:23:30 <michagogo> I'll build master and test
449 2015-01-06 15:25:18 <jgarzik> probably just need to copy that fix into the 0.10 branch
450 2015-01-06 15:27:45 <michagogo> Yeah, that should probably also get in for rc2
451 2015-01-06 15:57:08 <michagogo> ACTION wonders why any e.g. mining code needs to be compiled when only bitcoin-cli and bitcoin-tx are being built
452 2015-01-06 15:59:39 <michagogo> jgarzik: yep, works without a problem with master, using the same command
453 2015-01-06 16:00:52 <jgarzik> wumpus, 0.10 needs 2a3d988b802dcea4453241e37168d8511078940a and a089c50981e822014ffc18e8a37b3518feb52206
454 2015-01-06 16:02:30 <michagogo> Er, that's just the first commit of 3 in that PR
455 2015-01-06 16:02:34 <michagogo> Is the first one all it needs?
456 2015-01-06 16:02:42 <michagogo> (PR #5528)
457 2015-01-06 16:02:44 <hearn> wumpus: any idea when rc2 might be?
458 2015-01-06 16:03:51 <michagogo> jgarzik: oh, do you not need to give -create the in= entries if you're signing and setting prevtxes?
459 2015-01-06 16:03:55 <michagogo> prevtxs*
460 2015-01-06 16:03:55 <wumpus> hearn: when the remaning blocking issues are resolved https://github.com/bitcoin/bitcoin/milestones/0.10.0
461 2015-01-06 16:04:08 <wumpus> and seemingly some commits still need backporting
462 2015-01-06 16:05:00 <wumpus> hearn: any specific fix you need it for?
463 2015-01-06 16:05:44 <hearn> nope, just trying to get a rough idea
464 2015-01-06 16:07:44 <michagogo> Also, I think someone at some point recently was talking about a separate repo or something for trivial tweaks to avoid breaking patches and requiring rebase as often
465 2015-01-06 16:08:16 <michagogo> One thing that was mentioned was wasting travis time on building for e.g. doc changes
466 2015-01-06 16:08:33 <michagogo> There's another solution to that one aspect...
467 2015-01-06 16:09:00 <michagogo> train people to add [skip ci] or [ci skip] in their commit messages :P
468 2015-01-06 16:10:11 <jgarzik> wumpus, michagogo, indeed + 2c14d1532fe66a243cdbfb7de48b298213305765 for the test case
469 2015-01-06 16:10:41 <michagogo> jgarzik: ...and a089c50?
470 2015-01-06 16:10:48 <michagogo> er, wait
471 2015-01-06 16:10:56 <michagogo> nvm, somehow I missed you mentioning that at first
472 2015-01-06 16:12:04 <ajweiss> sipa: ping
473 2015-01-06 16:12:08 <sipa> ajweiss: pang
474 2015-01-06 16:12:18 <ajweiss> hey, i was just looking at this stuff
475 2015-01-06 16:12:35 <ajweiss> won't a simple timeout like that cause problems when parallel downloading?
476 2015-01-06 16:12:51 <sipa> ajweiss: there are never more than 8 outstanding requests from a single peer
477 2015-01-06 16:13:08 <ajweiss> but 8 peers?
478 2015-01-06 16:13:34 <michagogo> wumpus/jgarzik: maybe mark 5605 with the 0.10.0 milestone?
479 2015-01-06 16:13:38 <sipa> hmm, you mean when our own downstream bandwidth is insufficient
480 2015-01-06 16:13:40 <ajweiss> actually 16 blocks per peer
481 2015-01-06 16:13:44 <sipa> right, 16
482 2015-01-06 16:14:09 <ajweiss> so you'll disconnect if you can't transfer 8MB in 10 minutes
483 2015-01-06 16:14:17 <ajweiss> since it's 8 peers
484 2015-01-06 16:14:23 <michagogo> And maybe the Windows and Build system labels?
485 2015-01-06 16:15:13 <sipa> ajweiss: agree, maybe this policy is too aggresive
486 2015-01-06 16:15:38 <ajweiss> when i was thinking about this, i was thinking it would be best to try and avoid doing this when in IBD
487 2015-01-06 16:15:52 <ajweiss> or better yet, try to avoid situations where we know we're "busy"
488 2015-01-06 16:16:17 <sipa> ajweiss: one possibility is remembering how many blocks are queued already at the time a block is requested, and either only trigger the timeout for blocks that have a low number for that
489 2015-01-06 16:16:23 <sipa> ajweiss: or add extra time
490 2015-01-06 16:17:28 <ajweiss> also, just looking at the head of the queue looks at the timestamp when it was placed in the queue
491 2015-01-06 16:17:40 <sipa> yup
492 2015-01-06 16:17:42 <michagogo> So, anyway
493 2015-01-06 16:17:48 <michagogo> 14:07:35 <astuuu> when signing a tx with signrawtransaction() and passing in private keys and scriptPubKeys (and all other relevant data), why would I get a "missing redeemScript" message if no one output required more than one signature? 14:08:07 <astuuu> using bitcoind 0.10.0rc1 (earlier versions gave me no error at all) 14:08:37 <astuuu> the specific
494 2015-01-06 16:17:48 <michagogo> example applies when i am spending more than 10 outputs (to a single destination) and each output has a separate private key. works fine for <10 outputs (and <10 keys)
495 2015-01-06 16:17:55 <michagogo> I couldn't reproduce that issue
496 2015-01-06 16:18:12 <sipa> ajweiss: as opposed to when the getdata for it went out?
497 2015-01-06 16:18:30 <ajweiss> i played with something that was looking at the last time we got a block from a peer
498 2015-01-06 16:18:39 <ajweiss> but that's also complicated
499 2015-01-06 16:18:40 <sipa> yes, 0.9 did that
500 2015-01-06 16:18:41 <michagogo> I created a transaction with 12 inputs and one output, and was able to create, sign, and send it with bitcoin-cli with no problem
501 2015-01-06 16:19:01 <sipa> but it means a peer can ignore one block, and do everything for further blocks, and still stall you
502 2015-01-06 16:19:07 <morcos> sipa: i think ajweiss means as opposed to when the peer started sending it to you, if you requested 16 at once, and that was the 16th
503 2015-01-06 16:19:41 <sipa> morcos: yes, that's why i suggest taking the number of queued entries at the time of request into account
504 2015-01-06 16:19:52 <sipa> in steady state, that number will be very low (typically 0 or at most 1-2)
505 2015-01-06 16:20:37 <morcos> perhaps its worth considering a simple patch for 0.10 and then something a bit more thorough after to handle future situations such as gmaxwell mentioned where there might be occasional outsized blocks also
506 2015-01-06 16:20:48 <sipa> agree
507 2015-01-06 16:22:09 <ajweiss> also, disconnection seems a bit scary
508 2015-01-06 16:22:33 <ajweiss> as maybe it could be something that could be triggered by some other bug
509 2015-01-06 16:22:42 <ajweiss> that could be used to disconnect honest peers
510 2015-01-06 16:22:52 <ajweiss> and make sybil attacks easier
511 2015-01-06 16:23:38 <ajweiss> and if someone is stalling maliciously, there's nothing that eventually bans them
512 2015-01-06 16:24:10 <sipa> as long as we don't have a mechanism to cancel an existing download, i would really prefer to re-request the same block from elsewhere
513 2015-01-06 16:24:20 <sipa> *not
514 2015-01-06 16:24:33 <ajweiss> yeah i get that
515 2015-01-06 16:24:55 <ajweiss> it's kind of a trade off between a potential bandwidth starvation spiral or spurious disconnects
516 2015-01-06 16:24:58 <sipa> it has potential failure scenarios where we're downloading every block from every peer
517 2015-01-06 16:25:08 <sipa> and complicates reasoning about our internal state
518 2015-01-06 16:25:17 <ajweiss> that is true
519 2015-01-06 16:25:49 <ajweiss> the current code cleans it up when it re-reqs, but yeah there is a brief time where two nodes are active
520 2015-01-06 16:28:50 <ajweiss> anyway, i wrote this out to try and clarify my thoughts. i'm not sure what the right answer is: http://pastebin.com/SjJ52a2g
521 2015-01-06 16:30:18 <ajweiss> but i think looking at total blocks in flight might be better than just looking for one quiet node
522 2015-01-06 16:30:41 <sipa> ajweiss: updated my PR
523 2015-01-06 16:32:59 <ajweiss> looking now...
524 2015-01-06 16:33:50 <Luke-Jr> ACTION ponders what 5144 is held up by
525 2015-01-06 16:34:25 <ajweiss> i'm trying to think if there'd be a way to manipulate this to expand the timeout in malicious scenarios
526 2015-01-06 16:35:09 <sipa> hmm, good question
527 2015-01-06 16:35:58 <sipa> there probably is
528 2015-01-06 16:36:33 <sipa> 5 minutes extra per queued block, and you can basically announce up to 16 non-existing blocks per peer, which we'll try to download
529 2015-01-06 16:37:31 <ajweiss> so connect n times, announce 16 each, you then end up with a timeout of 5*16*n
530 2015-01-06 16:37:35 <sipa> yup
531 2015-01-06 16:37:41 <ajweiss> that's pretty cheap
532 2015-01-06 16:37:50 <sipa> agree, that's not good
533 2015-01-06 16:38:07 <sipa> perhaps we should only take the blocks requested through the parallel fetching mechanism into account
534 2015-01-06 16:38:16 <sipa> as those have validated headers
535 2015-01-06 16:38:38 <starsoccer> hey quick developer question, how often should I have a background request to check if an addy is funded
536 2015-01-06 16:38:48 <starsoccer> right now Its basically checking everysecond
537 2015-01-06 16:38:58 <ajweiss> so only count blocks that are in flight and in the header chain
538 2015-01-06 16:39:04 <sipa> starsoccer: checking from where?
539 2015-01-06 16:39:08 <wumpus> starsoccer: only check when a block came in?
540 2015-01-06 16:39:27 <ajweiss> hmm
541 2015-01-06 16:39:44 <starsoccer> wumpus, nah,
542 2015-01-06 16:39:56 <starsoccer> sipa, basically polling data to see if an addy has been deposited to
543 2015-01-06 16:40:03 <sipa> starsoccer: polling what?
544 2015-01-06 16:40:12 <starsoccer> polling address data
545 2015-01-06 16:40:23 <sipa> there is no such thing
546 2015-01-06 16:40:29 <starsoccer> sipa litterally its request what is address xyz balance
547 2015-01-06 16:40:38 <sipa> requesting where?
548 2015-01-06 16:40:55 <starsoccer> you mean what service am I requesting the data from?
549 2015-01-06 16:40:58 <sipa> yes
550 2015-01-06 16:41:08 <starsoccer> ah blockchain.info and bitreserve
551 2015-01-06 16:41:09 <sipa> or rather: ask that service how frequently they're fine
552 2015-01-06 16:41:23 <starsoccer> I was just curious what other devs use
553 2015-01-06 16:41:49 <sipa> not here please
554 2015-01-06 16:41:58 <sipa> this is not a third party service helpdeks
555 2015-01-06 16:45:37 <starsoccer> sipa, yea I know that, I am just asking if I wasnt using an api
556 2015-01-06 16:45:41 <starsoccer> how often would you poll
557 2015-01-06 16:45:44 <starsoccer> thats the question
558 2015-01-06 16:46:07 <sipa> that depends on the use case, and what the implementation can handle
559 2015-01-06 16:46:21 <sipa> and typically you'd set up a notification mechanism and not poll
560 2015-01-06 16:46:41 <starsoccer> sipa, ahh okay I didnt think of that, but that is for sure a better way to do it
561 2015-01-06 16:46:48 <sipa> sorry i'm not useful, but you'll get very little sympathy here if you choose to rely on third party services
562 2015-01-06 16:48:20 <starsoccer> no problem you were very helpful
563 2015-01-06 16:49:23 <wumpus> yes, ideally you'd use async notification, polling is wasteful and doesn't scale, hence my suggestion to check after each new block as that's the only time that transactions get confirmed
564 2015-01-06 16:50:00 <ajweiss> so basically you're thinking that nQueuedBefore should only count blocks in flight that are in the header chain?
565 2015-01-06 16:51:48 <sipa> ajweiss: pretty much
566 2015-01-06 16:52:14 <sipa> that corresponds exactly to blocks fetched through the parallel mechanism
567 2015-01-06 16:52:37 <sipa> but that mechanism is also used to fetch the missing in-between blocks in case of a reorganization for example
568 2015-01-06 16:53:28 <ajweiss> so you can't manipulate the timeout with pow so that's good.
569 2015-01-06 16:53:33 <ajweiss> ^without
570 2015-01-06 16:53:37 <sipa> updated
571 2015-01-06 16:55:13 <sipa> ajweiss: thanks for brainstorming about this :)
572 2015-01-06 16:55:31 <ajweiss> i've been thinking about it a lot, it's quite complicated!
573 2015-01-06 16:55:44 <ajweiss> but i think this looks good
574 2015-01-06 16:56:55 <michagogo> hmm
575 2015-01-06 16:57:06 <ajweiss> i guess the only other thing would be that the protocol should be updated to explicitly state that blocks should be transferred in the order they were inv'd
576 2015-01-06 16:57:21 <michagogo> wumpus: looks like there's other small stuff that could/should be cherry-picked back to 0.10: for example, https://github.com/bitcoin/bitcoin/commit/8f6860a083837e1f991ed75993f7c4fbcb10462c
577 2015-01-06 16:57:39 <wumpus> michagogo: I'd really like to avoid anything but critical fixes
578 2015-01-06 16:57:40 <sipa> ajweiss: well there are several node implementation that already rely on messages being processed in order
579 2015-01-06 16:58:00 <sipa> (per peer, at least)
580 2015-01-06 16:58:26 <michagogo> wumpus: Okay, I guess, though docstrings involving a new feature being wrong seems undesirable to me
581 2015-01-06 16:58:41 <ajweiss> ooh
582 2015-01-06 16:58:57 <ajweiss> don't forget to update the check statement, you're still looking at nQueuedBefore
583 2015-01-06 16:59:10 <sipa> yes?
584 2015-01-06 16:59:12 <wumpus> michagogo: right
585 2015-01-06 16:59:25 <sipa> ajweiss: maybe i need to rename it to nQueuedValidatedBefore
586 2015-01-06 16:59:39 <michagogo> From the perspective of a non-dev user just looking at the releases and not the process, this isn't not putting in a fix for an issue that's been around for a while
587 2015-01-06 16:59:53 <michagogo> It's a new release, with a new feature, that has incorrect documentation
588 2015-01-06 16:59:59 <ajweiss> ahh i see
589 2015-01-06 17:00:22 <sipa> ajweiss: if that wasn't obvious to you, it can use a better name
590 2015-01-06 17:00:36 <sipa> fixed
591 2015-01-06 17:02:56 <morcos> sipa: in a reorg, is it possible the other peer would inv you all the new blocks so you might request them without validated headers? in which case you only have 10 mins to get them all
592 2015-01-06 17:04:41 <sipa> morcos: yes, though that is for just one peer, which is limited to the number max outstanding requests per peer
593 2015-01-06 17:05:12 <sipa> morcos: when we introduce something like that, we should probably just relay the full new headers branch instead of doing invs, solving the problem entirely :)
594 2015-01-06 17:05:52 <morcos> when we introduce what?
595 2015-01-06 17:06:10 <sipa> announcing more than just the new tip
596 2015-01-06 17:07:22 <morcos> so how does it work now, if a node reorgs, it'll just inv the new tip first? so you should get the intervening headers?
597 2015-01-06 17:07:31 <sipa> yes, that's what happens
598 2015-01-06 17:08:05 <sipa> when an inv is received for an unknown block, we request the headers to it, followed by (in case we believe we're up to date, and not too many queued blocks already) fetching the block itself directly
599 2015-01-06 17:08:36 <sipa> if there are headers in between which are not being fetched already, those are downloaded through the normal parallel fetch mechanism
600 2015-01-06 17:09:28 <morcos> right, just wasn't sure how a node communicates a reorg, and thought maybe it inved all the new chain blocks, in which case we'd fetch all those blocks directly too
601 2015-01-06 17:12:06 <ajweiss> ok, cool. i'm going to test this and try to brainstorm how to break it. but looks good so far! i'll also close my old PR
602 2015-01-06 17:12:38 <sipa> yeah, sorry for just implementing something and not helping you to improve yours; but i'd like to see this issue solved quickly for the next rc
603 2015-01-06 17:13:13 <ajweiss> it's fine, there will be other bugs : )
604 2015-01-06 17:13:28 <sipa> ha
605 2015-01-06 17:14:20 <midnightmagic> sipa: there you go, should have everything fixed that you asked for
606 2015-01-06 17:17:38 <midnightmagic> the tests appear to run and succeed, and the benchmarks also; obviously I haven't personally verified that numbers match what they're supposed to.
607 2015-01-06 17:18:28 <midnightmagic> i ignored the other compiler warning because that had nothing to do with me
608 2015-01-06 17:35:55 <cfields> Luke-Jr: interesting. Since we've only seen runtime issues so far, i assume that ec.h was still shipped if ec is disabled in openssl's build
609 2015-01-06 17:36:00 <cfields> apparently not, though
610 2015-01-06 17:36:00 <sipa> ;;blocks
611 2015-01-06 17:36:02 <altgribble> 337798
612 2015-01-06 17:37:10 <Luke-Jr> cfields: well, Gentoo may do it differently than RedHat
613 2015-01-06 17:37:37 <cfields> Luke-Jr: i just looked at it in openssl source, looks like it's not shipped
614 2015-01-06 17:38:16 <cfields> Luke-Jr: i'm guessing the current problems have come from people running official builds on redhat. probably not many actually building there.
615 2015-01-06 17:38:33 <Luke-Jr> cfields: don't the official builds static-link openssl?
616 2015-01-06 17:38:52 <cfields> they do now, yes. iirc at one point they didn't
617 2015-01-06 17:39:21 <warren> cfields: huh? what special problems would happen with official builds on redhat?
618 2015-01-06 17:39:55 <sipa> warren: openssl EC not working
619 2015-01-06 17:40:09 <cfields> warren: shouldn't be any now afaik, was referring to older releases
620 2015-01-06 17:41:02 <warren> ok, that's what I thought
621 2015-01-06 17:41:11 <warren> sipa: only an issue if you use non-official builds
622 2015-01-06 17:41:20 <sipa> ah, right
623 2015-01-06 17:41:29 <sipa> we link in openssl statically
624 2015-01-06 17:41:38 <warren> in gitian yes
625 2015-01-06 17:42:46 <cfields> Luke-Jr: since we're going to the trouble to check the header, may as well go ahead and run a quick compile-test too? I believe ec.h can still be included without secp256k1 support.
626 2015-01-06 17:44:20 <cfields> Luke-Jr: i think something like this would be enough to pretty much guarantee support: EC_KEY *pkey = EC_KEY_new_by_curve_name(NID_secp256k1);
627 2015-01-06 17:45:03 <Luke-Jr> AC_TRY_RUN?
628 2015-01-06 17:45:07 <cfields> sipa: agree with ^^ statement ?
629 2015-01-06 17:45:14 <sipa> cfields: yes
630 2015-01-06 17:45:26 <cfields> Luke-Jr: no, that breaks cross. AC_TRY_LINK.
631 2015-01-06 17:45:57 <Luke-Jr> cfields: won't it link fine with RedHat's style EC?
632 2015-01-06 17:47:48 <Luke-Jr> actually, I should have a RedHat VM⦠I can just test :D
633 2015-01-06 17:48:04 <cfields> Luke-Jr: i'm assuming that redhat's would fail to compile due to missing NID_secp256k1 definition.
634 2015-01-06 17:48:17 <cfields> yea, that's an assumption worth testing for sure
635 2015-01-06 17:50:07 <Luke-Jr> any includes I need besides ec.h?
636 2015-01-06 17:50:49 <Luke-Jr> hm, my Redhat has no ec.h at all
637 2015-01-06 17:51:10 <Luke-Jr> oh, there's a new version ; I'm just got 6
638 2015-01-06 17:51:19 <Luke-Jr> anyone have a 7 to test with? :x
639 2015-01-06 17:52:10 <cfields> Luke-Jr: sounds like this is probably overkill then. if the 2 that we know to be problematic don't ship with ec.h, i suppose your check is enough aleady
640 2015-01-06 17:57:02 <cfields> Luke-Jr: yea, i don't see an option in vanilla openssl to remove just that curve. Seems to all be lumped in with OPENSSL_NO_EC.