1 2014-11-07 00:34:14 <BlueMatt> gavinandresen: c9690960709fd366d09b181b9f50cd7afc6924b3 was not signed!
2 2014-11-07 00:37:04 <BlueMatt> (and, in fact, was apparently done via github's merge button........)
3 2014-11-07 01:49:24 <cfields> BlueMatt: i'm going to try to push up the libbitcoinconsensus PR tonight, if you'd like to have a look
4 2014-11-07 01:49:42 <cfields> we'll still need to bikeshed about the external interfaces, PR seems like a good enough place for that
5 2014-11-07 02:38:13 <BlueMatt> cfields: nice! yea, was at money2020 plus some non-core work last week so Ive been away a bit but Ive got tomorrow on the caltrain to do bitcoin core stuff
6 2014-11-07 02:38:22 <BlueMatt> well, plus tonight
7 2014-11-07 02:41:52 <gmaxwell> cfields: I've been hardly paying attention to the interfaces, since I figure we're still really not at a stage where we'd consider them 'public' yet.
8 2014-11-07 02:43:04 <cfields> gmaxwell: not "public" until merged? or not "public" until they've lived through a release or two?
9 2014-11-07 02:44:50 <gmaxwell> the latter. Right now the focus needs to really be on the safe transformations to get the code seperated. Fixing up interfaces can be done seperately (not that it must be, but at least from my perspective it was less of a priority). Probably won't know much about whats stupid in the interface until someone tries to use it in a non-bitcoin-core codebase.
10 2014-11-07 02:46:03 <cfields> gmaxwell: i'd disagree with that to some extent. The easiest way to be sure that no one uses your lib is to keep breaking the api
11 2014-11-07 02:46:28 <cfields> for something so simple, i don't see why we shouldn't make a strong effort to get it stable the first time
12 2014-11-07 02:46:46 <cfields> not that it's set in stone, ofc. but not trying and calling it unstable seems somewhat self-defeating imo
13 2014-11-07 02:48:31 <BlueMatt> gmaxwell: too late...Ive already used it :p
14 2014-11-07 02:48:45 <gmaxwell> Feel free to try of course, but I've spent no review cycles on deciding if the api sucks or not, dunno if anyone else has... and just moving things around is hard enough to review, so even if I saw something where I thought the API sucked, I dunno that I'd really want to ask someone to fix it.
15 2014-11-07 02:48:59 <BlueMatt> but, I agree with both of you...luckily what we're doing now will have maximum 2/3 functions
16 2014-11-07 02:49:15 <cfields> gmaxwell: no worries though, i'm sure i'll be in the minority on this one :)
17 2014-11-07 02:49:17 <BlueMatt> so I think getting it right enough that we probably wont need to change it significantly in the future should be very doable
18 2014-11-07 02:51:03 <gmaxwell> cfields: Also, it's C++ ... pretty hard to not break your callers when you change the code. :P
19 2014-11-07 02:51:24 <BlueMatt> gmaxwell: huh? its C
20 2014-11-07 02:51:24 <cfields> gmaxwell: the interface is C
21 2014-11-07 02:52:10 <gmaxwell> hm. I didn't think the interface was actually pure C.
22 2014-11-07 02:52:37 <BlueMatt> again, one function
23 2014-11-07 02:52:37 <gmaxwell> (e.g. there were class parameters. cool. obviously I'm out of touch)
24 2014-11-07 02:53:03 <BlueMatt> there was no point where the interface /wasnt/ pure C, I think
25 2014-11-07 02:53:14 <cfields> gmaxwell: https://github.com/theuni/bitcoin/blob/libbitcoinconsensus/src/script/bitcoinconsensus.h
26 2014-11-07 02:53:32 <cfields> gmaxwell: that's quite out of date, but the header is still relatively unchanged
27 2014-11-07 02:54:58 <gmaxwell> hmph. I thought the libbitcoinconsensus work consistented of more than the scriptverify.
28 2014-11-07 02:55:08 <BlueMatt> gmaxwell: long-term, yes
29 2014-11-07 02:56:43 <cfields> gmaxwell: the code-base is prepped for much more now, but nearly everyone wanted to start with just that
30 2014-11-07 02:58:42 <BlueMatt> well, not /that/ much more....
31 2014-11-07 04:28:44 <tdlfbx> Let's say someone produces a block and someone else produces a block at the same time. Let's say the first one (perhaps fraudulently) puts a timestamp in the block that is earlier than the other block. Which one gets accepted? Does the timestamp matter? Or just which of the two is communicated to me first?
32 2014-11-07 04:31:05 <justanotheruser> tdlfbx: #bitcoin
33 2014-11-07 04:31:26 <tdlfbx> Fine.
34 2014-11-07 04:31:56 <tdlfbx> #bitcoin is full of off-topic idiots.
35 2014-11-07 04:56:33 <cfields> BlueMatt: https://github.com/theuni/bitcoin/tree/libbitcoinconsensus
36 2014-11-07 04:56:42 <BlueMatt> will review, thanks
37 2014-11-07 04:56:45 <cfields> BlueMatt: a bit more cleanup, then I'll PR it
38 2014-11-07 04:57:11 <BlueMatt> ACTION is proud of his pull-request-a-shitty-version, watch-as-people-make-a-clean-one trick with all of this :p
39 2014-11-07 04:58:03 <cfields> the bottom two commits are #5212, feel free to comment there if you have any beef with 'em
40 2014-11-07 04:58:09 <BlueMatt> kk
41 2014-11-07 04:58:47 <cfields> BlueMatt: haha, there's an internet law that defines that method, i forget the name though
42 2014-11-07 04:59:28 <BlueMatt> yes, it is incredibly useful...I think we should also start doing it more in general to pull more people in
43 2014-11-07 04:59:50 <BlueMatt> iirc my first "big thing" was wallet encryption because of jeff's original hack
44 2014-11-07 05:08:15 <BlueMatt> cfields: note that this will need updated before release for bip62
45 2014-11-07 05:08:23 <BlueMatt> and/or CLTV (if we do that one)
46 2014-11-07 05:08:38 <cfields> BlueMatt: the flags, you mean?
47 2014-11-07 05:09:58 <BlueMatt> yea
48 2014-11-07 05:10:12 <BlueMatt> speaking of which.... petertodd are we gonna see a CLTV pull like....yesterday?
49 2014-11-07 05:10:26 <BlueMatt> I think most people would be in favor of that for 0.10, though it'd be a quick turnaround
50 2014-11-07 05:12:14 <cfields> BlueMatt: sipa mentioned in #5212 that he wanted to map external flags to internal, and i assume he didn't want to do it 1:1. So I'm leaving that part to him
51 2014-11-07 05:12:39 <BlueMatt> well, our isStandard flags should not be exposed
52 2014-11-07 05:12:46 <BlueMatt> (and we might want to mask them out, actually)
53 2014-11-07 05:13:06 <BlueMatt> ACTION sees little reason to do anything more than expose enough to form consensus
54 2014-11-07 05:13:18 <BlueMatt> (which requires a BIP62 flag, not all of the bip62 flags)
55 2014-11-07 07:29:56 <Guest17982> my friend says bitcoin does not involve encryption, but I disagreed with him
56 2014-11-07 07:30:20 <Jouke> really?
57 2014-11-07 07:30:25 <Guest17982> yeah
58 2014-11-07 07:30:26 <Jouke> why?
59 2014-11-07 07:30:35 <phantomcircuit> Guest17982, there is no encryption in the bitcoin protocol
60 2014-11-07 07:30:38 <phantomcircuit> there is hashing
61 2014-11-07 07:30:40 <phantomcircuit> and signatures
62 2014-11-07 07:30:43 <phantomcircuit> but no encryption
63 2014-11-07 07:30:46 <Guest17982> he doesn't consider message signing to involve encryption
64 2014-11-07 07:30:50 <sipa> it doesn't
65 2014-11-07 07:30:51 <Jouke> it doesn't
66 2014-11-07 07:30:57 <phantomcircuit> bitcoin core includes wallet encryption
67 2014-11-07 07:31:04 <phantomcircuit> but that's optional and not part of the protocol
68 2014-11-07 07:31:13 <sipa> for RSA, encryption and signing use the same mechanism
69 2014-11-07 07:31:19 <Guest17982> I thought you signed a message by hashing it and encrypting it with a private key
70 2014-11-07 07:31:28 <sipa> but Bitcoin doesn't use RSA; it uses ECDSA, which can only be used for signing
71 2014-11-07 07:31:36 <sipa> Guest17982: this is correct for RSA, but we don't use RSA
72 2014-11-07 07:31:44 <Guest17982> oh ok
73 2014-11-07 07:32:00 <Guest17982> thanks for clarifying
74 2014-11-07 08:24:55 <sipa> cfields: with default options, libbitcoinconsensus.so is now 200kb here after stripping
75 2014-11-07 08:25:16 <cfields> sipa: yep. 68k with lto :)
76 2014-11-07 08:25:16 <sipa> with -flto -fdata-sections -ffunction-sections (allowing the linker to omit unused functions/constants), 83kb
77 2014-11-07 08:25:23 <sipa> aha
78 2014-11-07 08:25:57 <cfields> afaik, lto with fdata/ffunction-sections + garbage collect is redundant
79 2014-11-07 08:26:26 <sipa> seems reasonable
80 2014-11-07 08:26:32 <sipa> let me try just ffunction sections
81 2014-11-07 08:26:36 <cfields> sipa: er, the 68k one might've been cheating with -Os though :)
82 2014-11-07 08:27:32 <sipa> still 200k
83 2014-11-07 08:27:36 <sipa> so you really need lto
84 2014-11-07 08:27:48 <cfields> sipa: ffunctions just bloats without the gc in the link
85 2014-11-07 08:28:15 <cfields> (you need to pair it with -Wl,--gc-sections)
86 2014-11-07 08:28:17 <sipa> ah
87 2014-11-07 08:28:45 <gmaxwell> whats the junk being left in? sounds like more code moving around is needed. :P
88 2014-11-07 08:29:01 <sipa> not much, i think
89 2014-11-07 08:29:08 <cfields> but yes, lto strips more than those for sure
90 2014-11-07 08:29:22 <sipa> lto also unifies
91 2014-11-07 08:29:30 <sipa> header stuff that was duplication
92 2014-11-07 08:29:42 <cfields> iirc ld still links in per-object, rather than per function. so without it, it can't be smaller than the sum of its objects
93 2014-11-07 08:29:50 <cfields> *so without lto
94 2014-11-07 08:30:07 <sipa> with just functionsection/datasections/linkergc it's 100kb
95 2014-11-07 08:30:42 <cfields> sipa: ah, nice data point
96 2014-11-07 08:31:04 <cfields> sipa: i built static libcrypto with lto as well, and linked to a final binary
97 2014-11-07 08:32:00 <cfields> that may be worth considering as well. it was a reasonable size. and lto means that we take very little of openssl, so the usual security moans are reduced somewhat
98 2014-11-07 08:32:56 <Diablo-D3> ACTION is live streaming Mass Effect again, http://www.twitch.tv/diablod3/
99 2014-11-07 08:33:44 <cfields> personally, i wouldn't be opposed to that for the gitian release. that makes it a drop-in library for 3rd party apps. Ofc distros would package dynamically linked solibs as always
100 2014-11-07 08:46:09 <wumpus> cfields: +1
101 2014-11-07 08:46:38 <wumpus> a self contained library is very useful for clients
102 2014-11-07 08:47:49 <wumpus> especially on windows, for example, where you cannot assume anything about dynamic libraries being installed in a globally visible place
103 2014-11-07 08:49:23 <cfields> wumpus: i have a feeling everyone would agree with a self-contained dll for windows
104 2014-11-07 08:49:32 <wumpus> I also agree on linux
105 2014-11-07 08:49:33 <cfields> the linux .so is the one i'm not sure about
106 2014-11-07 08:49:46 <wumpus> as you say - at least for the gitian release
107 2014-11-07 08:49:47 <cfields> i see the merit in both, so i'm not opposed to either
108 2014-11-07 08:50:06 <cfields> sounds good to me, then
109 2014-11-07 08:50:08 <wumpus> our bitcoind executable is self-contained too, would be kind of strange otherwise
110 2014-11-07 08:51:20 <wumpus> it needs to be easily loadable from something such as python ctypes
111 2014-11-07 08:53:29 <cfields> time to catch a few zzz, nnite
112 2014-11-07 08:53:39 <wumpus> I agree that it is different if you just compile from source on the system you intend to run it on; in that case, having dependenies on the system libraries is expected
113 2014-11-07 08:53:41 <wumpus> ok nn
114 2014-11-07 08:54:11 <cfields> yea, in that sense i think it functions as expected
115 2014-11-07 08:54:21 <wumpus> good :)
116 2014-11-07 08:54:23 <cfields> a typical configure+make will have it depending on a shared libcrypto
117 2014-11-07 08:55:07 <wumpus> anything I should review on short term to help this along?
118 2014-11-07 08:55:42 <cfields> mainly #5212 as the prerequisite
119 2014-11-07 08:56:11 <cfields> other than that, and the api itself, i think the actual PR is pretty uninteresting
120 2014-11-07 08:57:30 <wumpus> ok
121 2014-11-07 08:57:38 <cfields> the api stuff is here: https://github.com/theuni/bitcoin/commit/da18a0266c4de76c2a461cc2984aa2fa066c42f5
122 2014-11-07 08:57:45 <cfields> i figured most discussion would revolved around that
123 2014-11-07 08:59:02 <cfields> -d
124 2014-11-07 09:45:38 <SomeoneWeird> https://github.com/theuni/bitcoin/blob/da18a0266c4de76c2a461cc2984aa2fa066c42f5/src/script/bitcoinconsensus.h#L4-L19
125 2014-11-07 09:45:40 <SomeoneWeird> windows :(
126 2014-11-07 09:52:13 <wumpus> SomeoneWeird: nah, marking symbol visibility makes sense on every OS, it helps exposing a specific and focused API, but yes the conditional is kind of ugly (and is almost half the interface header file... :P)
127 2014-11-07 09:52:48 <SomeoneWeird> wumpus: yeah, the if/else spaghetti was more what I was referring to :)
128 2014-11-07 10:14:15 <wumpus> cfields: thanks a lot for adding a travis test for disable-wallet mode, seems a lot of pulls break that