1 2014-03-21 00:00:57 <gmaxwell> dexX7: no, it's what the miners honestly believe it to be (minus their latency and plus any ntime rolling)
2 2014-03-21 00:11:11 <hno> Is the memorypool refilled with past transactions somehow when bitcoind is restarted, or does it only accumulate transactions announced to it after the restart?
3 2014-03-21 00:14:53 <Emcy_> dex block timestamps can be +-2 hours ish
4 2014-03-21 00:15:03 <Emcy_> dexX7
5 2014-03-21 00:15:50 <Emcy_> there can be no authoritative source of time for the bitcoin netowkr without giving it a huge centralisation
6 2014-03-21 00:16:05 <Emcy_> though im surprised a node capable of making a block would be minutes out
7 2014-03-21 00:16:31 <dexX7> + new block time has to be above the median time of the last 11.. but i was surprised nevertheless to actually see this
8 2014-03-21 00:16:34 <Emcy_> most of them have the OS keeping time from some ntp server id guess
9 2014-03-21 01:04:27 <gribble> The operation succeeded.
10 2014-03-21 01:04:27 <sipa> ;;later tell gavinandresen I've made some comments on your optimizing block broadcast gist https://gist.github.com/gavinandresen/9603614
11 2014-03-21 01:17:23 <SenseiV183> Got experience compiling the latest 0.9.0? I need some help please. Details here: http://pastebin.com/5Ak2n17c
12 2014-03-21 01:20:28 <Luke-Jr> SenseiV183: this is not #how-to-use-linux
13 2014-03-21 01:28:02 <lianj> lunix halp
14 2014-03-21 01:42:59 <SenseiV183> I wish the github bitcoin master branch had a sidebar link with build instructions. The help files within the source refer to other files not existing. There seems to be no makefiles included.
15 2014-03-21 01:44:58 <justanotheruser> SenseiV183: there is a makefile in src
16 2014-03-21 01:45:45 <SenseiV183> Why isn't there a mafefile.unix?
17 2014-03-21 01:45:57 <justanotheruser> SenseiV183: https://bitcoin.stackexchange.com/questions/18255/how-to-compile-bitcoin-qt-from-github-source-on-arch-linux
18 2014-03-21 01:47:26 <SenseiV183> That's exactly the last thing I tried before I came here to this channel lol.
19 2014-03-21 01:48:01 <justanotheruser> What was your error?
20 2014-03-21 01:48:56 <SenseiV183> I'm getting to that. Doing all over agin.
21 2014-03-21 01:49:22 <lianj> https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md
22 2014-03-21 01:53:39 <SenseiV183> justanotheruser, Here's the output http://pastebin.com/GhtYqhwH
23 2014-03-21 01:55:24 <justanotheruser> SenseiV183: please try this https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md
24 2014-03-21 01:57:02 <SenseiV183> justanotheruser, Ahhhh!
25 2014-03-21 01:57:22 <SenseiV183> justanotheruser, This is what I was looking for.
26 2014-03-21 01:57:41 <SenseiV183> That's looks like somewhere to start, I'll try that.
27 2014-03-21 02:13:48 <SenseiV183> ACTION is away: "I'll be right back, just gotta get 'er done."
28 2014-03-21 02:18:19 <SenseiV183> ACTION is back (gone 00:04:31)
29 2014-03-21 02:20:14 <SenseiV183> justanotheruser, What I'm concerned about is using the --enable-hardening option with ./configure and on an Amd64 processor where a library was not compiled with -fPIC, this will cause an error. (Bottom of link you sent).
30 2014-03-21 02:21:52 <justanotheruser> SenseiV183: I have no idea about those details. I just followed the instructions (which might not be safe). I would wait for a coredev, or someone more informed than me to answer.
31 2014-03-21 02:24:42 <SenseiV183> It's only extra protection if a hacker is already crawling around your computer that they won't be able to maliciously alter the executable file. However if an attacker has access to that daemon that is not good at all hehehe.
32 2014-03-21 02:26:24 <SenseiV183> justanotheruser, configure: error: Found Berkeley DB other than 4.8, required for portable wallets (--with-incompatible-bdb to ignore)
33 2014-03-21 02:28:23 <justanotheruser> SenseiV183: Did you install ldb in the way they described? for other Ubuntu & Debian:
34 2014-03-21 02:28:37 <SenseiV183> ACTION is away: On the phone.
35 2014-03-21 02:28:39 <justanotheruser> (assuming you have a debain based distro)
36 2014-03-21 02:36:03 <bitladen> Hi Guys could electrum be used to receive bitcoins from multiple addresses on a cold storage?
37 2014-03-21 02:48:29 <SenseiV183> ACTION is back (gone 00:19:53)
38 2014-03-21 02:49:31 <SenseiV183> justanotheruser, I don't know when the database was installed. I'm going to have to research what I've got. And Thank You.
39 2014-03-21 02:50:00 <justanotheruser> SenseiV183: try installing the versions they have. No problem.
40 2014-03-21 02:52:40 <SenseiV183> justanotheruser, I'm more interested at this point in figuring out first if the Berkeley DB I have installed is for another program and what will get broken and how to know that?
41 2014-03-21 02:54:48 <SenseiV183> I also know that Luke-Jr has a point, this is not a linux how to channel so hold off on more advice for me while I do some of my own research. I appreciate your help.
42 2014-03-21 02:55:13 <justanotheruser> SenseiV183: sure
43 2014-03-21 02:56:04 <Luke-Jr> reminder: all the pre-0.9 build instructions are wrong now
44 2014-03-21 02:56:29 <SenseiV183> I'm having a cigarette break from it
45 2014-03-21 02:56:30 <Luke-Jr> 0.9 is just a standard *nix build
46 2014-03-21 02:58:33 <SenseiV183> Luke-Jr, *nix rocks! Why pay Microsoft and Apple ;)
47 2014-03-21 03:00:46 <SenseiV183> Infact the only reason I (need) Windows at all is because the GoPro Hero 2 camera I have to do a firmware update they only make Windows and Apple applications for updating camera firmware. I'm afraid to wine that out and rish crash and brick the camera...
48 2014-03-21 03:01:22 <Luke-Jr> wait, you're trying to compile on *Windows*?
49 2014-03-21 03:01:34 <SenseiV183> No
50 2014-03-21 03:03:19 <SenseiV183> Ubuntu Studio - Saucy Salamander (While I'm still using it) I will eventually this year switch to Either Gentoo, Arch, Slackware, Xubuntu or even LFS!
51 2014-03-21 03:13:58 <SenseiV183> I just did a "getconf ARG_MAX" from my shell and it returned 2097152 Wow! With that many characters available on the command line it makes you wonder why more people don't use *nix's ";" command line operator to string together all the getting the right dependencies and put it a single block to copy and paste. :)
52 2014-03-21 03:15:45 <SenseiV183> ;;ticker
53 2014-03-21 03:15:56 <gribble> Bitstamp BTCUSD ticker | Best bid: 579.3, Best ask: 582.0, Bid-ask spread: 2.70000, Last trade: 582.0, 24 hour volume: 10099.82998632, 24 hour low: 578.1, 24 hour high: 606.44, 24 hour vwap: 0
54 2014-03-21 03:22:15 <melik> hi everyone; i recently upgraded to bitcoind 0.9
55 2014-03-21 03:22:27 <SenseiV183> justanotheruser, Are you on the mailing list?
56 2014-03-21 03:22:31 <melik> i think my heights are messed up :/
57 2014-03-21 03:22:41 <melik> i am polling for block height 546 (000000005a4ded781e667e06ceefafb71410b511fe0d5adc3e5a27ecbec34ae6)
58 2014-03-21 03:23:02 <melik> and its returning as block height 5 :s
59 2014-03-21 03:23:41 <melik> ergh, sorry; it also brings back an incorrect hash.. i'll provide a pastebin of the output
60 2014-03-21 03:26:38 <melik> i apologize gentlemen, i am an idiot :]
61 2014-03-21 03:34:40 <SenseiV183> ACTION is away: "I'll be right back, just gotta get 'er done."
62 2014-03-21 03:46:41 <atweiden> does bitpay have an irc presence?
63 2014-03-21 03:47:04 <atweiden> trying to improve bitcore insight systemd service https://github.com/atweiden/pkgbuilds/blob/master/insight-bitcore-git/insight.service
64 2014-03-21 03:47:06 <Luke-Jr> not really, beyond jgarzik
65 2014-03-21 03:47:56 <copumpkin> oh nice, I like these new coin control features
66 2014-03-21 03:48:07 <copumpkin> kudos to whomever put them in
67 2014-03-21 03:49:48 <Luke-Jr> copumpkin: unfortunately, I think the original author is long since gone and gave up on contributing :/
68 2014-03-21 03:50:29 <Luke-Jr> (he originally wrote it for 0.5 around 2012 Mar)
69 2014-03-21 03:58:30 <jgarzik> Luke-Jr, he left, but, JFYI you can point those people to #bitcore
70 2014-03-21 04:11:04 <SenseiV183> ACTION is back (gone 00:36:24)
71 2014-03-21 04:19:38 <copumpkin> Luke-Jr: who's that?
72 2014-03-21 04:23:00 <Luke-Jr> copumpkin: coderrr
73 2014-03-21 04:23:36 <Luke-Jr> copumpkin: actually, 2011 Jun: http://coderrr.wordpress.com/2011/06/30/patching-the-bitcoin-client-to-make-it-more-anonymous/
74 2014-03-21 04:23:45 <SenseiV183> justanotheruser, How do I go about becoming a gitian compiler? I found Berkeley 4.8 @ oracle. I would be interested in joining the community and being a gitian builder to build and sign packages That sounds cool. Helping stop people from putting spammy and malicious things in FOSS.
75 2014-03-21 04:24:51 <justanotheruser> SenseiV183: A gitian compiler being someone who compiles from git?
76 2014-03-21 04:25:03 <justanotheruser> Anyways, the unix readme includes the name of the package
77 2014-03-21 04:25:46 <SenseiV183> justanotheruser, check this out http://gitian.org/
78 2014-03-21 04:27:10 <justanotheruser> SenseiV183: what is the advantage of this over just trusting gavin andersen or trusting that you will hear about it if he puts something malicious in the source?
79 2014-03-21 04:28:12 <justanotheruser> also, join #bitcoin if we're going to discuss non-dev stuff
80 2014-03-21 04:28:16 <SenseiV183> justanotheruser, The advantages would be if those developers need any help getting those packages out faster it would help the community.
81 2014-03-21 04:29:08 <justanotheruser> I see
82 2014-03-21 04:29:09 <SenseiV183> justanotheruser, The advantage for me would just be the feeling of contribution to support something I believe in and get me more in to development.
83 2014-03-21 04:29:32 <Luke-Jr> justanotheruser: why not just trust the Fed?
84 2014-03-21 04:29:43 <venzen> hehe
85 2014-03-21 04:30:04 <justanotheruser> Luke-Jr: the trust of gitian seems to be the same as the trust of gavin and the community
86 2014-03-21 04:30:05 <Luke-Jr> justanotheruser: one of many answers: because trusting Gavin puts a high price on his life
87 2014-03-21 04:30:14 <Luke-Jr> justanotheruser: what?
88 2014-03-21 04:30:44 <Luke-Jr> justanotheruser: gitian makes it possible for multiple independent parties to produce the same binaries
89 2014-03-21 04:30:59 <Luke-Jr> justanotheruser: no release of Bitcoin Core is ever published without at least 3 independent verifications
90 2014-03-21 04:31:27 <justanotheruser> Luke-Jr: Why should I trust gitian over just compiling fro bitcoin.org then?
91 2014-03-21 04:31:51 <justanotheruser> Oops, I mean compiling from github or downloading from bitcoin.org
92 2014-03-21 04:31:52 <Luke-Jr> justanotheruser: many people don't want to compile themselves.
93 2014-03-21 04:31:58 <Luke-Jr> justanotheruser: â¦
94 2014-03-21 04:32:04 <SenseiV183> justanotheruser, If you read the gitian link, they compare the binaries built by everyone who submits them.
95 2014-03-21 04:32:14 <Luke-Jr> justanotheruser: the downloads on bitcoin.org are made by gitian
96 2014-03-21 04:32:18 <SenseiV183> p2p security
97 2014-03-21 04:32:33 <Luke-Jr> justanotheruser: and if you don't verify them, then someone exploiting the webserver can quietly infect you with a trojan or wallet-stealer
98 2014-03-21 04:33:03 <Luke-Jr> justanotheruser: and no, you won't be able to blame bitcoin.org for your failure to verify them -.-
99 2014-03-21 04:33:10 <justanotheruser> SenseiV183: I can either trust the bitcoin coredevs or I can trust the coredevs and anyone who does sybil
100 2014-03-21 04:33:16 <SenseiV183> Luke-Jr, I want to know how to do that. How to verify a bitcoin.org wallet build
101 2014-03-21 04:33:50 <Luke-Jr> SenseiV183: PGP signatures are here https://github.com/bitcoin/gitian.sigs
102 2014-03-21 04:37:23 <SenseiV183> Luke-Jr, Thanks.
103 2014-03-21 04:38:44 <SenseiV183> Oh getting sleepy.
104 2014-03-21 05:10:49 <jgarzik> ACTION is feeling cheeky, and throws a flame in the direction of Counterparty, https://bitcointalk.org/index.php?topic=395761.msg5815887#msg5815887
105 2014-03-21 05:11:21 <jgarzik> RE chain data storage
106 2014-03-21 05:13:32 <justanotheruser> ACTION monitors that comment
107 2014-03-21 05:49:07 <venzen> jgarzik: i'm not familiar with this issue and it's history. A cursory googl and look at page 1 of that thread shows Counterparty made the assumption that the BC is a public transaport/storage layer and set up their (what can one call it?) "brokerage" altcoin in late Dec 2013
108 2014-03-21 05:49:46 <justanotheruser> I wish they did this in an altcoin that was merge mined
109 2014-03-21 05:51:13 <venzen> what i don't understand is how they are accessing the BC from their XCP client? What makes this possible? Or are they only proposing?
110 2014-03-21 05:51:54 <jgarzik> venzen, those questions are too basic for #bitcoin-dev
111 2014-03-21 06:02:44 <venzen> jgarzik: ok, i retract them
112 2014-03-21 06:10:34 <justanotheruser> Anyone want to review a brief whitepaper I wrote of a decentralized application related to Bitcoin I plan on making. Specifically I am looking for criticisms on why you think it won't work and anything I should change.
113 2014-03-21 06:10:59 <justanotheruser> On a secondary point I would like to improve my writing style. Please PM me if you want to read it. It's 1500 words.
114 2014-03-21 06:27:46 <trumpertink> is there a minimum number of confirmations that bitcoind has to wait before it sign a transaction?
115 2014-03-21 06:31:53 <Luke-Jr> trumpertink: uh, you won't get mined until it's signed
116 2014-03-21 06:35:20 <trumpertink> ya i know. but to even sign a rawtransaction is there a min number of confs?
117 2014-03-21 06:35:33 <trumpertink> i keep getting false when i try to sign a rawtx with 3 confs
118 2014-03-21 06:36:35 <trumpertink> (confirmations on the tx used for vout)
119 2014-03-21 06:37:24 <shesek> you mean in?
120 2014-03-21 06:37:26 <trumpertink> i mean vin
121 2014-03-21 06:37:45 <trumpertink> ya
122 2014-03-21 06:41:55 <Luke-Jr> trumpertink: for rawtx there shouldn't be..
123 2014-03-21 06:42:40 <trumpertink> how about minimum bitcoins being sent?
124 2014-03-21 06:45:40 <Luke-Jr> trumpertink: outputs need to have a minimum amount
125 2014-03-21 06:46:28 <trumpertink> what's the min
126 2014-03-21 06:47:30 <trumpertink> i'm sending .01 that can't be to low
127 2014-03-21 06:47:52 <trumpertink> or .005 with a .005 fee
128 2014-03-21 06:48:04 <Luke-Jr> nah, it's something tiny
129 2014-03-21 06:48:07 <Luke-Jr> like .000001
130 2014-03-21 06:48:09 <trumpertink> this is on testnet btw
131 2014-03-21 06:48:19 <Luke-Jr> debug.log might have info for you
132 2014-03-21 07:03:52 <Emcy> jgarzik it depends on the prospect of getting lazy poolops to add your chain for mergemine
133 2014-03-21 07:04:10 <Emcy> its not really a defence if you didnt even try though
134 2014-03-21 07:15:21 <SenseiV183> after running autogen.sh it creats configure. When I load configure in to gedit 3.8.3 it defaults to sh syntax highlighting and something is wrong with it because comments are not a consistent color.
135 2014-03-21 07:18:18 <SenseiV183> http://pastebin.com/7pmqmnhL the configure script.
136 2014-03-21 07:21:24 <wumpus> SenseiV183: the syntax parsers of editors cannot handle the scaling issues involved with such a large and messy script as generated by GNU tools :-)
137 2014-03-21 07:23:28 <SenseiV183> wumpus, I compiled the Berkeley DB 4.8.3 from oracle and still get the error message about incompatible version. Do I need to set environment variables for bdbpath and bdb48path?
138 2014-03-21 07:24:12 <wumpus> if you compiled it yourself you do need to point the configure script at the lib and include directory of BDB
139 2014-03-21 07:24:23 <wumpus> otherwise it will only see your system's version
140 2014-03-21 07:25:53 <SenseiV183> Can you help me do that? My location is ~/db-4.8.30
141 2014-03-21 07:29:08 <wumpus> I created an issue, I'm surprised we don't have this yet https://github.com/bitcoin/bitcoin/issues/3921
142 2014-03-21 07:29:25 <SenseiV183> I'll look and see what you created.
143 2014-03-21 07:30:09 <wumpus> anyway you can always override LDFLAGS and CFLAGS to find them manually, don't forget that you need to manualy specify optimization flags in that case ie: ./configure LDFLAGS="-L/path/to/libs" CPPFLAGS="-I/path/to/includes -O2"
144 2014-03-21 07:32:16 <SenseiV183> I like the issue you created. Makes perfect sense. BDB is @ like version 6 or something ;)
145 2014-03-21 07:40:16 <SenseiV183> ACTION is away: eating pizza
146 2014-03-21 07:45:44 <wumpus> so, how do we allocate the weight for gitian-downloader sigs? https://github.com/bitcoin/bitcoin/pull/3907
147 2014-03-21 08:04:05 <wumpus> oops I forgot pushing my gitian sigs
148 2014-03-21 08:05:45 <SenseiV183> wumpus, I'm guessing that it would be LDFLAGS=/home/shaun/db-4.8.30/clib/ CPPFLAGS=/home/shaun/db-4.8.30/dbinc/ and do I need quotes around the paths?
149 2014-03-21 08:06:06 <wumpus> if there are no spaces in the paths you don't strictly need quotes (but they don't hurt)
150 2014-03-21 08:06:10 <wumpus> eh
151 2014-03-21 08:06:39 <wumpus> more like LDFLAGS="-L/home/shaun/db-4.8.30/clib/" CPPFLAGS="-I/home/shaun/db-4.8.30/dbinc/"
152 2014-03-21 08:06:53 <wumpus> and don't forget passing the optimization flag too, so
153 2014-03-21 08:06:57 <wumpus> more like LDFLAGS="-L/home/shaun/db-4.8.30/clib/" CPPFLAGS="-I/home/shaun/db-4.8.30/dbinc/ -O2"
154 2014-03-21 08:07:11 <SenseiV183> do I need to point any flag to the db-4.8.30 directory itself?
155 2014-03-21 08:07:28 <wumpus> manually specifying LDFLAGS/CFLAGS drops the standard optimization flags, so otherwise you get a non-optimized build which is usually unpleasant
156 2014-03-21 08:08:05 <wumpus> no, it needs only includes and libraries to be able to link against it
157 2014-03-21 08:08:35 <SenseiV183> is the "-L -02" the optimization?
158 2014-03-21 08:08:55 <wumpus> no
159 2014-03-21 08:08:59 <wumpus> the -O2 is
160 2014-03-21 08:09:52 <SenseiV183> ./configure LDFLAGS="-L/home/shaun/db-4.8.30/clib/" CPPFLAGS="-I/home/shaun/db-4.8.30/dbinc/ -O2"
161 2014-03-21 08:11:10 <SenseiV183> ./configure --enable-hardening LDFLAGS="-L/home/shaun/db-4.8.30/clib/" CPPFLAGS="-I/home/shaun/db-4.8.30/dbinc/ -O2"
162 2014-03-21 08:11:33 <SenseiV183> is --enable-hardening in the right place?
163 2014-03-21 08:11:39 <wumpus> yes
164 2014-03-21 08:11:57 <SenseiV183> how to specify build without upnp?
165 2014-03-21 08:13:12 <wumpus> don't be so lazy, please check the configure --help first before asking here
166 2014-03-21 08:13:17 <warren> wumpus: hey. where did you see the libstdc++ compat problem?
167 2014-03-21 08:13:28 <warren> wumpus: at least for Debian and RHEL6 it seems OK with your current binary.
168 2014-03-21 08:13:32 <SenseiV183> wumpus, Thank you.
169 2014-03-21 08:13:41 <wumpus> warren: my current binary is fine, it's 100% statically linked
170 2014-03-21 08:13:48 <warren> ooh
171 2014-03-21 08:14:16 <SenseiV183> wumpus, You helped me a lot. I didn' t realize the configure script had help lol. Thanks so much.
172 2014-03-21 08:14:16 <wumpus> warren: but I was warning @theuni, he wants to try something with wrapping specific glibc symbols which may not be enough as the libc++ of Ubuntu 12.04 is *also* newer
173 2014-03-21 08:14:19 <cheetah2> gentlemen how long does ir take to understand bitcoin
174 2014-03-21 08:14:26 <wumpus> SenseiV183: no problem
175 2014-03-21 08:14:29 <cheetah2> weeks?
176 2014-03-21 08:14:31 <warren> I know for a fact that libstdc++ supports linking to a particular symbol version, because I asked for this feature while at Red Hat for a particular problem we had back then.
177 2014-03-21 08:14:34 <cheetah2> months?
178 2014-03-21 08:14:50 <warren> this was like 6 years ago
179 2014-03-21 08:14:58 <Adlai> cheetah2: nine pages... https://bitcoin.org/bitcoin.pdfâ
180 2014-03-21 08:15:13 <cheetah2> no i mean the program
181 2014-03-21 08:15:16 <wumpus> cheetah2: well if you're as slow as me, it can take four years and you still don't get the whole thing ;)
182 2014-03-21 08:15:53 <cheetah2> as in being able to create my own software
183 2014-03-21 08:16:20 <wumpus> warren: well it may be possible that way, but in any case my static build is the sledgehammer approach: it should work on (almost) any x86 linux imaginable
184 2014-03-21 08:16:47 <warren> with the loss of ASLR, which is highly undesireable for the standard distro.
185 2014-03-21 08:17:08 <warren> my gitian build on lucid seems to work great everywhere
186 2014-03-21 08:17:12 <wumpus> only on 32-bit AFAIK, it seems that 64 bit supports -pie and -static (at least it doesn't produce an invalid executable)
187 2014-03-21 08:17:21 <warren> oh
188 2014-03-21 08:17:24 <warren> in that case, screw it
189 2014-03-21 08:17:42 <wumpus> (I haven't checked whether it actually randomized anything, mind you)
190 2014-03-21 08:17:43 <warren> although bitcoind only isn't the friendliest
191 2014-03-21 08:17:59 <warren> that's important to check
192 2014-03-21 08:18:03 <wumpus> it's what the serious people with stable linux distros want, they don't care about the GUI
193 2014-03-21 08:18:26 <warren> well, let's see what cfields does
194 2014-03-21 08:18:38 <wumpus> stable linux is used on servers
195 2014-03-21 08:21:28 <wumpus> well, someone who uses the damn thing can check, I don't feel like spending days on this
196 2014-03-21 08:22:06 <anton000> lol
197 2014-03-21 08:22:14 <anton000> thanks again wumps :)
198 2014-03-21 08:22:34 <SenseiV183> wumpus, configure: error: Found Berkeley DB other than 4.8, required for portable wallets (--with-incompatible-bdb to ignore)
199 2014-03-21 08:22:55 <wumpus> SenseiV183: something must be wrong with the arguments then, check config.log
200 2014-03-21 08:23:08 <SenseiV183> wumpus, ok
201 2014-03-21 08:26:44 <anton000> will try to see if we still got a slackware box up
202 2014-03-21 08:31:32 <wumpus> warren: a cursory test with printf("%p\n",&main) seems to show that ASLR doesn't work in 64 bit static executables either
203 2014-03-21 08:31:59 <warren> grr
204 2014-03-21 08:32:24 <aynstein> anton000: I can deploy a fresh image real quick slackware 14.1?
205 2014-03-21 08:32:29 <wumpus> but there is progress! we even get a nice error instead of an invalid executable: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC
206 2014-03-21 08:33:03 <anton000> aynstein: https://github.com/bitcoin/bitcoin/pull/3914
207 2014-03-21 08:33:10 <wumpus> the configure script catches this and hence removes -pie automatically, hence I don't need to do anything special for it in gitian
208 2014-03-21 08:33:27 <wumpus> but the end result is the same :(
209 2014-03-21 08:35:06 <warren> wumpus: I hope cfields comes up with something. Not sure what he's doing for work right now.
210 2014-03-21 08:35:48 <aynstein> so just build it on a slackware 32 and see if it craps out?
211 2014-03-21 08:36:23 <wumpus> aynstein: building should be fine, it's just that it's hard to make a portable executable on linux
212 2014-03-21 08:36:28 <aynstein> or use a min gcc lib?
213 2014-03-21 08:36:41 <warren> wumpus: at least for 0.9 the binary seems to be totally fine
214 2014-03-21 08:36:44 <aynstein> oh, i see now
215 2014-03-21 08:36:46 <warren> wumpus: built on lucid
216 2014-03-21 08:37:00 <wumpus> warren: yes, but as mentioned before, downgrading the gitian VM is not an option
217 2014-03-21 08:37:21 <SenseiV183> wumpus, I checked the config file and the word error occurs many times. Also Ubuntu/Linaro occurs many times, strange because I'm running Ubuntu Studio - Saucy Salamander and here's that log file http://pastebin.com/NHrUwK9C
218 2014-03-21 08:37:28 <warren> wumpus: I'm sorry I didn't protest this earlier, I discovered this and noted it last year.
219 2014-03-21 08:37:32 <wumpus> warren: of course that is possible, but we have a nice influx of gitian builders now, wouldn't want to scare them off by having them install three VM images...
220 2014-03-21 08:37:47 <warren> wumpus: it's a tiny amount of extra disk space, not a big deal
221 2014-03-21 08:38:01 <wumpus> warren: it is a big deal IMO
222 2014-03-21 08:38:29 <wumpus> some people are using virtualbox-based setups, it's not all as easy to switch them
223 2014-03-21 08:38:35 <warren> well, if I noticed it a month or two ago we would have a symbol filtered build, we'll be fine after that.
224 2014-03-21 08:39:29 <wumpus> warren: as I mentioned in another pull, disable FORTIFY_BUILD may be enough
225 2014-03-21 08:39:42 <wumpus> warren: at least for the glibc symbols, the new used symbol has to do with the feature
226 2014-03-21 08:40:12 <wumpus> unsure about the libc++ symbols
227 2014-03-21 08:40:34 <wumpus> probably boost using some state-of-the-art c++ feature
228 2014-03-21 08:40:58 <warren> shit
229 2014-03-21 08:41:18 <warren> might need to build boost with the same filtered symbols
230 2014-03-21 08:41:25 <warren> yes, that's needed
231 2014-03-21 08:41:36 <wumpus> 00000000 DF *UND* 00000000 GLIBC_2.15 __fdelt_chk that's the GLIBC_2.15 symbol
232 2014-03-21 08:42:11 <wumpus> apart from that everything is <=GLIBC_2.13 IIRC
233 2014-03-21 08:43:15 <warren> 2.13 isn't old enough
234 2014-03-21 08:43:18 <warren> need 2.12
235 2014-03-21 08:43:35 <warren> although RHEL6's glibc probably has backported things from newer glibc
236 2014-03-21 08:43:38 <wumpus> objdump -T bitcoin-qt bitcoind bitcoin-cli |grep GLIBC_2.13 doesn't show anything either
237 2014-03-21 08:45:42 <wumpus> as for libc++ we use symbols from GLIBCXX_3.4 GLIBCXX_3.4.9 GLIBCXX_3.4.11 GLIBCXX_3.4.15
238 2014-03-21 08:47:29 <wumpus> it's strange that the person in https://bitcointalk.org/index.php?topic=522014.msg5787094#msg5787094 mentions an error about GLIBC_2.14 as well... we don't even use any 2.14 symbols according to objdump -T :-/
239 2014-03-21 08:48:48 <wumpus> GLIBCXX_3.4.15 std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)
240 2014-03-21 08:48:50 <wumpus> GLIBCXX_3.4.15 std::out_of_range::~out_of_range()
241 2014-03-21 08:48:58 <wumpus> GLIBCXX_3.4.15 std::__detail::_List_node_base::_M_unhook()
242 2014-03-21 08:49:04 <wumpus> those are the new c++ symbols
243 2014-03-21 08:50:37 <wumpus> can we really convince g++ not to use them?
244 2014-03-21 08:50:45 <warren> wumpus: http://glandium.org/blog/?p=1901 this looks useful
245 2014-03-21 08:51:18 <wumpus> "Newer gcc, new problems" hah indeed
246 2014-03-21 08:51:35 <wumpus> it even mentions the same symbols as I did
247 2014-03-21 08:52:36 <wumpus> that hack they use to avoid the symbols looks scary though :(
248 2014-03-21 08:54:03 <wumpus> but yes it'd work
249 2014-03-21 08:54:14 <wumpus> if you define the symbols yourself, the linker won't be asking for them anymore ...
250 2014-03-21 08:54:19 <warren> hahaha
251 2014-03-21 08:54:29 <warren> that can be a non-default --configure option
252 2014-03-21 08:55:24 <wumpus> it's at a comparable level of evil with dropping ASLR
253 2014-03-21 08:55:53 <Belxjander> ASLR?
254 2014-03-21 08:56:11 <wumpus> (address space randomization, please read back a bit)
255 2014-03-21 08:56:22 <Belxjander> ahhh
256 2014-03-21 08:56:32 <Belxjander> scattering on loading
257 2014-03-21 08:57:28 <wumpus> it's very brittle; what about compiling our own libstdc++ and glibc and linking against that? :p
258 2014-03-21 08:59:58 <wumpus> I'm sure there is an obvious reason such a simple solution won't work (bound to gcc/g++ version?)
259 2014-03-21 09:05:18 <SenseiV183> ACTION is away: "I'll be right back, just gotta get 'er done."
260 2014-03-21 10:01:07 <aynstein> sorry, so you just want to see if the static runs as packaged on slackware right?
261 2014-03-21 10:01:28 <aynstein> it does not.
262 2014-03-21 11:02:05 <wumpus> aynstein: what do you get for error?
263 2014-03-21 11:16:29 <asdf_> @jgarzik - how would you recommend a newcomer to the bitcoin codebase get started?
264 2014-03-21 11:16:49 <asdf_> any canonical source of documentation on classes, namespaces, and the like? This appears to be out of date: http://webchat.freenode.net/?channels=bitcoin-dev
265 2014-03-21 11:18:26 <wumpus> asdf_: huh do you perhaps mean https://dev.visucore.com/bitcoin/doxygen/ ?
266 2014-03-21 11:18:59 <wumpus> (should be up to date daily with master, but sometimes the script hangs)
267 2014-03-21 11:22:51 <asdf_> doh. Yes.
268 2014-03-21 11:23:00 <asdf_> that's for version 0.9.0
269 2014-03-21 11:23:10 <cbeams_> wumpus: fwiw, that is the first time I've seen a link to the docs at visucore. A Google site: search against the wiki for 'visucore' shows zero results. But I just git grepped the repo and did find the link in doc/README.md.
270 2014-03-21 11:23:31 <cbeams_> ... and in any case, good to know, thanks!
271 2014-03-21 11:23:40 <wumpus> asdf_: .. 0.9.0 is very recent right? :p (it's actually not 0.9.0 but 0.9.99/master, but the version number is shown wrong)
272 2014-03-21 11:23:49 <asdf_> i see
273 2014-03-21 11:23:54 <asdf_> right
274 2014-03-21 11:24:03 <asdf_> i thought it might be out of date due to that version update not reflecting
275 2014-03-21 11:24:15 <asdf_> any tips on where to start?
276 2014-03-21 11:24:25 <wumpus> version should be updated in doc/Doxyfile as well...
277 2014-03-21 11:24:27 <asdf_> just look at some tickets and dive in, i guess
278 2014-03-21 11:24:39 <asdf_> but i'd like to get some kind of overview
279 2014-03-21 11:24:42 <wumpus> cbeams_: yes, for some reason its not very well linked
280 2014-03-21 11:24:52 <asdf_> sort of like Google's "life cycle of a search query"
281 2014-03-21 11:25:45 <asdf_> is there an overview of the codebase in terms of which functions, subroutines, etcetera are called for different tasks, like downloading the blockchain, computing proof of work, sending txs to network, etc.?
282 2014-03-21 11:25:51 <wumpus> did you see this bitcoin documentation initative?
283 2014-03-21 11:26:12 <cbeams_> wumpus: to which to you refer?
284 2014-03-21 11:27:27 <asdf_> Just googled "bitcoin documentation initiative" and don't see anything
285 2014-03-21 11:27:27 <wumpus> http://bitcoindev.us.to/en/developer-guide
286 2014-03-21 11:28:08 <asdf_> wow
287 2014-03-21 11:28:11 <asdf_> much thanks
288 2014-03-21 11:28:13 <wumpus> asdf_: it's very now, so I wouldn't be surprised if google hasn't properly indexed it yet
289 2014-03-21 11:28:16 <wumpus> new*
290 2014-03-21 11:28:32 <cbeams_> wumpus: Yeah, I did see that about a week ago when it was announced. Thanks for the reminder.
291 2014-03-21 11:28:43 <cbeams_> Who is working on that?
292 2014-03-21 11:29:14 <wumpus> quite a few people, see the links at the top
293 2014-03-21 11:29:35 <wumpus> (the big yellow slab with "Contribute")
294 2014-03-21 11:30:29 <cbeams_> wumpus: joined the mailing list. thanks.
295 2014-03-21 11:30:33 <michagogo> cloud|wumpus: commented re: gitian weight
296 2014-03-21 11:30:53 <michagogo> cloud|(Most of the discussion is really in the IRC logs)
297 2014-03-21 11:31:51 <wumpus> michagogo|cloud: so the conclusion of that was to give you a weight of 1? :p
298 2014-03-21 11:32:05 <asdf_> wumpus: thanks very much. Any tips on build environment and whatnot
299 2014-03-21 11:32:23 <asdf_> just standard C++ build environment? Do people use sx or libbitcoin very much?
300 2014-03-21 11:32:48 <wumpus> michagogo|cloud: anyhow that probably means aschildbach should set his to 1 as well
301 2014-03-21 11:33:55 <wumpus> asdf_: nope, I tend to avoid even looking at other bitcoin-related projects these days to avoid accusations of copying, especially after the btcd troll debacle
302 2014-03-21 11:35:56 <wumpus> (for reference, some idiot claimed that we 'copied over most features from btcd' in 0.9, even though we were almost the first to get the commit in every time, and it's Go versus C++ in a completely different source structure so copying is far from trivial :p)
303 2014-03-21 11:37:13 <asdf_> i see
304 2014-03-21 11:37:23 <asdf_> but isn't it good to copy over features
305 2014-03-21 11:37:32 <asdf_> wumpus: isn't it good to copy over features for compatibility?
306 2014-03-21 11:37:58 <wumpus> well normally in open source it is, but the bitcoin community is very hostile in some regards
307 2014-03-21 11:38:54 <asdf_> i've been looking through the codebase and there are definitely some hackish-seeming things, e.g.:
308 2014-03-21 11:38:55 <asdf_> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1745
309 2014-03-21 11:39:31 <asdf_> the main.cpp file is a lot less clean as a top-level file than i would have anticipated
310 2014-03-21 11:39:45 <asdf_> (i'm sure there is a good reason for it all, just trying to feel my way around :))
311 2014-03-21 11:39:47 <wumpus> main.cpp should really be split up
312 2014-03-21 11:39:59 <wumpus> then again, there are always zillions of more pressing issues
313 2014-03-21 11:41:45 <wumpus> I always suggest surpressing feelings of hacky/uglyness when reading a new codebase and focusing on understanding
314 2014-03-21 12:01:05 <wumpus> trying to generate a doxygen with call(er) graphs now, I think it's going to be too huge to upload tho :)
315 2014-03-21 12:02:15 <wumpus> gah I should really exclude leveldb
316 2014-03-21 12:07:26 <jouke> michagogo|cloud: you there? I did make-base-vm, but I am unsure on what to do next
317 2014-03-21 12:18:46 <michagogo> cloud|13:32:00 <wumpus> michagogo|cloud: so the conclusion of that was to give you a weight of 1? :p <-- Yes, but I don't remember what the reasons were at the time.
318 2014-03-21 12:19:06 <michagogo> cloud|wumpus: what's the btcd troll debacle?
319 2014-03-21 12:19:20 <michagogo> cloud|jouke: try the sanity check from the gitian readme
320 2014-03-21 12:19:51 <michagogo> cloud|wumpus: oh, ignore that question
321 2014-03-21 12:22:25 <wumpus> michagogo|cloud: some reddit thread, I can look it up if you're interested, it may be better to just ignore it, but I take accusations of plagiarism really serious
322 2014-03-21 12:24:33 <jouke> michagogo|cloud: should I have create a base-vm with --arch i386 ?
323 2014-03-21 12:25:03 <wumpus> jouke: you should have both, one with --arch i386 and without , but with suite 'precise'
324 2014-03-21 12:25:58 <jouke> wumpus: I can't find anything on "precise" in the README?
325 2014-03-21 12:27:02 <wumpus> fuck
326 2014-03-21 12:27:28 <wumpus> jouke: it isn't, but it should be
327 2014-03-21 12:28:45 <wumpus> by default it creates lucid images, which are useless for building recent versions of bitcoin
328 2014-03-21 12:29:16 <wumpus> should really be: bin/make-base-vm --suite precise --arch i386 and bin/make-base-vm --suite precise --arch amd64
329 2014-03-21 12:29:26 <jouke> ok
330 2014-03-21 12:32:09 <Luke-Jr> aschildbach: what are rotating addresses, and why do they not use the best-practice of pay-to-pubkey-hash? :/
331 2014-03-21 12:33:07 <aschildbach> That's addresses that are replaced by new adresses, for example because of a RNG bug that affected all addresses generated on Android devices pre August 2013.
332 2014-03-21 12:33:33 <wumpus> https://github.com/bitcoin/bitcoin/pull/3926/files
333 2014-03-21 12:33:42 <aschildbach> I'm not sure why it's "best practice"
334 2014-03-21 12:34:44 <aschildbach> Probably hearn knows.
335 2014-03-21 12:35:09 <Luke-Jr> aschildbach: p2pkh is a best practice to protect against ECDSA weaknesses
336 2014-03-21 12:40:46 <jgarzik> Luke-Jr, aschildbach: presumably rotating addresses are simply a new address each payment? That is best practice, and it would be good for Bitcoin Wallet to finally become secure.
337 2014-03-21 12:41:03 <jgarzik> The current practice of non-rotation really kills privacy
338 2014-03-21 12:41:41 <aschildbach> jgarzik: No, we're referring with "HD wallet" to what you're talking about
339 2014-03-21 12:42:49 <Luke-Jr> eh, HD wallet refers to a particular method of generating keypairs, not this :P
340 2014-03-21 12:45:11 <aschildbach> yes, generating keys (and thus addresses) with the prime usecase of never using an address twice
341 2014-03-21 12:45:31 <aschildbach> its not rotating any addresses however
342 2014-03-21 12:49:52 <wumpus> doxygen docs now include call graphs and caller graphs in svg format: https://dev.visucore.com/bitcoin/doxygen/
343 2014-03-21 12:51:24 <BTC-3> hi....
344 2014-03-21 12:51:44 <BTC-3> any gui dev's around ? :-)
345 2014-03-21 12:52:09 <BTC-3> got a little "bug" with the win core client gui
346 2014-03-21 12:53:42 <BTC-3> if I mark a outgoing transaction (with red amount number) the the Tranaction tab/ table it get blue => OK ..
347 2014-03-21 12:54:49 <wumpus> how is that a bug?
348 2014-03-21 12:55:10 <BTC-3> if I now loose focus to an other Application the blue bachground get's back to normal, but the amount ( eg -10) in now colored back .. even it it negative
349 2014-03-21 12:55:29 <BTC-3> is this a "feature"? ... or a bug ? :-)
350 2014-03-21 12:55:44 <wumpus> neither, really
351 2014-03-21 12:56:18 <wumpus> the focus color overrides any other colors in a row
352 2014-03-21 12:56:44 <wumpus> that's just how qt works by default, it's more a matter of taste than anything
353 2014-03-21 12:57:13 <optimator_> i'm having a problem compiling 0.9 on centos. I've downloaded the latest openssl and compiled it with ecc suport, but i don't think the bitcoind build sees those libraries. any idea how to make the build see those libraries?
354 2014-03-21 12:58:06 <wumpus> try setting SSL_CFLAGS / SSL_LIBS
355 2014-03-21 12:58:30 <optimator_> i see that in the Makefile but I'm not sure how to use it. any references?
356 2014-03-21 12:58:32 <BTC-3> if the client looses fokus, you could not anymore see with line is maked
357 2014-03-21 12:58:41 <BTC-3> marked
358 2014-03-21 12:58:58 <BTC-3> at leat if you mark one with a grey background
359 2014-03-21 12:59:26 <BTC-3> if it is a incomming one, nothing is to see anymore about the seletion
360 2014-03-21 12:59:30 <wumpus> optimator_: ./configure SSL_CFLAGS="-I/path/to/includes" SSL_LIBS="-L/path/to/libraries"
361 2014-03-21 12:59:57 <BTC-3> if it is an outgoing one, it now has back in sted of read amount numbers ... ....
362 2014-03-21 13:00:09 <optimator_> wumpus:ty
363 2014-03-21 13:00:46 <BTC-3> only a little optical flaw .... but only if one of the gui dev's does matter it ;-)
364 2014-03-21 13:03:43 <wumpus> BTC-3: really the only way you're going to get something like this addressed is by fixing it yourself, we're way understaffed to worry about small glitches on specific OSes
365 2014-03-21 13:09:00 <BTC-3> wumpus: Thanks .... I'll have a look at the code ;-)
366 2014-03-21 13:10:54 <jgarzik> dammit github, stop sucking
367 2014-03-21 13:11:15 <arubi> I'm having timeouts too, if that's what you mean
368 2014-03-21 13:12:33 <wumpus> yep it's definitely unusable right now...
369 2014-03-21 13:13:03 <jgarzik> and here I was about to dive into userland NFS, with nfs-ganesha. Poop.
370 2014-03-21 13:13:21 <jgarzik> It would be fun to export each block or TX as a file in a filesystem.
371 2014-03-21 13:13:51 <wumpus> bitcoinfs
372 2014-03-21 13:14:17 <Imbue> lol
373 2014-03-21 13:14:38 <Imbue> btcfs; just to annoy those who use font where c ~= r
374 2014-03-21 13:14:56 <arubi> haha ;D
375 2014-03-21 13:14:58 <wumpus> as FUSE module?
376 2014-03-21 13:15:11 <jgarzik> no, as an NFS mount
377 2014-03-21 13:15:21 <jgarzik> <jgarzik> and here I was about to dive into userland NFS, with nfs-ganesha.
378 2014-03-21 13:15:31 <wumpus> I don't get it, why would you need NFS?
379 2014-03-21 13:15:55 <jgarzik> wumpus, it is functionally the same as FUSE, but works over a network, works in a distributed fashion, ...
380 2014-03-21 13:16:26 <jgarzik> isn't Linux specific...
381 2014-03-21 13:16:51 <wumpus> it's also distributed if everyone mounts it locally :-)
382 2014-03-21 13:47:55 <wumpus> github is still under ddos attack: https://status.github.com/
383 2014-03-21 14:09:26 <diabl0z> hey jgarzik, how comes
384 2014-03-21 15:38:21 <etotheipi_> hey, do we have an "address" encoding for plain multi-sig transactions?
385 2014-03-21 15:41:17 <jgarzik> etotheipi_, <shrug> Just don't use them. There is even an active proposal to make bare multisig (non-P2SH) non-standard.
386 2014-03-21 15:41:37 <etotheipi_> jgarzik: why?
387 2014-03-21 15:41:44 <etotheipi_> that's crazy talk
388 2014-03-21 15:41:52 <jgarzik> etotheipi_, 99% of current uses are data storage, not actual multisigi
389 2014-03-21 15:42:11 <etotheipi_> well, I'm not talking about current use cases... I'm talking about using multi-sig for what it was intended for
390 2014-03-21 15:42:34 <jgarzik> etotheipi_, P2SH multisig works for that
391 2014-03-21 15:42:35 <etotheipi_> escrow transactions and one-off multi-sig tx should not use P2SH
392 2014-03-21 15:42:40 <flammit> you can achieve the same effect by using the P2SH multisig
393 2014-03-21 15:42:59 <jgarzik> etotheipi_, sure they should
394 2014-03-21 15:43:21 <etotheipi_> of course I *could* use P2SH, but that complicates things and makes it fragile, since you are required to backup extra data to find your P2SH coins
395 2014-03-21 15:44:12 <jgarzik> etotheipi_, that logic leads to a loss of privacy and early pubkey reveal
396 2014-03-21 15:44:23 <etotheipi_> uh... that's my decision to make
397 2014-03-21 15:44:28 <etotheipi_> the keys will be revealed eventually
398 2014-03-21 15:44:35 <jgarzik> etotheipi_, yes
399 2014-03-21 15:44:49 <jgarzik> etotheipi_, at spend time, like today's pay-to-pubkey
400 2014-03-21 15:44:53 <etotheipi_> for linked wallets, P2SH is 100% the way to go
401 2014-03-21 15:45:38 <etotheipi_> for random/one-off transactions between parties for which I don't store the public keys or have no way to associate them with mine, I will use multi-sig for robustness
402 2014-03-21 15:45:59 <jgarzik> etotheipi_, the long term storage costs for bare multisig are higher, few use bare multisig for their intended purpose, and they are being actively abused.
403 2014-03-21 15:46:11 <jgarzik> etotheipi_, huge output in UTXO versus tiny one
404 2014-03-21 15:46:12 <etotheipi_> jgarzik: that doesn't mean they should be disallowed
405 2014-03-21 15:46:31 <etotheipi_> the same could've been said about Bitcoin itself with drug dealing
406 2014-03-21 15:46:33 <hearn> long term storage costs are lower
407 2014-03-21 15:46:48 <hearn> it's the _short term_ costs that are higher (utxo db)
408 2014-03-21 15:46:50 <etotheipi_> "well, it's only used for illegal activity right now, so the whole thing shoudl be banned"
409 2014-03-21 15:47:06 <jgarzik> hearn, not true at all, when active utxo db is included, which is clearly is as an integral part of the system.
410 2014-03-21 15:47:31 <jgarzik> etotheipi_, That's fine. Rare miners that like data spam can leave the option on.
411 2014-03-21 15:47:33 <etotheipi_> of course I know the long-term storage costs are lower, and I expect that most multi-sig transactions in the future will use P2SH
412 2014-03-21 15:47:33 <hearn> assuming the outputs get spent at some point, long term storage is higher with p2sh as there's more redundancy, obviously
413 2014-03-21 15:47:43 <jgarzik> etotheipi_, The rest will turn it off: https://github.com/jgarzik/bitcoin/tree/bare-multisig
414 2014-03-21 15:47:49 <hearn> etotheipi_: no .... the long term storage of p2sh transactions are HIGHER
415 2014-03-21 15:47:50 <etotheipi_> but there *are* use cases for bare multisig
416 2014-03-21 15:47:58 <jgarzik> hearn, provably false, sorry
417 2014-03-21 15:48:00 <hearn> because you store a hash of the program, the program itself and the inputs to the program
418 2014-03-21 15:48:07 <etotheipi_> dependes whether you are storing the whole blockchain or not
419 2014-03-21 15:48:11 <etotheipi_> or pruning
420 2014-03-21 15:48:17 <etotheipi_> if you're pruning, obvioulsy P2SH is better
421 2014-03-21 15:48:22 <jgarzik> precisely
422 2014-03-21 15:49:03 <hearn> if you're deleting old blocks then long term storage costs are costs you choose not to pay. doesn't mean they don't exist, however
423 2014-03-21 15:49:49 <hearn> if the best thing people have to do is break existing, working code by forcing P2SH rather than doing something actually useful, like implementing a real anti-DoS framework, then bitcoin is truly doomed
424 2014-03-21 15:49:54 <hearn> priorities, people!
425 2014-03-21 15:50:32 <jgarzik> hearn, please tell me another way to prevent the ongoing data spam DoS
426 2014-03-21 15:51:01 <etotheipi_> jgarzik: banning multi-sig doesn't solve the problem, it makes it *harder*
427 2014-03-21 15:51:05 <hearn> "data spam" is not a DoS, sorry. it's not intended to deny anyone service. now you sound like luke :)
428 2014-03-21 15:51:08 <etotheipi_> err.. it makes it harder to spam
429 2014-03-21 15:51:15 <jgarzik> etotheipi_, precisely
430 2014-03-21 15:51:16 <etotheipi_> but it doesn't go away
431 2014-03-21 15:51:35 <jgarzik> etotheipi_, spam itself never goes away. You can only make it more costly and difficult for the spammer.
432 2014-03-21 15:51:38 <etotheipi_> so you destroy a use case of the network to reduce one dimension of spamming that spammers will work around anyway
433 2014-03-21 15:51:53 <hearn> jgarzik: if you're worried about data spam then let's make progress on pruning rather than adding payment channels to bitcore ;)
434 2014-03-21 15:52:32 <jgarzik> hearn, This is clearly low-hanging fruit, and the code is already written.
435 2014-03-21 15:52:43 <dexX7> <jgarzik> ... There is even an active proposal to make bare multisig (non-P2SH) non-standard. < can you point me to there?
436 2014-03-21 15:52:57 <jgarzik> dexX7, scroll back
437 2014-03-21 15:53:09 <etotheipi_> it doesn't change the fact that bare multi-sig is currently useful and standard... do we have a standardized encoding for it?
438 2014-03-21 15:53:09 <hearn> yes, obviously deleting features is always lower hanging fruit than fixing them
439 2014-03-21 15:53:12 <hearn> that's not an argument
440 2014-03-21 15:53:22 <gavinandresen> etotheipi_: what is your use case for bare multisig?
441 2014-03-21 15:53:39 <gavinandresen> etotheipi_: and no, we don't have a standard encoding for it.
442 2014-03-21 15:53:59 <etotheipi_> gavinandresen: one-off multi-signature transactions, say for escrow with partially unknown/untrusted parties
443 2014-03-21 15:54:11 <etotheipi_> I don't want to have to make persistent backups of my wallet meta-data just to find that tx later
444 2014-03-21 15:54:29 <hearn> "OMG resource usage, let's delete the feature" has been the approach for years. there's no end in sight. people prefer to play with cool toys rather than implement the real fixes, which are always pushed off to another day. forcing people to get it right is perhaps one reason to keep such features around :)
445 2014-03-21 15:54:34 <dexX7> ^
446 2014-03-21 15:54:43 <jgarzik> hearn, hyperbole much?
447 2014-03-21 15:54:48 <jgarzik> hearn, did you even read the code?
448 2014-03-21 15:55:09 <gavinandresen> etotheipi_: but⦠but⦠having a raw multisig that says "you were involved in an escrow. Have no idea who the other parties were, but you were involved in an escrow!" doesn't seem particularly user-friendly to me.
449 2014-03-21 15:55:36 <etotheipi_> I shouldnt' say "unknown/untrusted", but if I don't have all the public keys in my wallet and/or a way to know they were used together, I should have the ability to skip P2SH
450 2014-03-21 15:55:43 <gavinandresen> I suppose I might be able to remember "oh, yeah, that escrow from last February that I put 11 BTC into, I remember that was with Tom somebody...."
451 2014-03-21 15:55:50 <etotheipi_> gavinandresen: user-friendly is not relevant here
452 2014-03-21 15:55:56 <etotheipi_> this is low-level stuff
453 2014-03-21 15:56:08 <hearn> what is the goal here anyway? it can't be the sigops thing because sigops only matter when a tx is spent
454 2014-03-21 15:56:11 <gavinandresen> that's why I asked for a high-level use case
455 2014-03-21 15:56:15 <hearn> and obviously p2sh doesn't change the cost of spending the tx (well, it increases it)
456 2014-03-21 15:57:17 <jgarzik> Giving miners an option -- default off -- to avoid data spam seems perfectly reasonable to me.
457 2014-03-21 15:57:20 <etotheipi_> gavinandresen: perhaps I want to build a system that faciliatates certain types of multi-sig escrow transactions (in a user-friendly way)... but I now have extra backup requirements to deal with if I can't use multi-sig
458 2014-03-21 15:57:40 <gavinandresen> etotheipi_: my point is you have extra backup requirements in any case
459 2014-03-21 15:58:01 <gavinandresen> ⦠because knowing just "my public key is involved" won't be enough information to get the coins out of escrow
460 2014-03-21 15:58:14 <sipa> etotheipi_: no
461 2014-03-21 15:58:17 <etotheipi_> forcing P2SH complicates all that
462 2014-03-21 15:58:39 <gavinandresen> etotheipi_: we don't see how. You need to record information about the escrowâ¦.
463 2014-03-21 15:59:06 <dexX7> jgarzik: just catching up the discussion in the xcp thread etc.. - abusing multisig outputs to encode data doesn't create many unspent outputs, if spent?
464 2014-03-21 15:59:31 <hearn> people have already come up with protocols that can make use of being able to match what outputs contain (e.g. the bonds thing i proposed years ago). they will undoubtably come up with protocols that want to spot transactions without caring about all the data chunks involved in future too
465 2014-03-21 15:59:46 <hearn> what's the rationale for adding yet more restrictions?
466 2014-03-21 16:00:24 <etotheipi_> so it's worth disabling a part of the network capability on a hunch that no one will find this useful?
467 2014-03-21 16:00:46 <gavinandresen> for the record: I think we should keep raw multisig. I don't think we should have a standard address format / encoding for it
468 2014-03-21 16:01:57 <sipa> if i would build bitcoin today, it would certainly be p2sh only
469 2014-03-21 16:02:03 <jgarzik> +1
470 2014-03-21 16:02:16 <gavinandresen> mmm⦠me too....
471 2014-03-21 16:02:17 <sipa> so much simpler to let sending code only deal with one type of destinatioms
472 2014-03-21 16:02:29 <jgarzik> dexX7, the answer to that is conditional -- is it spent to another multisig output? if yes, then the cost to UTXO is unchanged.
473 2014-03-21 16:02:31 <sipa> and let receivers deal with what they want to deal with
474 2014-03-21 16:02:51 <sipa> it also guarantees being able go infer prevout address from a signature
475 2014-03-21 16:02:56 <hearn> sipa: but that can already be done. just have the recipient tell the sender what script they want;
476 2014-03-21 16:03:09 <hearn> recall the original justification for p2sh: addresses longer than N characters would be annoying for people
477 2014-03-21 16:03:22 <sipa> hearn: part of it is how we've dealt with it, agree
478 2014-03-21 16:03:35 <jgarzik> gavinandresen, That's why I wrote the patch the way I did -- "default off" but give users the ability to choose to disincentivize it themselves (or not).
479 2014-03-21 16:03:39 <hearn> i mean, why does bitcoin support <pubkey> CHECKSIG? because satoshi originally envisioned addresses only being used as a backup
480 2014-03-21 16:03:39 <sipa> hearn: but for various reasons, imho, p2sh only would be far simpler
481 2014-03-21 16:03:50 <hearn> and a payment protocol being used for the rest
482 2014-03-21 16:03:58 <hearn> which is where we're heading .......
483 2014-03-21 16:04:05 <sipa> hearn: short address is not an important reason to want p2sh for me
484 2014-03-21 16:04:06 <dexX7> no one ever wants to send coins into limbo, so they are spent at some point. rather than shutting down this feature, it may be a better solution to provide tools to spend multisig outputs.
485 2014-03-21 16:04:24 <hearn> so now the justification is changing to be shaving some bytes off the utxo db, which is certainly useful, but it comes at a cost of extra long term storage for anyone who holds the chain and fewer blocks fitting into the disk space nodes do allocate
486 2014-03-21 16:04:30 <sipa> dexX7: you need to backup private keys; backing up scripts is not harder
487 2014-03-21 16:04:45 <hearn> it's unclear to me that this is really better. at least, the costs involved are very murky and nobody really did some convincing mathematical analysis to show that shifting bytes around like that is a win
488 2014-03-21 16:04:55 <etotheipi_> look, I know what you're saying... but there's clearly a functional difference between raw multi-sig and P2SH, and I don't think it should need much justification to keep it
489 2014-03-21 16:05:07 <sipa> hearn: the storage cost of the blockchain are much lower per byte than the utxo set
490 2014-03-21 16:05:09 <etotheipi_> even though I don't have a great high-level use case, doesn't mean there' won't be
491 2014-03-21 16:05:15 <jgarzik> There is clearly an active, ongoing difference in use
492 2014-03-21 16:05:30 <sipa> etotheipi_: oh, i'm not argueing for removing bare multisig
493 2014-03-21 16:05:31 <jgarzik> RE this theoretical multisig people are describing, and the actual data storage by projects
494 2014-03-21 16:05:33 <etotheipi_> the argument against it seems to be that it enables spam... I'm sorry but ther'es going to be spam
495 2014-03-21 16:05:42 <jgarzik> etotheipi_, it /easily/ enables spam
496 2014-03-21 16:05:47 <hearn> sipa: sure? under what assumptions?
497 2014-03-21 16:06:08 <jgarzik> etotheipi_, engineering is never a binary decision, but a gauge of cost versus benefit.
498 2014-03-21 16:06:20 <etotheipi_> jgarzik: so you're saying that if someone wants to dump a bunch of data into the blockchain, that they won't find a way to do it if we disable multisig
499 2014-03-21 16:06:20 <sipa> hearn: having it indexed, fast acceasible, cached, low latency updatable
500 2014-03-21 16:06:23 <etotheipi_> ?
501 2014-03-21 16:06:42 <jgarzik> etotheipi_, it will be harder and more costly
502 2014-03-21 16:06:46 <etotheipi_> I thought we did the OP_RETURN thing to give people a channel to do that
503 2014-03-21 16:06:59 <jgarzik> etotheipi_, ...which is not stored in UTXO...
504 2014-03-21 16:07:02 <Imbue> etotheipi_: OP_RETURN is prunable
505 2014-03-21 16:07:04 <sipa> etotheipi_: NO NO NO
506 2014-03-21 16:07:15 <etotheipi_> sipa: I know
507 2014-03-21 16:07:26 <etotheipi_> I didn't mean that we're encouraging it
508 2014-03-21 16:07:26 <sipa> etotheipi_: op return is to avoid them using the much worse chanel of stuffing it into unprunable bare multisigs
509 2014-03-21 16:07:28 <hearn> sipa: but you only pay those costs until the utxo is deleted. and larger blocks have to be loaded into RAM and Bloom filtered, or served to other full nodes
510 2014-03-21 16:07:41 <hearn> meanwhile, leveldb is pretty efficient. eventually each entry compacts down to just one entry on disk
511 2014-03-21 16:07:51 <sipa> etotheipi_: it's like giving drug addicts a clean needle
512 2014-03-21 16:08:00 <Imbue> hah
513 2014-03-21 16:08:02 <jgarzik> sipa, heh, indeed, a fair analogy
514 2014-03-21 16:08:09 <etotheipi_> sipa: I know, I read all the discussions, I didn't mean to suggest it was encouraged
515 2014-03-21 16:08:24 <etotheipi_> or to use an inappropriate luke-jr analogy ... like making rapists wear condoms
516 2014-03-21 16:08:25 <hearn> oh come on. there are actual use cases for this stuff. look at the wiki on the p2p bond network
517 2014-03-21 16:08:40 <hearn> i've come up with protocols that could use OP_RETURN and which are actual decentralised finance
518 2014-03-21 16:08:44 <sipa> hearn: agree, but i doubt that's what it will end up being used for
519 2014-03-21 16:09:24 <sipa> hearn: also agree that utxo costs are temporeary instead of permanent, but imho the per-time costs are much much higher
520 2014-03-21 16:09:27 <dexX7> from a multisig-data-abuser perspective: what would the change imply? that data is rather stored in the scriptsig than output?
521 2014-03-21 16:09:29 <hearn> we can't predict that. part of the reason people like bitcoin is the uncontrollable innovation aspect of it
522 2014-03-21 16:09:37 <etotheipi_> my point is... if someone is intent to dump data on the blockchain, you think that disabling bare multi-sig is going to prevent it?
523 2014-03-21 16:09:39 <jgarzik> As a result, the code demonstrates an IMO reasonable position: give users the tool to disincentivize bare multisig, defaulted to off. Miners have already requested this.
524 2014-03-21 16:09:44 <jgarzik> dexX7, correct
525 2014-03-21 16:10:00 <jgarzik> dexX7, and as a result, not in UTXO database
526 2014-03-21 16:10:12 <sipa> hearn: and long term, costs drop because of moore's law, so the short term matters more
527 2014-03-21 16:10:20 <gavinandresen> jgarzik: I haven't looked at the code, does it make redeeming a bar multisig also non-standard? (shouldn't, if it does....)
528 2014-03-21 16:10:39 <dexX7> well, then "nothing changes" but the parsing and tx construction. sounds acceptable.
529 2014-03-21 16:10:41 <jgarzik> gavinandresen, it shouldn't, but I will test that before PR'ing
530 2014-03-21 16:10:49 <hearn> i'm really not a fan of removing every feature we can't immediately find a cool implementation using it for, just in case it gets "abused" (by our definition). we should find ways to let people control their own costs and so on. ok, so i admit i didn't read jgarzik's code, was just reacting to "let's scrap bare multisig", a default-off switch doesn't sound so bad
531 2014-03-21 16:11:08 <etotheipi_> so "active proposals to make bare multi-sig non-standard"... is that actively being considered?
532 2014-03-21 16:11:15 <jouke> Does it also make it not standard?
533 2014-03-21 16:11:17 <hearn> sipa: why would moore's law not affect utxo storage costs as well? btw i often wonder if we can't seriously beat LevelDB with an SSD-optimised store
534 2014-03-21 16:11:28 <dexX7> but i don't really like the additude of "we don't like this or that use-case"
535 2014-03-21 16:11:29 <jgarzik> etotheipi_, my patch adds a switch to make bare multisig non-standard. default off.
536 2014-03-21 16:11:30 <hearn> sipa: given that LDB is so heavily optimised for rotating platters (offtopic side note)
537 2014-03-21 16:11:34 <sipa> hearn: it does affect utxo storage equally
538 2014-03-21 16:11:59 <sipa> hearn: but utxo costs are temporary, blockchaim is permanent
539 2014-03-21 16:12:11 <etotheipi_> +1 "<hearn> i'm really not a fan of removing every feature we can't immediately find a cool implementation using it for, just in case it gets "abused""