1 2014-06-12 00:36:04 <phantomcircuit> 2014-06-12 00:37:42 UpdateTip: new best=000000000000000226587205b861852a82dee7a6d2dba770a6661186742ddce3  height=281002  log2_work=75.810496  tx=31164116  date=2014-01-17 16:34:09 progress=0.435385
  2 2014-06-12 00:56:02 <justanotheruser> phantomcircuit: why do you keep posting these?
  3 2014-06-12 00:56:19 <justanotheruser> genuinly curious, not complaining
  4 2014-06-12 00:57:06 <phantomcircuit> justanotheruser, running a reindex under valgrind
  5 2014-06-12 00:57:14 <phantomcircuit> basically just timestamping how long it's taking
  6 2014-06-12 01:40:24 <Luke-Jr> "Using a Mac, create a tarball for the 10.7 SDK" <-- what kind of cop-out is this <.<
  7 2014-06-12 01:43:05 <michagogo> Yeah, I don't understand that either
  8 2014-06-12 01:43:59 <michagogo> When I did it, it was just a matter of mounting the dmg and pulling out the 10.7 SDK dir
  9 2014-06-12 01:44:28 <michagogo> If we can create dmgs on Linux, I don't understand why we can't open them
 10 2014-06-12 01:45:15 <Hasimir> because the dmg is usually using hfs+ and by default you don't get write access to that
 11 2014-06-12 01:45:23 <michagogo> Hasimir: so?
 12 2014-06-12 01:45:39 <michagogo> You don't need write access
 13 2014-06-12 01:45:41 <Hasimir> depends what you want to do with the dmg
 14 2014-06-12 01:45:50 <Hasimir> and you can override that anyway
 15 2014-06-12 01:45:51 <michagogo> It's the Xcode dmg from apple
 16 2014-06-12 01:46:02 <michagogo> You just need to extract one directory from it
 17 2014-06-12 01:46:30 <Hasimir> yeah, I got nothing there, could just be Apple being fuckwits ...
 18 2014-06-12 01:46:50 <michagogo> No, this is our process
 19 2014-06-12 01:47:05 <Hasimir> who wrote the process?
 20 2014-06-12 01:47:20 <michagogo> cfields:
 21 2014-06-12 01:47:27 <michagogo> s/: //
 22 2014-06-12 01:48:07 <Hasimir> well, if there was a good reason for it, you know who to ask  ;)
 23 2014-06-12 01:50:24 <Hasimir> anyway, if you just need someone with a mac to do that bit for you, I'll do it
 24 2014-06-12 01:52:53 <michagogo> Hasimir: nah, I got it
 25 2014-06-12 01:53:11 <michagogo> Notice I've already gbuilt for mac
 26 2014-06-12 01:53:26 <Hasimir> ok
 27 2014-06-12 01:53:36 <michagogo> (Also, you shouldn't technically be redistributing it)
 28 2014-06-12 01:53:50 <Hasimir> probably better that way than waiting on my awful net connection
 29 2014-06-12 01:54:21 <Hasimir> I've probably got it somewhere ...
 30 2014-06-12 03:10:27 <jgarzik> blink blink.  really, we didn't check that?
 31 2014-06-12 03:21:39 <cfields> ?
 32 2014-06-12 03:25:23 <poutine> phantomcircuit, valgrind slows down stuff considerably, why would the timing be remotely relevant to anything?
 33 2014-06-12 05:35:06 <jgarzik> 
ACTION ponders replacing JSON with something very, very small: http://0bin.net/paste/AElXISFiSRDH9BOM#lBRIDi2R7J1A/U9NcJkKDTol5DPtjFxcdlASh2fjJb0=

 34 2014-06-12 05:35:35 <jgarzik> already have the implementation written for that.  about to start on JSON output.
 35 2014-06-12 06:23:45 <Luke-Jr> -rw-r--r-- 1 luke-jr luke-jr 230K Jun 12 06:19 inputs/MacOSX10.7.sdk.tar.gz <-- is this file really that small?
 36 2014-06-12 06:32:38 <michagogo> Luke-Jr: uh, I'm not sure
 37 2014-06-12 06:32:42 <michagogo> I think not, though
 38 2014-06-12 06:33:22 <michagogo> Yeah, that sounds too small to me -- how'd you get it?
 39 2014-06-12 06:33:26 <deego> Luke-Jr: file it. It colud be a text file saying "downloading.." :)
 40 2014-06-12 06:33:53 <michagogo> And you don't download that file
 41 2014-06-12 06:33:53 <michagogo> deego: nah, that would be a very long text file
 42 2014-06-12 06:33:53 <michagogo> You extract it from Xcode
 43 2014-06-12 06:34:00 <michagogo> Or rather
 44 2014-06-12 06:34:11 <Luke-Jr> michagogo: mounted the dmg and tar'd
 45 2014-06-12 06:34:14 <deego> michagogo: fine, it could be a text/html.. something.
 46 2014-06-12 06:34:14 <michagogo> You create it out of a directory extracted from Xcode
 47 2014-06-12 06:34:39 <michagogo> deego: nah, unless something's wrong it's the output of tar
 48 2014-06-12 06:34:44 <michagogo> Luke-Jr: what's in it?
 49 2014-06-12 06:34:55 <wumpus> Luke-Jr: it's 39M here
 50 2014-06-12 06:35:01 <Luke-Jr> michagogo: all the files, but 0 bytes :p
 51 2014-06-12 06:35:06 <michagogo> Yeah, 39M sounds about right
 52 2014-06-12 06:35:10 <Luke-Jr> ok, hm
 53 2014-06-12 06:35:10 <michagogo> Heh
 54 2014-06-12 06:35:19 <Luke-Jr> apple screwing around with HFS+ format I guess :/
 55 2014-06-12 06:35:26 <Luke-Jr> 
ACTION tries hfsplusutils instead

 56 2014-06-12 06:35:39 <Luke-Jr> ironically, other files are fine
 57 2014-06-12 06:35:45 <michagogo> Ah, doing it on Linux?
 58 2014-06-12 06:37:00 <Luke-Jr> yes
 59 2014-06-12 06:37:00 <wumpus> that'd be cool, I don't think anyone yet succeeded in extracting the file on linux :/
 60 2014-06-12 06:37:12 <Luke-Jr> wumpus: :|
 61 2014-06-12 06:37:46 <wumpus> currently the 'official' way to get it is to install the right xcode version on a mac then zip up the SDK files :/
 62 2014-06-12 06:40:48 <michagogo> wumpus: huh? No it's not
 63 2014-06-12 06:40:53 <michagogo> There's no need to install anything
 64 2014-06-12 06:41:09 <wumpus> michagogo: please, I don't want to argue for a change
 65 2014-06-12 06:41:25 <michagogo> You download the dmg from the dev website and take it from the .app in the dmg
 66 2014-06-12 06:41:39 <michagogo> Worked perfectly (on a Mac)
 67 2014-06-12 06:41:49 <michagogo> Pretty sure that's what the instruction I followed did
 68 2014-06-12 06:42:03 <michagogo> I don't remember being told to install it by the docs
 69 2014-06-12 06:43:04 <michagogo> 
ACTION links himself to GitHub.com/bitcoin/bitcoin/tree/v0.9.2rc2

 70 2014-06-12 06:44:25 <michagogo>   $ tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.7.sdk.tar.gz MacOSX10.7.sdk
 71 2014-06-12 06:44:25 <michagogo> To create a tarball suitable for gitian input, mount the dmg in OSX, then create it with:
 72 2014-06-12 06:44:25 <michagogo> wumpus: Unfortunately, the usual linux tools (7zip, hpmount, loopback mount) are incapable of opening this file.
 73 2014-06-12 06:47:11 <wumpus> ok, initially it involved installing, that's a little bit more refined, though it still needs a mac
 74 2014-06-12 06:47:15 <michagogo> wumpus: I'm curious: where did you see something about installing xkcd?
 75 2014-06-12 06:47:18 <michagogo> Xcode*
 76 2014-06-12 06:47:25 <wumpus> please stop it
 77 2014-06-12 06:47:38 <wumpus> as I said, I don't want to argue this, just use what work
 78 2014-06-12 06:48:03 <michagogo> wumpus: I'm not arguing. Just wondering where the install thing came from. And now I know.
 79 2014-06-12 06:50:03 <Luke-Jr> guess I'm out of OSX gitian for now :/
 80 2014-06-12 06:50:05 <Luke-Jr> https://bugzilla.kernel.org/show_bug.cgi?id=77721
 81 2014-06-12 06:50:17 <wumpus> Luke-Jr: did you see pm?
 82 2014-06-12 06:50:28 <Luke-Jr> wumpus: yes, but it defeats the purpose to use someone else's
 83 2014-06-12 06:54:47 <wumpus> there's are also various versions of the macosx 10.7 sdk on github, but the one I've tried crapped out at qt, probably an too-old version
 84 2014-06-12 06:55:27 <Luke-Jr> I wonder if we can build it from Darwin code or smth
 85 2014-06-12 06:57:36 <wumpus> this one may be newer though I haven't tried https://github.com/phracker/MacOSX-SDKs/tree/master/MacOSX10.7.sdk  ... it sucks that apple doesn't provide an official download/repository with just that sdk
 86 2014-06-12 07:00:03 <wumpus> having to download a gigabyte file to extract some files using a obscure ritual on a mac doesn't help grow the number of gitian builders
 87 2014-06-12 07:10:39 <wumpus> hah, github has a way to lock pull requests now https://github.com/blog/1847-locking-conversations
 88 2014-06-12 07:51:00 <wumpus> jgarzik: I like that idea; I was thinking in the same direction, it would allow for decoupling RPC internals from the transport mechanism used
 89 2014-06-12 07:56:59 <wumpus> jgarzik: and as an added bonus it would decrease compile time, no more need to include the whole boost::sprit stuff for every file that has something to do with RPC
 90 2014-06-12 07:57:01 <michagogo> wumpus: hm, are the access levels on repos all-or-nothing?
 91 2014-06-12 07:57:26 <michagogo> It would be nice if they had something like IRC's +v
 92 2014-06-12 07:57:41 <michagogo> Looks like locking a conversation is like setting +n
 93 2014-06-12 07:57:44 <michagogo> +m*
 94 2014-06-12 07:57:44 <wumpus> michagogo: there are 'owners' and 'collaborators' but I have no idea if there is more
 95 2014-06-12 07:58:02 <michagogo> wumpus: what's the difference?
 96 2014-06-12 07:58:13 <michagogo> Is it just that the owner creates it and adds collaborators?
 97 2014-06-12 07:58:33 <michagogo> Or can those levels both be assigned
 98 2014-06-12 07:58:34 <wumpus> michagogo: well it's really meant for discussions that go badly out of hand, for example if a link was accidentally posted on rediit :p I wouldn't use it for generally restricting it to in-group conversation
 99 2014-06-12 07:58:49 <wumpus> michagogo: yeah an owner can add collaborators I think that's the whole difference
100 2014-06-12 07:59:14 <michagogo> It might be nice to allow people to talk without giving them push access, though
101 2014-06-12 07:59:26 <michagogo> Hmm, or something like +mz
102 2014-06-12 07:59:51 <michagogo> Where comments are hidden until approved
103 2014-06-12 09:10:19 <dsnrk> is anybody with more competence than me willing to cluestick a user in #bitcoin who is reimplementing the client on their own to run a web wallet service?
104 2014-06-12 09:15:08 <Naphex> dsnrk: congratulate him and wish him the best
105 2014-06-12 09:15:18 <Naphex> maybe pass mtgox source so he can use as refference ^^
106 2014-06-12 10:01:40 <gdm85> any specific reason why -wallet=<file> must be in same directory? it doesn't accept a subdirectory either
107 2014-06-12 10:02:59 <sipa> because bdb needs an 'environment' directory
108 2014-06-12 10:03:02 <xeroc> gdm85: use -datadir!
109 2014-06-12 10:03:19 <sipa> and having the environment elsewhere could really make you shoot yourself in the foot
110 2014-06-12 10:03:34 <gdm85> xeroc: already using that
111 2014-06-12 10:03:48 <sipa> like if it's on a usb stick, the wallet file may be unusable without the corresponding host computer's env
112 2014-06-12 10:04:09 <gdm85> sipa: is wallet.dat hard coupled to BDB?
113 2014-06-12 10:04:17 <sipa> wallet.dat is a BDB file...
114 2014-06-12 10:04:39 <gdm85> 
ACTION takes note

115 2014-06-12 10:05:03 <gdm85> ls
116 2014-06-12 10:05:37 <sipa> so, what we *could* do is automatically make the directory that you specify in -wallet the environment
117 2014-06-12 10:05:55 <sipa> but nobody bothered implementing that, as the env is determined by the datadir
118 2014-06-12 10:07:18 <gdm85> sipa: no, I understand. it's a BDB environment directory. the only problem I have found with this limitation is that you will need to bind-mount first data directory and then blocks/chainstate in case you want to keep wallet.dat and the blocks/chainstate on separate partitions
119 2014-06-12 10:07:47 <sipa> just symlink the blocks/chainstate dir
120 2014-06-12 11:42:37 <terve> hey folks
121 2014-06-12 11:42:53 <terve> i am playing with listtransactions here
122 2014-06-12 11:43:12 <terve> is there any limit on amount of transcations it can display?
123 2014-06-12 11:43:45 <terve> and blockindex - it shows from which block transactions came from?
124 2014-06-12 12:38:22 <phedny> I've a question: when there are two transactions in the memory pool that try to spend the same outputs, which one will most probably be mined? the one that was received first or the one with the highest fee?
125 2014-06-12 12:40:02 <dsnrk> that situation can't happen, the second transaction would be rejected
126 2014-06-12 12:40:28 <sipa> there can never be two conflicting transactions in one node's memory pool
127 2014-06-12 12:40:47 <dsnrk> https://github.com/bitcoin/bitcoin/blob/3f39b9d4551d729c3a2e4decd810ac6887cfaeb3/src/main.cpp#L882
128 2014-06-12 12:40:50 <sipa> the reference client will ignore a conflicting one
129 2014-06-12 12:40:53 <phedny> let's rephrase; will miners expunge and existing mempool tx if they receive a tx with a higher fee trying to spend the same output?
130 2014-06-12 12:41:21 <phedny> ah, I see
131 2014-06-12 12:41:25 <sipa> the reference client won't do that
132 2014-06-12 12:41:28 <sipa> at least today
133 2014-06-12 12:41:35 <sipa> but you probably shouldn't rely on that
134 2014-06-12 12:42:23 <dsnrk> phedny: keep in mind that node all nodes will have the same mempool state. if two spends are send to different nodes at the same time they might reject different ones.
135 2014-06-12 12:42:35 <dsnrk> *that NOT all nodes
136 2014-06-12 12:42:46 <phedny> dsnrk: I understand
137 2014-06-12 12:44:19 <phedny> what I'm working on is a monitoring system that can detect when an UTXO that's under our control is spent, but our system believes it's never signed by us, in which case it would trigger the broadcast of a preconstructed "emergency tx" that transfers funds into a cold storage
138 2014-06-12 12:44:20 <hearn> phedny: there are people who'd like bitcoin to work that way. however it'd make bitcoin largely useless, or at least a lot harder to work with.
139 2014-06-12 12:44:53 <hearn> phedny: that won't work reliably, at all. once the tx is out there signed by your key, it's game over. for instance the attacker could submit the tx to all major mining pools directly.
140 2014-06-12 12:45:26 <dsnrk> not to mention, once you see the spend has happened chances are your double spend will be rejected
141 2014-06-12 12:45:37 <sipa> hearn: i don't want bitcoin to work like that, but i think it's the only way it can work in the long term :)
142 2014-06-12 12:46:24 <hearn> why are you working on a system that you think will end up being mostly useless, then? :)
143 2014-06-12 12:46:41 <hearn> it may well be that in the end, bitcoin fails as an experiment
144 2014-06-12 12:46:48 <sipa> because i don't think it would be useless
145 2014-06-12 12:46:51 <edcba> you can 'just' connect to the most node you can
146 2014-06-12 12:46:51 <hearn> it's certainly looking pretty sick at the moment
147 2014-06-12 12:46:57 <hearn> but i hope not ...
148 2014-06-12 12:47:04 <edcba> and forward the tx faster than the other...
149 2014-06-12 12:47:49 <dsnrk> edcba: that has very little chance of doing anything. phedny would have been better off spending their time not getting compromised in the first place.
150 2014-06-12 12:47:50 <edcba> you just have to pray the tx hasn't reached a large pool
151 2014-06-12 12:48:16 <edcba> dsnrk: unless he wants to sell that as a service
152 2014-06-12 12:48:33 <dsnrk> that would be a stupid service. once your key is compromised it's game over.
153 2014-06-12 12:48:44 <dsnrk> work on compartmentalisation, work on not getting popped in the first place.
154 2014-06-12 12:48:58 <phedny> dsnrk: correct, that's the reason for my question
155 2014-06-12 12:49:18 <phedny> hearn: I see what you mean, with both statements
156 2014-06-12 12:49:32 <dsnrk> phedny: got a solid hot/cold wallet system going?
157 2014-06-12 12:49:53 <phedny> dsnrk: of course that's a start
158 2014-06-12 12:50:20 <dsnrk> 
ACTION glances at inputs.io

159 2014-06-12 12:50:21 <phedny> dsnrk: what I was thinking that if we're able to detect something with the hot wallet, an emergency transfer into cold storage reduces the probability of losing coins, even if it's not failsafe
160 2014-06-12 12:50:28 <hearn> sipa: i'm not sure there's much of a market for a payment system that's very slow, and i am extra doubtful that merchants want to write special code to handle double spending. but we'll see. i see the future of bitcoin as being quite in doubt, at the moment. or at least the future of proof of work.
161 2014-06-12 12:50:39 <sipa> hearn: i don't consider bitcoin to be a payment system
162 2014-06-12 12:50:53 <edcba> money transfer !
163 2014-06-12 12:51:08 <wumpus> I don't think this is the appropriate channel to discuss doubts about the future of the bitcoin
164 2014-06-12 12:51:34 <therp> sipa: I can see the fraud proofs you explained to me in the context of side-chains being useful for regular tx as well, not just tx that move stuff to side changes. a utxo could specify in its script that within x blocks, the transaction can be rolled back by another supervising key. (or rather, the utxo would only unlock in the absence of reverse transaction). that would enable a rollback that phedny would like to see.
165 2014-06-12 12:51:50 <dsnrk> phedny: why do you believe somebody would only take a portion of your wallet?
166 2014-06-12 12:51:56 <hearn> sipa: what is it then?
167 2014-06-12 12:52:01 <wumpus> use either #bitcoin or #bitcoin-wizards or so
168 2014-06-12 12:52:12 <sipa> hearn: a digital currency, one that allows building payment systems on top
169 2014-06-12 12:52:30 <phedny> dsnrk: I don't believe anyone would do that, except when for some reason he is unaware of all the utxo
170 2014-06-12 12:52:47 <phedny> dsnrk: my question was if I can overrule his transaction by broadcasting another one (double spending) with a higher fee
171 2014-06-12 12:53:18 <phedny> but apparently that's not how the reference client works
172 2014-06-12 12:53:28 <dsnrk> phedny: yep. answer today is "no" overwhelmingly. you can try to do otherwise, but it's unlikely to make any difference.
173 2014-06-12 12:53:28 <hearn> phedny: if you could do that so could he. you end up spending the whole tx to miners fees. this is the "scorched earth" policy peter todd sometimes talks about
174 2014-06-12 12:54:10 <phedny> hearn: true; at least it reduces the incentive for stealing, except for miners ;)
175 2014-06-12 12:54:17 <hearn> phedny: at that point both of you "lose" unless of course one of you manages to get the money back from a miner, but that's hard. in reality if someone stole a key that was very valuable though, he would be tempted to work with a miner or be a miner himself to ensure you never even see the theft tx until it's appeared in a block
176 2014-06-12 12:54:56 <hearn> yes but anyone can be a miner, especially for cold storage where the money isn't likely to move much. you'd just buy some equipment and mine: unless your electricity costs are way out of whack, you'd eventually find a block even if it takes a long time to do it. and then you win.
177 2014-06-12 12:55:12 <phedny> I agree
178 2014-06-12 12:55:21 <hearn> there are really only two solutions to this kind of problem: (1) make sure you don't get hacked, (2) have a social system in place to find thieves and take the money back from them, essentially, a system for repairing mistakes in the ledger.
179 2014-06-12 12:55:33 <hearn> for example a decentralised coin tracing/marking scheme
180 2014-06-12 12:55:41 <hearn> as we lack the latter, it all boils down to (1) today
181 2014-06-12 12:55:56 <phedny> or (3) be a larger miner and cause a chain reorg
182 2014-06-12 12:56:38 <phedny> we've been focussing mostly on (1), but today I've been thinking about what we could do in the event we do get hacked
183 2014-06-12 12:56:53 <epscy> cry
184 2014-06-12 12:57:42 <dsnrk> phedny: one option is some extreme compartmentalisation. have your wallet on a server isolated from anything else that only talks to the rest of the application via an API. the isolated server can do some of it's own sanity checks and decide if what it is being told is out of the ordinary or not. not foolproof obviously, but another barrier to someone just running off with a wallet.dat.
185 2014-06-12 12:57:45 <hearn> well, as you probably already realised, bitcoin is a world that is _entirely_ based on defence. if you aren't perfect at defence, you will eventually lose everything. i suspect this is not sustainable in the long run. most people would fear such a world.
186 2014-06-12 12:57:56 <hearn> but for now that's what it is
187 2014-06-12 12:58:15 <phedny> dsnrk: that's one thing we already do
188 2014-06-12 12:58:34 <dsnrk> hearn: what? our world is already like that. if I'm not at home my house relies entirely on defence.
189 2014-06-12 12:58:38 <epscy> realtime auditing
190 2014-06-12 12:59:10 <dsnrk> phedny: that's good. if somebody gets root on your main server can they easily find out where the wallet black box is located?
191 2014-06-12 12:59:12 <hearn> no it doesn't, that's ridiculous. if someone breaks into your home whilst you're away, you can file a police report and they'll try and catch the burglar. they may or may not succeed, depends a lot on various factors, but there is definitely an offence-based component
192 2014-06-12 12:59:47 <phedny> dsnrk: at the moment they can find out IP address with netstat, but we're thinking on moving Tor in that connection
193 2014-06-12 13:00:41 <phedny> dsnrk: however, that IP doesn't allow incoming connections, so you would need to somehow send an axploit over an already open TCP connection
194 2014-06-12 13:00:49 <wumpus> bitcoin is not distinct from the rest of the world; if your bitcoin gets stolen you can also file a police report and (hopefully) they'lll try and catch the hacker, if the police doesn't take bitcoin seriously that's a political problem not a technical one
195 2014-06-12 13:00:54 <dsnrk> hearn: you can't chargeback a TV or a gold necklace. it's the same with bitcoin. police report is not the point.
196 2014-06-12 13:02:18 <dsnrk> phedny: heh, I was going to suggest a hidden service as an extreme measure. point was more that if you can find out where the wallet server is physically you can socially engineer against it. localbitcoins had issues with that sort of thing, somebody convinced their DC to reset their server for them with no authorization.
197 2014-06-12 13:02:27 <hearn> sure it's the point. if you are thinking of breaking into somebodies house or a shop, you have to balance the potential reward with the risk of getting caught. so most people don't break into other people's houses, even if the lock is kind of weak or the window would be easily shattered. there's a defensive component to the system, but also an offence-based component. bitcoin is basically risk-free for attackers: they can only win.
198 2014-06-12 13:02:41 <hearn> so there is obviously a lot of incentive to try. worst case, you waste a bit of time and earn nothing. best case: huge payoff with no risk of ever getting caught.
199 2014-06-12 13:02:54 <wumpus> hackers do get caught sometimes
200 2014-06-12 13:03:06 <phedny> dsnrk: when our server restarts, two authorized people need to supply a password to unlock the encrypted configuration block
201 2014-06-12 13:03:23 <dsnrk> phedny: yeah :) that's what saved localbitcoins too.
202 2014-06-12 13:04:12 <hearn>  the scammers. so more and more of them give into temptation
203 2014-06-12 13:04:12 <hearn> yes, it does happen occasionally, though most never do of course. i saw this working on gmail, with nigeria. it's a place where law enforcement doesn't work, basically, so there's an entire industry of hackers/scammers. it's very corrosive to their society, because the young guys, they see that the scammers have all the best stuff, the best cars, the hottest women. the honest guys get dirt, in comparison. and nothing ever happens to
204 2014-06-12 13:04:56 <wumpus> maybe the police is less effective in catching them than burglars because they've been chasing burglars for hundreds of years, and hackers only for a short while, that's always to be expected with new tech, I guess
205 2014-06-12 13:05:03 <hearn> and of course the defence doesn't work 100%. so lots of people get scammed by them, often huge losses. very problematic.
206 2014-06-12 13:05:58 <hearn> well, the internet is designed to be pretty anarchic. and that's OK. i don't think the regular internet is all that bad. but it must be recognised that ~all important bitcoin businesses sit behind Cloudflare or Incapsula for a reason. there's no real way to find DoS attackers, so you end up with everyone trying to live in walled gardens/castles. it's actually working against decentralisation, oddly enough.
207 2014-06-12 13:06:20 <wumpus> they're not 100% effective in catching burglars either, someone broke into my car a few weeks ago (with lots of damage), well it's not like they seem to be doing much
208 2014-06-12 13:06:37 <hearn> anyway, bitcoin is what it is today. changing the balance would be a huge effort, and my gut sense is that right now there's still so much important low hanging defence fruit, it's not worth focusing on other things
209 2014-06-12 13:07:21 <hearn> we need to get risk analysed wallets, hardware 2FA, etc, widely deployed. once that's done we'll probably hit the state of the art in money security and then ways to find attackers might become the next lowest hanging fruit. but not for a while yet.
210 2014-06-12 13:08:01 <hearn> yes it's true, low level crime often goes unsolved, though if they keep doing it the chances of being caught goes up a lot. but you still need strong defence. the big drop in car theft came after the widespread deployment of immobilisers.
211 2014-06-12 13:08:18 <hearn> when immobilisers get hacked, theft of that kind of car skyrockets. but those guys tend to do it repeatedly, so the risk of getting caught goes up over time.
212 2014-06-12 13:13:42 <wumpus> yes, I already had the idea from the beginning that if bitcoin would be succesful, it would improve the state of computer security, as there is actually something to steal now (instead of just copy)
213 2014-06-12 13:14:39 <wumpus> not having your private keys stolen provides a very good incentive to make things more secure
214 2014-06-12 13:15:10 <hearn> well ..... or people won't use bitcoin. i'm not sure bitcoin is enough to turn the tide on decades of writing software to be cheap and featureful rather than secure. they might say instead, rather than paying 100x more to buy really secure software, i'd rather just sell bitcoins as soon as i get them and put them into a nice safe bank :)
215 2014-06-12 13:15:24 <hearn> but it's hard to know how this will play out. there's clearly some equilibrium somewhere
216 2014-06-12 13:15:56 <wumpus> *some* people will use bitcoin, like now; technology usually adds options it doesn't replace them
217 2014-06-12 13:16:01 <hearn> yeah
218 2014-06-12 13:16:19 <hearn> by "people" i'm abbreviating, i guess i mean "some large percentage of the average population"
219 2014-06-12 13:16:29 <wumpus> there are still good reasons to ride a horse instead of taking a car
220 2014-06-12 13:16:49 <hearn> anyway, there's only one way to find out what happens and that's to try it :) someone has started implementing support for married wallets in bitcoinj
221 2014-06-12 13:16:53 <hearn> so that's a really good start.
222 2014-06-12 13:18:16 <wumpus> yeah social/economic change is extremely slow, I don't expect much from "some large percentage of the population" in the short run
223 2014-06-12 13:18:46 <epscy> hearn: what's a married wallet?, multisig?
224 2014-06-12 13:23:43 <hearn> it's a multi-sig 2-of-3 wallet where the other key is held by a risk analysis service like bitgo. i prefer the term "married wallet" because multisig can refer to lots of very different setups, and married wallets require the permission of their significant other to spend money :)
225 2014-06-12 13:23:53 <hearn> unless of course you divorce yourself from the risk analysis service
226 2014-06-12 13:24:24 <epscy> ok, so similar to greenaddress.it but 2 of 3 instead of 2 of 2?
227 2014-06-12 13:24:28 <hearn> i wrote up design notes for it a while ago, now someone has started submitting pull requests
228 2014-06-12 13:24:33 <hearn> yes like BitGo
229 2014-06-12 13:24:38 <hearn> though the code written so far is agnostic
230 2014-06-12 13:24:49 <hearn> current multisig wallet providers have to write their own wallets from scratch, which is suboptimal
231 2014-06-12 13:24:59 <epscy> i see
232 2014-06-12 13:25:38 <hearn> once bitcoinj has built in support, risk analysis (RA) providers can just provide a small plugin, and then the existing wallets can all use it. so now the RA provider can focus on their security, the quality of their 2FA, the quality of their risk analysis etc instead of worrying about things like letting the user attach notes to transactions
233 2014-06-12 13:25:42 <hearn> specialisation of effort
234 2014-06-12 13:27:58 <wumpus> sounds sensible
235 2014-06-12 13:46:27 <dgenr8> dsnrk:  "chances are your double spend will be rejected" Unfortunately it's more like 50/50 today http://bit.ly/1hR8S7s
236 2014-06-12 13:47:48 <dsnrk> dgenr8: have you been stealing from my repo? :P
237 2014-06-12 13:47:56 <dsnrk> that looks stupid similar to something I wrote
238 2014-06-12 13:48:38 <dsnrk> dgenr8: jokes aside, that's very nice
239 2014-06-12 13:48:54 <hearn> dgenr8: it'd be neat if you could link to the containing block so we can eyeball the pools doing it
240 2014-06-12 13:48:56 <hearn> and yes very nice page
241 2014-06-12 13:50:41 <hearn> so basically people using the new lower fee are getting double spent a lot. no surprise, given the general lethargy of mining pools
242 2014-06-12 13:50:54 <hearn> plus dice sites because of the eligius spam filter
243 2014-06-12 13:51:23 <dgenr8> click on tx2
244 2014-06-12 13:52:00 <dgenr8> i don't know how to identify the pool
245 2014-06-12 13:52:53 <hearn> you can just link to blockchain.info - their data isn't perfect by any means but it's not bad
246 2014-06-12 13:53:08 <hearn> http://blockorigin.pfoe.be/blocklist.php
247 2014-06-12 13:53:08 <hearn> or here
248 2014-06-12 13:54:02 <dgenr8> hearn: that looks nice
249 2014-06-12 13:54:40 <dgenr8> sipa: suppose bitcoin is not a payment network.  But is being a 5-20 minute network OK?  Doesn't it need to be a 15s network?
250 2014-06-12 13:55:24 <gavinandresen> dgenr8: in-person payments need to be just a handful of seconds
251 2014-06-12 13:55:52 <dsnrk> as someone just caught in #bitcoin, nice reorg by ghash.io just now
252 2014-06-12 13:56:36 <Emcy> how many blox
253 2014-06-12 13:58:04 <dsnrk> two
254 2014-06-12 13:58:38 <SomeoneWeird> neat
255 2014-06-12 13:58:57 <hearn> is ghash.io putting KnCMinerB-A1 into their coinbase?
256 2014-06-12 13:59:36 <hearn> gavinandresen: sure, you're preaching to the choir there, dgenr8 is the guy working on the double spend relay alerts for this exact reason ...
257 2014-06-12 14:00:11 <Emcy> DS relay is back now is it lol
258 2014-06-12 14:00:14 <hearn> gavinandresen: i must admit the fee drop is kind of a mess. i feel bad about that. i thought miners would be faster to upgrade to 0.9 than regular users, seems it's the opposite. floating fees will hopefully resolve this, though guessing what miners would drop from their mempools is still a risky proposition
259 2014-06-12 14:00:17 <dsnrk> hearn: no that block is 732KB, ghash.io are the default 341KB
260 2014-06-12 14:00:28 <hearn> right
261 2014-06-12 14:00:36 <hearn> i guess they're using the default 350kb block size
262 2014-06-12 14:00:49 <dsnrk> they weren't until a day ago, now they are
263 2014-06-12 14:00:58 <hearn> oh? what were they using until yesterday?
264 2014-06-12 14:01:02 <gavinandresen> hearn: why do you think those 0-conf double-spends are due to fee drop?  They consistent 490u fee increase looks like somebody playing with replace-by-fee
265 2014-06-12 14:01:37 <dsnrk> hearn: 1M I think. they've changed a few things, somewhere before a week ago they stopped tagging all of their blocks
266 2014-06-12 14:01:51 <gavinandresen> hearn: wait, no, I see—
267 2014-06-12 14:02:11 <gavinandresen> hearn: it is somebody playing with send-with-very-small-fees and then send-with-bigger-fees
268 2014-06-12 14:02:16 <hearn> gavinandresen: actually i might be wrong. i thought old 0.8.x miners would drop 10uBTC fee txns from their mempool as being too cheap to relay.
269 2014-06-12 14:02:42 <hearn> gavinandresen: so the miners never "see" the original tx and do "see" the second larger tx. however the merchant who has upgraded sees both. so the double spending is possible because there's a consensus failure over what enters the mempool
270 2014-06-12 14:02:52 <hearn> back in bitcoin 0.1 this could not happen because all transactions entered the mempool
271 2014-06-12 14:03:10 <dgenr8> you can change &limit= to see back to 5/2/2014 or so
272 2014-06-12 14:03:22 <hearn> gavinandresen: but i am thinking actually those txns should enter the mempool just be treated as free? perhaps they're being dropped by the free relay limiter code or something?
273 2014-06-12 14:04:10 <hearn> dsnrk: i wish we could communicate with the pool operators more easily. i want to poll them to find out what their block policies are, but the ghash io guys seem to have been mostly anonymous until yesterday? or at least not easily found
274 2014-06-12 14:04:18 <gavinandresen> hearn: if both priority and fee are too low they’re just dropped.
275 2014-06-12 14:04:24 <hearn> i guess i need to talk to this jeffery smith guy. not sure how to reach him except via twitter
276 2014-06-12 14:04:39 <hearn> gavinandresen: ah ok. that's probably what happens here then.
277 2014-06-12 14:04:42 <gavinandresen> hearn: there is a self-organized pool operators mailing list
278 2014-06-12 14:04:59 <Graet> ghash.io isnt on it
279 2014-06-12 14:05:01 <hearn> gavinandresen: would you accept a patch that puts the Core version in the coinbase?
280 2014-06-12 14:05:23 <hearn> i am not sure if it'd do anything as i guess by now most pool operators don't use the standard code to construct their coinbases at all
281 2014-06-12 14:06:24 <dsnrk> hearn: there's a contact email in their January 2014 "we aren't evil" PDF
282 2014-06-12 14:07:17 <gavinandresen> hearn: i’d have no objections to version-in-the-coinbase, but I’m pretty sure somebody will scream “PRIVACY!” ….
283 2014-06-12 14:08:09 <hearn> well, we've done the equivalent before, e.g. the height in coinbase change
284 2014-06-12 14:08:22 <hearn> given that many pools announce which blocks they solve or put their name in the coinbase anyway ...
285 2014-06-12 14:09:00 <hearn> dsnrk: do you have a url for that pdf?
286 2014-06-12 14:10:57 <dsnrk> hearn: hold on.
287 2014-06-12 14:12:25 <gavinandresen> hearn: so I’m thinking about what big coding thing to tackle next, and two things come to mind:  rewriting the transaction relay / memory pool code to be more robust against DoS attacks (do the “relay everything until we run out of bandwidth, then start dropping stuff by some priority criteria”).
288 2014-06-12 14:12:39 <dsnrk> hearn: https://ghash.io/ghashio_press_release.pdf
289 2014-06-12 14:13:02 <dsnrk> (don't be confused, that was for earlier this year not recently)
290 2014-06-12 14:13:09 <hearn> thanks! i will email them and ask if they would join the mailing list
291 2014-06-12 14:13:32 <Emcy> gavinandresen headers only /w chain backfill for bitcoin core surely?
292 2014-06-12 14:14:02 <gavinandresen> hearn: … or there is a set of changes to transaction signing that it feels like should be tackled. Rework what is hashed so big transactions aren’t constantly re-hashed and so SPV clients can know what fee a transaction paid.  Switch to Schnorr signatures because they’re better….
293 2014-06-12 14:14:09 <gavinandresen> Emcy: sipa is already working on that
294 2014-06-12 14:14:20 <Emcy> cool
295 2014-06-12 14:14:32 <Emcy> sipa +1
296 2014-06-12 14:16:49 <hearn> gavinandresen: i'd love to see a tx v3 with malleability fixes, value in scriptSig when hashing etc, but my gut feeling is that anti-DoS is more important. the general weakness of our current strategy results in ~every possible change turning into "but what about DoS" type discussion, plus, it'd really throw a spanner in the works if someone did a major DoS on the network. for instance, if we had a proper mempool limiter in place,
297 2014-06-12 14:16:49 <hearn>  probably there would be fewer double spends on dgenr8's page.
298 2014-06-12 14:17:09 <hearn> i was pondering if the mempool should become a leveldb actually, as it already has memory caching infrastructure in place.
299 2014-06-12 14:17:29 <hearn> but either big piece would be good.
300 2014-06-12 14:17:42 <thaReal> would it matter tho?
301 2014-06-12 14:17:48 <thaReal> heh sorry to jump in like that
302 2014-06-12 14:17:59 <hearn> btw it'll be a little while until i catch up with floating fees in SPV land. i'm still digesting some big coding projects myself, and lots of new contributors keep showing up and giving me code to review :)
303 2014-06-12 14:18:00 <thaReal> i know im not on the level you guys are
304 2014-06-12 14:18:28 <thaReal> but ive been spending a lot of time learning the code lately
305 2014-06-12 14:18:37 <thaReal> so yah know... a little dissapointing
306 2014-06-12 14:18:42 <thaReal> at the end of the rainbow i guess
307 2014-06-12 14:18:57 <thaReal> but i would like to help if possible
308 2014-06-12 14:19:09 <gavinandresen> hearn: implementing Schnorr signatures is the kind of thing somebody else is likely to get really excited about, so mempool/relay/DoS is probably what it’ll be for me.
309 2014-06-12 14:19:22 <hearn> i know that feeling....
310 2014-06-12 14:19:23 <wumpus> thaReal: a good way to get started is to write unit tests
311 2014-06-12 14:19:34 <hearn> wumpus: we always say that but let's face it, that's pretty boring :)
312 2014-06-12 14:19:47 <thaReal> well
313 2014-06-12 14:19:54 <thaReal> is there something specific
314 2014-06-12 14:19:55 <hearn> wumpus: i found a mini todo list of small features worked better for bitcoinj. after i posted one, a bunch of them got done by new people
315 2014-06-12 14:20:00 <thaReal> rather than just the general gitain build
316 2014-06-12 14:20:08 <thaReal> hmm
317 2014-06-12 14:20:20 <thaReal> i mean id like to work on something where i can learn too
318 2014-06-12 14:20:29 <hearn> gavinandresen: i was thinking maybe we should create a kind of "Core News" email that people can sign up for. as a start towards improving community communications. i was surprised to discover that the operators of one major bitcoin company learn about new Core releases by following your twitter feed
319 2014-06-12 14:20:38 <wumpus> hearn: well, it may be boring but that doesn't change the fact that writing tests is a good way to learn the code more deeply
320 2014-06-12 14:20:54 <thaReal> ^^ i agree
321 2014-06-12 14:21:00 <thaReal> but i would need some direction
322 2014-06-12 14:21:05 <thaReal> i mean im self taught with coding
323 2014-06-12 14:21:07 <hearn> thaReal: You could add a GUI alert to tell the user when it's time to do a fresh backup
324 2014-06-12 14:21:08 <thaReal> but im an engineer
325 2014-06-12 14:21:25 <hearn> thaReal: currently Core is not an HD wallet, so people who use it as a GUI wallet can accidentally run out of keys in the keypool without noticing.
326 2014-06-12 14:21:26 <thaReal> hmm thats actually interesting
327 2014-06-12 14:21:40 <thaReal> im aware of that
328 2014-06-12 14:21:46 <gavinandresen> hearn: good idea, somebody should do that…. (I would volunteer, but I am TERRIBLE at being responsible and doing something once a month)
329 2014-06-12 14:21:49 <thaReal> i mean ive never really had to worry about it
330 2014-06-12 14:21:53 <thaReal> hahahah
331 2014-06-12 14:21:58 <thaReal> i mean i wouldnt mind giving it a shot
332 2014-06-12 14:22:00 <wumpus> hearn: "small features" sounds good but we don't have an awful lot of them
333 2014-06-12 14:22:02 <thaReal> be gentle
334 2014-06-12 14:22:03 <thaReal> lol
335 2014-06-12 14:22:06 <hearn> wumpus: yeah i know :)
336 2014-06-12 14:22:12 <thaReal> but i mean
337 2014-06-12 14:22:13 <Belxjander> thaReal: I'm also self-taught to a degree...haven't made it beyond code monkey in the business though
338 2014-06-12 14:22:22 <thaReal> im more concerned with soem of the bigger issues
339 2014-06-12 14:22:30 <gavinandresen> hearn: … and I know I’m terrible and probably it would be good for me but I’m generally trying to shed responsibilities, not get new ones
340 2014-06-12 14:22:42 <thaReal> heh - cant blame u
341 2014-06-12 14:22:42 <wumpus> hearn: and go 'debug and fix a github issue' usually needs deeper knowledge already
342 2014-06-12 14:22:45 <hearn> gavinandresen: don't worry, was just bouncing the idea off you, not suggesting you actually do it yourself :)
343 2014-06-12 14:23:10 <thaReal> yeah, i agree
344 2014-06-12 14:23:22 <thaReal>  i mean i 'attempted' to clone a coin
345 2014-06-12 14:23:26 <hearn> gavinandresen: it's the kind of thing I bet saivann_ would do an excellent job of, with a small amount of input. and i don't mean monthly. there isn't enough important news for that. i'm thinking:    when there's a new release of Core, when there's a security event that we'd put on the website, when there's some important initiative people need to get on board with, etc
346 2014-06-12 14:23:29 <thaReal> and actually ended up learning lol
347 2014-06-12 14:23:32 <thaReal> so i threw it away
348 2014-06-12 14:23:38 <thaReal> and know id like to actually do something
349 2014-06-12 14:23:40 <hearn> gavinandresen: so probably quarterly at most
350 2014-06-12 14:23:49 <Belxjander> gavinandresen: maybe I should rebuild the automated gentoo box I had a while back...it ran a clone of itself within a screen sessioned chroot shell...and updated everything there constantly with migrating some packages out once a week
351 2014-06-12 14:23:53 <jcorgan> n/cl
352 2014-06-12 14:24:05 <wumpus> I guess this one is pretty easy: https://github.com/bitcoin/bitcoin/issues/4176
353 2014-06-12 14:24:07 <thaReal> yeah im surprised u havent taken advantage of that more
354 2014-06-12 14:24:20 <thaReal> cant think of much off the top of my head
355 2014-06-12 14:24:39 <thaReal> but if u let users maybe filter message tags or something of that nature
356 2014-06-12 14:24:54 <Belxjander> gavinandresen: that sort of thing where it can notify-on-update might be useful so you just need to make sure the box is there and working whenever you randomly care?
357 2014-06-12 14:24:59 <thaReal> you could potentially have multiple data streams for bitcoin-dev related info
358 2014-06-12 14:25:15 <thaReal> well
359 2014-06-12 14:25:20 <thaReal> yeah thats a good point
360 2014-06-12 14:25:29 <thaReal> can it stay up?
361 2014-06-12 14:25:37 <thaReal> im trying to think of another program that does something like that
362 2014-06-12 14:25:38 <jgarzik> jgarzik@hum:~/repo/bitcoin/src$ ls -l *univalue*.o
363 2014-06-12 14:25:39 <jgarzik>  133 univalue.cpp
364 2014-06-12 14:25:39 <jgarzik>   50 univalue.h
365 2014-06-12 14:25:39 <jgarzik> jgarzik@hum:~/repo/bitcoin/src$ wc -l univalue*.{h,cpp}
366 2014-06-12 14:25:39 <jgarzik> -rw-rw-r-- 1 jgarzik jgarzik  146168 Jun 12 10:23 rawtx-univalue_write.o
367 2014-06-12 14:25:39 <jgarzik> -rw-rw-r-- 1 jgarzik jgarzik 1492576 Jun 12 10:15 rawtx-univalue.o
368 2014-06-12 14:25:41 <jgarzik>  139 univalue_write.cpp
369 2014-06-12 14:25:43 <jgarzik>  322 total
370 2014-06-12 14:25:47 <jgarzik> That's right.  JSON-spirit, eat your heart out.
371 2014-06-12 14:25:55 <thaReal> hahaha
372 2014-06-12 14:25:58 <wumpus> woohoo
373 2014-06-12 14:26:05 <Belxjander> thaReal: I ran that gentoo box for 1 year unattended...and it was only 3 days latent off current gentoo at the end when I had to shutdown and relocate it
374 2014-06-12 14:26:33 <jgarzik> Note that JSON parsing (univalue_read.cpp) is not yet implemented.
375 2014-06-12 14:26:34 <hearn> thaReal: maybe designing a new RPC API that doesn't have floats anywhere would be useful :)
376 2014-06-12 14:26:52 <thaReal> heh yeah see now this is what id def love to work on
377 2014-06-12 14:26:57 <wumpus> hearn: I had actually done that, but closed it today due to lack of interest
378 2014-06-12 14:27:08 <thaReal> well sooner or later
379 2014-06-12 14:27:24 <thaReal> i think the interest will grow
380 2014-06-12 14:27:40 <thaReal> but actually so thats a good idea
381 2014-06-12 14:27:50 <wumpus> hearn: https://github.com/bitcoin/bitcoin/pull/3759
382 2014-06-12 14:27:52 <hearn> gavinandresen: by the way, not sure if you noticed, but there's a group working on Android based mobile 2FA, decentralised (using bitcoinj)
383 2014-06-12 14:27:52 <thaReal> specifically cause im terible with types in C++
384 2014-06-12 14:27:58 <thaReal> btw i hate c++ so much
385 2014-06-12 14:28:02 <hearn> gavinandresen: so your vision of multisig devices is coming slowly real
386 2014-06-12 14:28:14 <gavinandresen> hearn: huzzah!
387 2014-06-12 14:28:14 <thaReal> thats sick
388 2014-06-12 14:28:36 <hearn> wumpus: oh, i didn't even see that pull req!
389 2014-06-12 14:28:57 <thaReal> okay actually i will definitly look into this
390 2014-06-12 14:29:06 <thaReal> cause one of the things i had originally wanted to work on
391 2014-06-12 14:29:12 <thaReal> heh back before i knew what i was getting into
392 2014-06-12 14:29:28 <thaReal> was trying to rewrite a better diff algo
393 2014-06-12 14:29:30 <wumpus> hearn: maybe four options was overkill, but heh, that's what you get if everyone disagrees :)
394 2014-06-12 14:29:34 <thaReal> and moreso just kind of explain it
395 2014-06-12 14:29:53 <thaReal> and that was def one of the problems i was having being new to c
396 2014-06-12 14:30:19 <thaReal> was the precision not so much of the variables, but when they were passed through calculations
397 2014-06-12 14:30:21 <gavinandresen> Speaking of working on things… I’m still looking to pay somebody to do a little python project: https://gist.github.com/gavinandresen/88f2f247f574fe16bd57
398 2014-06-12 14:30:36 <gavinandresen> oops, wait… didn’t notice the comment, might already be done
399 2014-06-12 14:30:42 <thaReal> heh damn
400 2014-06-12 14:30:44 <thaReal> i was gonna say
401 2014-06-12 14:30:48 <thaReal> python is way more appealing
402 2014-06-12 14:30:49 <thaReal> lol
403 2014-06-12 14:31:55 <gavinandresen> PYTHON SUCKS!  PHP ROCKS!  EMACS RULES!  VI SUCKS!
404 2014-06-12 14:31:58 <gavinandresen> oops, sorry…
405 2014-06-12 14:32:20 <gavinandresen> troll-ish part of my brain couldn’t resist trying to start a holy war
406 2014-06-12 14:32:47 <thaReal> hahaha
407 2014-06-12 14:32:59 <thaReal> im not that hardcore linux that id be arguing u on those
408 2014-06-12 14:33:00 <hearn> gavinandresen: btw did you add a getfees message to the p2p protocol yet? :)
409 2014-06-12 14:33:02 <dsnrk> gavinandresen: this is low-quality bait.
410 2014-06-12 14:33:06 <thaReal> ill agree with VI SUCKS tho
411 2014-06-12 14:33:08 <thaReal> lol
412 2014-06-12 14:33:17 <upb> python is truly appscale
413 2014-06-12 14:33:44 <wumpus> HOLY WARS SUCK
414 2014-06-12 14:34:36 <thaReal> heh
415 2014-06-12 14:34:53 <Belxjander> pushing opinionated crap as "everyone knows .." is an automated marker of "the following is bullshit" after translation for me :)
416 2014-06-12 14:35:23 <Belxjander> gavinandresen: you managed to trigger my "bullshit meter" with an "oh... idiocracy alert"
417 2014-06-12 14:36:53 <hearn> gavinandresen: the other thing we'll need to tackle after SPV floating fees is the BIP70 fees upgrade.
418 2014-06-12 14:36:54 <Belxjander> upd: what do you mean "python is truly appscale" ?
419 2014-06-12 14:37:26 <thaReal> did i miss somethign here?
420 2014-06-12 14:37:30 <thaReal> well i guess yes clearly
421 2014-06-12 14:37:52 <wumpus> python is truly snake scale
422 2014-06-12 14:38:00 <thaReal> hmm
423 2014-06-12 14:38:07 <thaReal> i think i know why ur saying that
424 2014-06-12 14:38:28 <thaReal> so ty
425 2014-06-12 14:38:37 <gavinandresen> hearn: speaking of BIP70, would you be willing to take over as BIP70 Champion (aka Author) ?
426 2014-06-12 14:38:51 <thaReal> heh is that the big one?
427 2014-06-12 14:39:01 <hearn> ooh more work .... goodie :)
428 2014-06-12 14:39:13 <dsnrk> thaReal: payment protocol.
429 2014-06-12 14:39:17 <gavinandresen> hearn: like I said, I’m trying to shed responsibilities :)
430 2014-06-12 14:39:17 <thaReal> ooo
431 2014-06-12 14:39:22 <thaReal> yeah i just looked now
432 2014-06-12 14:39:32 <hearn> well, how about we put my name down AND yours, and i'll start taking part in maintaining it more.
433 2014-06-12 14:39:39 <gavinandresen> hearn: done deal.
434 2014-06-12 14:40:25 <hearn> alright. i already have a fully committed next week or two, but i'll try and do a pull req after that to take it out of draft standard, merge in my suggested changes from the mailing list a month or two ago, and try to put nick dorier's test cases somewhere useful (if they  pass bitcoinj too)
435 2014-06-12 14:40:56 <gavinandresen> I’ll move it from Draft to Final status, too
436 2014-06-12 14:40:58 <dsnrk> thaReal: BIPs you'll hear about a lot are 32, 39, 50 and 70. 50 is special because it's an adjective and verb as well as a noun.
437 2014-06-12 14:41:07 <thaReal> oh hey guys, wheres the mailing list
438 2014-06-12 14:41:10 <thaReal> heh
439 2014-06-12 14:41:28 <thaReal> well done
440 2014-06-12 14:41:32 <thaReal> nice name
441 2014-06-12 14:41:41 <hearn> thanks
442 2014-06-12 14:42:10 <thaReal> heh
443 2014-06-12 14:42:29 <thaReal> hey how can i get added to the dev mailing list?
444 2014-06-12 14:42:39 <thaReal> now that i actually have a little bit of experience
445 2014-06-12 14:42:45 <dsnrk> thaReal: do it yourself. https://lists.sourceforge.net/lists/listinfo/bitcoin-development
446 2014-06-12 14:42:53 <thaReal> awesome
447 2014-06-12 14:42:54 <thaReal> thx
448 2014-06-12 14:45:58 <Emcy> >mfw bitcoin-development 2000 unread
449 2014-06-12 14:50:41 <hearn> gavinandresen: re: schnorr signatures being cool/exciting, you might want to write up how you imagine that working and some basic design notes then send it to bitcoin-development. i've found that posting clear design docs encourages contributions very effectively. otherwise most people will simply not realise that there's a cool project hanging around waiting to be done
450 2014-06-12 14:51:13 <thaReal> ^^ that sounds like a real good idea
451 2014-06-12 14:51:21 <thaReal> i have to imagine there are others like me
452 2014-06-12 14:51:27 <thaReal> that would contribute
453 2014-06-12 14:51:34 <thaReal> if there was a little more direction
454 2014-06-12 14:51:57 <thaReal> maybe after the fix announcements..
455 2014-06-12 14:52:06 <gavinandresen> thaReal: our bottleneck is not new contributions it is code review and testing of the contributions we already have
456 2014-06-12 14:52:21 <gavinandresen> … so encouraging more contributions is not helpful.
457 2014-06-12 14:52:26 <thaReal> well i mean
458 2014-06-12 14:52:33 <thaReal> thats a contribution
459 2014-06-12 14:52:44 <thaReal> like im definitley gonig to try
460 2014-06-12 14:52:50 <thaReal> i cant promise u anything will come of it
461 2014-06-12 14:52:56 <thaReal> but hey, it cant hurt
462 2014-06-12 14:52:59 <thaReal> so let me ask you this
463 2014-06-12 14:53:13 <thaReal> is there any particular area in general that you think needs the most improvmetn
464 2014-06-12 14:53:20 <gavinandresen> that’s what I’m saying: lousy contributions that require lots of discussion and review and back-and-forth actually DO hurt
465 2014-06-12 14:53:22 <thaReal> i could venture a few guesses...
466 2014-06-12 14:53:52 <thaReal> hmm - but i mean not a test right?
467 2014-06-12 14:54:17 <thaReal> like how bad can i screw up a test i guess lol?
468 2014-06-12 14:54:34 <gavinandresen> more unit or regression tests are always welcome, and require very little review— so that’s awesome
469 2014-06-12 14:54:38 <thaReal> or i assume u mean general commits
470 2014-06-12 14:54:46 <thaReal> hmm ok
471 2014-06-12 14:54:56 <thaReal> i was interested in doing some of the regression tests
472 2014-06-12 14:55:08 <thaReal> so ill get started playing with that
473 2014-06-12 14:55:11 <thaReal> n see what comes of it
474 2014-06-12 14:55:16 <thaReal> thanks for the help
475 2014-06-12 15:05:10 <ryantw> hi.
476 2014-06-12 15:05:33 <ryantw> can someone help me with a minor patch for rpcrawtransaction.cpp ?
477 2014-06-12 15:05:55 <ryantw> i am trying to output the blocknumber and blocktime in TxToJSON
478 2014-06-12 15:06:49 <ryantw> totally stuck
479 2014-06-12 15:10:20 <gavinandresen> ryantw: what are you trying to do?  TxToJSON doesn’t include that information because it might not be known (transaction is not yet in a block, transaction was included in several blocks, perhaps none of which are on the longest chain....)
480 2014-06-12 15:10:35 <ryantw> hi
481 2014-06-12 15:10:52 <ryantw> i have a patch for 0.8.2 that outputs all transactions to json
482 2014-06-12 15:11:03 <ryantw> i am importing the json to a DB for large queries
483 2014-06-12 15:11:15 <ryantw> 12GB table using the json
484 2014-06-12 15:11:33 <ryantw> the patch separates blocks from tx's
485 2014-06-12 15:11:54 <gavinandresen> ryantw : so you’re iterating through all blocks, getting txids, then calling getrawtransaction?
486 2014-06-12 15:11:59 <ryantw> so the tx json contains all blockchain transactions, however, I would like to include the blocknumber and blocktime with the tx json
487 2014-06-12 15:12:20 <ryantw> yes i believe that is what the patch is doing
488 2014-06-12 15:12:35 <ryantw> it is outputting all transactions to a single json
489 2014-06-12 15:12:49 <ryantw> i am importing that json to a single DB query
490 2014-06-12 15:12:54 <ryantw> table
491 2014-06-12 15:12:57 <ryantw> to query
492 2014-06-12 15:13:16 <ryantw> but it would be great if I could also include the blocknumber and blocktime with the transactions json.
493 2014-06-12 15:13:27 <gavinandresen> okey dokey.  Have fun… that’s not a RPC extension we’d accept into core.
494 2014-06-12 15:13:40 <ryantw> i know
495 2014-06-12 15:13:48 <ryantw> was just wondering if someone could possibly help
496 2014-06-12 15:13:58 <ryantw> i have been going crazy for days trying to figure it out
497 2014-06-12 15:14:12 <thaReal> hey i might be able to
498 2014-06-12 15:14:21 <thaReal> wait i need to read through all those messages
499 2014-06-12 15:14:23 <thaReal> just sat down
500 2014-06-12 15:14:37 <thaReal> ooo - you want it to be built directly in..
501 2014-06-12 15:14:50 <ryantw> this is the patch i received courtesy of blockr.io
502 2014-06-12 15:14:51 <ryantw> http://pastebin.com/RcTV7R6E
503 2014-06-12 15:14:54 <thaReal> yeah no, heh - i think a bash script is the way to go
504 2014-06-12 15:15:25 <wumpus> looking at TxToJSON in master it already adds blockhash, confirmations, time and blocktime *if available*
505 2014-06-12 15:16:26 <ryantw> wumpus: is that with 0.8.2?
506 2014-06-12 15:16:42 <wumpus> no, read my comment again "looking at TxToJSON in master"
507 2014-06-12 15:16:43 <ryantw> i had to use 0.8.2 in order for the patch to work
508 2014-06-12 15:16:58 <ryantw> i see
509 2014-06-12 15:17:10 <wumpus> maybe you can backport it, or forward port the other stuff
510 2014-06-12 15:17:52 <ryantw> yea i might have to do that
511 2014-06-12 15:18:11 <ryantw> i am creating a cool project using BigQuery that will include the entire blockchain for querying
512 2014-06-12 15:18:17 <ryantw> so i wanted to include the blockchain
513 2014-06-12 15:18:31 <ryantw> because i am a big fan of bitcoin
514 2014-06-12 15:18:57 <ryantw> so someone could query all tx's/blocks using bigquery syntax for whatever reason they would want to
515 2014-06-12 15:19:46 <ryantw> i already imported all txs and blocks, except there is no way to know which blocks the tx's came from
516 2014-06-12 15:19:52 <ryantw> with my current jso
517 2014-06-12 15:20:03 <ryantw> sorry for cluttering your chatroom with this
518 2014-06-12 15:21:10 <epscy> does anyone know if we are likely to get an (optional) address index?
519 2014-06-12 15:21:19 <epscy> or if it has already been added?
520 2014-06-12 15:22:07 <hearn_> it has not been added in Bitcoin Core, though possibly maaku's work does this (don't recall)
521 2014-06-12 15:22:37 <gavinandresen> sipa had an address index patch that he doesn’t like (encourages bad behavior, like re-using addresses)
522 2014-06-12 15:22:46 <wumpus> epscy: extremely unlikely; an output-based index on the UTXO set may be added though
523 2014-06-12 15:22:58 <thaReal> ha
524 2014-06-12 15:23:43 <wumpus> epscy: but indexing the whole block chain is outside bitcoin core's responsibilities, other projects exist for that like insight
525 2014-06-12 15:24:45 <hearn_> bitcoinj has code to calculate a postgres db address index as well
526 2014-06-12 15:24:58 <epscy> ok fair enough
527 2014-06-12 15:27:14 <jgarzik> https://github.com/jgarzik/bitcoin/blob/rawtx/src/univalue.cpp
528 2014-06-12 15:27:14 <jgarzik> https://github.com/jgarzik/bitcoin/blob/rawtx/src/univalue.h
529 2014-06-12 15:27:14 <jgarzik> https://github.com/jgarzik/bitcoin/blob/rawtx/src/univalue_write.cpp
530 2014-06-12 15:27:39 <jgarzik> I found a tiny and usable JSON parser (< 100 LOC) that should work with this class, permitting total elimination of JSON-spirit.
531 2014-06-12 15:28:02 <jgarzik> the main question for that reader is license, but hopefully I can get that sorted
532 2014-06-12 15:29:53 <jgarzik> JSON output is readable, though that indentation is mildly buggy.  As always, coding the "make it pretty" stuff takes more time than the correctness portion of the code.
533 2014-06-12 15:30:33 <lorenzoasr> jgarzik: hello
534 2014-06-12 15:31:27 <thaReal> hey i have to say that i didnt really 'understand' until recently starting to learn the code on my own and when i figured that out
535 2014-06-12 15:31:34 <thaReal> well i have to say its fucking impressive
536 2014-06-12 15:31:36 <thaReal> lol
537 2014-06-12 15:31:43 <phantomcircuit> 2014-06-12 15:34:59 UpdateTip: new best=000000000000000034018de6d016b52ba3adbcec2be8d07f2c8da2c308f49f31  height=281947  log2_work=75.960567  tx=31487835  date=2014-01-23 00:30:47 progress=0.455130
538 2014-06-12 15:31:46 <phantomcircuit> ha
539 2014-06-12 15:31:48 <phantomcircuit> ok maybe this is going to take > 70 hours
540 2014-06-12 15:31:52 <thaReal> i guess from a non-coder perspective
541 2014-06-12 15:33:38 <justanotheruser> phantomcircuit: anything interesting from the valgrind?
542 2014-06-12 15:36:13 <phantomcircuit> justanotheruser, not yet
543 2014-06-12 15:36:19 <phantomcircuit> actually forget it im going to kill it now
544 2014-06-12 15:36:33 <phantomcircuit> lock 281k is high enough
545 2014-06-12 15:39:34 <lorenzoasr> Hello, does anyone know about "addredeemscript" command via RPC ? I find this "patch" of petertodd.  https://gitorious.org/bitcoin/luke-jr-bitcoin/commit/c42c9e2af57594c89cf98cd95230f322ef0ee07b .I would to know if i have simply to apply this change on bitcoind 0.9 and recompile it to make it works
546 2014-06-12 15:40:45 <phantomcircuit> not surprisingly 45% of cpu time was spent in ECDSA_verify
547 2014-06-12 15:41:10 <phantomcircuit> hmm
548 2014-06-12 15:41:35 <phantomcircuit> 15% was spent doing sha256
549 2014-06-12 15:41:45 <thaReal> lol
550 2014-06-12 15:42:31 <phantomcircuit> CTransaction::UpdateHash is 58% of that
551 2014-06-12 15:44:46 <phantomcircuit> http://198.27.67.106/callgrind.out.24457
552 2014-06-12 15:48:23 <jgarzik> lorenzoasr, hello
553 2014-06-12 15:48:36 <hearn_> phantomcircuit: there's a pull req to reduce redundant hashing, i think
554 2014-06-12 15:48:43 <hearn_> txns get rehashed over and over again pointlessly
555 2014-06-12 15:48:59 <phantomcircuit> hearn_, that's what im testing
556 2014-06-12 15:49:16 <gmaxwell> hearn_: phantomcircuit's been working on that, his profiling is what resulted in it. :)
557 2014-06-12 15:49:36 <phantomcircuit> seems like there is still redundant hashing with blocks
558 2014-06-12 15:49:44 <jgarzik> lorenzoasr, give it a try and see...
559 2014-06-12 15:51:45 <hearn> ah ha
560 2014-06-12 15:52:14 <jgarzik> 
ACTION wants all C++ templates to just die

561 2014-06-12 15:52:29 <jgarzik> ban templates from the build at compiler level
562 2014-06-12 15:54:26 <wumpus> c++ becomes a lot less powerful language without templates
563 2014-06-12 15:55:51 <Naphex> ~3~u-
564 2014-06-12 15:56:00 <wumpus> that doesn't mean they should be used for everything, but they are a powerful tool, just imagine the c++ standard library without them
565 2014-06-12 15:56:09 <Naphex> b\
566 2014-06-12 15:56:10 <Naphex> \
567 2014-06-12 15:57:33 <phantomcircuit> https://i.imgur.com/79v5If4.jpg
568 2014-06-12 15:57:41 <phantomcircuit> loverly visualization
569 2014-06-12 15:58:37 <thaReal> wow that is pretty cool
570 2014-06-12 15:59:17 <wumpus> seems like BN_mul_mont and sha256_block_data_order are the heavy hitters, everything else is peanuts in comparison
571 2014-06-12 15:59:28 <gdm85> is it possible to take a snapshot of chainstate while it's being used by bitcoind? It's not AFAIU
572 2014-06-12 15:59:48 <wumpus> gdm85: no
573 2014-06-12 16:00:42 <phantomcircuit> wumpus, yup
574 2014-06-12 16:00:54 <gmaxwell> phantomcircuit: is that a profile of a few blocks near the tip?  The EC parts are less exciting to profile at the moment, since sipa's code already makes those a bunch faster.
575 2014-06-12 16:01:17 <phantomcircuit> gmaxwell, it's upto block ~281k
576 2014-06-12 16:01:45 <phantomcircuit> wanted to get a more complete profile
577 2014-06-12 16:01:57 <phantomcircuit> but i wasn't going to wait another 4 days for it to finish
578 2014-06-12 16:02:54 <lorenzoasr> jgarzik, i'll try it :)
579 2014-06-12 16:02:58 <wumpus> the picture looks very similar to when I tried with only a few blocks, it's good to confirm that
580 2014-06-12 16:03:39 <phantomcircuit> wumpus, it looks very different depending on which blocks you're profiling
581 2014-06-12 16:05:04 <wumpus> the relative amount of time spent in sha256 should go down with #4309 merged
582 2014-06-12 16:06:25 <phantomcircuit> that's what im working on
583 2014-06-12 16:06:44 <wumpus> and EC should be faster with #4312 merged
584 2014-06-12 16:07:28 <phantomcircuit> that's libsecp256k1?
585 2014-06-12 16:08:26 <phantomcircuit> yeah
586 2014-06-12 16:08:51 <phantomcircuit> wumpus, work not done is easier than working faster :P
587 2014-06-12 16:10:03 <thaReal> heh work smarter not harder ;)