1 2013-09-12 00:00:52 <cfields> git push repo tag
2 2013-09-12 00:02:12 <warren> oh
3 2013-09-12 00:03:53 <warren> cfields: a while back you gave me advice on how to always order linking such that it doesn't matter if it is a static or dynamic link
4 2013-09-12 00:04:07 <warren> cfields: what was that again? I'm actually at a point where I'm using that knowledge now.
5 2013-09-12 00:15:43 <cfields> warren: great explanation here: http://webpages.charter.net/ppluzhnikov/linker.html
6 2013-09-12 00:20:06 <cfields> tl;dr is most->least dependent
7 2013-09-12 00:21:08 <cfields> though for the most part, build tools like libtool/pkg-config should be handling that for you
8 2013-09-12 00:33:39 <theboos> is there an idempotent alternative to the rpc "move" command? I'd be assuaged if it returned some sort of hash of the results so I could check whether the move had taken place already
9 2013-09-12 00:34:04 <sipa> there's no such thing, no
10 2013-09-12 00:34:17 <sipa> it just adds a move entry
11 2013-09-12 00:34:56 <theboos> is a move guaranteed to succeed?
12 2013-09-12 00:34:57 <phantomcircuit> theboos, the bitcoind accounts functionality should not be used for any serious accounting
13 2013-09-12 00:35:13 <phantomcircuit> it's effectively impossible to have a correct backup
14 2013-09-12 00:35:49 <jgarzik> w00t
15 2013-09-12 00:36:02 <jgarzik> that inline assembly sure was easy. register-based data storage, here we come.
16 2013-09-12 00:36:20 <sipa> theboos: how do you mean, guaranteed to succeed?
17 2013-09-12 00:36:26 <theboos> ok thanks. I guess I got the impression that the account functionality was recommended as a replacement
18 2013-09-12 00:36:35 <sipa> replacement for what?
19 2013-09-12 00:36:41 <phantomcircuit> jgarzik, linux kernel question, say i wanted to turn discard ops from the filesystem into null sector writes, how/where would i do that?
20 2013-09-12 00:36:53 <phantomcircuit> (stupid virtualization platforms dont support TRIM)
21 2013-09-12 00:37:15 <sipa> theboos: it's guaranteed to succeed, assuming no crashes or database write errors
22 2013-09-12 00:37:20 <jgarzik> phantomcircuit, block layer
23 2013-09-12 00:37:28 <theboos> a replacement for more abstract solutions like keeping track of accounts in software that calls the bitcoin rpc api
24 2013-09-12 00:37:29 <jgarzik> phantomcircuit, or a tiny Device Mapper shim layer
25 2013-09-12 00:37:33 <jgarzik> "DM"
26 2013-09-12 00:37:40 <jgarzik> *poof* baby bedtime, bbiah
27 2013-09-12 00:37:47 <phantomcircuit> hmm maybe a tiny device mapper would be better
28 2013-09-12 00:37:55 <phantomcircuit> dont really want to be rebuilding the debian kernel
29 2013-09-12 00:37:55 <sipa> theboos: it works for one particular type of problem, and indeed you can't do decent backups
30 2013-09-12 00:38:04 <phantomcircuit> jgarzik, thanks
31 2013-09-12 00:38:14 <sipa> i wouldn't recomment it in general
32 2013-09-12 00:38:18 <theboos> the data is not stored in the wallet.dat folder then?
33 2013-09-12 00:38:21 <theboos> file*
34 2013-09-12 00:38:23 <sipa> it is
35 2013-09-12 00:38:34 <sipa> but you basically need a backup after every operation
36 2013-09-12 00:39:18 <phantomcircuit> theboos, the bitcoind wallet is good at keeping track of keys and transactions involving those keys
37 2013-09-12 00:39:20 <gavinandresen> theboos : if you have a small number of "accounts" to keep track of, and they are all your own, and you're running on reliable hardware (e.g. maybe a RAID array of disks) then bitcoind's accounts might be a good idea.
38 2013-09-12 00:39:24 <phantomcircuit> it's not a very good accounting system
39 2013-09-12 00:39:34 <gavinandresen> Don't use it to keep track of other people's money.
40 2013-09-12 00:40:16 <phantomcircuit> theboos, i guess the way to think of it is, if all the accounting information disappeared, would that be a real problem
41 2013-09-12 00:40:21 <phantomcircuit> if the answer is no then yeah why not
42 2013-09-12 00:40:29 <theboos> ok - maybe we should change the wiki page that says "makes it easy to create web services that maintain a separate bitcoin balance for each customer" :P
43 2013-09-12 00:40:33 <gavinandresen> In general, my advice would be: unless you have previous experience keeping track of other people's money, don't use bitcoin as your first experience doing that.
44 2013-09-12 00:40:41 <phantomcircuit> theboos, link?
45 2013-09-12 00:40:54 <theboos> on my other pc - it's the wiki page titled Accounts Explained
46 2013-09-12 00:41:51 <phantomcircuit> gavinandresen, lol
47 2013-09-12 00:41:54 <phantomcircuit> https://en.bitcoin.it/w/index.php?title=Accounts_explained&diff=1183&oldid=628
48 2013-09-12 00:42:01 <phantomcircuit> fix your mess :)
49 2013-09-12 00:42:17 <phantomcircuit> (iirc my wiki account isn't whitelisted or whatever it is)
50 2013-09-12 00:42:23 <theboos> hehe
51 2013-09-12 00:42:27 <sipa> phantomcircuit: you need to pay a fee
52 2013-09-12 00:42:34 <sipa> anti-spam measure or something
53 2013-09-12 00:42:36 <phantomcircuit> sipa, i know
54 2013-09-12 00:42:37 <sipa> ok
55 2013-09-12 00:42:43 <phantomcircuit> sipa, i was part of the decision to do that
56 2013-09-12 00:42:51 <phantomcircuit> and then didn't ever bother to pay it
57 2013-09-12 00:43:54 <gavinandresen> phantomcircuit: Mmm. I'm older and wiser now.
58 2013-09-12 00:44:40 <phantomcircuit> gavinandresen, it took trying to fix a messed up britcoin wallet to understand that the accounts feature didn't really work for that
59 2013-09-12 00:44:58 <gavinandresen> Mmm. we're all older and wiser now....
60 2013-09-12 00:45:04 <phantomcircuit> essentially restore from backup -> wrong people getting coins
61 2013-09-12 00:45:08 <phantomcircuit> "wat"
62 2013-09-12 00:52:15 <nanotube> <gavinandresen> Mmm. we're all older and wiser now.... <- speak for yourself. i'm just older. :P
63 2013-09-12 00:53:26 <gavinandresen> I do sometimes wonder if I'm getting stupider yet; I should dig out that graph of cognitive ability versus age, but my stupid brain doesn't remember where I saw it.
64 2013-09-12 00:53:40 <sipa> QED.
65 2013-09-12 01:07:11 <gavinandresen> phantomcircuit: edited https://en.bitcoin.it/wiki/Accounts_explained
66 2013-09-12 01:18:15 <warren> sipa: one more gitian patch to push to you
67 2013-09-12 01:24:16 <nanotube> hehe
68 2013-09-12 01:29:36 <sipa> cfields: present?
69 2013-09-12 01:30:09 <cfields> yes
70 2013-09-12 01:30:57 <sipa> cfields: to deal with libsecp256k1 for now, to integrate it with bitcoin's makesystem, just ~mimic the leveldb stuff?
71 2013-09-12 01:31:15 <cfields> yep
72 2013-09-12 01:31:27 <sipa> bah :)
73 2013-09-12 01:31:33 <cfields> sipa: for your own hacking, or for potential integration?
74 2013-09-12 01:31:38 <sipa> cfields: my own hacking
75 2013-09-12 01:32:27 <cfields> then yes, i'd say so.
76 2013-09-12 01:32:38 <cfields> i forget, does it have a make? or just a shell script for now?
77 2013-09-12 01:34:32 <sipa> a config script that generates a config file, which is then included in the makefile
78 2013-09-12 01:40:22 <cfields> sipa: can you point me to the script?
79 2013-09-12 01:42:22 <sipa> https://github.com/sipa/secp256k1/blob/master/configure
80 2013-09-12 01:43:43 <cfields> sipa: i could integrate that pretty quickly if that's your ultimate goal
81 2013-09-12 01:44:27 <cfields> it could build as an island, like leveldb does, so that it could be split out if desired
82 2013-09-12 01:46:37 <sipa> cfields: if you have time for that, by all means
83 2013-09-12 01:46:51 <sipa> but there's no intent to get this into bitcoin anytime soon
84 2013-09-12 01:46:56 <sipa> at least not upstream
85 2013-09-12 01:51:34 <cfields> sipa: ok. it will be a while then, time is short atm
86 2013-09-12 02:04:00 <warren> sipa: pushed
87 2013-09-12 02:11:55 <sipa> warren: i'm first rebasing it onto bitcoin master
88 2013-09-12 02:27:23 <sipa> cfields: where would i add -lgmp?
89 2013-09-12 02:39:00 <cfields> sipa: quick example: http://pastebin.com/raw.php?i=qkF3Kn5Z
90 2013-09-12 02:40:49 <jgarzik> w00t
91 2013-09-12 02:41:10 <jgarzik> key storage-in-registers working for mmx and sse2
92 2013-09-12 02:41:24 <jgarzik> now to look at other ABIs, and see if they have registers typically untouched by compilers
93 2013-09-12 02:41:57 <jgarzik> ACTION 's recall of ABI details is rusty 10 year old knowledge at this point
94 2013-09-12 02:48:48 <gavinandresen> I just pushed a 0.8.5 candidate branch to github: https://github.com/bitcoin/bitcoin/commits/0.8.5
95 2013-09-12 02:49:22 <gavinandresen> Backported two cherry-picks (sipa's fix for the height-in-the-coinbase code, and gmaxwell's workaround for the negative transaction.version problem)
96 2013-09-12 02:57:11 <tiberiusiv> gavinandresen: how many more fuckups can we expect?
97 2013-09-12 02:57:54 <gavinandresen> tiberiusiv: the usual number.
98 2013-09-12 02:58:13 <tiberiusiv> maybe time to pass the torch to more professional crowd?
99 2013-09-12 02:58:23 <gavinandresen> tiberiusiv: if you're looking for bug-free software, then ⦠umm ...
100 2013-09-12 02:59:13 <gavinandresen> tiberiusiv: sure, be my guest. Go find somebody Professional who writes bug-free code to take on bitcoin, like Microsoft or Adobe orâ¦. ummmâ¦.
101 2013-09-12 03:00:05 <TheLordOfTime> ;;op
102 2013-09-12 03:02:36 <TheLordOfTime> gavinandresen (and everyone here) I apologize, he's been ranting about bugs in the software, and been doing so in a manner which has gotten him silenced in pretty much every channel that matters, I guess I forgot he wasn't banned from here... :/
103 2013-09-12 03:02:42 <TheLordOfTime> sorry for subjecting you all to his crap.
104 2013-09-12 03:02:57 <TheLordOfTime> ACTION goes back to the sniper perch.
105 2013-09-12 03:07:12 <warren> sipa: please be sure -lgmp can be either static or dynamic along with boost, bdb, etc.
106 2013-09-12 03:08:49 <Luke-Jr> gavinandresen: that git fix should probably go in too
107 2013-09-12 03:09:06 <gavinandresen> what git fix
108 2013-09-12 03:11:07 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/2808
109 2013-09-12 03:11:10 <Luke-Jr> weird, I thought it was in master already
110 2013-09-12 03:11:21 <Luke-Jr> although now it won't be mergable at all probably
111 2013-09-12 03:11:26 <Luke-Jr> (to master/autoconf)
112 2013-09-12 03:12:40 <cfields> gavinandresen: mist clientversion.h ?
113 2013-09-12 03:12:45 <cfields> *missed. heh
114 2013-09-12 03:13:57 <cfields> Luke-Jr: a different version of that went into master with autotools
115 2013-09-12 03:14:21 <Luke-Jr> cfields: right, but 0.8.5 doesn't benefit from that
116 2013-09-12 03:14:44 <cfields> <Luke-Jr> although now it won't be mergable at all probably
117 2013-09-12 03:14:44 <cfields> <Luke-Jr> (to master/autoconf)
118 2013-09-12 03:14:47 <cfields> was responding to that
119 2013-09-12 03:27:01 <gavinandresen> Luke-Jr: that isn't a critical bugfix, NACK on including it in 0.8.5
120 2013-09-12 03:28:00 <Luke-Jr> gavinandresen: ok, though I'm not sure any of 0.8.5 is very critical either with that definition O.o
121 2013-09-12 03:28:26 <Luke-Jr> (best case, it causes source builds to report the wrong version; worst case, it causes a security violation)
122 2013-09-12 03:28:31 <warren> Luke-Jr: allow clients to start without a corrupted db error is not critical?
123 2013-09-12 03:28:38 <Luke-Jr> (the bug being fixed with the git PR)
124 2013-09-12 03:28:54 <Luke-Jr> warren: there is a simple workaround, and it's temporary
125 2013-09-12 03:29:33 <gavinandresen> sigh. Luke, you're being unnecessarily annoying again.
126 2013-09-12 03:29:39 <Luke-Jr> as long as miners are running with the non-standard patch, it shouldn't affect 0.8.0-0.8.4 soon (if it still does at all)
127 2013-09-12 03:30:11 <warren> Luke-Jr: you are overly optimistic, especially for the thousands of p2pool nodes
128 2013-09-12 03:30:21 <gavinandresen> what warren said.
129 2013-09-12 03:30:32 <Luke-Jr> gavinandresen: sorry, just trying to provide additional information - I started my reply with "ok" to express my acceptance of your decision regardless, but thought that other info might be relevant
130 2013-09-12 03:31:35 <cfields> gavinandresen: just-in-case ping. You saw my comment about clientversion.h bump?
131 2013-09-12 03:32:11 <gavinandresen> cfields: nope, missed it.
132 2013-09-12 03:32:51 <gavinandresen> I forgot to update clientversion.h?
133 2013-09-12 03:33:05 <cfields> gavinandresen: seems that way
134 2013-09-12 03:33:18 <gavinandresen> yup, sure did⦠that's why I don't tag immediately....
135 2013-09-12 03:33:19 <warren> gavinandresen: was a CVE assigned to the negative tx version issue?
136 2013-09-12 03:33:45 <gavinandresen> warren: no. Does it warrant one? Not a vulnerability per-se
137 2013-09-12 03:33:55 <warren> gavinandresen: it's sort of a DoS, kinda
138 2013-09-12 03:34:00 <gavinandresen> ⦠just a bug. And I don't think we need a CVE number for every bug
139 2013-09-12 03:34:31 <warren> ok
140 2013-09-12 03:35:54 <gavinandresen> Bumped clientversion.h: + 7b5d1d7...ef14a26 0.8.5 -> 0.8.5 (forced update)
141 2013-09-12 03:37:40 <warren> looks good
142 2013-09-12 03:37:43 <cfields> thanks
143 2013-09-12 03:43:00 <cfields> er, heh, thanks for bumping. i wasn't taking credit for the release :p
144 2013-09-12 03:50:44 <road33> anyone have a recomended way to get a private key on both android's main app, bitcoin-wallet to something like multibit? Google is not helping
145 2013-09-12 03:51:16 <TheLordOfTime> road33, i think the first part you have to figure out is whether you can actually *get* the privkeys out of the android wallet
146 2013-09-12 03:51:25 <TheLordOfTime> only person who would know for certain is the developer of the app
147 2013-09-12 03:51:31 <Luke-Jr> road33: not even Google can solve a problem with no (current) solution
148 2013-09-12 03:52:02 <Luke-Jr> road33: and really, it's the wallet you want to export/share, not the address
149 2013-09-12 03:52:05 <road33> the app will backup an encrypted key, but its not able to go into multibit from what i can tell
150 2013-09-12 03:52:30 <road33> agree but wallet=priv key me thinks?
151 2013-09-12 03:52:34 <doublec> I've imported keys from the android app into bitcoind
152 2013-09-12 03:52:46 <doublec> is that what you want to do?
153 2013-09-12 03:52:47 <Luke-Jr> road33: in a sense; but the wallet is always changing
154 2013-09-12 03:53:14 <Luke-Jr> road33: so you can't just copy it once, you'd have to constantly copy back and forth
155 2013-09-12 03:53:16 <road33> Luke-Jr: sorry thats from blockchain, as I understand it, basically, I want the balance on my PC, and android when I am on the road
156 2013-09-12 03:53:32 <road33> both clients update indipendantly
157 2013-09-12 03:53:44 <road33> and I can accept and send payment from either place
158 2013-09-12 03:53:55 <Luke-Jr> road33: that isn't possible today
159 2013-09-12 03:54:12 <road33> and most of all if I loose the phone I can still spend it, without purchasing another android phone
160 2013-09-12 03:54:13 <Luke-Jr> road33: there's some work on "HD wallets" which can support sharing them, but it's not complete yet
161 2013-09-12 03:54:48 <road33> the android app will not export an unencrptyed key, which makes sense to me as the phone is less secure than a pc
162 2013-09-12 03:56:00 <Luke-Jr> road33: trying to do this without HD wallets, you will *probably* end up losing money
163 2013-09-12 03:56:01 <road33> doublec: bitcoind could work, but rather have something like multibit
164 2013-09-12 03:56:17 <Luke-Jr> I think Multibit is further along with HD wallets than bitcoind
165 2013-09-12 03:58:24 <road33> this sounds overly complicated, HD wallets, it has its usages and its smart, but at the end of the day this is a private key, can't i just get that decrypted somehow, and import it?
166 2013-09-12 03:59:16 <road33> then each client updates their wallets indipendalty, i just want a small spending account, and move btc to it from time to time.
167 2013-09-12 03:59:20 <doublec> road33: this is what I did iirc http://gary-rowe.com/agilestack/2011/12/28/how-to-recover-lost-bitcoins-from-an-android-wallet/
168 2013-09-12 03:59:24 <road33> can you export from bitcoind to multibit
169 2013-09-12 03:59:26 <Luke-Jr> road33: a regular wallet is not "just a private key" - it's a collection of private keys; and sharing just a single one is generally useless
170 2013-09-12 03:59:44 <doublec> my case was the android wallet for some reason wasn't picking up transactions involving the address so I imported into bitcoind to recover funds
171 2013-09-12 04:00:16 <doublec> road33: it won't help your usecase though since multibit/bitcoind behave differently in the way it uses addresses than the android wallet
172 2013-09-12 04:00:25 <road33> doublec: but that was just a reported balance on the app, the balance is correct in the blockchain, correct?
173 2013-09-12 04:00:40 <Luke-Jr> road33: the blockchain doesn't have balances..
174 2013-09-12 04:00:40 <road33> doublec: reading your link
175 2013-09-12 04:00:41 <doublec> iirc the android wallet always sends change to the same address - not so with other clients.
176 2013-09-12 04:00:57 <Luke-Jr> doublec: that's a bug
177 2013-09-12 04:12:07 <Luke-Jr> gavinandresen: will you be tagging rc1 in the next hour or so? (should I wait up for it?)
178 2013-09-12 04:12:26 <road33> no dice, I guess I can get adb out, and try to decode base58
179 2013-09-12 04:19:30 <gavinandresen> Luke-Jr: I want to wait for ACKS from gmaxwell and maybe sipa
180 2013-09-12 04:19:34 <road33> ok got it to work, not sure the issues, maybe spaces in the filename
181 2013-09-12 04:20:47 <warren> gavinandresen: FWIW, we've been testing that patch in production on our 0.8.4.x
182 2013-09-12 04:21:33 <gavinandresen> warren: cool. Identical backported patch?
183 2013-09-12 04:21:57 <warren> gavinandresen: nearly identical, we have an earlier patch that displays the reason for tx rejection
184 2013-09-12 04:22:27 <gavinandresen> The "nearly" is why I want another core dev's eyeballs to look it over
185 2013-09-12 04:22:27 <warren> gavinandresen: https://github.com/litecoin-project/litecoin/commit/2a220540258487709b77eded1e82e3839cfd5aab
186 2013-09-12 04:22:46 <warren> yep
187 2013-09-12 05:18:47 <gmaxwell> gavinandresen: ack on content of 0.8.5
188 2013-09-12 05:20:06 <gavinandresen> gmaxwell: great
189 2013-09-12 05:22:47 <gavinandresen> I'll tag 0.8.5 as soon as I page swap out from what I'm in the middle of doing
190 2013-09-12 05:32:38 <gavinandresen> Pushed * [new tag] v0.8.5 -> v0.8.5
191 2013-09-12 05:34:37 <gavinandresen> cfields: ping
192 2013-09-12 05:38:29 <cfields> gavinandresen: pong
193 2013-09-12 05:38:47 <gavinandresen> So RE: building osx -arch i386 : how are Linux builds built?
194 2013-09-12 05:39:06 <gavinandresen> -arch i386 or -arch 64 or 'whatever you happen to be compiling on' ?
195 2013-09-12 05:41:09 <cfields> gavinandresen: if i understand your question, whatever compiler you're using
196 2013-09-12 05:41:48 <cfields> gavinandresen: i assume you're pointing out that linux builds suffer the same fate?
197 2013-09-12 05:42:20 <gavinandresen> Yes. Release builds must be tested, because they will ALWAYS be somewhat different than what developers are using
198 2013-09-12 05:42:30 <gavinandresen> That's why any non-trivial releases we go through a release candidate process
199 2013-09-12 05:42:59 <cfields> gavinandresen: i'll point out, however, that most linux users are probably more likely to go through their distro
200 2013-09-12 05:43:01 <gavinandresen> Asking volunteer open source developers to all use exactly the same toolchain⦠ain't gonna happen
201 2013-09-12 05:43:54 <cfields> gavinandresen: i'm not suggesting that they use the same toolchain, but it seems like a reasonable requirement to use the same arch/sdk
202 2013-09-12 05:44:27 <gavinandresen> cfields: it really isn't on OSX. Have you tried recompiling all of your macports with -arch i386 -mmacos_min_blahblah
203 2013-09-12 05:45:12 <nsh> gmaxwell (or anyone), if you were given a random string of 256 hex digits and told it was a clue from which you should be able to find a codeword
204 2013-09-12 05:45:20 <nsh> what steps would you take to try and solve it?
205 2013-09-12 05:45:32 <gmaxwell> nsh: I would ask in #bitcoin :P
206 2013-09-12 05:45:34 <cfields> gavinandresen: yes. headache, i agree. but There that is another can of worms itself
207 2013-09-12 05:45:43 <cfields> -There
208 2013-09-12 05:45:45 <nsh> sorry
209 2013-09-12 05:45:47 <gmaxwell> cfields: Whats the subject being discussed here?
210 2013-09-12 05:45:57 <gavinandresen> gmaxwell: https://github.com/bitcoin/bitcoin/pull/2988#issuecomment-24294869
211 2013-09-12 05:46:20 <gavinandresen> cfields: what can of worms?
212 2013-09-12 05:46:52 <cfields> gavinandresen: one being that macports right now does not look like macports last week
213 2013-09-12 05:47:19 <warren> hence the desire for gitian mac
214 2013-09-12 05:47:51 <gmaxwell> cfields: On the flipside, extra diversity where it is less important (away from the gitian deterministic builds) will sometimes make bugs that exist in all configurations more visibile.. this is a perk as well as a limitation.
215 2013-09-12 05:48:08 <cfields> gavinandresen: but that's a different discussion, i'd like to wrestle about that one another time :)
216 2013-09-12 05:48:17 <gmaxwell> cfields: I think your root concern there should be solved via a gitian-mac solution, and then let the regular builds be diverse.
217 2013-09-12 05:48:31 <gavinandresen> +1 gmaxwell
218 2013-09-12 05:48:35 <warren> +1
219 2013-09-12 05:48:41 <gmaxwell> (and the diversity of the regular builds addressed with better tests too!)
220 2013-09-12 05:48:49 <cfields> gmaxwell: that does not really address my main concern though
221 2013-09-12 05:48:59 <gavinandresen> Ideally, we have a release engineering team that gitian builds everything, reviews changes in dependencies, yada yada yada
222 2013-09-12 05:49:19 <cfields> my main concern is that users end up with a runtime configuration that devs have likely never seen
223 2013-09-12 05:49:24 <gavinandresen> cfields: what is your main concern? My main concern is making it so difficult for OSX developers that we have to drop OSX support completely.
224 2013-09-12 05:50:26 <gavinandresen> cfields: in three years we have had approximately zero problems caused by the OSX release being built with different -arch / -mmacos_min_version. Those types of bugs are really rare.
225 2013-09-12 05:50:33 <cfields> gavinandresen: consider the recent osx database corruption bug
226 2013-09-12 05:50:43 <cfields> (forget the details, just the scenario itself)
227 2013-09-12 05:51:41 <gavinandresen> ok, consideringâ¦.
228 2013-09-12 05:51:46 <cfields> trying to determine the root cause of why that's unique to osx is very difficult when you consider the spectrum of binaries built
229 2013-09-12 05:51:48 <gmaxwell> cfields: we can only make the builds really consistent with something gitian grade.. which we absolutely should have. If you're saying that we're likely to have a lot of OSX "Users" who are not developing, but build from source and don't use gitian... I'm skeptical, this is OSX we're talking about.
230 2013-09-12 05:51:56 <gjs278> as long as the coins don't send to the wrong person, there is no problem
231 2013-09-12 05:52:35 <cfields> gmaxwell: consistent/deterministic buids are not my concern here, the opposite actually
232 2013-09-12 05:52:43 <gmaxwell> cfields: the diversity on Linux is far far greater, and there you can't even pretend to remove it with just some flags.
233 2013-09-12 05:52:43 <warren> cfields: I met *one* windows user who builds litecoin from source, and he's a pool operator.
234 2013-09-12 05:52:52 <gavinandresen> cfields: even I am not going to spend the time needed to keep a -arch i386 development environment on my main development machine
235 2013-09-12 05:53:36 <gavinandresen> So if the default was -arch i386 for configure I'd just constantly set CXXFLAGS to override it, and we'd be in the same situation we are in today
236 2013-09-12 05:53:38 <cfields> gavinandresen: if i volunteered to come up with something to ease the process, and it delivered, would you consider changing your mind?
237 2013-09-12 05:53:41 <gmaxwell> cfields: for developers the diversity is somewhat good, because we do marginally increase the odds of hitting a low visibility bug... creating controlled failures away from production use.
238 2013-09-12 05:53:50 <warren> gavinandresen: meh ... chroot or multiarch linux distros make i386 build environment easy these days.
239 2013-09-12 05:53:55 <gmaxwell> cfields: I think I may not be understanding what you are tring to solve here then.
240 2013-09-12 05:54:20 <gavinandresen> warren: on OSX? Cool! send me instructions.
241 2013-09-12 05:54:31 <warren> oh
242 2013-09-12 05:54:34 <cfields> gmaxwell: i'd like for the builds that devs use every day to be somewhat representative of what a user will see
243 2013-09-12 05:54:45 <gavinandresen> cfields: they are
244 2013-09-12 05:55:04 <gavinandresen> cfields: modulo weird i386/x_64 bugs that never actually happen in practice
245 2013-09-12 05:55:31 <warren> cfields: can we please have deterministic cross compile mac before we worry about this? currently very few of the devs can build for mac
246 2013-09-12 05:55:58 <gmaxwell> s/never actually happen/never actually happen for us/ (there are other development teams that can't seem to resist steping on 64 bit bugs due to being heedless of type safty⦠not like we'd ever make a type safty bug. :P )
247 2013-09-12 05:56:05 <gavinandresen> Yes, by the time we get deterministic cross-compiled mac builds it will probably be time to drop 32-bit support entirely
248 2013-09-12 05:56:40 <Diablo-D3> gavinandresen: honestly
249 2013-09-12 05:56:41 <Diablo-D3> I'd drop it now
250 2013-09-12 05:57:03 <Diablo-D3> seeing as now all the important OSes and archs support 64 bit
251 2013-09-12 05:57:10 <Diablo-D3> theres no reason to ever ship 32 bit software ever again
252 2013-09-12 05:57:15 <cfields> i'm clearly outnumbered here, but I find that strange
253 2013-09-12 05:57:52 <gavinandresen> more developers contributing is higher priority than "might theoretically prevent bugs"
254 2013-09-12 05:58:14 <Diablo-D3> gavinandresen: yeah, but most magfags have quit using 32-bit-only macs
255 2013-09-12 05:58:18 <Diablo-D3> because 10.8 wont run on them
256 2013-09-12 05:58:30 <Diablo-D3> gavinandresen: anything thats core 1 isnt 64 bit
257 2013-09-12 05:58:35 <Diablo-D3> anything core 2 or later is
258 2013-09-12 05:58:36 <gavinandresen> (because more developers contributing helps find and fix more bugs)
259 2013-09-12 05:58:45 <Diablo-D3> and core 2 is, what, 6 years old now? 7?
260 2013-09-12 05:58:57 <gmaxwell> cfields: I think we think the things you want are only fully answered by "we must test the determinstic builds" a build which is kinda like the one the user uses, but isn't the same, isn't good enough. ... and given that we're not solving that problem we'd rather not complicate building.
261 2013-09-12 05:59:24 <Diablo-D3> gmaxwell: have you done chunked analysis on the binaries?
262 2013-09-12 05:59:40 <warren> Diablo-D3: err, not all Core 2 was 64bit
263 2013-09-12 05:59:46 <Diablo-D3> warren: all core 2 macs are
264 2013-09-12 05:59:53 <cfields> gmaxwell: i'm not asking for devs to be using deterministic builds...
265 2013-09-12 05:59:59 <gmaxwell> cfields: Exactly. :P
266 2013-09-12 06:00:00 <warren> can't mac binaries be fat?
267 2013-09-12 06:00:06 <Diablo-D3> warren: all the core 2s that cant do 64 bit are effectively broken, but intel sold them anyhow
268 2013-09-12 06:00:07 <cfields> gmaxwell: sec, let me quote myself (cause i'm fancy like that)
269 2013-09-12 06:00:16 <Diablo-D3> warren: no, mac doesnt do fat binaries like that
270 2013-09-12 06:00:20 <warren> oh
271 2013-09-12 06:00:29 <cfields> the release binary will be completely different (read: different compiler, min sdk, target sdk, and architecture)
272 2013-09-12 06:00:30 <Diablo-D3> warren: it does that weird ass universal crap, but thats for side by side ppc and x86
273 2013-09-12 06:00:41 <Diablo-D3> warren: ia32 and amd64 side by side
274 2013-09-12 06:00:52 <cfields> Diablo-D3: hmm? you can do fat 32/64 builds no problem
275 2013-09-12 06:00:54 <Diablo-D3> warren: er, not those
276 2013-09-12 06:00:56 <cfields> i have a fat bitcoin around somewhere
277 2013-09-12 06:00:59 <Diablo-D3> cfields: since when/
278 2013-09-12 06:01:06 <Diablo-D3> last time I noticed no one could get clang to do it
279 2013-09-12 06:01:06 <gmaxwell> cfields: You're asking them to do something which not as good for mimicing the user expirence as a deterministic build, but which still requires build time consessions. It has (say) half the cost, but half the benefit. It also reduces the _inconsistency_ benefit during development.
280 2013-09-12 06:01:10 <gavinandresen> those differences are the least of our worries. Dependency versions are a lot more likely to cause problems
281 2013-09-12 06:01:30 <Diablo-D3> gavinandresen: yeah, but to make THAT easy you should just depend on brew
282 2013-09-12 06:01:45 <cfields> ok ok, i surrender
283 2013-09-12 06:01:56 <cfields> still don't agree by any stretch, but i'll drop it
284 2013-09-12 06:02:12 <gmaxwell> cfields: I mean, I should shuttup, I don't build on OSX, but ... you and gavin are basically the only people I know who do.
285 2013-09-12 06:02:20 <warren> fat deterministic cross-compiled mac builds would be AWESOME
286 2013-09-12 06:03:04 <Diablo-D3> macs having a sane build system in general would be awesome
287 2013-09-12 06:03:44 <gavinandresen> I suspect jgarzik might compile on OSX sometimes, but won't admit it.
288 2013-09-12 06:04:16 <cfields> Diablo-D3: i was going to dive in and make us a universal dependencies buildsystem. but it sounds as though it solves a problem that's not a high priority relative to the work it'd entail
289 2013-09-12 06:04:35 <Diablo-D3> cfields: you'd make friends doing it
290 2013-09-12 06:05:05 <cfields> Diablo-D3: i've already done it once, and it was wildly successful
291 2013-09-12 06:05:07 <cfields> https://github.com/xbmc/xbmc/tree/master/tools/depends
292 2013-09-12 06:05:32 <Diablo-D3> lol xbmc
293 2013-09-12 06:06:18 <warren> Diablo-D3: don't tease, he's saving our collective asses
294 2013-09-12 06:06:22 <cfields> Diablo-D3: i'm one of the main devs
295 2013-09-12 06:06:47 <cfields> just thought i'd throw that out there in case you had one in the chamber :)
296 2013-09-12 06:06:56 <Diablo-D3> ACTION holds up his Roku like one would hold up a cross to a vampire
297 2013-09-12 06:07:10 <cfields> eww
298 2013-09-12 06:08:05 <gmaxwell> cfields: Feel free to ignore Diablo-D3 at will.
299 2013-09-12 06:09:15 <cfields> heh
300 2013-09-12 06:09:50 <cfields> well, i'm not even sure what the argument is now. but i know i'm surely not winning :p
301 2013-09-12 06:10:15 <cfields> but here's the thing
302 2013-09-12 06:11:41 <warren> cfields: deterministic cross compile mac builds has been a strong desire for a while, and the community should collectively reward whatever dev who actually makes it possible.
303 2013-09-12 06:11:43 <cfields> my experience lies with making this kind of development easier for devs, and more predictable for end users. but my priorities don't seem to match up with the other devs here
304 2013-09-12 06:11:56 <warren> that is a priority. what you are talking about sounds nice to have for later.
305 2013-09-12 06:11:59 <cfields> so i guess i'm going about it wrong. so how's this:
306 2013-09-12 06:13:03 <Diablo-D3> gmaxwell doesnt get my humor
307 2013-09-12 06:13:05 <Diablo-D3> cfields: just think, you might get bitcoins for this
308 2013-09-12 06:13:33 <cfields> i'm offering to help make building easier and more reliable, with less dependence on third parties. what do the other devs see as priorities?
309 2013-09-12 06:17:46 <gmaxwell> cfields: I dont think your priorties are wrong, but (1) you're talking about OSX which I've seen relatively few people building on and thus don't personally care much about the development expirence on, (2) I don't believe your "make building easier" will do so if it involves replacing their toolchains.
310 2013-09-12 06:18:10 <gmaxwell> (3) concerned with solving a problem which is solved more completely (at somewhat higher cost) by gitian-like builds.
311 2013-09-12 06:20:17 <gmaxwell> So I'd rather see time spent making gitian-like building a reality for OSX and getting its cost and complexity reduced. But hey, if you're able to make other build consistency improvements that don't strike gavin as inconvient thats ducky with me too.
312 2013-09-12 06:21:32 <cfields> gmaxwell: to be clear, the buildsystem i was proposing would be universal. meaning that it's the same for all platforms
313 2013-09-12 06:21:48 <cfields> so the osx dependency build procedure would be the same as linux, win32, etc
314 2013-09-12 06:22:09 <cfields> which means that gitian could use it as well to be verifiably deterministic
315 2013-09-12 06:22:45 <gmaxwell> And would it be four hours of compiling to download and fetch the hoisted toolchain?
316 2013-09-12 06:23:24 <cfields> gmaxwell: take a look at what we build for xbmc: https://github.com/xbmc/xbmc/tree/master/tools/depends/target
317 2013-09-12 06:23:28 <cfields> that takes about 30min
318 2013-09-12 06:23:37 <gmaxwell> if so, thats starting to sound like a replacement for gitian, which might be fine, but please you can't pass off something that requires building a toolchain to be something _easier_ for developers.
319 2013-09-12 06:24:18 <cfields> gmaxwell: no, it uses an existing toolchain, just sets up a cross build environment
320 2013-09-12 06:24:25 <gmaxwell> also, we do not want to become a GNU distributor. For one, now someone who is trying to audit our code has 1000x more code to audit.
321 2013-09-12 06:24:52 <cfields> hmm?
322 2013-09-12 06:24:55 <gmaxwell> cfields: ugh, but then it's much of the complexity (building cross libs for all the dependency chain) without actually giving determinism. :(
323 2013-09-12 06:26:03 <gmaxwell> cfields: part of the purpose of gitian is that more than just the determinism is reduces the number of places this team could hide backdoors.. e.g. we don't provide zlib.
324 2013-09-12 06:30:12 <cfields> gmaxwell: sure you do, gitian's win32 deps builds it.
325 2013-09-12 06:30:48 <gmaxwell> not provided or maintained by us, however.
326 2013-09-12 06:31:14 <warren> the toolchain is provided by Ubuntu in that case
327 2013-09-12 06:31:17 <cfields> gmaxwell: i wasn't suggesting by any means that the dependencies be hosted/maintained by us
328 2013-09-12 06:31:59 <warren> the cross compile toolchain itself can be gitian built by a distro toolchain? =)
329 2013-09-12 06:32:39 <gmaxwell> cfields: then we already have what you want: gitian. and it produces reproducable deterministic binaries. Maybe it would be good to change how it works and narrow it down, so that it's not such a burden to use.. but if the result isn't determinstic binaries: I yawn.
330 2013-09-12 06:34:05 <cfields> gmaxwell: yes, that sounds like the logical outcome here
331 2013-09-12 06:35:04 <gmaxwell> cfields: I would not that the recent NSA stuff has a much much wider group of people talking about determinstic binaries now, so as we speak people might be coming up with useful thoughts elsewhere.
332 2013-09-12 06:37:41 <cfields> gmaxwell: i don't disagree by any means.
333 2013-09-12 06:39:02 <cfields> but i'll drop my work on an overhaul. You're correct that you already have a solution there. I'm not a fan of it, but effort would be better spent on fixing it up
334 2013-09-12 06:41:57 <cfields> gavinandresen: would you like me to PR the change to drop hardening and switch to release, minus the osx changes? I believe you'd rather do that than pull in the -O2 change?
335 2013-09-12 06:44:06 <gmaxwell> drop hardening?!
336 2013-09-12 06:44:07 <gmaxwell> Fuck no.
337 2013-09-12 06:44:30 <cfields> gmaxwell: hehe, context is everything
338 2013-09-12 06:44:33 <cfields> drop the hardening switch
339 2013-09-12 06:44:37 <gmaxwell> ohhh
340 2013-09-12 06:45:21 <cfields> debug is vanilla, release is hardened, override is removed
341 2013-09-12 06:45:48 <gmaxwell> Why would you remove hardening from debug builds? I don't believe I've ever had it interfear with debugging.
342 2013-09-12 06:46:22 <cfields> gmaxwell: entire context: https://github.com/bitcoin/bitcoin/pull/2988
343 2013-09-12 06:46:24 <gmaxwell> Oh the string protection warnings that need value analysis? Just make the debug builds O1 unless someone has recently done some debugging that needed O0 instead of O1?
344 2013-09-12 06:46:33 <warren> some strange happened with my gitian build of 0.8.5
345 2013-09-12 06:46:39 <gmaxwell> I have it on my screen it wasn't clear to me from your context?
346 2013-09-12 06:47:32 <gmaxwell> cfields: I vaguely think what we want is to remove the hardening switch (uh, maybe it stays as a --disable?) release builds by default. Debug builds are O1.
347 2013-09-12 06:47:43 <gmaxwell> warren: How informative! :P
348 2013-09-12 06:47:46 <warren> 0.8.5/wtogami/bitcoin-build.assert somehow ended up identical to 0.8.5-win32/wtogami/bitcoin-build.assert
349 2013-09-12 06:47:51 <warren> both containing win32
350 2013-09-12 06:48:04 <warren> ACTION tries again
351 2013-09-12 06:50:25 <gavinandresen> out for a while. gmaxwell: debug builds with -O1 violates principle of least surprise (I'd expect no optimizations, maximum ability to debug)
352 2013-09-12 06:50:27 <cfields> gmaxwell: please chime in on that PR. ultimately a decision is going to have to be made.
353 2013-09-12 06:51:04 <gmaxwell> gavinandresen: okay, fine enough then.
354 2013-09-12 06:51:23 <warren> gavinandresen: debug would then be -O0 with hardening disabled
355 2013-09-12 06:51:39 <gmaxwell> warren: what? NO!
356 2013-09-12 06:51:46 <gmaxwell> stop fucking asking to disable hardening.
357 2013-09-12 06:51:54 <warren> gmaxwell: I didn't
358 2013-09-12 06:52:01 <warren> gmaxwell: you need at least -O1 for hardening to work
359 2013-09-12 06:52:40 <gmaxwell> NO. You do not. You need O1 for printf validation and compile time strcpy checking which is just one little thing.
360 2013-09-12 06:53:18 <warren> err, you're right, I need more sleep.
361 2013-09-12 06:54:07 <gmaxwell> It's fine. I would personally prefer O1 for debug because there is a huge performance difference esp when run in valgrind, but that preference ended the moment anyone expressed the view that they'd find it surprising.
362 2013-09-12 06:54:39 <gmaxwell> we shouldn't go make debug builds having entirely different build options except to the extent that it fixes problems debugging.
363 2013-09-12 06:55:01 <gmaxwell> I don't want some hardening exposed heisenbug going away in debug builds to whatever extent it can be avoided.
364 2013-09-12 06:55:23 <warren> I personally think debug builds should have configurable -O. devs shoudln't be surprised by any optimization.
365 2013-09-12 06:55:41 <cfields> warren: you can override with anything you want
366 2013-09-12 06:55:42 <gmaxwell> warren: cflags should be able to override them.
367 2013-09-12 06:55:42 <warren> entire distros are built with -O2 -andlotsofothershit
368 2013-09-12 06:55:56 <cfields> ./configure CXXFLAGS="-Orice"
369 2013-09-12 06:56:23 <gmaxwell> what are you going on about we're talking about an explicit debug build this is common and usual for software packages, because normal O2 optimizations obscure information in the debugger.
370 2013-09-12 06:56:48 <warren> what might be nice is a way to strip the gitian builds into an optional download debuginfo. Dunno if other distros does this, but all debuginfo is available in separate packages and can be loaded on the side by gdb to debug any distro package.
371 2013-09-12 06:57:00 <gmaxwell> This isn't a speculative issue, this is an issue you will encounter virtually every time you run the software in a debugger.
372 2013-09-12 06:57:15 <gmaxwell> warren: yes, we should do that. but thats entirely orthorgonal to a debug build.
373 2013-09-12 06:57:21 <warren> right
374 2013-09-12 06:57:31 <gmaxwell> The whole purpose of a debug build is to turn of the build options that screw up running under gdb.
375 2013-09-12 06:58:03 <cfields> gmaxwell: was that aimed at me? if so, i was only pointing out to warren how to override whatever defaults we pick
376 2013-09-12 06:58:18 <gmaxwell> cfields: no, it was aimed at warren
377 2013-09-12 07:00:47 <cfields> ok, i'm off as well
378 2013-09-12 07:01:07 <cfields> thanks gmaxwell and gavinandresen for the rational debates
379 2013-09-12 07:01:15 <gmaxwell> cfields: I commented on that pull req.
380 2013-09-12 07:03:23 <cfields> gmaxwell: just for the record, i was doing my best to segregate the osx issue as i assumed it would be contentious. i really don't like mixing bugfixes with policy changes
381 2013-09-12 07:04:50 <gmaxwell> cfields: No problem.
382 2013-09-12 07:05:37 <cfields> thanks again
383 2013-09-12 07:05:38 <cfields> nnite
384 2013-09-12 07:05:44 <gmaxwell> warren: sorry for barking you, I have to say that I find talking about build system twizzling is about the least rewarding stuff to discuss ever, so I have a low tolerance for tangents on it. :P
385 2013-09-12 07:12:24 <warren> gmaxwell: I was wrong about the FORTIFY_SOURCE thing, it's been years since I've looked at what it actually does.
386 2013-09-12 07:15:15 <SomeoneWeird> https://github.com/JaviSoto/iOS7-Runtime-Headers/commit/6ccf9c4526992fec0dc414d48e4a3f7446e9822f#L10L60
387 2013-09-12 07:53:51 <t7> ugh, people who post meme images on github...
388 2013-09-12 09:11:19 <Micha> iPhone|I won't be able to get to my Ubuntu machine to gbuild 0.8.5 for at least 12, maybe more like 24 hours... Is that still useful?
389 2013-09-12 09:47:39 <phantomcircuit> 7600e7fc (Jeff Garzik 2012-08-21 02:21:33 -0400 298) map<uint256, int64_t> setTxIndex;
390 2013-09-12 09:47:44 <phantomcircuit> lol
391 2013-09-12 09:52:23 <sipa> ?
392 2013-09-12 09:54:06 <phantomcircuit> sipa, it's a map
393 2013-09-12 10:00:47 <sipa> ah!
394 2013-09-12 10:02:48 <Micha> iPhone|Hmm?
395 2013-09-12 10:04:00 <sipa> it's called set
396 2013-09-12 10:05:09 <Micha> iPhone|ACTION uspects he missed something
397 2013-09-12 10:05:29 <Micha> iPhone|ACTION checks the logs
398 2013-09-12 10:15:06 <phantomcircuit> sipa, is it just more or should the version field for transactions not have been interpreted as signed in the first place?
399 2013-09-12 10:16:05 <phantomcircuit> ah i see it's an int
400 2013-09-12 10:16:29 <phantomcircuit> sipa, is there anything that relies on it being an int? possibly we should change it to unsigned before anything starts to actually use it
401 2013-09-12 10:17:48 <sipa> phantomcircuit: i think it should just become unsigned
402 2013-09-12 10:17:55 <sipa> and serialized as such
403 2013-09-12 10:18:09 <sipa> but i need to double check whether nothing depends on a negative number
404 2013-09-12 10:18:33 <sipa> like using -1 for uninitialized/invalid
405 2013-09-12 10:23:15 <phantomcircuit> sipa, hopefully nothing does...
406 2013-09-12 10:26:35 <Micha> iPhone|I won't be able to get to my Ubuntu machine to gbuild 0.8.5 for at least 12, maybe more like 24 hours... Is that still useful?
407 2013-09-12 10:28:08 <warren> Micha|iPhone: my team has five people capable of gitian sigs sooner
408 2013-09-12 10:28:18 <swulf--> I'm trying to envision a strategy for doing off-chain peer-to-peer bitcoin payments, but I'm coming up short. Am I wasting my time? Is it even possible?
409 2013-09-12 10:31:09 <Micha> iPhone|What is /doc/Doxyfile?
410 2013-09-12 10:37:25 <sipa> Micha|iPhone: doxygen config, i believe
411 2013-09-12 10:37:59 <Micha> iPhone|I ask because it seems it has a version nimber of 0.5.0
412 2013-09-12 10:38:39 <Micha> iPhone|Should be either updated or removed (is doxygen still used?)
413 2013-09-12 10:38:56 <sipa> hardly
414 2013-09-12 10:39:07 <sipa> i don't think it ever was used much
415 2013-09-12 10:39:23 <sipa> but maybe wumpus still maintains a website with code documentation
416 2013-09-12 10:44:51 <wumpus> yes, I do
417 2013-09-12 10:45:00 <c0rw1n> swulf-- it's possible, but the system that does the offchain transaction has to be Trusted (TM) which is Bad (TM)
418 2013-09-12 10:45:10 <wumpus> feel free to update the version number (or make it auto update) but if you remove it I get angry :)
419 2013-09-12 10:45:43 <wumpus> https://dev.visucore.com/bitcoin/doxygen/
420 2013-09-12 10:46:25 <swulf--> c0rw1n: but there is a mathematical provable way to do trustless peer to peer offchain transactions?
421 2013-09-12 10:47:01 <wumpus> trustless offchain transactions, that'd be nice, you'd almost not need a blockchain anymore
422 2013-09-12 10:47:19 <c0rw1n> swulf--: I think I remember there exists guaranteed cross-chain atomic transactions
423 2013-09-12 10:47:19 <sipa> swulf--: i really doubt that
424 2013-09-12 10:47:36 <swulf--> well, suppose Alice and Bob both are full nodes. is there any way to transfer coin between the two without hitting the blockchain and without a third party?
425 2013-09-12 10:47:46 <sipa> i don't think atomic transactions between unrelated chains are possible
426 2013-09-12 10:48:13 <sipa> swulf--: by coins do you mean bitcoins, or some future hypothetical uber cryptocurrency?
427 2013-09-12 10:48:28 <swulf--> Or how about, Alice wants to pay Bob, both are full nodes, is it possible for Alice to give bob the transaction at and the same time provably destroy the private key to which the coins are coming from?
428 2013-09-12 10:48:31 <swulf--> sipa: bitcoins :)
429 2013-09-12 10:48:46 <sipa> swulf--: impossible, afaict
430 2013-09-12 10:48:56 <c0rw1n> swulf--: the one problem with that is the "destroy the privkey" part
431 2013-09-12 10:49:01 <swulf--> yeah, I know
432 2013-09-12 10:49:46 <swulf--> wonder if a pay to script is possible by sharing the script with Bob, so that bob can form the transaction and broadcast it?
433 2013-09-12 10:50:03 <c0rw1n> oh yes, but with a multikey exchange
434 2013-09-12 10:50:07 <c0rw1n> argh
435 2013-09-12 10:50:10 <c0rw1n> multisig
436 2013-09-12 10:50:14 <swulf--> yeah
437 2013-09-12 10:50:32 <c0rw1n> that shit is fucking psychedelic
438 2013-09-12 10:50:53 <swulf--> before going out, Alice pays herself to a script address. once meeting up with Bob, she gives bob the script necessary to spend the output and a change address. Bob broadcasts the transaction and sends the txid to alice.
439 2013-09-12 10:50:55 <swulf--> would this work?
440 2013-09-12 10:51:28 <c0rw1n> not sure how you ensure that bob sends the txid back
441 2013-09-12 10:51:43 <c0rw1n> nlocktime?
442 2013-09-12 10:51:49 <c0rw1n> inner transaction?
443 2013-09-12 10:51:49 <swulf--> damn. you'd still have to wait for confirmations to avoid double-spends
444 2013-09-12 10:51:53 <swulf--> could use that?
445 2013-09-12 10:52:18 <c0rw1n> i don't know enough how it works exactly
446 2013-09-12 10:59:00 <sipa> swulf--: do you know, fundamentally, why the blockchain is necessary?
447 2013-09-12 10:59:25 <swulf--> sure, at least, I think so :)
448 2013-09-12 11:00:19 <swulf--> what I'm particularly curious about is whether there's a strategy such that Bob can broadcast a transaction that he KNOWS has a very high probability of being included in a block so that he doesn't have to wait for confirmations in order to accept a payment from alice
449 2013-09-12 11:00:37 <c0rw1n> sure. high fee.
450 2013-09-12 11:00:58 <c0rw1n> it's a bid for inclusion in the next block, so a high bid is sure to be mined asap.
451 2013-09-12 11:02:14 <swulf--> but i also need to be certain alice won't broadcast something else in an attempt to spend the input before bob's transaction is confirmed
452 2013-09-12 11:02:44 <swulf--> its quite likely this isn't possible
453 2013-09-12 11:07:53 <sipa> swulf--: can you tell me? :)
454 2013-09-12 11:10:36 <swulf--> errr my best guess: it's the deciding factor, the authority, on what addresses "own" how many bitcoins. or rather, it's a list of all unspent (and spent, tho those aren't *as* important) coins.
455 2013-09-12 11:11:31 <sipa> close enough - you're really describing the UTXO set, which is sort of the result of "history", while the blockhain is the history itself
456 2013-09-12 11:11:52 <swulf--> right
457 2013-09-12 11:11:54 <sipa> but the reason the blockchain is necessary at all, is just because of one reason: to prevent double spends
458 2013-09-12 11:11:59 <swulf--> sounds good. your words are better:)
459 2013-09-12 11:12:29 <sipa> nodes do not always agree about the past timeline, but within each timeline itself, no double spends are possible because of it
460 2013-09-12 11:13:14 <sipa> it's a roundabout way to avoid the fundamental problem that you cannot have a globally consistent database without knowing all participants
461 2013-09-12 11:13:29 <swulf--> sure, but there are other ways of transferring bitcoins without the blockchain between individuals
462 2013-09-12 11:13:35 <swulf--> for example, giving the private key to someone else
463 2013-09-12 11:13:40 <sipa> right
464 2013-09-12 11:13:50 <swulf--> the problem with just giving the private key away is of course "forgetting" it on giver side
465 2013-09-12 11:14:00 <sipa> but that's just changing the mapping of addresses to humans
466 2013-09-12 11:14:12 <swulf--> which is my main though process right now
467 2013-09-12 11:14:47 <swulf--> how can i get two humans to transfer coins between eachother without confirmations and without a thirdparty?
468 2013-09-12 11:15:19 <sipa> by giving a transaction
469 2013-09-12 11:15:32 <sipa> but you can't guarantee a consistent view between the two parties
470 2013-09-12 11:15:41 <sipa> so you can't prevent double spending that way
471 2013-09-12 11:15:55 <swulf--> you can have a high probability of similar views, especially if the coins in question are deep in the chain
472 2013-09-12 11:15:56 <sipa> and if you continue that reasoning, you'll end up with a second blockchain to fix it :)
473 2013-09-12 11:16:11 <sipa> high probability may be true in the average case
474 2013-09-12 11:16:29 <sipa> but it won't be true when there's an arbitrarily high amount to win for an attacker
475 2013-09-12 11:17:02 <swulf--> if Bob is part of the bitcoin network and has a full copy of the blockchain, Alice can lie all she wants about the coins and Bob can verify without trusting alice
476 2013-09-12 11:17:13 <sipa> or put otherwise: the blockchain is there exactly to deal with the case where sender and receiver do not trust eachother
477 2013-09-12 11:17:27 <swulf--> but what about in the case where Alice trusts Bob, but Bob doesn't trust Alice
478 2013-09-12 11:17:46 <sipa> that's what the blockchain is for
479 2013-09-12 11:17:58 <swulf--> consider a old-time analogy: you go pay for a $14.99 item with a $20 bill, you hand $20 to the cashier and you implicitly trust the cashier to return change