1 2014-06-27 00:02:48 <sipa> some of the changes do look really silly, and don't seem like they can be avoided
2 2014-06-27 00:02:58 <gmaxwell> cfields: forcing alignment of 1 can be horrible for performance.
3 2014-06-27 00:03:06 <sipa> unsigned char *ptr = (unsigned char*)malloc(...)
4 2014-06-27 00:03:25 <cfields> gmaxwell: https://github.com/theuni/secp256k1/commit/11718c9a5835b389d926b271c713f6b7db009046
5 2014-06-27 00:04:04 <sipa> i dont understand
6 2014-06-27 00:04:20 <cfields> gmaxwell: understood that the change is very wrong. that was meant to be a placeholder to investigate whether or not the padding could be harmful
7 2014-06-27 00:04:49 <justanotheruser> Is there someone that is checking the consensus of clients 0.1-.8?
8 2014-06-27 00:05:04 <sipa> cfields: i don't see a sizeof(secp256k1_ge_consts_t) in tests
9 2014-06-27 00:05:11 <sipa> and i'm not sure what you're trying to do
10 2014-06-27 00:05:19 <gmaxwell> cfields: if you're worred about padding _inside_ a struct you should sort the struct by object size. Though this too can have performance implications if the original order was designed to pack cache lines well.
11 2014-06-27 00:05:48 <cfields> sipa: sorry, i wasn't looking to keep you up with a review tonight, was just curious as to your overall thoughts
12 2014-06-27 00:05:58 <sipa> if a struct is padded, its sizeof goes up too
13 2014-06-27 00:06:21 <sipa> cfields: ok; well... unsure, i like the general idea of being extra safe
14 2014-06-27 00:06:42 <sipa> but it does seem a bit excessivw
15 2014-06-27 00:06:51 <cfields> sipa: clearly adding in hacks for the sake of discussion didn't go well... :)
16 2014-06-27 00:07:01 <cfields> sipa: i'll try another round with clean fixes instead
17 2014-06-27 00:07:30 <sipa> sure, but i still just don't understand what you were trying to do, even if it was a knowingly incorrect solution
18 2014-06-27 00:07:34 <gmaxwell> it's just not clear to me which changes were discussion ones and what you were trying to discuss. :)
19 2014-06-27 00:08:22 <sipa> is there some particular compiler warning that is affected by this?
20 2014-06-27 00:08:29 <cfields> gmaxwell: heh, fair enough.
21 2014-06-27 00:08:37 <sipa> (the pack pragma, specifically)
22 2014-06-27 00:08:44 <cfields> sipa: yea, but i was afraid that there could be actual implicationss
23 2014-06-27 00:08:57 <sipa> what is the warning?
24 2014-06-27 00:09:11 <cfields> sipa: iirc there are a few places where sizeof(some struct) was used in calculating loop counters
25 2014-06-27 00:09:20 <sipa> yes, so?
26 2014-06-27 00:09:41 <gmaxwell> yes? if it's sizeof(struct[])/sizeof(struct) thats exactly right.
27 2014-06-27 00:10:09 <cfields> heh, understood. i'll try to dig up the case that made me add it
28 2014-06-27 00:10:16 <sipa> okay :)
29 2014-06-27 00:10:34 <sipa> ACTION zZzZ
30 2014-06-27 00:10:42 <cfields> sipa: and yea, clang will warn about the compiler adding padding
31 2014-06-27 00:11:02 <cfields> which i agree is pretty useless, i just wanted to ensure that it wasn't causing any complications
32 2014-06-27 00:11:21 <gmaxwell> sipa: I think with the right crazy options clang warns when there is pading _inside_ a struct that could be avoided by reordering it.
33 2014-06-27 00:12:18 <gmaxwell> e.g. int *;int;int*
34 2014-06-27 00:12:33 <cfields> gmaxwell: i was under the impression that it was warning about eg: struct foo{ char x[3]; };
35 2014-06-27 00:13:19 <gmaxwell> that would be crazy
36 2014-06-27 00:15:09 <cfields> gmaxwell: yep, you're correct
37 2014-06-27 00:15:32 <gmaxwell> whew
38 2014-06-27 00:16:17 <cfields> wow, i had a pretty serious misunderstanding of that one :)
39 2014-06-27 00:17:13 <cfields> gmaxwell: http://pastebin.com/raw.php?i=yLrW7z7t
40 2014-06-27 00:17:48 <gmaxwell> yea, if you sort the struct so that it's *,*,int the warning goes away, right?
41 2014-06-27 00:18:51 <cfields> heh, nope
42 2014-06-27 00:19:01 <cfields> test.c:1:8: warning: padding size of 'struct foo' with 4 bytes to alignment boundary [-Wpadded]
43 2014-06-27 00:19:48 <cfields> adding another int does it
44 2014-06-27 00:26:17 <cfields> gmaxwell: fwiw, it was cases like this that i was worried about: https://github.com/theuni/secp256k1/blob/master/src/ecmult_impl.h#L186
45 2014-06-27 00:26:42 <cfields> not saying it's a bug by any means, only that i hoped to get someone else's eyes on it
46 2014-06-27 00:29:31 <gmaxwell> sipa: as an aside, wrt good C style, it's generally better to always use sizeof(var) instead of sizeof(var's type) whenever the sizeof is referring directly to a specific variable that you're operating on, since the latter can become desynced from the variable.
47 2014-06-27 00:34:43 <cfields> http://pastebin.com/raw.php?i=x0x8Kj1W
48 2014-06-27 00:35:20 <cfields> so, it can point out bugs, just no idea if those apply to secp's uses or not
49 2014-06-27 00:38:03 <gmaxwell> I don't know why you think thats a bug example there.
50 2014-06-27 00:42:30 <cfields> gmaxwell: i don't, i'm just trying to explain my thought process, very poorly as usual :)
51 2014-06-27 00:43:29 <cfields> i suppose the only place i've ever seen it hit in the real world is when pushing to external libs/drivers that expect samples of packed data. gl/gles specifically
52 2014-06-27 00:45:08 <cfields> anyway, i'll just drop the warning
53 2014-06-27 00:52:14 <gmaxwell> cfields: the function that was concerning you is basically copying a secp256k1_ge_t in a funny order, it's actually working with the size of the structure there (since its copying it), so there is no harm. It's a rather odd construction, basically a localhost only private information retrivial scheme which attempts to hide the memory access patterns. :)
54 2014-06-27 00:54:59 <cfields> gmaxwell: ok. ultimately i just wanted some eyes on it, and you've done that. Thanks for endulging me :)
55 2014-06-27 00:55:55 <cfields> and for explaining as well.
56 2014-06-27 04:58:11 <ryan-c> does bitcoin still use json_sprint?
57 2014-06-27 04:58:13 <ryan-c> er
58 2014-06-27 04:58:22 <ryan-c> json_spirit
59 2014-06-27 05:00:18 <gmaxwell> for the moment.
60 2014-06-27 05:00:52 <gmaxwell> jeff has a replacementâ far simpler and smaller, perhaps we'll switch to it.
61 2014-06-27 05:03:56 <ryan-c> gmaxwell: are you at all familiar with it?
62 2014-06-27 05:04:36 <ryan-c> I've got an Object - I want to access a particular value (which should be an array) within it by key/property name and iterate over that array.
63 2014-06-27 05:05:04 <ryan-c> and i'm about to start pulling hair out over it :(
64 2014-06-27 05:07:57 <andytoshi> ryan-c: like, if you did 'decoderawtransaction' and wanted to iterate over the inputs, using the name "vin" to get them?
65 2014-06-27 05:08:52 <ryan-c> andytoshi: I'm trying to iterate over the addresses to rewrite them with a different version byte (yes, i have a sane reason to do this)
66 2014-06-27 05:09:43 <andytoshi> what i described, i did in https://github.com/bitcoin/bitcoin/pull/4226/files .... what you describe i think is done by the createrawtransaction RPC?
67 2014-06-27 05:10:12 <ryan-c> I'm operating on the object returned by ScriptPubKeyToJSON
68 2014-06-27 05:10:31 <ryan-c> wait
69 2014-06-27 05:10:49 <ryan-c> ...yeah, need to do it after.
70 2014-06-27 05:11:34 <sipa> scriptpubkeys do not have a version byte
71 2014-06-27 05:11:42 <gmaxwell> wumpus: get ready for another certificational respin (I expect): http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html
72 2014-06-27 05:11:42 <ryan-c> sipa: i know
73 2014-06-27 05:12:00 <andytoshi> ryan-c: ok, i'm not sure about replacing strings, but i was able to iterate over an array of objects and add some fields to them in the PR that i linked
74 2014-06-27 05:12:01 <ryan-c> sipa: but what ScriptPubKeyToJSON has them
75 2014-06-27 05:12:14 <ryan-c> ack
76 2014-06-27 05:12:20 <ryan-c> language fail
77 2014-06-27 05:12:52 <ryan-c> andytoshi: find_value looks like what I want.
78 2014-06-27 05:14:12 <gmaxwell> hm, actually looks like -qt doesn't really have a copy of lz4 in it, just lzf. whew
79 2014-06-27 06:22:49 <wumpus> phew
80 2014-06-27 06:32:51 <wumpus> gmaxwell: so this would have normally affected openssl?
81 2014-06-27 06:36:02 <gmaxwell> if it had been lzf instead of lzo or if openssl had lzo (some ssl implementations do...)
82 2014-06-27 07:31:11 <mindphlux> Hi. I have a question about OP_RETURN. Is this the right place to ask?
83 2014-06-27 07:33:21 <maaku> mindphlux: just ask the question. don't ask to ask (you'll be redirected if OT)
84 2014-06-27 07:33:55 <mindphlux> kk. Is it possible to have more than one OP_RETURN script outputs in a transaction?
85 2014-06-27 07:34:21 <maaku> possible yes, but fails IsStandard (so not relayed by most clients)
86 2014-06-27 07:34:43 <mindphlux> how does it fail? because OP_RETURN fails generally or more than one OP_RETURN fails?
87 2014-06-27 07:35:23 <maaku> more than one OP_RETURN is non-standard
88 2014-06-27 07:35:42 <mindphlux> Thank you!
89 2014-06-27 07:35:58 <maaku> but why do you need more than one?
90 2014-06-27 07:36:45 <mindphlux> I want to store meta data in a big sendmany transaction to many individual addresses, with couple of bytes of meta data for each output
91 2014-06-27 07:37:05 <mindphlux> and I thought, using multiple OP_RETURNs, one for each output would be a good way
92 2014-06-27 07:38:28 <maaku> what kind of metadata? this is probably an indication that you're doing something wrong
93 2014-06-27 07:38:57 <mindphlux> think colored-coins implementation
94 2014-06-27 07:39:43 <maaku> ok well that's fully unvalided information, no? i would highly recommend a more compressed approach, such as padded order-based coloring
95 2014-06-27 07:41:29 <mindphlux> My approach is not 100% like the colored coins implementations that are available, I want to implement a much more lightweight solution to "color" my tokens
96 2014-06-27 07:44:03 <mindphlux> so I must think about outsourcing certain data to fit my stuff into one single OP_RETURN
97 2014-06-27 07:44:06 <mindphlux> thanks
98 2014-06-27 08:08:09 <dsnrk> mindphlux: you shouldn't be trying to store any data in an OP_RETURN. there's enough space for a hash and nothing else.
99 2014-06-27 08:09:36 <jcorgan> and with a hash tree, you can commit to a large number of individual pieces of data that are stored elsewhere, so you don't need a transaction per hash
100 2014-06-27 08:11:05 <jcorgan> in other words, use OP_RETURN sparingly, you are making other people store data that is only relevant to your service
101 2014-06-27 08:11:49 <Luke-Jr> against their will*
102 2014-06-27 08:12:45 <dsnrk> ACTION nods
103 2014-06-27 09:50:09 <Plarkplark_> What would be an advised method to convert a SHA1 to Bitcoin addres (not private key). Yes I understand that the coins sent there would become unmoveable.
104 2014-06-27 09:50:48 <Plarkplark_> Converting SHA1 to BASE58 does not make it a valid address.
105 2014-06-27 09:51:14 <dsnrk> what
106 2014-06-27 09:51:31 <dsnrk> no. don't do that. if you're going to be a jerk and store things in the block chain use OP_RETURN.
107 2014-06-27 09:53:09 <Plarkplark_> ok
108 2014-06-27 09:53:41 <Plarkplark_> But that is not pruneable.
109 2014-06-27 09:54:11 <dsnrk> OP_RETURN IS pruneable, sending outputs to random addresses is not.
110 2014-06-27 09:54:50 <Plarkplark_> They end up stuck, right? I don't want to harm blockchain so.
111 2014-06-27 09:54:56 <Plarkplark_> Why is that a problem
112 2014-06-27 09:55:45 <dsnrk> we keep a DB of all unspent outputs. if you send crap to addresses which don't exist, we need to keep track of those outputs until the end of time. if you use OP_RETURN they are marked as unspendable forever, so we can just ignore them and never add them to the UXTO at all.
113 2014-06-27 09:56:30 <dsnrk> OP_RETURN is the kind one. even though it's still a bad move to store anything in the block chain
114 2014-06-27 09:56:32 <Plarkplark_> Right. Thanks for explaining. OP_RETURN looks like more then I wished it would do, people could cram illegal stuff in there.
115 2014-06-27 09:56:54 <dsnrk> they could without OP_RETURN too.
116 2014-06-27 09:57:29 <Plarkplark_> fair point. thanks
117 2014-06-27 10:00:02 <Plarkplark_> So the outputs in an OP_RETURN go "back" to the wallet/input of the sending wallet?
118 2014-06-27 10:01:10 <jcorgan> no, you make a 0 valued OP_RETURN txout
119 2014-06-27 10:01:42 <Luke-Jr> Plarkplark_: the blockchain is NOT FOR DATA
120 2014-06-27 10:01:50 <Luke-Jr> Plarkplark_: no matter how you do it, you are harming it
121 2014-06-27 10:02:04 <Plarkplark_> But.... why did OP_RETURN got put there? it's used for it?
122 2014-06-27 10:02:24 <Luke-Jr> Plarkplark_: inputs are not wallets either
123 2014-06-27 10:02:35 <Luke-Jr> Plarkplark_: it wasn't put there.
124 2014-06-27 10:03:30 <Plarkplark_> Luke-Jr, So your stance on all these "proof of existence" document things is that it's spam?
125 2014-06-27 10:03:36 <Plarkplark_> (no offence)
126 2014-06-27 10:03:48 <jcorgan> OP_RETURN was created because people were doing even worse things, like what you were considering with the SHA1->addr idea
127 2014-06-27 10:03:56 <Luke-Jr> Plarkplark_: if they bloat the blockchain, yes. there are plenty of easier and better ways to do it that don't.
128 2014-06-27 10:04:25 <Luke-Jr> spamming the blockchain is just a lazy man's way out at the expense of everyone else
129 2014-06-27 10:04:30 <Plarkplark_> Yeah, but bitcoin is the single most secure decentral concensus network. So much room for innovation. But doing this would hurt the blockchain and that is a dilemma.
130 2014-06-27 10:04:45 <Luke-Jr> Plarkplark_: proof of existence does not require consensus
131 2014-06-27 10:05:11 <Luke-Jr> Plarkplark_: merged mining allows you to use the blockchain framework for virtually anything else
132 2014-06-27 10:05:18 <Luke-Jr> (without bloating it)
133 2014-06-27 10:06:10 <Plarkplark_> I won't go any further then personal experiments, just for learning. But you can't stop a system being "abused" when it does work,.
134 2014-06-27 10:06:19 <dsnrk> Plarkplark_: think of OP_RETURN like a needle exchange. people keep shooting up, OP_RETURN is the safe but totally undesirable option that reduced the impact.
135 2014-06-27 10:06:39 <Plarkplark_> dsnrk, lol ok, you made the point.
136 2014-06-27 10:06:59 <dsnrk> we can't stop people doing stupid shit, but we can lessen the impact.
137 2014-06-27 10:07:09 <Luke-Jr> Plarkplark_: miners have a duty to filter out spam and crap, so yes we can
138 2014-06-27 10:07:21 <Luke-Jr> Plarkplark_: also, testnet exists for this stuff
139 2014-06-27 10:07:24 <dsnrk> there's a lot more interesting things to do with Bitcoin than cloning ideas you see on hacker news anyway.
140 2014-06-27 10:07:25 <Luke-Jr> (personal experiments)
141 2014-06-27 10:07:44 <jcorgan> Luke-Jr: i know you feel very strongly about this, but i never got where you came up with the idea that miners have some sort of "duty"
142 2014-06-27 10:08:10 <Luke-Jr> jcorgan: why have a human component at all? because without it, spam destroys the system.
143 2014-06-27 10:08:14 <Plarkplark_> You have to remember that there are a lot of crappy hobbiest programmers like me that will just attempt these things.
144 2014-06-27 10:08:32 <Luke-Jr> Plarkplark_: yes, that's why we have a testnet; for anyone to experiment
145 2014-06-27 10:08:47 <Luke-Jr> you can do even more crazy stuff on testnet too
146 2014-06-27 10:09:38 <Plarkplark_> Maybe it's like attachments in Email. Email was never meant to be used as a file exchange platform. Yet, my clients sometimes sent 100s of MB (or bigger) over SMTP.
147 2014-06-27 10:09:56 <Luke-Jr> Plarkplark_: I would flame someone for that.
148 2014-06-27 10:10:02 <Plarkplark_> I mail plaintext
149 2014-06-27 10:10:25 <Luke-Jr> email *is* plaintext. binary attachments have to be base64 encoded..
150 2014-06-27 10:10:34 <Luke-Jr> so they waste like 1.5x the bandwidth
151 2014-06-27 10:10:38 <Plarkplark_> i know, but users don't care.
152 2014-06-27 10:10:57 <dsnrk> users of bitcoin care. you should see how much they complain about the core client being slow.
153 2014-06-27 10:11:03 <dsnrk> WHY IS IT SO BIG
154 2014-06-27 10:11:19 <Plarkplark_> That's what I meant. As long as Bitcoin can be abused, as you call it, it will be. I understand you feel annoyed by it, dont shoot the messenger and all.
155 2014-06-27 10:11:20 <dsnrk> because jerk developers keep doing shit like proof of existence.
156 2014-06-27 10:11:43 <Plarkplark_> dsnrk, I'm pretty sure anti-bitcoin shills spam the blockchain to hurt it. Put in EICAR test files etc.
157 2014-06-27 10:12:12 <dsnrk> that's not a problem we can solve easily. we can tell you not to do things though.
158 2014-06-27 10:12:21 <Plarkplark_> Thanks for explaining.
159 2014-06-27 10:13:10 <Plarkplark_> So Mastercoin and Colored coins are both equally bad?
160 2014-06-27 10:13:16 <jcorgan> it is a (perhaps unsolveable) weakness of bitcoin that it cannot prevent all forms of bad acting by design, but still has to rely on social norms to do so
161 2014-06-27 10:13:47 <Plarkplark_> jcorgan, I would still cost a lot of BTC (money) to spam the blockchain into unmanageable sizes.
162 2014-06-27 10:13:53 <Luke-Jr> Plarkplark_: mostly bad ideas; smart property (a variant of coloured coins) could be a good idea, if implemented sanelty
163 2014-06-27 10:13:55 <Luke-Jr> sanely*
164 2014-06-27 10:14:15 <Luke-Jr> Plarkplark_: unfortunately, it doesn't cost enough :/
165 2014-06-27 10:14:40 <Plarkplark_> Sidechains?
166 2014-06-27 10:15:37 <Luke-Jr> Plarkplark_: doesn't need to be on sidechains per se
167 2014-06-27 10:15:43 <Plarkplark_> What you essentially would want is that Bitcoin can be moved off the network in a way, and people can run all kinds of crappy networks on it - having to incentive to keep that sidechain running themselfs without hurting the main network. With a possibility to return btc back to the main network.
168 2014-06-27 10:16:13 <Plarkplark_> If, for instance, the storage would bloat it would be the sidechain's problem - not bitcoin.
169 2014-06-27 10:16:40 <jcorgan> the idea of merge mined sidechains is an excellent one, but i've seen no movement to create the facility inside bitcoin to allow it. i know there must be people furiously working on it somewhere but it's either in stealth mode or i'm just not that informed.
170 2014-06-27 10:17:20 <jcorgan> it's not a complaint; just expressing surprise
171 2014-06-27 10:17:21 <Luke-Jr> jcorgan: you'd have to talk to adam back to see where that's at
172 2014-06-27 10:17:32 <Luke-Jr> he's getting funding for it and stuff
173 2014-06-27 10:19:59 <Plarkplark_> What if you would fire up a P2P network with like 10 nodes. They run Sidechain-blahcoin. Every node goes into "generate" mode and generates part of a multisig key. (8/10 or something). BItcoin is moved to that addr. They now have "proof of sidechain".
174 2014-06-27 10:20:16 <Plarkplark_> TO move it back to the main chain: 80% (f/a) of the nodes need to agree to move it back.
175 2014-06-27 10:20:56 <dsnrk> nodes can't be used for voting. that's not sybil safe.
176 2014-06-27 10:21:14 <Plarkplark_> I'm not a smart man ;)
177 2014-06-27 10:21:35 <Luke-Jr> dsnrk: well, that's possible (what he describes)
178 2014-06-27 10:21:43 <Luke-Jr> if they negotiate the nodes themselves
179 2014-06-27 10:21:45 <jcorgan> there are better ways already established for moving btc back and forth to/from a sidechain, at least in theory. now we need code.
180 2014-06-27 10:21:57 <Luke-Jr> the better ways require a softfork
181 2014-06-27 10:22:49 <jcorgan> right. it's an exciting capability and i wish there were a way i could contribute to its development.
182 2014-06-27 10:22:52 <dsnrk> Luke-Jr: sort of pointless if only a select few can be the "voters" though. I got the impression they were interested parties, not trusted.
183 2014-06-27 10:23:27 <dsnrk> I think I missed the point of that entirely.
184 2014-06-27 10:26:04 <Plarkplark_> Ok. But you could create a PoW kind of blockchain. 1 Minute blockrate, for a period of time. The blockchain then evenly starts distributing the private keys among the mined blocks. After this genesis period the "vote" is complete.
185 2014-06-27 10:27:28 <SomeoneWeird> ACTION removes highlight for 'adam'
186 2014-06-27 10:27:30 <dsnrk> all that sort of thing is not the hard bit. the hard bit is the softfork.
187 2014-06-27 10:27:33 <SomeoneWeird> ACTION glares at Luke-Jr
188 2014-06-27 10:30:48 <Luke-Jr> SomeoneWeird: why is my thermostat smoking?
189 2014-06-27 10:31:18 <dsnrk> Luke-Jr: something to do with calming bees?
190 2014-06-27 10:31:36 <Luke-Jr> dsnrk: well, it's no doubt related to using resistors as "cooling", but .. :|
191 2014-06-27 10:33:07 <Luke-Jr> ACTION working on http://gtvhacker.com/index.php/Nest_Hacking#Nest_backplate_interface :p
192 2014-06-27 10:34:05 <dsnrk> hacking embedded devices is always the most fun. extra props if you can turn the Nest into a one button Bitcoin wallet. address entry is in morse.
193 2014-06-27 10:35:53 <Luke-Jr> ACTION wonders just how effective scotch tape is at insulation
194 2014-06-27 10:48:46 <gdm85> Luke-Jr: check the batteries, they might have leaked and be frying some juice for you ;)
195 2014-06-27 10:54:45 <Luke-Jr> gdm85: I'd have to teardown to get to that
196 2014-06-27 10:55:54 <Luke-Jr> although sadly, it decided the battery was low immediately after and shut off networking
197 2014-06-27 10:56:06 <Luke-Jr> and no idea if it's charging or not
198 2014-06-27 11:37:58 <SomeoneWeird> Luke-Jr: sorry i'm drunk i can't exactly parse what you said
199 2014-06-27 12:46:58 <dipendra> how to get status of transaction when coins are successfully sent to other guy
200 2014-06-27 12:47:14 <dipendra> I mean the transaction status from our wallet just like :- https://dogechain.info/tx/1c7fbf820e0d352dac9ea9bfba74600e4afe36bceca7592301bd5c6948c0a0c8
201 2014-06-27 12:47:35 <sipa> gettransaction <txid>
202 2014-06-27 12:48:01 <sipa> (only works for transactions relevant to your wallet)
203 2014-06-27 12:49:07 <dipendra> @sipa yup i have tried it but the details array is not getting updated
204 2014-06-27 12:49:17 <sipa> details array?
205 2014-06-27 12:50:10 <dipendra> when trying gettransaction <txid> in reponse to that... We will have a json which contains details array
206 2014-06-27 12:50:47 <dipendra> in which the send and other end receiver information is added
207 2014-06-27 12:51:55 <dipendra> but in my case 'details' array only have sender information even if the transaction made successfully
208 2014-06-27 12:52:55 <sipa> the only thing you expect to change after confirmation is the number of confirmations, and blockhash
209 2014-06-27 12:53:06 <sipa> details is set when the transaction is created
210 2014-06-27 12:55:56 <dipendra> @sipa okey but how do we know about the exact no of confirmations which designates the transaction success
211 2014-06-27 12:56:17 <sipa> you define what success is
212 2014-06-27 12:56:47 <sipa> confirmations are a measure for how hard it is to revert your transaction
213 2014-06-27 13:01:17 <dipendra> @sipa okey here I used success for complete transfer of coins to other end
214 2014-06-27 13:01:24 <dipendra> but by looking into no of confirmations how do we confirm the complete transactions
215 2014-06-27 13:01:51 <sipa> #bitcoin please
216 2014-06-27 13:04:40 <dipendra> @sipa okey...
217 2014-06-27 13:06:21 <t7> do you guys remember that project for a banking server type thing where clients had to sign all their transactions and the server could never change a clients balance and stuff?
218 2014-06-27 13:06:36 <t7> i remember some people talking about it in here
219 2014-06-27 13:06:41 <t7> it was on github
220 2014-06-27 13:09:19 <dipendra> @sipa so in which situation Do we confirm the complete transfer of bitcoins to other end
221 2014-06-27 13:10:16 <sipa> #bitcoin
222 2014-06-27 13:10:25 <sipa> this channel is about development of bitcoin
223 2014-06-27 13:12:20 <t7> i wonder if you could create a service where the banker doesn't even know the balance of accounts (after an initial transaction)
224 2014-06-27 13:16:14 <t7> might need homomorphic encryption to prove the value of the outputs is = value of inputs
225 2014-06-27 13:16:36 <t7> bitcoin 2.0
226 2014-06-27 13:23:13 <gdm85> t7: generally, ideas are cheap, while giving legs to a project requires hard work
227 2014-06-27 13:23:27 <t7> pff
228 2014-06-27 13:23:53 <t7> spoil sport
229 2014-06-27 13:35:17 <btc123> how big is the current UTXO set, and what is the easiest way to grab it from bitcoind?
230 2014-06-27 13:35:54 <rebroad> Hi all..
231 2014-06-27 13:36:52 <rebroad> I wondered if there are people willing to help me test my latest pull request? I'd really like to see the functionality added sooner than later. My previous pull requests have been ignored for months and then closed due to being tricky to rebase. I spent quite a lot of time developing #4431, so I'd really appreciate it not stagnating like the others did...
232 2014-06-27 13:41:37 <btc123> rebroad: looks like an intereseting pull
233 2014-06-27 13:41:46 <btc123> id ack it if i had any say ;)
234 2014-06-27 13:42:01 <btc123> add to mailing list
235 2014-06-27 13:42:01 <wumpus> btc123: just help testing then you have something to say
236 2014-06-27 13:42:46 <Luke-Jr> wumpus: +1
237 2014-06-27 13:43:24 <wumpus> it's one of the bottlenecks in development that few people are testing pulls
238 2014-06-27 13:44:22 <btc123> if thats the case, the foundation should hire 2-3 test engineers to test pulls full-time
239 2014-06-27 13:44:32 <Luke-Jr> rebroad: it would be a lot easier to review if it didn't have a bunch of other crap in there with it
240 2014-06-27 13:44:39 <btc123> if they actually cared about bitcoin, that is
241 2014-06-27 13:44:49 <wumpus> btc123: WUT?
242 2014-06-27 13:44:58 <wumpus> why should the foundation have to hire people to do your work?
243 2014-06-27 13:45:00 <Luke-Jr> btc123: instead of Gavin or wumpus?
244 2014-06-27 13:45:11 <wumpus> anyhow, not #bitcoin-dev talk
245 2014-06-27 13:45:23 <rebroad> Luke-Jr, I included only what I felt was a core part of the changes.
246 2014-06-27 13:45:38 <Luke-Jr> rebroad: changing the log IPs to nodeids isn't.
247 2014-06-27 13:45:43 <rebroad> Luke-Jr, it makes a lot of changes to debug.log, which was needed in order to debug what was happening and thus fix the problem.
248 2014-06-27 13:45:58 <rebroad> Luke-Jr, node ids was one such changed that was needed.
249 2014-06-27 13:45:59 <Luke-Jr> wumpus: is there a reason that isn't merged yet btw?
250 2014-06-27 13:46:05 <btc123> wumpus, if its a bottleneck, they should fix it with money. anyway, i'll test this pull later tonight if i i have time
251 2014-06-27 13:46:19 <gmaxwell> rebroad: This seems redundant with the work Sipa has been doing to incrementally merge headers first synchronization.
252 2014-06-27 13:46:21 <wumpus> btc123: 'they should fix it with money'? oh? how much are you paying the bitcoin foundation?
253 2014-06-27 13:46:24 <rebroad> Luke-Jr, plus, i thought for ages people were saying it's better not to log IPs
254 2014-06-27 13:46:55 <Luke-Jr> rebroad: again, I agree that we should merge s/IP/nodeid, but it's not related to *this* PR, and just makes reviewing it harder.
255 2014-06-27 13:46:59 <rebroad> gmaxwell, it's much due to headersfirst3 that the problem came in the first place.
256 2014-06-27 13:47:08 <gmaxwell> rebroad: luke is complaining that the changes merge seperate concerns, e.g. the logging could be in another pull that this is on top of.
257 2014-06-27 13:47:12 <rebroad> Luke-Jr, I wasn't able to separate them without a lot of work.
258 2014-06-27 13:47:28 <wumpus> Luke-Jr: because more important stuff got ahead
259 2014-06-27 13:47:33 <rebroad> the node id pull request was done months ago in order to be in place ready for this one. I can't separate them.
260 2014-06-27 13:48:08 <rebroad> it doesn't make sense to remove the node ids from it, they are a large part of the useful debug info
261 2014-06-27 13:48:24 <rebroad> i can change to addresses instead but that would surely be a regression
262 2014-06-27 13:48:25 <Luke-Jr> rebroad: sounds like it's just a matter of time until the nodeid is merged (see wumpus above), so you're better off asking once that is done
263 2014-06-27 13:48:49 <Luke-Jr> rebroad: but I wouldn't spend much time on this. as gmaxwell points out, sipa is working on the problem in a better way
264 2014-06-27 13:48:59 <wumpus> your pulls are usually messy and hard to review rebroad
265 2014-06-27 13:50:05 <rebroad> I raised a pull request 2 years ago that made block download do a better job than it currently does in master... sipa's changes over the last year haven't come close to the improvements i made two years ago, in terms of avoiding stuck IBD
266 2014-06-27 13:50:23 <wumpus> also it appears you haven't even replied to sipa's comment yet
267 2014-06-27 13:50:39 <rebroad> wumpus, yes, i realise this... which is why I'd really like someone to clone it and make it less messy... the functionality is there, but I'm not quite good enough at c++ to know some of the intricacies
268 2014-06-27 13:50:59 <wumpus> rebroad: he's trying to improve things in the long run, toward parallel block download
269 2014-06-27 13:51:03 <wumpus> that's *hard*
270 2014-06-27 13:51:05 <rebroad> wumpus, I made a real effort with this one, hence the commits separating so much of it. I really hope it's above my usual standard
271 2014-06-27 13:51:28 <Luke-Jr> rebroad: iff sipa doesn't expect headers-first to be ready for 0.10, it'd be worth *minimal* time to review your stuff (after nodeid is merged), but it's just not that important when it's bound to be replaced soonish
272 2014-06-27 13:51:44 <rebroad> wumpus, I think this pull of mine certainly goes a long way to that.. the only thing needed now would be to enable multiple syncnodes, and that can fit in quite easily with the changes I've made
273 2014-06-27 13:52:29 <rebroad> Luke-Jr, it's frustrating when my work is replaced by stuff that doesn't work as well though.. why replace it if it works well?
274 2014-06-27 13:53:22 <wumpus> rebroad: ok that sounds good -- the problem with your logic before has been that it was short-sighted logic, like 'disconnect a peer that sends a wrong block' instead of not requesting it in the first place
275 2014-06-27 13:53:26 <gmaxwell> jesus christ you've again reintroduced code that randomly hangs up on peers
276 2014-06-27 13:53:50 <gmaxwell> You _cannot_ just hang up on peers when they take >10 seconds to respond.
277 2014-06-27 13:53:52 <rebroad> I don't understand why most of the things I write, are NACKed, and then a few months later, someone else does them, usually in an identify way, or a less reliable way, and they are then ACKed
278 2014-06-27 13:54:09 <gmaxwell> Because you do crap like that.
279 2014-06-27 13:54:16 <rebroad> gmaxwell, don't be ridiculous please. there is nothing random about it
280 2014-06-27 13:54:17 <wumpus> gmaxwell: exactly
281 2014-06-27 13:54:32 <rebroad> and why wait 2 minutes when 10 seconds is enough to know when it's failed? actually, 5 seconds is sufficient.
282 2014-06-27 13:54:47 <wumpus> you can't have a P2P network if you program the nodes to be sociopatic
283 2014-06-27 13:54:51 <rebroad> gmaxwell, please be a little more respectfu
284 2014-06-27 13:55:39 <rebroad> wumpus, why is it sociopathic any more than disconnecting after 2 minutes? My original pull 2 years ago didn't even disconnect, but actually allowed for nodes to recover. Sipa's stuck block code is actually more sociopathic than that.
285 2014-06-27 13:56:14 <Luke-Jr> rebroad: serial downloading is slower than parallel
286 2014-06-27 13:56:18 <wumpus> rebroad: we don't disconnect after two minutes, the ping limit is ~20 minutes now
287 2014-06-27 13:56:20 <rebroad> my code is actually very sociable. e.g. I prefer to cater for diverse behaviour from other nodes, rather than make assumptions
288 2014-06-27 13:56:28 <rebroad> Luke-Jr, yes, I know.
289 2014-06-27 13:56:58 <btc123> gmaxwell: perhaps explain why you can't just hang up on peers when they take > 10 sec to respond, so that rebroad can better understand the issue and make changes to the pull
290 2014-06-27 13:56:58 <rebroad> Luke-Jr, that can be a later pull. But if you want parallel now, I can code it.
291 2014-06-27 13:57:04 <gmaxwell> rebroad: in this ull, someone in a place where a block takes longer than 10 seconds to download will just constantly disconnect their peers instead of making progress.
292 2014-06-27 13:57:20 <Luke-Jr> rebroad: sipa is already coding it, why reinvent his efforts?
293 2014-06-27 13:57:31 <rebroad> gmaxwell, you are making a false assumption I think... let me explain
294 2014-06-27 13:57:56 <btc123> rebroad: thats a good point -- maybe nodes in a rural african village need a few minutes
295 2014-06-27 13:57:56 <rebroad> gmaxwell, why don't you run it and see? most of the time, it's <200ms between block reception and last block reception
296 2014-06-27 13:58:02 <Diablo-D3> http://fastcompression.blogspot.com/2014/06/debunking-lz4-20-years-old-bug-myth.html
297 2014-06-27 13:58:05 <rebroad> so 10000 is very generous
298 2014-06-27 13:58:19 <rebroad> even on a GPRS network, it is never that slow
299 2014-06-27 13:58:24 <rebroad> I know, I used to use one
300 2014-06-27 13:58:34 <gmaxwell> rebroad: because correctness isn't just about what I observe in a few minutes. You can randomly change characters in the source code and if it compiles it will likely run okay for a bit.
301 2014-06-27 13:58:44 <sipa> if you ask for 500 recent blocks during IBD, it can take minutes to receive them...
302 2014-06-27 13:58:46 <rebroad> it measures reception. i.e. any progress.. not just the time since a last complete block
303 2014-06-27 13:58:47 <btc123> rebroad: have you run some tests from nodes in cuba or liberia?
304 2014-06-27 13:58:48 <Luke-Jr> rebroad: I've seen ping times of 10 seconds on GPRS
305 2014-06-27 13:59:24 <rebroad> Luke-Jr, do you really want to be downloading from such a slow connection? to me, it makes sense not to select such a slow link for IDB
306 2014-06-27 13:59:30 <gavinandresen> I was thinking⦠there are hyper-optimized content delivery networks that aren't very expensive on a per-gigabyte. I wonder how hard it would be to code up a patch that tried fetching from a CDN URL instead of 'getblock' (but fell back to getblock if the http fetch failed)
307 2014-06-27 13:59:48 <rebroad> 10s ping does not make a good sync node...
308 2014-06-27 14:00:00 <gmaxwell> I use bitcoin over a 10 second RTT from time to time (you can see me complaining about it on IRC), but it's not just RTT that matters, its also the time it takes to seralize the block. This change means that no one could use bitcoin, once blocks are 1mb on a link slower than 800kbit/sec.
309 2014-06-27 14:00:05 <rebroad> it would be a detriment to the network IMHO
310 2014-06-27 14:00:20 <btc123> gavinandresen: interesting idea.
311 2014-06-27 14:00:22 <jgarzik> ACTION starts rebasing pointlessly broken code
312 2014-06-27 14:00:39 <sipa> if you ask for 500 blocks, and then send a ping, it can take minutes before you see the pong
313 2014-06-27 14:00:45 <sipa> even if it's the fastest peer you have
314 2014-06-27 14:01:05 <Luke-Jr> rebroad: if *I* am on that connection, *all* the peers will be that slow.
315 2014-06-27 14:01:11 <gavinandresen> jgarzik: broken because of somebody's obsessive-compulsive desire over syntax?
316 2014-06-27 14:01:13 <rebroad> sipa, maybe ping times are irrelevant then
317 2014-06-27 14:01:40 <rebroad> sipa, my code doesn't currently use the ping time. It's still using the selection algorithm you coded
318 2014-06-27 14:02:01 <rebroad> sipa, a better selection criteria might be bytes/second instead then
319 2014-06-27 14:02:12 <sipa> well the current code is pretty bad, but it's always been bad
320 2014-06-27 14:02:21 <rebroad> also, it has 16 blocks in flight, so it's unlikely to find a long pause given so many blocks are queued up
321 2014-06-27 14:02:58 <sipa> it's really a preparation for parallel download, where the criterion can become "just disconnect your slowest peer, if he's holding you up"
322 2014-06-27 14:03:07 <sipa> which needs no special constants
323 2014-06-27 14:04:14 <rebroad> sipa, would you be willing to have a look at my pull please? I'd really appreciate it if at least some of the code could be used. I have tested it well, and the 10 second thing does sound short I know, but it actually is reasonable based on the testing. when a block sticks for 10 seconds, it rarely means it's a good choice for a sync node.
324 2014-06-27 14:04:51 <rebroad> it reslects a sync node based on various timeouts, each of which can be different
325 2014-06-27 14:04:53 <jgarzik> gavinandresen, +1 on http fetch try... but we do tend to have a better replication factor than most torrents on the P2P network today. we just stick with one peer too long, which hides our massive replication factor.
326 2014-06-27 14:05:36 <rebroad> 1) delay between getblocks and invs 2) delay between getdata and block reception, and 3) time since last block reception (even partial-blocks count)
327 2014-06-27 14:05:43 <jgarzik> gavinandresen, yes (though of course that answer is PoV dependent :)) Had a dependent PR merged, then somebody tweaked syntax, and broke main PR
328 2014-06-27 14:05:53 <sipa> rebroad: i want to get rid of the sync node
329 2014-06-27 14:06:00 <rebroad> sipa, me too!
330 2014-06-27 14:06:08 <wumpus> jgarzik: serves you well for using annoying syntax :p
331 2014-06-27 14:06:14 <jgarzik> Saw this in Linux kernel too. Cleanup patches are in general good.... but they have costs too. You break more useful patches.
332 2014-06-27 14:06:15 <sipa> it's just a hack to make sure we are always asking for new blocks from someone
333 2014-06-27 14:06:29 <rebroad> sipa, I had to really rejig it a lot to incorporate your sync code, but it actually can transition to multiple sync nodes quite easily for parallel download
334 2014-06-27 14:06:56 <sipa> rebroad: not "multiple sync nodes", we need to just download everything from everyone
335 2014-06-27 14:07:07 <sipa> the only reason we don't, is because we don't know in advance what to ask for
336 2014-06-27 14:07:15 <sipa> which is why i've been working on headers-first
337 2014-06-27 14:07:18 <rebroad> sipa, what is the difference? I'm just definiing "sync node" as someone to download blocks from.
338 2014-06-27 14:07:28 <jgarzik> wumpus, it is a useful syntax when you have many cascading 'if' blocks, each of which get a comment
339 2014-06-27 14:07:36 <sipa> rebroad: we download blocks from everyone
340 2014-06-27 14:07:37 <jgarzik> wumpus, but that is not visible without future PRs
341 2014-06-27 14:07:42 <jgarzik> wumpus, which is why you ask, not assume
342 2014-06-27 14:07:48 <wumpus> jgarzik: I really don't like it
343 2014-06-27 14:07:49 <sipa> rebroad: the sync node is just there to make sure we've always asked someone
344 2014-06-27 14:07:58 <sipa> rebroad: but we download whatever anyone announces
345 2014-06-27 14:08:33 <wumpus> jgarzik: not even with 1000 cascading if/else blocks you can convince me that adding blank lines after ; or } and before an else is a good idea
346 2014-06-27 14:08:44 <rebroad> sipa, it was that that was causing the huge orphan lists though.. isn't it better to download the blocks in the right order (assuming no headers first)
347 2014-06-27 14:08:59 <sipa> rebroad: yes, but we don't know the order
348 2014-06-27 14:09:03 <wumpus> jgarzik: it bothers me when reading the code and I think the if {} clause is finished, then suddenly some lines later.. OH, else
349 2014-06-27 14:09:34 <wumpus> jgarzik: and we've never had that in the bitcoin core code as far as I know
350 2014-06-27 14:09:43 <rebroad> sipa, i don't think this pull of mine in any way interferes with your headersfirst changes does it?
351 2014-06-27 14:09:47 <Luke-Jr> (FWIW, I think the else and if can/should be on their own lines, and comments between the else and if are okay, but a blank line makes no sense to me)
352 2014-06-27 14:09:48 <rebroad> sipa, at least, I hope not.
353 2014-06-27 14:10:06 <rubensayshi> so, no more (white)spaces anywhere at all then?
354 2014-06-27 14:10:23 <Luke-Jr> rubensayshi: nobodyh said that, and it's not worth arguing over
355 2014-06-27 14:10:26 <wumpus> rubensayshi: yes, let's create an opposite strawman argument! that will help
356 2014-06-27 14:10:30 <rebroad> sipa, there are a few variables i created which duplicate some you created, but that was only because the way your code uses them was ambiguous in places and potentially could change. e.g. nLastBlockProcessed
357 2014-06-27 14:10:57 <rebroad> I did use nLastBlockReceived though - as it did just what I needed it to do
358 2014-06-27 14:11:29 <wumpus> Luke-Jr: yes, adding a comment in between is fine
359 2014-06-27 14:12:29 <rebroad> hmmm... I'm running autogen.sh and configure and then make, but I'm getting timedata.h not found...
360 2014-06-27 14:13:05 <jgarzik> As first observed by Donald Knuth in Literate Programming, you want to create "paragraphs" with your code. Most code logic should not go more than 5-10 lines without a blank line. You see _many_ patching errors over time with mashed-together code, once a lot of developers start reading and patching the code.
361 2014-06-27 14:13:17 <jgarzik> Bitcoin Core definitely suffers from the mashed-together problem.
362 2014-06-27 14:13:33 <wumpus> jgarzik: I agree with that *in general* but not in this specific case
363 2014-06-27 14:13:37 <jgarzik> But that is speaking generally, not azbout this specific issue.
364 2014-06-27 14:13:40 <rebroad> jgarzik, are you referring to my pull?
365 2014-06-27 14:13:42 <btc123> i use whitespace often
366 2014-06-27 14:15:49 <jgarzik> Therefore, in command processing or token parsing, where a long trail of 'if' statements are simulating a 'switch' statement, it is a "normal exception" to separate code blocks with whitespace.
367 2014-06-27 14:15:51 <jgarzik> e.g.
368 2014-06-27 14:15:54 <wumpus> jgarzik: the same argument could be used the other way, blank lines around else statements can cause merge errors, when someone tries to solve a merge conflict, doesn't notice the else due to the distance
369 2014-06-27 14:16:00 <jgarzik> if (strMethod == "alice")
370 2014-06-27 14:16:05 <jgarzik> else if (strMethod == "bob")
371 2014-06-27 14:16:08 <jgarzik> else if (strMethod == "charlie")
372 2014-06-27 14:16:34 <jgarzik> _presuming_ that there is (a) a lot of code in between or (b) they call a function/method which is effective its own paragraph.
373 2014-06-27 14:16:36 <wumpus> jgarzik: anyhow let's just agree to disagree here, I don't feel like arguing this
374 2014-06-27 14:17:13 <jgarzik> wumpus, direct experience here says different. You get the sum of programmers' experiences coming into a new project and patching, it becomes useful.
375 2014-06-27 14:17:14 <wumpus> we should settle down on one if/else if/else syntax, document that in the coding style, and that's it
376 2014-06-27 14:17:44 <sipa> ACTION votes for {} on the same line (and that's all i'll add)
377 2014-06-27 14:17:52 <jgarzik> it's not about one programmer or another programmer prefs, but what is more likely to be readable and compatible with the total mass
378 2014-06-27 14:18:05 <wumpus> sipa: so } else { and } else if(...) { ?
379 2014-06-27 14:18:10 <sipa> yes
380 2014-06-27 14:18:13 <wumpus> sipa: +1
381 2014-06-27 14:18:22 <sipa> and void methodname(args) {
382 2014-06-27 14:18:23 <Luke-Jr> â¹
383 2014-06-27 14:18:31 <Luke-Jr> }\nelse\nif(â¦)\n{ please
384 2014-06-27 14:18:39 <wumpus> for methods I prefer the { to be on the next line
385 2014-06-27 14:18:40 <jgarzik> sipa, } else { sure
386 2014-06-27 14:18:45 <jgarzik> wumpus, +1
387 2014-06-27 14:18:50 <jgarzik> functions/methods: next line
388 2014-06-27 14:18:57 <jgarzik> everything else: cuddle
389 2014-06-27 14:19:03 <jgarzik> *with one exception :)
390 2014-06-27 14:19:05 <wumpus> usually because method signatures get very long, so tacking on the { means you hardly see it :p
391 2014-06-27 14:19:24 <sipa> that's an independent problem, and means you need to split up the signature
392 2014-06-27 14:19:30 <wumpus> also it's closer to what we already have
393 2014-06-27 14:20:02 <Luke-Jr> too much time spent on formatting --
394 2014-06-27 14:20:53 <wumpus> Luke-Jr: well if we define it now and add it to doc/coding-style.md we can stop arguiing
395 2014-06-27 14:21:03 <jrick> go fmt
396 2014-06-27 14:21:06 <jrick> ACTION sees himself out
397 2014-06-27 14:21:08 <sipa> ACTION votes: write a clang-format config file, define it as the canonical style to be used, don't be too picky in reviews, and at the end of a merge window, apply clang-format (which can be done by multiple people and should give the exact same result)
398 2014-06-27 14:21:08 <wumpus> see also https://github.com/bitcoin/bitcoin/pull/4398/files
399 2014-06-27 14:21:11 <jgarzik> coding-style says "{" on a line by itself
400 2014-06-27 14:21:14 <jgarzik> puke
401 2014-06-27 14:21:21 <Luke-Jr> wumpus: and then Diapolo jumps whenever there's some harmless deviation
402 2014-06-27 14:21:36 <wumpus> Luke-Jr: yes, that's pretty annoying sometimes..
403 2014-06-27 14:21:44 <helo> consistent indentation should make placement of { mostly irrelevant </shed>
404 2014-06-27 14:21:57 <Luke-Jr> as long as it's readable, who cares :x
405 2014-06-27 14:22:12 <sipa> consistency helps
406 2014-06-27 14:22:27 <sipa> it helps to not make the wrong assumptions when reviewing
407 2014-06-27 14:22:31 <wumpus> it helps to avoid discussions
408 2014-06-27 14:22:37 <gavinandresen> ACTION votes: steal a clang-format config file from some other popular project. Then what sipa said.
409 2014-06-27 14:22:48 <wumpus> gavinandresen: +1
410 2014-06-27 14:22:54 <wumpus> is there any project that does thsi?
411 2014-06-27 14:23:02 <sipa> Google :p
412 2014-06-27 14:23:12 <gavinandresen> Cool, Google is popular.
413 2014-06-27 14:23:14 <Luke-Jr> why clang-format instead of some common code-formatting program?
414 2014-06-27 14:23:15 <Luke-Jr> :P
415 2014-06-27 14:23:17 <sipa> (and its config is shipped with clang-format)
416 2014-06-27 14:23:31 <wumpus> google is not open source, so we don't want to steal their clang format file...
417 2014-06-27 14:23:38 <sipa> wumpus: ^
418 2014-06-27 14:23:53 <wumpus> I'm really looking for open source projects
419 2014-06-27 14:24:04 <sipa> well we'll need to make some modifications anyway
420 2014-06-27 14:24:10 <sipa> or every line everywhere will change
421 2014-06-27 14:24:13 <wumpus> there are many places where bitcoin innovates, but source code indentation shoulndn't be one of them
422 2014-06-27 14:24:23 <Luke-Jr> LLVM has their own style for it I think
423 2014-06-27 14:24:24 <wumpus> stealing something that works and is freely available would be better
424 2014-06-27 14:24:59 <wumpus> the LLVM style is pretty OK from what I remember
425 2014-06-27 14:25:00 <sipa> wumpus: clang-format ships with a few styles already, "LLVM" and "Google" among them
426 2014-06-27 14:25:05 <gavinandresen> lets form a code-format-convention committee and write a BIP. Wait, no, better: an RFC, so everybody else will use what we decide........
427 2014-06-27 14:25:12 <gavinandresen> :)
428 2014-06-27 14:25:38 <wumpus> gavinandresen: lol!
429 2014-06-27 14:25:47 <sipa> so: {} on separate lines for functions/methods, on the same line for other control flow blocks
430 2014-06-27 14:25:51 <sipa> what indentation?
431 2014-06-27 14:26:04 <wumpus> same as now, four spaces
432 2014-06-27 14:26:17 <sipa> what indentation for private/public ?
433 2014-06-27 14:26:30 <sipa> i'll try to match what is already used
434 2014-06-27 14:26:39 <sipa> what max line length?
435 2014-06-27 14:26:42 <wumpus> yes -- try to match what is already used
436 2014-06-27 14:26:48 <wumpus> 120
437 2014-06-27 14:26:51 <sipa> 80 is pretty standard, but i find that pretty short
438 2014-06-27 14:26:56 <Luke-Jr> tabs for indentation! <.<
439 2014-06-27 14:27:10 <sipa> 120 is fine to me
440 2014-06-27 14:27:15 <wumpus> Luke-Jr: please...
441 2014-06-27 14:27:27 <Luke-Jr> wumpus: that's what they're there for :|
442 2014-06-27 14:27:35 <gavinandresen> ACTION votes for max-111-length lines (then runs away)
443 2014-06-27 14:28:44 <wumpus> gavinandresen: except every 11th line, it should be 121 long
444 2014-06-27 14:28:58 <Luke-Jr> ACTION wonders why clang-format hard-codes the builtin styles
445 2014-06-27 14:29:14 <sipa> they are just basisses to derive from, i think
446 2014-06-27 14:29:22 <sipa> so take anything you're not specifying from
447 2014-06-27 14:31:00 <jgarzik> sipa, 80 LL preferred, 120 OK.... as long as the code reformatter is not __joining__ already broken lines!
448 2014-06-27 14:31:17 <wumpus> yes, it should certainly not be arbitrarily joining lines :)
449 2014-06-27 14:31:21 <jgarzik> breaking overly long lines, or warning about them, is fine.
450 2014-06-27 14:31:24 <Diablo-D3> you mean 79
451 2014-06-27 14:31:45 <Luke-Jr> ACTION goes back to reverse engineering his Nest so he can have a thermostat..
452 2014-06-27 14:31:47 <andytoshi> 72, i am using an 80x24 terminal and have line numbers on
453 2014-06-27 14:31:54 <wumpus> sigh...
454 2014-06-27 14:32:08 <Luke-Jr> side note: decent editors can wrap long lines at window length just fine
455 2014-06-27 14:32:12 <wumpus> I'm using a 40x20 MSX screen and want everyone to adapt to me!
456 2014-06-27 14:32:20 <Luke-Jr> (but manual line breaks make that ugly)
457 2014-06-27 14:32:25 <sipa> i only have a pixel, you insensitive clods
458 2014-06-27 14:32:30 <Diablo-D3> yeah, I prefer no line breaks tbh
459 2014-06-27 14:32:36 <Diablo-D3> I only do them when it clarifies code
460 2014-06-27 14:33:05 <wumpus> sipa: well at least a color pixel I hope?
461 2014-06-27 14:33:30 <jgarzik> I always use 80 column terms, and that is standard window-opening width by default
462 2014-06-27 14:33:35 <cdecker> sipa: what happened to your DNS Server?
463 2014-06-27 14:33:36 <jgarzik> however, as Luke noted, editors will wrap
464 2014-06-27 14:33:39 <wumpus> or is it one of those old fashioned pixels which can only be yellow, cyan or magenta or black
465 2014-06-27 14:33:50 <cdecker> It nosedived a few minutes ago
466 2014-06-27 14:34:04 <jgarzik> 80 columns is default on all modern terminals, on linux/osx/windows
467 2014-06-27 14:34:10 <sipa> cdecker: out of disk space..
468 2014-06-27 14:34:21 <wumpus> sigh
469 2014-06-27 14:34:22 <Diablo-D3> 80 columns default is older than any of those
470 2014-06-27 14:34:30 <jgarzik> HOWEVER, that does not imply that clang static checker should limit lines to 80.
471 2014-06-27 14:34:31 <Diablo-D3> it comes from line printers being that wide
472 2014-06-27 14:34:45 <wumpus> terminals are easy to resize to slightly wider...
473 2014-06-27 14:34:47 <wumpus> right
474 2014-06-27 14:34:55 <jgarzik> Several LOC in bitcoin are annoying is wrapped down to 80
475 2014-06-27 14:34:57 <cdecker> Ah k
476 2014-06-27 14:35:05 <jgarzik> *if
477 2014-06-27 14:35:16 <cdecker> Is china doing anything actively with bitcoin DNS?
478 2014-06-27 14:35:20 <sipa> cdecker: up again
479 2014-06-27 14:35:28 <wumpus> jgarzik: yes, I usually find wrapped lines more annoying than useful either, espeically if they are arbitrarily wrapped instead of intelligently
480 2014-06-27 14:35:31 <cdecker> According to https://www.whatsmydns.net/#A/seed.bitcoin.sipa.be sipas node was still working
481 2014-06-27 14:36:32 <cdecker> sipa: thanks it was a bit disconcerting to have 4 out of 6 default DNS servers down/returning no results
482 2014-06-27 14:36:56 <Luke-Jr> cdecker: mine is down because a major internet backbone is DoSing my server if I run it -.-
483 2014-06-27 14:37:06 <Luke-Jr> and I haven't had the time to figure out how to deal with them
484 2014-06-27 14:37:16 <gmaxwell> Fortunately bitcoin continues working with them all down.
485 2014-06-27 14:37:32 <jgarzik> It really depends on static checker's behavior. Ideal is difficult to program for: "terminals default to 80. that is the vast majority. many programmers resize their windows larger and don't care, or use non-terminal editors and don't care. additionally, many lines of code should not be auto-wrapped, and best fit in >80 char single line, based on human judgement."
486 2014-06-27 14:37:42 <jgarzik> Therefore 100 or 120 and no auto-breaks is best, IMO.
487 2014-06-27 14:37:54 <jgarzik> but I'll yell at people if too many lines > 80
488 2014-06-27 14:38:22 <Luke-Jr> maybe I should take the time to write a public rant against XO.net for harming Bitcoin? :p
489 2014-06-27 14:39:00 <gmaxwell> Luke-Jr: did you confirm that it was the spider part that was making it blackhole you?
490 2014-06-27 14:39:20 <Luke-Jr> gmaxwell: the spider part? not that specifically, no :/
491 2014-06-27 14:39:30 <cdecker> Luke-Jr: do you think Bitcoin is the target of that or is it a coincidence?
492 2014-06-27 14:39:33 <Luke-Jr> sipa: is there a trivial way to disable that part only? :D
493 2014-06-27 14:39:55 <gmaxwell> cdecker: whenever he starts it XO blackholes whatever IP its running on.
494 2014-06-27 14:39:55 <Luke-Jr> cdecker: probably some automation on their end that misidentifies it. but I have no way to appeal or complain
495 2014-06-27 14:40:21 <cdecker> Hm, that's not good
496 2014-06-27 14:40:25 <Luke-Jr> abuse@xo.net just gets ignored
497 2014-06-27 14:40:34 <cdecker> As usual xD
498 2014-06-27 14:40:40 <jgarzik> heh
499 2014-06-27 14:40:50 <Luke-Jr> wizkid057 has access to some inter-backbone ticket system with a ticket on this, XO just ignores it
500 2014-06-27 14:41:05 <gmaxwell> Luke-Jr: could try running the spider part over tor... would actually be useful to have one of the seeds returning a starkly different view of the network in any case.
501 2014-06-27 14:41:19 <gmaxwell> Though if its the req side that they're misclassifying I have no suggestion.
502 2014-06-27 14:41:33 <gmaxwell> Any of these more centeralized mechenisms always end up getting blocked.
503 2014-06-27 14:42:33 <sipa> Luke-Jr: what part?
504 2014-06-27 14:43:43 <wizkid057> ticket has been open for a while, no answers from them... but, this is pretty normal for many low priority/single-user-affected issues
505 2014-06-27 14:44:03 <sipa> Luke-Jr: allowing infinite linelength, and respecting existing breaking decisions is possible yes
506 2014-06-27 14:44:46 <wumpus> sipa: but it won't join lines, just split them?
507 2014-06-27 14:45:00 <Luke-Jr> wizkid057: "affected" as if it's a mere issue :| they should pay more attention when they're actively causing someone a problem
508 2014-06-27 14:45:46 <sipa> wumpus: i don't know; the documentation is unclear - if you do specify a line length limit, i think it will join and split as needed
509 2014-06-27 14:46:04 <sipa> though it's usually pretty intelligent, with different scores assigned to different types of breaking
510 2014-06-27 14:46:15 <sipa> if you don't specify a line length limit, it leaves breaking alone
511 2014-06-27 14:46:29 <gmaxwell> Luke-Jr: would be useful to figure out if its the spider or the dns traffic that causes them to blackhole things.
512 2014-06-27 14:46:32 <wumpus> sipa: may be better to not specify a limit for now, it's not something there is a lot of argument about
513 2014-06-27 14:46:35 <wizkid057> Luke-Jr: well, keep in mind you're doing something pretty non-standard. Not many clients have a need to connect to thousands of IPs, not maintain those connections, etc... from the perspective of some security algo it probbaly looks like you're scanning random IPs for vulnerabilities
514 2014-06-27 14:46:47 <sipa> wumpus: we can start by setting it to 0, and maybe in a later stage try to find a nice value
515 2014-06-27 14:46:52 <wizkid057> *probably
516 2014-06-27 14:46:52 <wumpus> sipa: +1
517 2014-06-27 14:47:59 <sipa> oh, the worst bikeshed possible
518 2014-06-27 14:48:02 <sipa> int* a
519 2014-06-27 14:48:04 <sipa> or int *a
520 2014-06-27 14:48:05 <sipa> ?
521 2014-06-27 14:48:15 <wumpus> let's see what is used most in the current source
522 2014-06-27 14:49:24 <wumpus> seems that usually the * or & is immediately after the data type
523 2014-06-27 14:49:25 <Luke-Jr> sipa: can I disable bitcoin-seeder's crawler only?
524 2014-06-27 14:49:37 <sipa> Luke-Jr: what would it return?
525 2014-06-27 14:49:45 <Luke-Jr> sipa: whatever it last saw :P
526 2014-06-27 14:49:51 <gavinandresen> int* pna; is the Official Satoshi Coding Style. But he's not here, so I vote to get rid of the type prefixes.
527 2014-06-27 14:50:04 <wumpus> gavinandresen: me too
528 2014-06-27 14:50:09 <wumpus> but let's keep the int* part
529 2014-06-27 14:50:13 <gmaxwell> Luke-Jr: just run the crawler over tor.
530 2014-06-27 14:50:24 <wumpus> instead of int *pna ... though I really don't care deeply about this
531 2014-06-27 14:50:33 <GAit> gavinandresen: +1
532 2014-06-27 14:50:47 <Luke-Jr> gmaxwell: I don't really want to run tor.
533 2014-06-27 14:50:58 <gavinandresen> yeah, I really don't care about any of this, either.
534 2014-06-27 14:51:06 <gmaxwell> I vaguely believe that just running it inside the torify wrapper should be enough, I think torify will leave the udp alone.
535 2014-06-27 14:51:06 <wumpus> what does LLVM use?
536 2014-06-27 14:51:15 <Luke-Jr> wumpus: 'int *' rather than 'int* ' is hard-coded into C sadly
537 2014-06-27 14:51:43 <gavinandresen> I do care about https://github.com/bitcoin/bitcoin/pull/3883/ and https://github.com/bitcoin/bitcoin/pull/4250 and https://github.com/bitcoin/bitcoin/pull/4365
538 2014-06-27 14:52:20 <sipa> PointerBindsToType: false
539 2014-06-27 14:52:25 <sipa> in style:LLVM
540 2014-06-27 14:52:49 <wumpus> gavinandresen: ACK on 4365
541 2014-06-27 14:53:18 <gmaxwell> WRT coding style, I generally don't care and I'm happy to try to emulate the style other people perfer (so long as they'll be forgiving if I mess up here and there). One thing I'm not super fond of about our current behavior is that we will do if(condition)\n unbraced_statement; ... I generally prefer to always brace statements unless they are on the same line as the condition, due to mistakes from thinking something is in the ...
542 2014-06-27 14:53:24 <gmaxwell> ... conditon (or loop) when its not, though I don't recall us having too many issues there.
543 2014-06-27 14:53:37 <gavinandresen> wumpus: merged.
544 2014-06-27 14:54:11 <wumpus> gmaxwell: always adding {}'s is usually my preference as well, although it can be overly verbose in some cases so I'm not sure with that as general rule
545 2014-06-27 14:54:38 <sipa> i'm fine with always using braces
546 2014-06-27 14:54:44 <sipa> though we very rarely do so now
547 2014-06-27 14:54:56 <wumpus> sipa: right
548 2014-06-27 14:55:09 <gavinandresen> I wonder why fees for confirm-in-next-block transactions jumped up so much yesterdayâ¦. : http://bitcoincore.org/smartfee/fee_graph.html
549 2014-06-27 14:55:14 <gmaxwell> wumpus: the rule I use in my private code is always brace unless the whole statement is one line. But I think we don't like one line loops/ifs.
550 2014-06-27 14:55:21 <Luke-Jr> ACTION dislikes elongating single-statement if.
551 2014-06-27 14:57:18 <sipa> i can't find a setting for allowing unbraced if...
552 2014-06-27 14:58:18 <Luke-Jr> maybe it's always true? :P
553 2014-06-27 14:58:38 <gmaxwell> sipa: one of the daala contributors managed to get clang-formater working on the daala coding style (which is unbraced if and only if it fits on one line), I can find out how he did that.
554 2014-06-27 14:58:56 <GAit> skipping {} can only lead to terrible bugs, adding them allows for more explicit intent. +1
555 2014-06-27 15:00:21 <gavinandresen> â¦. this conversation is why I voted to steal the coding style from another project that has already painted this shed....
556 2014-06-27 15:01:13 <GAit> more important than which style is consistency, i'm all for some style from some other project. I used to use uncrustify too, not sure what people think about that.
557 2014-06-27 15:01:25 <wumpus> gavinandresen: I think the conversation is going quite well, it's not like there is a lot of disagreement (except Luke-Jr maybe :-) )
558 2014-06-27 15:01:26 <Luke-Jr> unrelated to specific formatting, it'd be nice if there was a bot that just modified the PR to be formatted, so things couldn't sneak past review
559 2014-06-27 15:01:54 <GAit> i used to have uncrustify as a git commit hook
560 2014-06-27 15:01:56 <Luke-Jr> I was inclined to try to abuse a single-line if to introduce an exploit (to see if anyone caught it before merging) not long ago (but I never found a nice place to hide something)
561 2014-06-27 15:01:58 <wumpus> Luke-Jr: you could force people to run a script before pushing
562 2014-06-27 15:02:13 <wumpus> Luke-Jr: though that sort of rules out windows developers :p
563 2014-06-27 15:02:24 <gavinandresen> Luke-Jr: good idea. pull-tester could run the code formatter on any changed files, and complain if syntax changedâ¦.
564 2014-06-27 15:02:24 <Luke-Jr> wumpus: what's windows?
565 2014-06-27 15:02:28 <sipa> pulltester could enforce that applying clang-formatter on it has 0 effect
566 2014-06-27 15:02:46 <Luke-Jr> sipa: then it's just annoying IMO
567 2014-06-27 15:02:47 <GAit> oh clang-formatter is probably very similar to uncrustify
568 2014-06-27 15:02:49 <sipa> but i'm fine with being lax
569 2014-06-27 15:02:59 <sipa> and just run the formatter once in the merge window
570 2014-06-27 15:03:02 <wumpus> yes, we could periodically run it over the whole code
571 2014-06-27 15:03:04 <wumpus> right
572 2014-06-27 15:03:10 <Luke-Jr> sipa: that won't affect reviewing
573 2014-06-27 15:03:12 <wumpus> an auto-diapolo
574 2014-06-27 15:03:26 <gmaxwell> I don't have any great recommendations. In daala we use https://git.xiph.org/?p=daala.git;a=blob_plain;f=doc/coding_style.html but it's a C project (so some of the style choices would be a little different from C++), and some people don't love the style, and its very different from the existing bitcoin one. I'm generally of the view that code style is unsolvable. I do like machine achievable code style.
575 2014-06-27 15:03:28 <Luke-Jr> we really ought to detect potential exploits before merging if possible
576 2014-06-27 15:03:39 <wumpus> who is talking about exploits?
577 2014-06-27 15:03:48 <gmaxwell> sipa: the only protest I have to the pulltester enforce is that if I run a different version of clang than the pulltester we might get different results.
578 2014-06-27 15:03:57 <sipa> gmaxwell: agree
579 2014-06-27 15:04:11 <wumpus> the pulltester should really test the code, not judge code style IMO
580 2014-06-27 15:04:38 <gmaxwell> Luke-Jr: if we ever get testing to the point where we could have pulltester about code decreasing coverage it would make it harder to hide things in commits.
581 2014-06-27 15:04:43 <gmaxwell> but we're still a long way from that.
582 2014-06-27 15:04:45 <wumpus> big change I'll start to ignore it if it starts to be too fussy
583 2014-06-27 15:04:49 <wumpus> chance*
584 2014-06-27 15:05:08 <wumpus> right now pulltester fail = serious problem
585 2014-06-27 15:05:09 <btc123> isn't there a tool that will convert one code style to another? i dont see what the fuss is - chose a standard that github uses, and let devs convert back and forth to whatever format they like
586 2014-06-27 15:05:14 <Luke-Jr> gmaxwell: indeed, that solves it better than worrying over formatting
587 2014-06-27 15:05:16 <gmaxwell> wumpus: well it could note the formating seperately so you could ignore jsut that part.
588 2014-06-27 15:05:40 <Luke-Jr> wumpus: I started mostly ignoring pulltester failures when it failed for stupid reasons like out of disk space or server trouble
589 2014-06-27 15:05:53 <wumpus> Luke-Jr: well that usually gets fixed pretty soon!
590 2014-06-27 15:07:10 <sipa> it's been getting stuck like once every two days still
591 2014-06-27 15:10:44 <wumpus> gavinandresen: nice that #4250 splits GetFee into GetMinRelayFee and CWallet::GetMinimumFee
592 2014-06-27 15:13:28 <wumpus> gavinandresen: really needs an #define GAVINS_FAVORITE_NUMBER 11 tho :)
593 2014-06-27 15:14:08 <gavinandresen> #define BEST_NUMBER_IN_THE_WORLD 11 you mean
594 2014-06-27 15:14:15 <wumpus> ha
595 2014-06-27 15:15:01 <Luke-Jr> gavinandresen: 0xb
596 2014-06-27 15:15:09 <sipa> #define BEST_NUMBER_IN_THE_WORLD (ANSWER_TO_THE_ULTIMATE_QUESTION_OF_LIFE_THE_UNIVERSE_AND_EVERYTHING + 2) / 4
597 2014-06-27 15:15:20 <Luke-Jr> it's called "hu" in tonal.
598 2014-06-27 15:15:44 <gavinandresen> huh. hu. who knew.
599 2014-06-27 15:16:11 <gavinandresen> why do I feel like I'm speaking Doge....
600 2014-06-27 15:16:19 <Luke-Jr> âº
601 2014-06-27 15:16:27 <sipa> ACTION recently flew with "WOW airlines" to inceland
602 2014-06-27 15:16:33 <sipa> such flight
603 2014-06-27 15:16:59 <gavinandresen> my dirty little secret today: I'm wearing the Doge T-shirt they gave me in Amsterdamâ¦. don't tell anybody.
604 2014-06-27 15:17:22 <Jouke> pics or it didn't happen
605 2014-06-27 15:17:42 <Luke-Jr> Jouke: exactly.
606 2014-06-27 15:17:55 <wumpus> hehehe
607 2014-06-27 15:18:07 <GAit> sipa: lol
608 2014-06-27 15:18:07 <gavinandresen> right, exactly, didn't happen. Good show.
609 2014-06-27 15:18:32 <Einewton> lol
610 2014-06-27 15:18:40 <Jouke> ^_^
611 2014-06-27 15:40:19 <JackH> hey gavin, you did this today: https://twitter.com/gavinandresen/status/482544093696753664
612 2014-06-27 15:40:30 <JackH> does it mean we can send complex transactions and that those will be mined now?
613 2014-06-27 15:40:40 <JackH> or is this "yet to be added"
614 2014-06-27 15:40:55 <Luke-Jr> JackH: it means they will be relayed.
615 2014-06-27 15:41:06 <Luke-Jr> changes to Bitcoin Core don't affect miners inherently
616 2014-06-27 15:41:13 <JackH> ah yes, true
617 2014-06-27 15:41:16 <Luke-Jr> miners still need to choose to make the same changes
618 2014-06-27 15:41:22 <JackH> well at least relayed then
619 2014-06-27 15:41:34 <JackH> but, I assume this is a 0.9.3 feature?
620 2014-06-27 15:41:39 <gmaxwell> 0.10
621 2014-06-27 15:41:51 <Luke-Jr> JackH: of course, Eligius will probably mine it for you..
622 2014-06-27 15:41:52 <Luke-Jr> already\
623 2014-06-27 15:41:58 <gmaxwell> Eligius was already doing something along those lines though, so you already can get them mined (with a little awkwardness)
624 2014-06-27 15:42:31 <JackH> wait a sec. This feature already existed in our Bitcoin-qt?
625 2014-06-27 15:43:08 <Luke-Jr> JackH: uh, this isn't relevant to the GUI at all
626 2014-06-27 15:43:14 <Luke-Jr> JackH: or even the Bitcoin protocol
627 2014-06-27 15:43:21 <Luke-Jr> it's just a relay policy
628 2014-06-27 15:43:29 <JackH> ahh gotcha
629 2014-06-27 15:43:31 <cdecker> You just had to make sure Eligius somehow got it and it would mine it
630 2014-06-27 15:43:39 <JackH> so its pretty much in effect now
631 2014-06-27 15:43:45 <JackH> all over
632 2014-06-27 15:43:53 <Luke-Jr> JackH: if you choose to make it in effect..
633 2014-06-27 15:44:02 <JackH> yes, I understand
634 2014-06-27 15:44:05 <gmaxwell> This discussion is not moving in a productive way.
635 2014-06-27 15:45:04 <gmaxwell> JackH: the change merged today hasn't had any effect. It's just software on a website. It will have an effect when people deploy it. What Luke and I were pointing out was that some people had already deployed similar changes (years ago), so it's also not as simple as saying that its not in effect yet either.
636 2014-06-27 15:45:09 <gmaxwell> More clear?
637 2014-06-27 15:45:41 <Luke-Jr> in other news, I merged auto_solomine
638 2014-06-27 15:45:51 <JackH> yes very clear. the confusion was that if this is/was/will be a part of the client in any way
639 2014-06-27 15:45:57 <gmaxwell> Luke-Jr: sweet.
640 2014-06-27 15:46:07 <Luke-Jr> hopefully maaku won't get upset
641 2014-06-27 15:46:08 <Luke-Jr> :p
642 2014-06-27 15:46:16 <gmaxwell> Did maaku not like it?
643 2014-06-27 15:46:21 <Luke-Jr> I didn't mention it to him
644 2014-06-27 15:46:30 <Luke-Jr> but in theory it breaks Freicoin unless people add --no-local-bitcoin
645 2014-06-27 15:46:41 <Luke-Jr> Freicoin mining*
646 2014-06-27 15:47:14 <gmaxwell> Cool. How does it do that? (cool because I assume that means that its imposing some of the local state on the miner)
647 2014-06-27 15:47:29 <Luke-Jr> gmaxwell: BFGMiner can't handle multiple blockchains within the same instance, at the moment
648 2014-06-27 15:48:48 <gmaxwell> Luke-Jr: still need to figure out how to make that work further than localhost.
649 2014-06-27 15:49:04 <Luke-Jr> ?
650 2014-06-27 15:50:03 <gmaxwell> e.g. bfgminer on standalone miners on the local network can't do the same thing... so we're still not zero-touch solo mining.
651 2014-06-27 15:50:38 <Luke-Jr> gmaxwell: right, that'd be a security issue in theory
652 2014-06-27 15:50:48 <Luke-Jr> trusting the network layer isn't a good idea IMO
653 2014-06-27 15:51:15 <gmaxwell> Luke-Jr: sorta, but so long as mining is completely unauthenticated it's no different largely.
654 2014-06-27 15:51:27 <gmaxwell> Its something that could be disabled once something was configured.
655 2014-06-27 15:51:50 <gmaxwell> e.g. use the auto-local daemon as the local daemon unless something is explicitly configured.
656 2014-06-27 15:51:57 <maaku> i think people will figure out --no-local-bitcoin. not that it matters much after we switch to merged mining
657 2014-06-27 15:52:04 <maaku> need compact spv commitments first though :(
658 2014-06-27 15:54:07 <gmaxwell> I've still not dissuaded myself that we should be offering a GBT-like functionality over the P2P port.
659 2014-06-27 15:54:55 <maaku> gmaxwell: i'm having trouble parsing that, are you pro or con?
660 2014-06-27 15:55:16 <gmaxwell> I am pro.
661 2014-06-27 15:55:49 <maaku> i think it's very advantageous for lots of non-mining reasons
662 2014-06-27 15:56:12 <gmaxwell> I was trying to convince myself to be con, but I have failed. It may enable some totally braindead activity like mining using random nodes as the data source, but braindeadness happens regardless.
663 2014-06-27 15:56:31 <Luke-Jr> I don't see any use for it
664 2014-06-27 15:56:55 <maaku> yeah you can already shoot yourself in the foot with SPV mining
665 2014-06-27 15:57:03 <gmaxwell> Luke-Jr: coupled with a facility to find bitcoin nodes on the local network it allows zero conf local mining (unless configured otherwise)
666 2014-06-27 15:57:27 <maaku> on the non-mining front, it lets you peek into other nodes transaction selection mechanisms
667 2014-06-27 15:57:36 <maaku> with some useful priors it lets you get a better smart fee estimate
668 2014-06-27 15:57:42 <gmaxwell> basically all ideas we have to get people doing better decenteralized mining are frustrated by having to configure authentication.
669 2014-06-27 15:57:48 <Luke-Jr> gmaxwell: not any better than just exposing standard GBT without authentication
670 2014-06-27 15:58:03 <Luke-Jr> maaku: transaction selection of non-miners is worthless
671 2014-06-27 15:58:26 <gmaxwell> Luke-Jr: its just different there in respect to not exposing the rpc port is a good security practice.
672 2014-06-27 15:58:41 <maaku> Luke-Jr: only when miners really do have different selection policies
673 2014-06-27 15:58:48 <gmaxwell> (and a non-json GBT would probably have much better scalablity)
674 2014-06-27 15:58:50 <maaku> which, let's face it, they don't right now
675 2014-06-27 15:58:54 <Luke-Jr> maaku: which they should
676 2014-06-27 15:59:02 <Luke-Jr> maaku: no point giving people tools to assume they do
677 2014-06-27 15:59:23 <gmaxwell> Luke-Jr: e.g. if gbt works on rpc without auth I fear having more issues where people expose their rpc port to places they shouldn't and get wallets robbed.
678 2014-06-27 15:59:43 <Luke-Jr> p2p port could speak HTTP
679 2014-06-27 16:00:17 <Luke-Jr> alternatively, no reason GBT couldn't be used over TCP similar to stratum either
680 2014-06-27 16:01:23 <gmaxwell> I wonder if jeff's json code is faster than the current really slow stuff.
681 2014-06-27 16:06:17 <mr_burdell> Is it a bad idea to calculate transaction fee in the getrawtransaction RPC call?
682 2014-06-27 16:06:32 <mr_burdell> I made a patch that does it on my node, but wasn't sure if anyone else might want it