1 2014-09-29 01:09:05 <andytoshi> bliljerk101: have you read https://download.wpsoftware.net/bitcoin/accounts-faq.pdf ?
  2 2014-09-29 01:09:45 <andytoshi> i also have a rawtx writeup but i assume you know this https://testing.wpsoftware.net/coinjoin/rawtx.html
  3 2014-09-29 01:12:02 <kanzure> andytoshi: off-topic, but it is hard to know whether there is a page missing in your pdf document (such as if the download was incomplete) because the last page is never marked (usually conclusion sections give it away, but an eof would be hepful in its absence)
  4 2014-09-29 01:13:44 <andytoshi> kanzure: good idea, i will update the *-faq documents at some point with that
  5 2014-09-29 02:15:35 <jgarzik> woo
  6 2014-09-29 02:15:38 <jgarzik> pull #5000
  7 2014-09-29 02:39:55 <horny-sama> Anyone in here familiar with java and is willing to give me a hand
  8 2014-09-29 02:40:48 <bliljerk101> andytoshi thanks, i read it briefly, but i understand all of this already. my problem is more of an implementation engineering problem
  9 2014-09-29 02:41:07 <horny-sama> need some help with java
 10 2014-09-29 02:41:10 <horny-sama> comrade
 11 2014-09-29 02:43:16 <bliljerk101> i'm not a java developer, sorry
 12 2014-09-29 02:43:31 <horny-sama> no worries
 13 2014-09-29 03:02:09 <Luke-Jr> 
ACTION peers at horny-sama

 14 2014-09-29 03:02:24 <horny-sama> Luke-Jr: you are everywhere
 15 2014-09-29 03:03:04 <bliljerk101> horny-sama hentai-san sounds better
 16 2014-09-29 03:05:05 <horny-sama> bliljerk101: agree
 17 2014-09-29 06:09:39 <SomeoneWeird> bliljerk101: lets not do that...
 18 2014-09-29 07:33:04 <mrebola> see you later alligator
 19 2014-09-29 07:34:29 <wumpus> BlueMatt: I've done various block syncs with master over the weekend (with gui and daemon), and haven't been able to reproduce any crashes; anything specific about your setup?
 20 2014-09-29 08:15:54 <petertodd> jgarzik: https://www.youtube.com/watch?v=u4EuqGZKTH4
 21 2014-09-29 08:24:03 <wumpus> petertodd: congrats :-)
 22 2014-09-29 08:24:40 <petertodd> wumpus: I swear it was totally not planned, really!
 23 2014-09-29 08:26:32 <wumpus> petertodd: we need to spin this into a media story about how fast bitcoin core development is going
 24 2014-09-29 08:27:07 <gmaxwell> hm?
 25 2014-09-29 08:27:12 <petertodd> wumpus: lol, well, here's a new opcode: https://github.com/petertodd/bitcoin/tree/checklocktimeverify
 26 2014-09-29 08:28:01 <petertodd> gmaxwell: https://github.com/bitcoin/bitcoin/pull/5000
 27 2014-09-29 08:28:05 <gmaxwell> ah!
 28 2014-09-29 08:28:37 <wumpus> "github's database stresses under pace of development"
 29 2014-09-29 08:29:01 <Happzz> is there any plan on introducing pruning to the core client?
 30 2014-09-29 08:29:32 <Happzz> because i was thinking about it, and i must have talked about it before.. i can't see any real reason to actually force end users into storing the whole blockchain
 31 2014-09-29 08:29:36 <wumpus> Happzz: you know there's a find function for pull requests: https://github.com/bitcoin/bitcoin/pull/4701
 32 2014-09-29 08:30:11 <Happzz> oh, wow.
 33 2014-09-29 08:32:27 <Happzz> how do we make sure people wont "change the history", though?
 34 2014-09-29 08:32:41 <sipa> because pruning does not change validation
 35 2014-09-29 08:32:49 <sipa> you still need to download and process all history
 36 2014-09-29 08:32:58 <sipa> you only just keep the last part of it on disk
 37 2014-09-29 08:33:49 <Happzz> yup, but once pruning is widely enough adopted, where would you download everything from to begin with?
 38 2014-09-29 08:33:58 <wumpus> from nodes that don't prune
 39 2014-09-29 08:34:13 <Happzz> i.e. from a small portion of the nodes
 40 2014-09-29 08:34:13 <sipa> and if everyone prunes, i'll seed jeff's torrent
 41 2014-09-29 08:34:27 <Happzz> ... = centralization
 42 2014-09-29 08:34:33 <sipa> yes
 43 2014-09-29 08:34:39 <wumpus> well, that's what you get
 44 2014-09-29 08:34:42 <sipa> but no reduction in trustlessness
 45 2014-09-29 08:34:54 <wumpus> if that matters to you, keep the entire blockchain
 46 2014-09-29 08:34:59 <sipa> you end up with a central party, but not a trusted central party (which is much worse)
 47 2014-09-29 08:35:20 <gmaxwell> Happzz: in any case, there is no risk of that now. At the moment pruning turns off node network which effectively disables relaying blocks, and disables the wallet.
 48 2014-09-29 08:35:28 <wumpus> if you don't keep the information yourself by definition you rely on others (although not in a trusted sense, indeed)
 49 2014-09-29 08:35:56 <Happzz> gmaxwell i dont understand what you just said..
 50 2014-09-29 08:36:04 <gmaxwell> Subsiquently I plan to implement signaling block ranges, so that even if no one stores the whole thing you can assemble a complete copy from people storing parts.
 51 2014-09-29 08:36:08 <wumpus> it's a strange thing to be asking for something and then start to argue why it's a bad idea :)
 52 2014-09-29 08:36:29 <phantomcircuit> gmaxwell, have you figured out how to do that yet?
 53 2014-09-29 08:36:31 <sipa> gmaxwell: we should ust use a DHT for blocks
 54 2014-09-29 08:36:33 <Happzz> is there a way to keep *part* of the blocks' data to still verify, but not necessarily keep ALL of the data of each block?
 55 2014-09-29 08:36:37 <phantomcircuit> sipa, >.>
 56 2014-09-29 08:36:46 <Happzz> wumpus it's called brainstorming
 57 2014-09-29 08:36:48 <gmaxwell> Happzz: sorry, I don't know how I could have used simpler language there. Right now the feature disables the wallet. It disables relaying blocks, so there is no risk of people rushing out and turning it on.
 58 2014-09-29 08:36:50 <sipa> Happzz: verification doesn't need blocks at all
 59 2014-09-29 08:36:57 <phantomcircuit> gmaxwell, i was thinking nodes would keep blocks with a specific prefix (suffix?)
 60 2014-09-29 08:37:03 <phantomcircuit> (the random end)
 61 2014-09-29 08:37:13 <gmaxwell> random is bad. it has poor locality.
 62 2014-09-29 08:37:18 <sipa> Happzz: the only reason you need to keep blocks around it to _show_ them to new peers
 63 2014-09-29 08:37:36 <phantomcircuit> gmaxwell, im not sure it matters with headers first
 64 2014-09-29 08:38:06 <wumpus> sipa: apart from the last few blocks, for rewinding when a reorg happens
 65 2014-09-29 08:38:15 <gmaxwell> phantomcircuit: sure it does, since you have to open a connection and we cannot sensibly support unbounded reordering.
 66 2014-09-29 08:38:17 <Happzz> sipa i mean something else. maybe my thought comes from lack of understanding, so i'll appreciate if you correct me on this: each block has a hash, right? do you actually need the _content_ of the block, in order to verify it was valid 10 years ago, or do you must have the whole content of the block as well?
 67 2014-09-29 08:38:18 <sipa> wumpus: you _could_ just wipe and restart in that case, even
 68 2014-09-29 08:38:23 <wumpus> sipa: .... true!
 69 2014-09-29 08:38:40 <phantomcircuit> gmaxwell, unbounded reordering?
 70 2014-09-29 08:38:46 <gmaxwell> Happzz: you don't need to have the content anymore once you've already validated it.
 71 2014-09-29 08:38:48 <sipa> Happzz: you need to _see_ a block's contents to validate it, but you don't need to keep it around after that
 72 2014-09-29 08:39:03 <sipa> and you need those blocks in order
 73 2014-09-29 08:39:27 <gmaxwell> phantomcircuit: if you're validating block 10000 now, getting block 100000 will do you no good. All you could do is save it for much later (which is potentially a dos attack)
 74 2014-09-29 08:39:32 <Happzz> would it make sense to make it so nodes only keep last 100K blocks, or whatever other reasonable number of blocks, and that way
 75 2014-09-29 08:39:37 <Happzz> "shorten" the history?
 76 2014-09-29 08:39:44 <wumpus> nodes keep a running state of the blocks they've've seen and validated, aka the UTXO set
 77 2014-09-29 08:39:50 <phantomcircuit> gmaxwell, hmm
 78 2014-09-29 08:39:59 <phantomcircuit> i see what you mean
 79 2014-09-29 08:40:01 <Happzz> in fact, i can't happen, because ancient coins may be lost.
 80 2014-09-29 08:40:12 <phantomcircuit> that seems to leave us with specifying ranges of blocks
 81 2014-09-29 08:40:24 <sipa> Happzz: all you need is the UTXO set
 82 2014-09-29 08:40:39 <sipa> Happzz: which has the state of _all_ coins, including those produced by pruned blocks
 83 2014-09-29 08:41:01 <Happzz> that's what *I* need. i'm trying to think what the network needs as well.
 84 2014-09-29 08:41:16 <gmaxwell> phantomcircuit: I guess you missed my shuffle idea... just need to figure out how to make it efficient.
 85 2014-09-29 08:41:17 <Happzz> i realize i could be pruning a bunch of what i have in hands, because i trust myself and i already verified it
 86 2014-09-29 08:41:40 <Happzz> but that means much less full nodes, which means centralization.
 87 2014-09-29 08:41:52 <wumpus> it doesn't mean 'much less full nodes'
 88 2014-09-29 08:41:58 <wumpus> right now, people stop running a full nodes if their disk is full
 89 2014-09-29 08:42:01 <sipa> Happzz: you can be a fully validating node, which just doesn't know history
 90 2014-09-29 08:42:07 <Happzz> wumpus we're not at that point yet
 91 2014-09-29 08:42:11 <sipa> Happzz: which is still massively useful (for you, and for others)
 92 2014-09-29 08:42:13 <wumpus> with pruning they can keep running a full node with only the last blocks
 93 2014-09-29 08:42:18 <gmaxwell> phantomcircuit: first observe that it's possible to unformly select N lines out of a huge number using only N memory.
 94 2014-09-29 08:42:23 <wumpus> which means more verifying nodes
 95 2014-09-29 08:42:44 <wumpus> not more archive nodes, but remember, you'd have lost them as archive nodes in the first place
 96 2014-09-29 08:43:15 <sipa> Happzz: storage of blocks could even just be completely outsourced to other systems (bittorrent? http? freenet? dropbox?)
 97 2014-09-29 08:43:23 <wumpus> if the P2P protocol had a way to advertise block ranges, nodes  could keep multiple ranges of blocks, ie the first 100000 as well as the last blocks, and the storage could be distributed too
 98 2014-09-29 08:43:25 <gmaxwell> phantomcircuit: so you can say have a short random seed for a host, and a capacity... and then play forward the height and find out at a particular height what ranges they are currently storing.
 99 2014-09-29 08:43:26 <sipa> Happzz: which may be more or less decentralized than bitcoin full nodes
100 2014-09-29 08:43:48 <gmaxwell> phantomcircuit: I just don't know how to do it without O(N) work in the number of blocks to find out what a node is storing now.
101 2014-09-29 08:44:10 <Happzz> sipa but.. if the whole history is on dropbox, and nodes only keep the UTXO and verify newer blocks. couldn't dropbox change the history and cause chaos?
102 2014-09-29 08:44:16 <sipa> Happzz: no
103 2014-09-29 08:44:22 <sipa> they could delete blocks
104 2014-09-29 08:44:25 <gmaxwell> phantomcircuit: the result, in any case, is uniformly distributed storage, and just a short (e.g. 8 byte) signaling.
105 2014-09-29 08:44:45 <Happzz> sipa i.e. delete money.
106 2014-09-29 08:44:51 <sipa> Happzz: no
107 2014-09-29 08:44:52 <wumpus> Happzz: no, and keeping it on dropbox is just an example, in practice you'd store it on multiple storage systems not controlled by one actor, or use a distributed protocol such as torrents
108 2014-09-29 08:44:57 <sipa> Happzz: just prevent new full nodes from spinning up
109 2014-09-29 08:45:27 <Happzz> sipa because new nodes couldn't fetch the whole history and prune it properly, right?
110 2014-09-29 08:45:40 <sipa> couldn't _validate_ it
111 2014-09-29 08:45:44 <sipa> so they can't sync
112 2014-09-29 08:45:52 <petertodd> Happzz: people can be *lazy* and trust dropbox's/their neighbors/whatever copy of the UTXO set and not bother to actually validate the blockchain, but that's being lazy
113 2014-09-29 08:45:54 <sipa> but it wouldn't affect running full nodes
114 2014-09-29 08:46:06 <Happzz> i see.
115 2014-09-29 08:46:11 <sipa> it's a DoS risk
116 2014-09-29 08:46:14 <sipa> not a security risk
117 2014-09-29 08:46:32 <petertodd> Happzz: you'll still be able to get the complete history from archival nodes even if no one person has the full blockchain, and you can then verify that full history yourself
118 2014-09-29 08:46:44 <sipa> a centralized party that fails can prevent the system from working
119 2014-09-29 08:46:57 <sipa> a centralized trusted party that fails can make the system malfunction
120 2014-09-29 08:46:59 <wumpus> there is really no risk of *everyone* deleting their copy of a certain block, it's just too big in scale for that
121 2014-09-29 08:47:00 <petertodd> Happzz: that said, I *strongly* suspect that without (U)TXO commitments people will get lazy and there will be occasional disasters...
122 2014-09-29 08:47:38 <gmaxwell> Just for performance reasons I prefer to have distributed copies too; this lets people be granular in the storage or bandwidth they contribute instead of big all or nothing chunks.
123 2014-09-29 08:48:06 <gmaxwell> And avoids creating bandwidth hotspots around the nodes that do have all the data ("some grattitude, I host all the data and they melt my internet connection") :)
124 2014-09-29 08:48:07 <Happzz> gmaxwell i guess people could volunteer to run full nodes.
125 2014-09-29 08:48:22 <gmaxwell> Happzz: A pruned node is a full node.
126 2014-09-29 08:48:22 <sipa> Happzz: s/full nodes/archive nodes/
127 2014-09-29 08:48:23 <petertodd> Happzz: full node != archival node
128 2014-09-29 08:48:26 <Happzz> sipa k
129 2014-09-29 08:48:36 <Happzz> yeah, sorry for the wrong terminology.
130 2014-09-29 08:48:37 <wumpus> Happzz: that's already how it goes, right?
131 2014-09-29 08:48:46 <petertodd> Happzz: in fact, you can have archival nodes that aren't full nodes and only have SPV security, heck, you can have the entire blockchain and not bother to verify it
132 2014-09-29 08:48:46 <wumpus> running a full node is completely voluntary
133 2014-09-29 08:48:56 <gmaxwell> and distributed copies also close down paranoia like Happzz's.
134 2014-09-29 08:48:59 <sipa> petertodd: my apache can be an archival node
135 2014-09-29 08:49:17 <petertodd> sipa: oh cool! I like the idea of an archival node that can fly
136 2014-09-29 08:49:23 <wumpus> petertodd: you could just send around blockchain on USB sticks :P
137 2014-09-29 08:49:27 <Happzz> ew apace.
138 2014-09-29 08:49:29 <Happzz> apache even
139 2014-09-29 08:49:48 <sipa> petertodd: dude, a bit respect for those indians, please
140 2014-09-29 08:49:52 <petertodd> wumpus: blockchainbymail.com <- no joke
141 2014-09-29 08:50:09 <petertodd> wumpus: I actually sold those guys that domain name
142 2014-09-29 08:50:14 <wumpus> petertodd: whoa, cool
143 2014-09-29 08:50:23 <Happzz> i believe bittorrent would be so much better than the current method of downloading the blockchain
144 2014-09-29 08:50:33 <petertodd> wumpus: I highly suspect their # of customers is zero :) esp with them talking about a "10GB blockchain"
145 2014-09-29 08:50:42 <Happzz> because downloading 25gb from maximum 8 random nodes is shit
146 2014-09-29 08:50:43 <petertodd> Happzz: bittorrent isn't magic...
147 2014-09-29 08:50:44 <sipa> Happzz: headersfirst sync is superior, as it doesn't need temporary storage :)
148 2014-09-29 08:51:02 <wumpus> petertodd: at some point that can be more efficient than downloading through the internet
149 2014-09-29 08:51:05 <Happzz> i have no idea what headersfirst sync is, but i'll go ahead and google it
150 2014-09-29 08:51:05 <sipa> Happzz: the current method of downloading the blockchain only downloads from one peer
151 2014-09-29 08:51:06 <gmaxwell> Happzz: headersfirst is massively faster than bittorrent in my testing.
152 2014-09-29 08:51:27 <petertodd> wumpus: I've personally given people copies of the blockchain via USB stick!
153 2014-09-29 08:51:31 <sipa> Happzz: it's the new download/validation logic that enables parallel download
154 2014-09-29 08:52:07 <sipa> Happzz: in practice, the current method of downloading downloads from 1 peer 10% of the time, and from 0 peers 90% of the time :)
155 2014-09-29 08:52:33 <Happzz> what's headers-first in a few words? i cant seem to find much info online
156 2014-09-29 08:52:48 <gmaxwell> fortunately the data transfer from 0 peers is provably optimal, no overhead at all.
157 2014-09-29 08:52:52 <sipa> Happzz: you first download and validate the headers (from one peer, like the current sync mechanism)
158 2014-09-29 08:53:06 <Happzz> and then the content of the blocks?
159 2014-09-29 08:53:10 <wumpus> gmaxwell: hah
160 2014-09-29 08:53:17 <sipa> Happzz: then you fetch the blocks (which you already know in order) in parallel using a moving window, from all peers at once
161 2014-09-29 08:53:39 <Happzz> and what makes it so much faste?
162 2014-09-29 08:53:41 <Happzz> faster
163 2014-09-29 08:53:50 <sipa> the fact that it knows in advance what to d
164 2014-09-29 08:53:51 <Happzz> you still need to get 25gb from N nodes
165 2014-09-29 08:54:09 <sipa> so it can be parallellized, and recover from peers that behave weird
166 2014-09-29 08:54:18 <Happzz> oh, so it doesn't have to get blocks 1 by 1
167 2014-09-29 08:54:26 <gmaxwell> Happzz: I'm not sure you saw, 01:52 < sipa> Happzz: in practice, the current method of downloading downloads from 1 peer 10% of the time, and from 0 peers  90% of the time :)
168 2014-09-29 08:54:41 <Happzz> i saw it, i didnt understand what it means though,
169 2014-09-29 08:54:53 <Happzz> im like the NSA, i see everything.
170 2014-09-29 08:54:57 <sipa> it means your node isn't doing anything at all most of the time during sync
171 2014-09-29 08:55:16 <sipa> because it doesn't know what to do
172 2014-09-29 08:55:29 <Happzz> yup, makes sense.
173 2014-09-29 08:55:39 <sipa> headersfirst sync takes 3-4 hour on recent hardware
174 2014-09-29 08:56:10 <Happzz> this is still pretty much for end users
175 2014-09-29 08:56:26 <sipa> yes
176 2014-09-29 08:56:28 <Happzz> not complaining, because it took me like 20 hours...
177 2014-09-29 08:56:29 <sipa> inevitably
178 2014-09-29 08:56:33 <wumpus> who are these 'end users' anyway?
179 2014-09-29 08:56:41 <Happzz> wumpus my mom and dad.
180 2014-09-29 08:56:47 <Happzz> wumpus and their 16gb iphones
181 2014-09-29 08:56:55 <sipa> they should be running a light client...
182 2014-09-29 08:57:00 <wumpus> if you put yourself in the position that you're hurried to get the chain verified, you start from the wrong assumptions
183 2014-09-29 08:57:04 <gmaxwell> Happzz: how is it 'long' for them? it should be occuring in the background in any case.
184 2014-09-29 08:57:23 <Happzz> gmaxwell it's faster to open a bank account.
185 2014-09-29 08:57:24 <wumpus> Happzz: so mom and dad volunteer to run a full node... why the hurry?
186 2014-09-29 08:57:43 <wumpus> my mom and dad run a full node, they hardly aware of it
187 2014-09-29 08:57:44 <gmaxwell> Happzz: I'm guessing you've never opened a bank account. In the US you're required to show up in person with proof of address. :)
188 2014-09-29 08:57:51 <gmaxwell> (ask mom and dad about it, I guess)
189 2014-09-29 08:58:22 <Happzz> im not from the US, but i have had bank accounts for years.
190 2014-09-29 08:58:29 <gmaxwell> But you've missed my point... you can't use a bank account until you've opened it. There shouldn't be a need to wait on your full node to verify to do anything.
191 2014-09-29 08:58:32 <Happzz> it takes much less than 4 hours to open an account.
192 2014-09-29 08:58:33 <wumpus> you shouldn't compare it with opening a bank account
193 2014-09-29 08:58:39 <petertodd> Happzz: there's also my idea of partial UTXO set nodes, that start off with SPV security and scan backwards until they're full nodes that have 100% verified the blockchain: http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02511.html
194 2014-09-29 08:58:49 <Happzz> gmaxwell yeah, makes sense.
195 2014-09-29 08:59:52 <wumpus> if you're a first-time bitcoin user you don't *need* a full node, you should probably not even try, except if you're interested technically
196 2014-09-29 09:01:00 <wumpus> (wonder why these things always assume mom and dad are untechnical though)
197 2014-09-29 09:01:21 <sipa> 
ACTION learned how to program from his dad

198 2014-09-29 09:01:27 <wumpus> 
ACTION too

199 2014-09-29 09:01:30 <sipa> (he never got past BASIC, though)
200 2014-09-29 09:01:32 <gmaxwell> wumpus: ideally it should be painless enough that you can just "contribute this much space and bandwidth to the bitcoin network; you'll get somewhat improved security if you do"
201 2014-09-29 09:01:56 <petertodd> wumpus: we should assume fine arts graduates instead
202 2014-09-29 09:03:10 <wumpus> gmaxwell: agreed, that would be the goal
203 2014-09-29 09:03:29 <gmaxwell> Even my grandmother is tech savvy, she worked for Wang Laboratories back when it was still a thing.
204 2014-09-29 09:03:41 <petertodd> gmaxwell: it's interesting how with compact fraud proofs even SPV clients storing nothing that don't even accept incoming connections are definitely contributing to everyone's security
205 2014-09-29 09:04:00 <gmaxwell> petertodd: yea, trick is all the engineering for the fraud proofs.
206 2014-09-29 09:04:31 <Luke-Jr> sipa: hah, I finally "forced" my dad to at least move on to Python, though he still struggles with the OO parts :x
207 2014-09-29 09:04:45 <petertodd> gmaxwell: I'm becoming more and more convinced they're not as bad as we thought, modulo of course the obvious stuff where we need to make things provable in the first place
208 2014-09-29 09:05:28 <petertodd> gmaxwell: related: notice how my CHECKLOCKTIMEVERIFY implementation now only checks that the txin you're spending is !final...
209 2014-09-29 09:06:57 <petertodd> heh, it was actually my mom who first taught me how RSA signatures worked
210 2014-09-29 09:07:05 <gmaxwell> I never thought they were bad or I wouldn't have said I liked them previously; it's just this maximum: code isn't tested is wrong by definition, code that doesn't run isn't tested.  I think you can do some implementation engineering such that you always do validation by creating proposed fraud proofs and then asking your fraud proof verifier if they're valid fraud proofs... but it still has more exceptional cases than we have today.
211 2014-09-29 09:08:25 <petertodd> gmaxwell: see, if you structure things correctly, fraud proofs are just highly pruned copies of blockchain data - e.g. imagine a fraud proof for a block being nothing more than a CMerkleBlock with a single transaction in it that happens to be invalid
212 2014-09-29 09:09:28 <petertodd> gmaxwell: of course, you still have to test the code making the fraud proofs, but at least the verification part of them can be the same code as standard verification
213 2014-09-29 09:13:10 <petertodd> gmaxwell: (of course, in that scenario verification returns either 'Valid', 'I don't know; missing data', or 'Invalid')
214 2014-09-29 09:18:23 <gmaxwell> actually making can be run normally too.
215 2014-09-29 09:18:54 <gmaxwell> you just always make one for every transaction you're verifying. e.g. the proof is all the data needed to verify it in its smallest increment.
216 2014-09-29 09:24:56 <petertodd> gmaxwell: "actually making can be run normally too." <- ?
217 2014-09-29 09:25:24 <petertodd> gmaxwell: yeah, notice how TXO commitments txin proofs do that, and the structure required to make them possible is the same thing required for fraud proofs
218 2014-09-29 09:26:02 <petertodd> gmaxwell: I've got a colored coins library whose proof structure lends itself pretty naturally to this kind of stuff; what got me thinking about it
219 2014-09-29 09:27:22 <gmaxwell> yea, I had come around to all of this back last time it had come up... it does naturally fit in bitcon too (assuming we could make compact fraud proofs)
220 2014-09-29 09:27:34 <phantomcircuit> gmaxwell, you're assuming too much meaning to specific words
221 2014-09-29 09:27:36 <phantomcircuit> it's confusing
222 2014-09-29 09:27:56 <petertodd> gmaxwell: I should write up a demo in Python when I get a chance...
223 2014-09-29 09:27:57 <gmaxwell> really what caught me up more than the engineering (which was a concern) was the censorship problem, basically there is one kind of fraud that is fundimentally harder to make compact proofs for.
224 2014-09-29 09:28:44 <gmaxwell> ... that some part of the block is being witheld, because its a fraud in absence.. (like the current problem of it being not possible to prove the non-existance of a utxo which is being spent)
225 2014-09-29 09:28:51 <petertodd> gmaxwell: right, and what the censorship problem also indicates is that any serious adversary will just sybil attack your ability to get the fraud proofs in the first place - they'll *always* be categorically less secure than a treechains-like tx history proof
226 2014-09-29 09:29:24 <gmaxwell> that sent me on a path of considering linear codes, and I felt like there is a solution there but didn't quite have a crisp statement of it.
227 2014-09-29 09:29:34 <petertodd> gmaxwell: but at least now we're confident that the engineering overlaps 99% for both ways of doing things
228 2014-09-29 09:29:56 <gmaxwell> Sure, if your goal is your own transaction validity only, being given the complete history of the coins you recieved works, when you care about more than that its more complex.
229 2014-09-29 09:30:23 <petertodd> gmaxwell: yeah, that linear code stuff I suspect would be sybil attacked away - they'll always be more costly to evaluate than non-linear, so people naturally will disable that codepath in favor of cheaper ways to use bitcoin
230 2014-09-29 09:30:53 <gmaxwell> in any case, I came up with some scheme of a commited locally testable linear code where someone can't hide any specific part of a block without hiding the whole thing with exponential probablity. But I haven't worked out if its efficient enough to be pratical.
231 2014-09-29 09:30:56 <petertodd> gmaxwell: yes, hence why 'global consensus' sucks on so many levels, even if it is attractive as hell on others :)
232 2014-09-29 09:31:28 <petertodd> gmaxwell: did you remember to ensure the linear code commitment can't be frauded? ;)
233 2014-09-29 09:31:59 <gmaxwell> yes, thats what the 'locally testable' requirement comes from.
234 2014-09-29 09:32:12 <petertodd> linear codes have the engineering problem that they're !@#$ complex compared to not, so I'm sure we'll see wallets skip them...
235 2014-09-29 09:32:49 <gmaxwell> Sure but thats true for anything. Ideally this stuff is nicely libraized and so those who don't care can do the optimal amount of work: zero.
236 2014-09-29 09:33:28 <gmaxwell> in any case, I have no clue if its really pratical, the intermediate state required for adequate security may be too large.
237 2014-09-29 09:33:48 <petertodd> yup
238 2014-09-29 09:35:15 <petertodd> related: I was thinking a good model to use would be to have EvalScript() get passed a CMerkleTransaction instead of a CTransaction in the toTo, in the sense that any future opcode should be able to get all it's state from that
239 2014-09-29 09:35:46 <gmaxwell> (for those trying to follow along and failing, petertodd has more context because we've discussed it before.  The general issue is that if you hope to have a network work by everyone only verifying parts of blocks, thats workable if nodes can announce a short segement showing something wrong if they find it (fraud proof). ... but one remaining issue is that a evil miner could just refuse to release part of his block, and obviously no one ...
240 2014-09-29 09:35:52 <gmaxwell> ... can produce a compact proof of naughtyness for data they don't even have.
241 2014-09-29 09:36:16 <petertodd> unfortunately that means you'll want to at least internally implement (U)TXO commitments so things like CHECKPREVOUTVALUEVERIFY can work
242 2014-09-29 09:38:06 <petertodd> might be enough to just implement an internal merkle-tree version of transactions and have all your CHECK<prevtx stuff>VERIFY opcodes first check that the txin.merkle_hash_version_2 matches what they're expecting
243 2014-09-29 09:38:43 <btcdrak> wow, a lot of reading to catch up on
244 2014-09-29 09:38:44 <petertodd> gmaxwell: I feel bad for the peanut gallery right now too :)
245 2014-09-29 09:39:08 <gmaxwell> I have a conjectural fix for this problem which goes: You change how the block is encoded, so that its encoded with a highly redudant error correcting code. Such that to read any part of a block you pick several segments of the code... and can reconstruct the part you want. The ways you can decode parts overlap, such that a node will need to basically reject one block out of every fetch in order to relably censor any subset of the block).
246 2014-09-29 09:39:13 <petertodd> btcdrak: https://github.com/petertodd/bitcoin/tree/checklocktimeverify
247 2014-09-29 09:39:39 <gmaxwell> petertodd: better than zerocash which needs a _transaction internal_ utxo tree too. :P
248 2014-09-29 09:40:14 <petertodd> gmaxwell: lol, true
249 2014-09-29 09:41:11 <petertodd> btcdrak: next is to write up a regtest-using python script to create nVersion==3 blocks in all the permutations of the IsSuperMajority() function
250 2014-09-29 09:41:20 <petertodd> btcdrak: the opcode itself is pretty well tested by the unittests
251 2014-09-29 09:41:56 <petertodd> btcdrak: I'd *highly* suggest that someone other than me do the port to viacoin to ensure we've got another set of eyes on it 100%
252 2014-09-29 09:41:59 <gmaxwell> (conjectural, because I've not worked out a set of parameters and seen if it remotely makes sense scaling wise.   One bonus, at least, is that the same encoding could be used to achieve faster block relay.)
253 2014-09-29 09:42:25 <petertodd> btcdrak: oh, and yeah, needs a BIP of course too
254 2014-09-29 09:42:50 <sipa> you need a BIP for viacoin?
255 2014-09-29 09:42:58 <sipa> 
ACTION thinks a VIP is more appropriate

256 2014-09-29 09:43:12 <gmaxwell> hah that was worth it just for that joke
257 2014-09-29 09:43:15 <petertodd> sipa: our evil plan is to do a BIP and have you guys argue about it until we're confident we didn't miss anything
258 2014-09-29 09:43:31 <petertodd> sipa: you'll make a great father one day
259 2014-09-29 09:43:55 <gmaxwell> petertodd: working so far, since I already switched you to my alternative construction. :)
260 2014-09-29 09:43:55 <sipa> ...?
261 2014-09-29 09:44:11 <petertodd> gmaxwell: indeed, and then I improved on it slightly :)
262 2014-09-29 09:44:23 <gmaxwell> sipa: that sounded like a canonical "dad humor"
263 2014-09-29 09:44:41 <sipa> :(
264 2014-09-29 09:44:56 <gmaxwell> hah don't be sad. Everyone loves your puns.
265 2014-09-29 09:45:14 <gmaxwell> (if they can survive them or not is another question…)
266 2014-09-29 09:45:21 <sipa> it was no pun intended, actually...
267 2014-09-29 09:45:32 <petertodd> sipa: sheesh, don't tell us that!
268 2014-09-29 09:45:46 <gmaxwell> one key to dad humor is never admitting you weren't joking, I think.
269 2014-09-29 09:45:48 <sipa> i was being serious: wondering whether you were aiming for inclusion in viacoin or in bitcoin
270 2014-09-29 09:45:52 <gmaxwell> sipa: he's writing it as a proposal for Bitcoin.
271 2014-09-29 09:45:54 <sipa> I WAS NOT JOKING
272 2014-09-29 09:45:58 <petertodd> sipa: both!
273 2014-09-29 09:46:22 <sipa> also, why am i awake?
274 2014-09-29 09:46:23 <petertodd> sipa: keep in mind, I'm just a consultant, who has clients who want to see it in both viacoin and bitcoin
275 2014-09-29 09:46:52 <gmaxwell> sipa: I dunno but you're keeping me up so you should quit it.
276 2014-09-29 09:46:59 <sipa> gmaxwell: likewise
277 2014-09-29 09:47:08 <petertodd> 
ACTION doesn't know what timezone he's in anymore

278 2014-09-29 09:48:22 <gmaxwell> petertodd: somewhere in the middle of the pacific I'd guess.
279 2014-09-29 09:48:54 <petertodd> gmaxwell: lol, given my travels you'd thick smack dab in the middle of the atlantic...
280 2014-09-29 09:49:47 <gmaxwell> obviously you need to head out to this coast to resynchronize your biorithims or something. I may have an extra actual bed soon.
281 2014-09-29 09:50:32 <petertodd> gmaxwell: oh, I'll be in SF on wednesday actually
282 2014-09-29 09:50:55 <gmaxwell> ! how long are you out here for? any free time?
283 2014-09-29 09:50:55 <gribble> Error: "how" is not a valid command.
284 2014-09-29 09:51:13 <phantomcircuit> petertodd, way to bury the lead
285 2014-09-29 09:51:16 <petertodd> gmaxwell: until the 4th, should be able to get dinner or something
286 2014-09-29 09:51:24 <petertodd> phantomcircuit: lol
287 2014-09-29 09:51:45 <petertodd> gmaxwell: going to the Las Vegas bitcoin conference on the 4th, then back to TO on the 7th(?)
288 2014-09-29 09:53:38 <petertodd> gmaxwell, phantomcircuit: SF trip was planned about... yesterday
289 2014-09-29 09:55:34 <gmaxwell> petertodd: had this been planned better we probably could have gotten 99% of all #bitcoin-wizards and #bitcoin-dev channel traffic in one room. (The results of doing so are no doubt undefined by the laws of physics)
290 2014-09-29 09:56:11 <petertodd> gmaxwell: haha, yeah, the client this is for is unfortunately somewhat last minute :)
291 2014-09-29 09:56:54 <gwillen> gmaxwell: be careful, you don't want the feds to know which room to accidentally blow up ;-)
292 2014-09-29 09:57:30 <gmaxwell> s/s//
293 2014-09-29 09:59:04 <melvster> can bitcoin core / qt store more than 100 keys?
294 2014-09-29 09:59:15 <gmaxwell> Yes.
295 2014-09-29 09:59:19 <melvster> great, thx
296 2014-09-29 09:59:44 <phantomcircuit> melvster, works with millions
297 2014-09-29 09:59:51 <phantomcircuit> load time gets slightly annoying though
298 2014-09-29 10:00:24 <melvster> cool!
299 2014-09-29 10:10:37 <btcdrak> sipa: :D)))
300 2014-09-29 10:37:49 <wumpus> now that's a low limit; even the default keypool is 100, what doesn't support more than 100 keys?
301 2014-09-29 10:40:43 <wumpus> it's annoying how github keeps marking bitcoin project as 'typescript'
302 2014-09-29 10:41:53 <btcdrak> wumpus the only way around that is to outsource the transifex files from the repo.
303 2014-09-29 10:42:20 <wumpus> ...or rename them
304 2014-09-29 10:42:21 <btcdrak> wumpus in fact, it doesnt really make sense to have the translations in the repo at all, they can just be pulled during "make"
305 2014-09-29 10:42:32 <wumpus> eh... that would be very wrong
306 2014-09-29 10:42:37 <wumpus> make shouldn't rely on external sources
307 2014-09-29 10:42:42 <wumpus> deterministic building, remember? :p
308 2014-09-29 10:43:09 <btcdrak> wumpus: no reason they cant go in a separate repo then, you can just build that like any other library
309 2014-09-29 10:43:29 <btcdrak> sipa: quite seriously though. some features we want for viacoin are definitely things that bitcoin would also benefit from: since we keep sync with bitcoin it makes sense to contribute those useful patches to bitcoin first.
310 2014-09-29 10:43:44 <wumpus> well one good thing, most of it will get split off with the wallet
311 2014-09-29 10:44:11 <btcdrak> wumpus, that's true. so it's going that way anyway (to split into separate repos).
312 2014-09-29 10:46:05 <wumpus> well the wallet I'd like to split off and forget about, can't do the same for the translations right now - they're necessary for building the project
313 2014-09-29 11:55:20 <wumpus> @coryfields another file missing from the tarball :/ https://github.com/bitcoin/bitcoin/issues/4997
314 2014-09-29 14:05:16 <jgarzik> wumpus, what is a criteria for releasing 1.0, do you think?
315 2014-09-29 14:05:24 <jgarzik> gavinandresen, ^
316 2014-09-29 14:05:38 <wumpus> total world domination
317 2014-09-29 14:06:19 <gavinandresen> jgarzik: I looked at an old forum post where I sketched out what I thought needed to be in a 1.0
318 2014-09-29 14:06:43 <wumpus> headers-first!
319 2014-09-29 14:06:53 <gavinandresen> I think the only thing we’re missing is a multisig auto-backup wallet.  So if we split out the wallet functionality.....
320 2014-09-29 14:06:55 <wumpus> *not a bit obsessed with that*
321 2014-09-29 14:08:04 <gavinandresen> wumpus: just upgraded to osx 10.9.5, and getting the same ‘signature not valid’ problem others are reporting.  I’ll re-sign using 10.9.5, I bet 10.9.4 wasn’t good enough for latest gatekeeper changes……
322 2014-09-29 14:08:04 <wumpus> right, having any wallet requirements for 1.0 makes no sense anymore
323 2014-09-29 14:08:47 <michagogo> I'd imagine one criterion would be some kind of full, formal evaluation, auditing, and quadruple-checking of every bit of code
324 2014-09-29 14:09:28 <wumpus> michagogo: people are doing that all the time
325 2014-09-29 14:09:53 <wumpus> gavinandresen: ugh at the mess that is macosx
326 2014-09-29 14:10:04 <gribble> Admin, Alias, Anonymous, AutoMode, BadWords, BitcoinData, Channel, ChannelLogger, ChannelStats, Conditional, Config, Debug, Dict, Dunno, Factoids, Filter, Format, GPG, Games, Gatekeeper, Google, Herald, Internet, Later, Market, Math, MessageParser, Misc, Network, OTCOrderBook, Owner, Plugin, RSS, RatingSystem, Reply, Scheduler, Seen, Services, Status, String, Time, Topic, URL, Unix, User, (1 more message)
327 2014-09-29 14:10:04 <michagogo> ;;list
328 2014-09-29 14:10:15 <michagogo> ;;list bitcoindata
329 2014-09-29 14:10:16 <gribble> bcstats, blockdiff, blocks, bounty, diff, diffchange, estimate, genprob, genrate, gentime, halfreward, hextarget, interval, nethash, nextretarget, prevdiff, prevdiffchange, tblb, timetonext, totalbc, and tslb
330 2014-09-29 14:10:19 <gavinandresen> wumpus: yup.  Still not right, I’m now getting:  dist/Bitcoin-Qt.app: unsealed contents present in the root directory of an embedded framework
331 2014-09-29 14:10:24 <wumpus> michagogo: please don't botspam here
332 2014-09-29 14:10:46 <gavinandresen> coryfields : ping?  can you help with an OSX signing issue?
333 2014-09-29 14:10:55 <michagogo> Saying "this is complete/ready and out of beta" is really a huge deal for a piece of software that controls $,,(calc [totalbc]*[tlast])
334 2014-09-29 14:10:57 <gribble> 5073446137.5
335 2014-09-29 14:11:29 <wumpus> michagogo: that's a good argument to never call it 1.0
336 2014-09-29 14:11:40 <michagogo> wumpus: yes
337 2014-09-29 14:11:42 <michagogo> I agre
338 2014-09-29 14:11:47 <michagogo> Agree*
339 2014-09-29 14:12:04 <wumpus> I mean there are two opinions here: either arbitrarily label a release 1.0 when it has a certain feature, or *it should be perfect*... the second will never happen
340 2014-09-29 14:12:22 <michagogo> Right, that's true
341 2014-09-29 14:12:27 <wumpus> there's always 2.0, and 3.0
342 2014-09-29 14:12:29 <wumpus> :P
343 2014-09-29 14:12:37 <kinlo> or just label a version 1.0 that is good enough for the public to stimulate confidence
344 2014-09-29 14:12:46 <kinlo> being perfect is impossible, so don't try to be it
345 2014-09-29 14:13:01 <gavinandresen> 1.0, to me, means “this is a stable release that we intend to patch/support/upgrade for a while.”
346 2014-09-29 14:13:22 <michagogo> And then, what happens if something goes wrong
347 2014-09-29 14:13:22 <wumpus> hah
348 2014-09-29 14:13:30 <michagogo> Who gets blamed?
349 2014-09-29 14:13:37 <michagogo> And who gets sued?
350 2014-09-29 14:13:42 <wumpus> michagogo: you :D
351 2014-09-29 14:13:48 <kinlo> gavinandresen: that means backporting pathes, as bitcoin might require urgent upgrades on the entire network, but that can be done with any version
352 2014-09-29 14:13:56 <michagogo> What kind of liability could there be, around the world?
353 2014-09-29 14:13:59 <wumpus> michagogo: you should read the license
354 2014-09-29 14:14:01 <michagogo> Eep!
355 2014-09-29 14:14:04 <michagogo> 
ACTION hides

356 2014-09-29 14:14:54 <wumpus> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED
357 2014-09-29 14:15:47 <michagogo> It's kinda crazy to think that that clause is on a $5b piece of software, actually
358 2014-09-29 14:15:50 <wumpus> kinlo: we already backport important patches, at least to the last stable release
359 2014-09-29 14:16:27 <kinlo> wumpus: I know, luke does
360 2014-09-29 14:16:56 <michagogo> Eh?
361 2014-09-29 14:17:17 <michagogo> kinlo: I think he means e.g. 0.9.3
362 2014-09-29 14:17:23 <wumpus> yes
363 2014-09-29 14:17:45 <kinlo> michagogo: you know luke was backporting important fixes too?
364 2014-09-29 14:18:03 <kinlo> dunno if he's still doing so but there were ancient versions he was still "maintaining"
365 2014-09-29 14:18:05 <wumpus> kinlo: yes, he does
366 2014-09-29 14:18:31 <michagogo> kinlo: I don't think I knew that, actually
367 2014-09-29 14:18:59 <wumpus> michagogo: anyhow that's why companies such as Redhat exist, offering commercial support for free software solutions
368 2014-09-29 14:19:18 <michagogo> Right, good point
369 2014-09-29 14:19:26 <wumpus> michagogo: the software itself comes without warranty, but that doesn't mean you can't provide it as an extra paid service
370 2014-09-29 14:26:10 <gavinandresen> coryfields: I think I’ve figured it out, framework version symbolic links are being broken with the copy to dist/ during macdeploy, and that is making codesign unhappy.
371 2014-09-29 14:38:32 <gavinandresen> wumpus: 251938650bd79681dd93dcce346589aa5d1217d012a6f8e749165ef2149662d2  bitcoin-0.9.3-macosx.dmg uploaded
372 2014-09-29 14:38:51 <gavinandresen> wumpus: … to https://bitcoincore.org/~gavin/bin/0.9.3/
373 2014-09-29 14:39:52 <gavinandresen> wumpus: it is 5MB smaller because the framework code isn’t duplicated in it
374 2014-09-29 14:39:54 <wumpus> gavinandresen: ok, I'll update SHA256SUMS.asc and upload them
375 2014-09-29 14:40:32 <gavinandresen> wumpus: RE shasums:  to avoid confusion I always told gpg to use SHA256 when creating SHA256SUMS
376 2014-09-29 14:41:12 <gavinandresen> (default is for gpg to use SHA1 to create the signing hash, if I recall)
377 2014-09-29 14:41:30 <wumpus> gavinandresen: I've configured my gpg to use SHA512 at some point
378 2014-09-29 14:41:58 <gavinandresen> wumpus: I think you can override on the command line.  -a sha256 or something.....
379 2014-09-29 14:44:26 <wumpus> gpg --digest-algo sha256 --clearsign SHA256SUMS seems to work
380 2014-09-29 14:45:38 <wumpus> -a doesn't work, and gpg is really fussy about the order of arguments
381 2014-09-29 14:50:35 <gavinandresen> wumpus: sorry, should have dug out my notes. And should have updated doc/release_process.md long ago.
382 2014-09-29 14:53:14 <wumpus> no problem - I'll update it so that it matches what we're actually doing
383 2014-09-29 14:53:45 <rdponticelli> Isn't -a to enable the use of the agent in gpg?
384 2014-09-29 14:54:16 <wumpus> ok, new dmg and sha256sums are in place
385 2014-09-29 14:54:58 <wumpus> rdponticelli: could be, although using the agent seems to be the default
386 2014-09-29 14:56:46 <rdponticelli> No, it's for armor
387 2014-09-29 15:03:17 <michagogo> Yeah, -a for ASCII/armor
388 2014-09-29 16:01:11 <wadabada> I want to delete/remove addresses from wallet.dat file (bitcoind), pywallet can do it but not from command line. Any way to do this?
389 2014-09-29 16:38:29 <BlueMatt> wumpus: probably, it was built in one vm and run on another, but I dont think it should be so strange (both were up-to-date arch)
390 2014-09-29 16:38:45 <BlueMatt> wumpus: I'll try to reproduce when I get the motherboard back on rma
391 2014-09-29 16:38:51 <BlueMatt> wumpus: until then, dont worry about it
392 2014-09-29 17:10:02 <sipa> coryfields: present?
393 2014-09-29 17:19:33 <cfields> ugh, sorry if i've been disconnecting/connecting like crazy, shell went down and i've been trying to get my ircd back up
394 2014-09-29 17:20:37 <sipa> i was wondering how i can run bitcoind locally with the stl vector debugging enabled
395 2014-09-29 17:21:11 <sipa> but i think i found what broke the build without it
396 2014-09-29 17:21:25 <cfields> sipa: make depends with DEBUG=1
397 2014-09-29 17:21:31 <sipa> i mean without depends
398 2014-09-29 17:21:38 <cfields> ugh, something's broken? I'm just catching up
399 2014-09-29 17:21:43 <sipa> i broke it
400 2014-09-29 17:22:12 <cfields> sipa: you have to have depends built with it in order to use it
401 2014-09-29 17:23:08 <sipa> cfields: why?
402 2014-09-29 17:23:32 <sipa> seems strange that depends could do something that i can't do myself...
403 2014-09-29 17:24:18 <cfields> sipa: sorry... i meant that your dependencies (boost) must be built with the option set as well
404 2014-09-29 17:24:34 <sipa> ah, hmm
405 2014-09-29 17:24:43 <cfields> it changes symbols around
406 2014-09-29 17:24:49 <cfields> so, easiest way is to just use ours
407 2014-09-29 17:24:53 <sipa> right
408 2014-09-29 17:25:01 <cfields> sec for link
409 2014-09-29 17:25:31 <cfields> sipa: it'd probably be ok except that boost is so header-heavy and template-heavy
410 2014-09-29 17:25:51 <cfields> https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_design.html#debug_mode.design.methods.coexistence
411 2014-09-29 17:25:55 <sipa> if it's only headers, there would be no dependency to rebuild :)
412 2014-09-29 17:26:15 <sipa> but the combination of templates and non-header objects is probably the cause
413 2014-09-29 17:26:39 <gavinandresen> cfields: when you’re done with sipa, I need your brain, too
414 2014-09-29 17:26:48 <sipa> 
ACTION releases cfields

415 2014-09-29 17:28:30 <gavinandresen> cfields: I’ve got two issues: fixing macdeploy so codesign on osx 10.9.5 is happy.  And configure+brew+qt5 .....
416 2014-09-29 17:29:10 <sipa> cfields: actually, that's pretty awesome about the depends system then, that we can just selectively enable that feature for some tests
417 2014-09-29 17:30:14 <cfields> gavinandresen: yea, i'm trying to get caught up on what's going on
418 2014-09-29 17:30:49 <cfields> gavinandresen: is there a dmg now that seems to be working, and it's just a matter of getting a proper fix checked in? Or still trying to get something that actually works
419 2014-09-29 17:31:08 <gavinandresen> cfields: working dmg has been uploaded, so this is about working-in-the-future
420 2014-09-29 17:31:24 <cfields> ok
421 2014-09-29 17:31:59 <gavinandresen> so:  running macdeployqtplus inside my just-built tree, it is producing Qt frameworks with a weird structure
422 2014-09-29 17:32:08 <cfields> gavinandresen: e3d8d586 should've fixed the gatekeeper stuff wrt symlinks. I realize that didn't make it into 0.9.3 though. Have you verified that it's not enough?
423 2014-09-29 17:32:34 <gavinandresen> cfields: yes.  If I run -verbose=3, I see:
424 2014-09-29 17:32:40 <gavinandresen> Linked: dist/Bitcoin-Qt.app/Contents/Frameworks/QtWidgets.framework/QtWidgets -> Versions/5/QtWidgets
425 2014-09-29 17:32:41 <gavinandresen> Linked: dist/Bitcoin-Qt.app/Contents/Frameworks/QtWidgets.framework/Contents -> Versions/5/Contents
426 2014-09-29 17:32:57 <gavinandresen> … which I don’t understand.  It should be linking Versions/Current to Versions/5/
427 2014-09-29 17:36:14 <cfields> gavinandresen: sec, let me get a build up
428 2014-09-29 17:36:57 <gavinandresen> cfields: ok. I created a gist showing what doesn’t work, and what did:   https://gist.github.com/gavinandresen/85f475671203c0eb641c
429 2014-09-29 17:41:42 <cfields> gavinandresen: ok, that seems to line up with the structure that i had intended, because individual versions must be signed now rather than the top-level...
430 2014-09-29 17:41:50 <cfields> so what's the part that "doesn't work"? It refuses to sign?
431 2014-09-29 17:42:28 <gavinandresen> cfields: yes, codesign complains that there is extra stuff in the framework
432 2014-09-29 17:43:11 <gavinandresen> dist/Bitcoin-Qt.app: the main executable or Info.plist must be a regular file (no symlinks, etc.)
433 2014-09-29 17:43:12 <gavinandresen> In subcomponent: /Users/gavin/src/bitcoin/dist/Bitcoin-Qt.app/Contents/Frameworks/QtCore.framework
434 2014-09-29 17:45:14 <cfields> mm, trying to reproduce
435 2014-09-29 17:45:40 <cfields> i tried to follow the new recommended layout for gatekeeper, sounds like i missed something obvious
436 2014-09-29 17:49:05 <gavinandresen> cfields: you running 10.9.5 ?  10.9.4 was happy to sign the old layout
437 2014-09-29 17:50:47 <cfields> gavinandresen: yea. But I'm bothered because I thought I switched us to the futureproof(tm) layout
438 2014-09-29 17:52:49 <gavinandresen> cfields: if you’re fixing macdeployqtplus… you should include https://github.com/gavinandresen/bitcoin-git/commit/84eb04330cb8c29bc09ea2cca7c7bb5f3713e1d4
439 2014-09-29 17:53:18 <gavinandresen> cfields: that’s not needed for sign-the-first-time, but is needed by the build-and-then-sign-later process
440 2014-09-29 17:54:47 <cfields> gavinandresen: ok, thanks
441 2014-09-29 17:55:30 <cfields> gavinandresen: are you sure that issue made it into the final image, though? It's an iso which uses an index to avoid file copying rather than symlinking, because it's not compat with the standard
442 2014-09-29 17:55:52 <cfields> so if you extract files from the dmg, they'll look duped. but they're really just pointing to the same file in the image
443 2014-09-29 17:57:09 <cfields> not saying that it's not the right fix, only that the contents can be a bit deceiving if you c/p them out of the dmg
444 2014-09-29 17:58:13 <lechuga_> is relaying partially signed transactions crazy talk?
445 2014-09-29 17:58:43 <lechuga_> or could it maybe make sense and be accomodated if there were clever enough DoS prevention mechanisms in place
446 2014-09-29 18:00:06 <gavinandresen> lechuga_: crazy talk
447 2014-09-29 18:00:21 <lechuga_> :)
448 2014-09-29 18:01:33 <gavinandresen> cfields: I spent way too much time banging my head against the wall— I’d fix the structure of Bitcoin-Qt.app, then run macdeployqtplus to do the codesign + create fancy dmg, and end up with codesigning failing because macdeployqtplus was breaking the symlinks when it copied to dist/Bitcoin-Qt.app
449 2014-09-29 18:02:05 <gavinandresen> cfields: …. getting a Bitcoin-Qt.app out of the .dmg with symlinks intact might be an issue, too.
450 2014-09-29 18:02:32 <gavinandresen> (that’s just not the issue I was fixing)
451 2014-09-29 18:02:58 <cfields> gavinandresen: ok, understood
452 2014-09-29 18:03:14 <gavinandresen> lechuga_: crazy talk, because what if the person who needs to sign next doesn’t happen to be online when the partially signed transaction is relayed?
453 2014-09-29 18:03:36 <gavinandresen> lechuga_: you really need a store-and-forward system to gather signatures.
454 2014-09-29 18:04:27 <gavinandresen> And no, the blockchain is NOT a store-and-forward system. Even though people constantly seem to want to make it one......
455 2014-09-29 18:05:08 <lechuga_> it just seems like all multisig wallet solutions need this behavior and the only way to do achieve it atm seems to be to rely on a central server
456 2014-09-29 18:05:16 <lechuga_> s/do//
457 2014-09-29 18:11:03 <lechuga_> isnt the mempool store-and-forward
458 2014-09-29 18:12:00 <cfields> grabbing 10.9.5 now
459 2014-09-29 18:12:11 <cfields> sipa: meantime: is your issue worked out?
460 2014-09-29 18:15:21 <cfields> nm, i see it
461 2014-09-29 18:21:08 <jgarzik> lechuga_, check out the "EphemeralCoin" design.  I hope to put that idea to code eventually
462 2014-09-29 18:21:47 <cfields> gavinandresen: mind describing your brew+qt problem so i can be looking into that too?
463 2014-09-29 18:21:57 <jgarzik> lechuga_, Basic idea:  chain, that expires entries after 2 weeks (or sooner, if requested).  You obtain the ability to post to the chain by creating a transaction with a locktime 400 years in the future
464 2014-09-29 18:22:14 <jgarzik> as long as that coin remains unspent, you can use up to X associated resources posting to the chain
465 2014-09-29 18:22:32 <jgarzik> if the coin is spent, or your "credit" is used up, no more posting
466 2014-09-29 18:22:59 <jgarzik> lechuga_, that handles the offline case, because entries persist for a short period
467 2014-09-29 18:23:38 <lechuga_> jgarzik: awesome
468 2014-09-29 18:25:59 <lechuga_> all i can find googling for you and ephemeralcoin is a wizards log
469 2014-09-29 18:26:03 <lechuga_> that about as expected?
470 2014-09-29 18:28:14 <jgarzik> lechuga_, yes
471 2014-09-29 18:28:40 <jgarzik> lechuga_, I talk about it in the hopes that the idea will be stolen, and implemented with zero effort from me ;p
472 2014-09-29 18:33:45 <lechuga_> haha good luck with that
473 2014-09-29 18:35:19 <gavinandresen> cfields: (sorry, little meeting) :  Sure.  I done did: brew uninstall qt; brew install qt5    .  Then re-ran autogen.sh and configure, and configure doesn’t automatically find qt5
474 2014-09-29 18:36:08 <gavinandresen> cfields: if I add /usr/local/opt/qt5/bin to PATH and /usr/local/opt/qt5/lib/pkgconfig to PKG_CONFIG_PATH then configure gets happy.
475 2014-09-29 18:38:07 <cfields> gavinandresen: ok, looking
476 2014-09-29 18:38:50 <cfields> gavinandresen: side-note, just rebooted into 10.9.5, a few of my other progs went crazy, errors for busted signatures
477 2014-09-29 18:38:56 <cfields> so we're not alone :)
478 2014-09-29 18:39:11 <gavinandresen> cfields: misery loves company
479 2014-09-29 18:39:34 <cfields> odd thing to change for a patch-level update
480 2014-09-29 18:41:33 <gavinandresen> cfields: there’s probably an exploit they’re not telling us about.
481 2014-09-29 18:42:22 <cfields> yea, that'd make sense
482 2014-09-29 18:46:52 <goodbtc> I have constant crashes of bitcoin core 0.9.3 on windows xp sp3 32 bit
483 2014-09-29 18:47:37 <goodbtc> I use it with -nowallet option
484 2014-09-29 18:48:26 <lechuga_> does eventvwr say anything interesting
485 2014-09-29 18:48:29 <lechuga_> or debug.log
486 2014-09-29 18:48:58 <goodbtc> tell me where to look, I have now the crash error on the screen
487 2014-09-29 18:49:05 <lechuga_> url
488 2014-09-29 18:50:48 <goodbtc> msvcrt.dll 0x000233oc
489 2014-09-29 18:51:04 <goodbtc> *msvcrt.dll 0x0002330c
490 2014-09-29 18:53:10 <goodbtc> http://pastebin.com/mqc7bUwB + http://i.imgur.com/cC25Bxe.png
491 2014-09-29 18:53:54 <goodbtc> these I saved when I was using the beta version of 0.9.3
492 2014-09-29 18:54:28 <goodbtc> the official version have the same problem
493 2014-09-29 19:14:31 <goodbtc> best idea is to go back to 0.9.2, never had problems with that
494 2014-09-29 19:19:57 <cfields> gavinandresen: when you get a chance, could you please try: http://pastebin.com/raw.php?i=1yRgdyAC
495 2014-09-29 19:20:13 <cfields> it needs some sanitizing, but it should work for you
496 2014-09-29 19:20:46 <cfields> after patching, you'll need to ./autogen.sh and ./configure
497 2014-09-29 19:20:56 <gavinandresen> cfields: what’s the magic git or patch command to apply that to my tree?
498 2014-09-29 19:21:19 <cfields> sec
499 2014-09-29 19:24:25 <cfields> gavinandresen: "curl http://pastebin.com/raw.php?i=PF4Xjhbj | git am"
500 2014-09-29 19:25:05 <gavinandresen> cfields: … Patch does not have a valid e-mail address.
501 2014-09-29 19:25:20 <gavinandresen> must be Monday.
502 2014-09-29 19:25:30 <cfields> heh, sigh