1 2014-07-14 02:20:24 <super3> has any progress been made on gavin's proposed broadcast 0 confirm double spends?
  2 2014-07-14 02:20:58 <justanotheruser> super3: replace by fee?
  3 2014-07-14 02:21:10 <justanotheruser> I thought that was peter todds proposal
  4 2014-07-14 02:21:25 <super3> nah, its another one i think let me find the pull
  5 2014-07-14 02:24:39 <super3> well i can't find it now
  6 2014-07-14 02:24:48 <super3> it must have been closed
  7 2014-07-14 02:24:56 <super3> its was there for months
  8 2014-07-14 02:28:57 <kazcw> super3: there was a pull accepted in the end of june for limited doublespend relaying
  9 2014-07-14 02:49:02 <super3> kazcw: oh ok thats were it went. thanks
 10 2014-07-14 02:49:42 <jgarzik> super3, it was merged, but there are several problems with it
 11 2014-07-14 02:49:55 <jgarzik> super3, why do you need it, if I may ask?
 12 2014-07-14 02:52:01 <mr_burdell> https://github.com/bitcoin/bitcoin/pull/3883
 13 2014-07-14 02:53:14 <super3> i just found it particularly interesting, and wanted to follow its progress
 14 2014-07-14 02:53:20 <super3> mr_burdell: thank you
 15 2014-07-14 02:53:27 <mr_burdell> and this: https://github.com/bitcoin/bitcoin/pull/4484
 16 2014-07-14 05:51:34 <RainMan28> Is there a way for me to be able to change the transaction fee on Bitcoin Core on Windows? In the GUI options there's a setting which doesn't actually make any difference. I have tried setting the fee lower than 0.0001 BTC but it does not respect it.
 17 2014-07-14 05:58:51 <sipa> it sets the fee per kilobyte
 18 2014-07-14 05:59:04 <RainMan28> hi sipa
 19 2014-07-14 05:59:25 <RainMan28> sipa: but even if I set it to 0 in the GUI, it still doesn't respect that
 20 2014-07-14 05:59:26 <sipa> and it will not go below the fee that would make it consider the transavction as spam
 21 2014-07-14 05:59:32 <RainMan28> I was trying 0.00005 BTC
 22 2014-07-14 06:00:02 <RainMan28> really? I was trying to send 0.5 BTC with 0.00005 and it still pops up saying it needs 0.0001 BTC
 23 2014-07-14 07:00:35 <RainMan28> sipa: any idea why a 0.5 BTC transaction would be seen as spam?
 24 2014-07-14 07:05:28 <justanotheruser> RainMan28: did it have a fee? Did it have many days destroyed?
 25 2014-07-14 07:05:53 <RainMan28> hey justanotheruser i'm actually trying to set the fee in bitcoin core to be 0.00005 BTC
 26 2014-07-14 07:06:17 <RainMan28> but it still continues to want to charge 0.0001 BTC
 27 2014-07-14 07:08:14 <justanotheruser> RainMan28: so it isn't propogating?
 28 2014-07-14 07:09:19 <RainMan28> justanotheruser: no i don't actually send it, it just prompts me that a fee of 0.0001 will be required
 29 2014-07-14 07:09:26 <RainMan28> and i'm trying to see if i can have the fee changed to 0.00005 instead
 30 2014-07-14 07:09:45 <RainMan28> like why does the Bitcoin Core wallet GUI have a place to enter in a fee, but it doesn't actually respect that value
 31 2014-07-14 07:11:44 <kazcw> RainMan28: the fee is per KB. Has your wallet received a lot of small payments in the past? ~8 inputs could add up to a ~2KB transaction
 32 2014-07-14 07:12:46 <kazcw> there are also other factors, it would be impossible for the wallet to always pay exactly the fee you specify
 33 2014-07-14 07:13:19 <RainMan28> ah ok
 34 2014-07-14 07:13:48 <RainMan28> kazcw: if i didn't care about the speed it took to confirm, I couldn't set the fee to 0?
 35 2014-07-14 07:14:56 <otila> RainMan28: what about using -txconfirmtarget=3 -paytxfee=0
 36 2014-07-14 07:15:50 <RainMan28> otila: if I type getinfo on the console, it shows me the tx fee is : "paytxfee": 0.00005000
 37 2014-07-14 07:16:15 <RainMan28> otila: but i'm trying to make it work via the GUI, not send transactions from console
 38 2014-07-14 07:16:42 <otila> you can give options for gui
 39 2014-07-14 07:17:19 <RainMan28> how?
 40 2014-07-14 07:17:31 <otila> -txconfirmtarget=<n>   If paytxfee is not set, include enough fee so transactions are confirmed on average within n blocks (default: 1)
 41 2014-07-14 07:17:52 <kazcw> otila: dynamic fee estimation is only in git. RainMan28: if you're running a released version rather than a recent testing version, those options won't be available
 42 2014-07-14 07:18:06 <RainMan28> kazcw: i'm on 0.9.2.1 on windows 7
 43 2014-07-14 07:18:24 <otila> I was going to mention that next :)
 44 2014-07-14 07:18:36 <RainMan28> kazcw: I have 6 unspent outputs with 0.85 BTC total amongst them
 45 2014-07-14 07:20:47 <RainMan28> so the biggest unspent is 0.194 BTC. If i try sending a transaction of 0.18, that should only be using that single unspent, but still the wallet wants to charge 0.0001
 46 2014-07-14 10:45:45 <ghash-io> hello
 47 2014-07-14 11:53:30 <darkip> Hi, are there any issues in 0.9.2 that would mean that I should fork an older version / master ?
 48 2014-07-14 12:11:49 <hearn> gmaxwell: thanks!
 49 2014-07-14 12:11:56 <hearn> darkip: not that i heard of, why?
 50 2014-07-14 12:12:05 <darkip> Thanks
 51 2014-07-14 12:12:09 <darkip> I'm forking for an alt
 52 2014-07-14 12:12:17 <darkip> But want to use the latest bitcoin code
 53 2014-07-14 12:12:30 <hearn> well, you would need to keep up no matter what
 54 2014-07-14 12:12:33 <hearn> so best to use the latest code
 55 2014-07-14 12:24:08 <SatoshiSon> Hi all https://bitcointalk.org/index.php?topic=683704
 56 2014-07-14 14:15:57 <xenog> hey people, I tried to discuss an issue with AddTimeData yesterday here, but I think World Cup final meant that nobody was really here then :)
 57 2014-07-14 14:16:51 <xenog> I sent issue #4521 to the GitHub issues for bitcoin, as well as a pull request, any questions please contact me and I'll gladly help
 58 2014-07-14 14:40:14 <wumpus> xenog: seems to make sense to me
 59 2014-07-14 14:43:07 <xenog> wumpus: good, then I guess I didn't miss anything
 60 2014-07-14 14:43:38 <xenog> I don't code C++ on a daily basis, I do Haskell, which is very different, so a C++ dev should look at the fix and see if I may have missed something
 61 2014-07-14 14:45:16 <xenog> wumpus: if you are a C++ dev, that is the case then, and everything should be cool
 62 2014-07-14 14:45:40 <xenog> wumpus: thanks for looking at it
 63 2014-07-14 14:49:14 <maaku> xenog: it'd be awesome to have another contributor to haskoin ;)
 64 2014-07-14 14:49:35 <wumpus> xenog: that bug went unfixed for pretty long, it makes me wonder if we really need the time offset functionality at all
 65 2014-07-14 14:49:56 <xenog> maaku: I started Haskoin, although I haven't been the one doing most of the coding
 66 2014-07-14 14:51:46 <xenog> maaku: the idea was born after two or three pints in a pub in Zurich with Pieter Wuile, Mike Hearn, and Stefan Thomas, I was like: "it would be cool to make a Bitcoin client in Haskell", then my friend and colleague Philippe Laprade, who was very much into Haskell and functional programming, decided to execute on the idea, he had more time in his hands than I did at the time
 67 2014-07-14 14:52:33 <maaku> haha ok :)
 68 2014-07-14 14:53:03 <maaku> i've played with it, and want to use it in more projects
 69 2014-07-14 14:53:12 <maaku> hard to convince my coworkers to use haskell though :\
 70 2014-07-14 14:53:43 <xenog> maaku: we'll have a bitcoind-like daemon for the wallet with SPV-features pretty soon, with the functionality exposed via a JSON API, so no Haskell expertise will be required to use it
 71 2014-07-14 14:54:37 <xenog> wumpus: when I was reading that time offset code, I came to the list to ask for the rationale behind it
 72 2014-07-14 14:55:24 <xenog> NTP is a somewhat-centralized system, and it could be attacked to skew clocks and cause some havoc, which could have unforeseen consequences in the Bitcoin network
 73 2014-07-14 14:55:36 <maaku> xenog: open source?
 74 2014-07-14 14:55:43 <xenog> maaku: certainly
 75 2014-07-14 14:56:12 <xenog> maaku: all code is released to the public domain
 76 2014-07-14 14:56:24 <xenog> unlicense.org
 77 2014-07-14 14:56:48 <xenog> we are strongly against intellectual monopoly
 78 2014-07-14 14:59:09 <wumpus> xenog: right, NTP (over network) could be confused, I don't think we should integrate that either
 79 2014-07-14 14:59:18 <xenog> we'll run a wallet from our own servers with some security protocols in place for people that would rather trust us to run the services, but the platform is public domain
 80 2014-07-14 15:01:07 <xenog> wumpus, yes, NTP is currently a reliable way to synchronize system clocks, but since it can be gamed, we get that time offset kluge, which is not perfect, and it is still vulnerably to Sybil attacks
 81 2014-07-14 15:01:25 <xenog> wumpus: we argued at length in Haskoin whether to implement the time offset thing
 82 2014-07-14 15:01:39 <xenog> wumpus: we did not reach any conclusion, therefore we are going to implement it
 83 2014-07-14 15:02:47 <xenog> if only to achieve the same behaviour as bitcoind and not give core developers more reasons to mistrust multiple implementations out of concerns for different behaviours leading to chaos
 84 2014-07-14 15:07:06 <xenog> by the way, maaku, if you want to take a potshot at doing something for haskoin, haskoin needs you, we still do not have payment protocol support ;-)
 85 2014-07-14 15:08:35 <wumpus> xenog: well I'd think someone that can attack the global NTP infrastructure to mess with bitcoin nodes can also trivially sybil attack nodes to produce a time offset
 86 2014-07-14 15:09:23 <xenog> yes, but a sybil attack against nodes will lead to skewed clocks that may in the end agree about the network time anyways
 87 2014-07-14 15:09:38 <jtimon> xenog I prefer the term "intellectual poverty" ;)
 88 2014-07-14 15:10:46 <xenog> an attack against the NTP network and code that filters, say any peer that is not within five minutes, instead of the 70-minute gap that is currently allowed, could lead to isolated nodes that can then be sybil-attacked into believing certain transactions are valid with some people not noticing
 89 2014-07-14 15:11:26 <maaku> xenog: I may reach out to you privately. we're doing some wallet applications and evaluating arious options
 90 2014-07-14 15:11:31 <xenog> perhaps some of us running Bitcoin companies and servers should consider having GPS devices to get the time from the GPS satellite network, and/or precise hardware clocks set by hand
 91 2014-07-14 15:11:47 <xenog> maaku: that sounds great
 92 2014-07-14 15:11:51 <xenog> maaku: root@haskoin.com
 93 2014-07-14 15:11:58 <maaku> thanks
 94 2014-07-14 15:12:46 <maaku> are gps or glonass timestamps signed?
 95 2014-07-14 15:13:19 <xenog> maaku: I'm afraid not, but if they were tampered with, I believe we would notice a lot more quickly than an NTP attack
 96 2014-07-14 15:13:33 <maaku> well and there's no reason you can't do both
 97 2014-07-14 15:13:34 <sipa> yeah, the time adjustment makes me a bit unconfortable
 98 2014-07-14 15:13:58 <xenog> I'll start being in Alaska or Antarctica suddenly, and that is not right, because my servers are not in space or baloons
 99 2014-07-14 15:14:14 <sipa> xenog: oh, that was you at the zurich meetup back then :)
100 2014-07-14 15:14:21 <xenog> maaku: well, I don't know if they are signed
101 2014-07-14 15:14:23 <sipa> xenog: in june 2012 iirc, right?
102 2014-07-14 15:14:26 <xenog> sipa: yeah!
103 2014-07-14 15:14:38 <xenog> sipa: yes, when you were visiting Google's offices
104 2014-07-14 15:14:51 <xenog> sipa, before I moved to Ireland
105 2014-07-14 15:15:10 <sipa> right
106 2014-07-14 15:16:11 <hearn> maaku: you can get signed timestamps from various TSA's.
107 2014-07-14 15:16:31 <maaku> hearn: TSA?
108 2014-07-14 15:16:59 <xenog> hearn: I was looking for TSA on the Internet, but I could only get to Transport Security Administration, is that what you meant?
109 2014-07-14 15:17:16 <sipa> time stamping authority?
110 2014-07-14 15:17:17 <hearn> timestamping authority. (rfc 3161)
111 2014-07-14 15:17:19 <hearn> http://en.wikipedia.org/wiki/Trusted_timestamping#Trusted_.28digital.29_timestamping
112 2014-07-14 15:17:55 <hearn> most CA's run one
113 2014-07-14 15:18:00 <hearn> (all?)
114 2014-07-14 15:18:34 <hearn> so if we wanted a more robust time cross-check than NTP we could use those. they're exposed via HTTP
115 2014-07-14 15:18:52 <maaku> hearn: oh ok. it was the ubiquitous over-the-air option that seemed interesting
116 2014-07-14 15:19:00 <hearn> those servers tend to be synced to GPS
117 2014-07-14 15:19:05 <hearn> but a direct path would have been nice yes
118 2014-07-14 15:19:08 <sipa> how about we just leave the responsibility of having a decently synced clock to the system operator?
119 2014-07-14 15:19:12 <drizztbsd> do you trust CA :P
120 2014-07-14 15:19:42 <xenog> I tend to agree with sipa that it is not bitcoin's job to keep time synced
121 2014-07-14 15:19:56 <hearn> you can also get authenticated NTP (using hashes)
122 2014-07-14 15:20:06 <hearn> well, i think that's what bitcoin already does, no?
123 2014-07-14 15:20:20 <sipa> bitcoin has no ntp
124 2014-07-14 15:20:34 <hearn> right. there was a TODO from satoshi to add it
125 2014-07-14 15:20:38 <sipa> indeed
126 2014-07-14 15:24:21 <wumpus> every OS has NTP, no need to implement it in bitcoin
127 2014-07-14 15:24:36 <wumpus> sipa: +1 for leaving the responsibility up to the system operator
128 2014-07-14 15:25:02 <sipa> we could do some safety checking, similar to the current time adjustment, but just warn if it looks suspiciously high
129 2014-07-14 15:25:05 <gmaxwell> hearn: authenticated NTP is mostly only used privacy (to the extent that its used at all). The only publically known servers I'm aware of are a pair run by NIST where you have to send them a dead-tree letter to get access.
130 2014-07-14 15:25:21 <wumpus> he can either use NTP, set the clock manually, or some super-precise hardware clock connected to the machine, better to encourage diversity here to avoid a single attack vector
131 2014-07-14 15:25:38 <gmaxwell> A reasonable thing to do, I think, is to query the local service to decide what it thinks the state of the world is— e.g. if it thinks its in sync then trust the local clock more strongly.
132 2014-07-14 15:25:45 <sipa> even a few minutes off is not a problem for us
133 2014-07-14 15:25:55 <sipa> what local service? :o
134 2014-07-14 15:26:14 <gmaxwell> NTP (see the code in gnunet)
135 2014-07-14 15:26:14 <sipa> does every OS run a ntpd now?
136 2014-07-14 15:26:23 <kuzetsa> yeah, what gmaxwell is about right -- authenticated NTP is mostly only used by government sponsored institutitons (military and metrology authorities)
137 2014-07-14 15:26:25 <sipa> seems i'm indeed running one
138 2014-07-14 15:26:36 <kuzetsa> and in the 'states, NIST and USNO are the main ones for that.
139 2014-07-14 15:26:39 <sipa> i remember 10 years ago i had to configure it manually
140 2014-07-14 15:26:46 <gmaxwell> (or likewise have a setting e.g. localclock=1 that basically clamps the offset adjustments to 10 minutes or something small, — risk of breaking your node if your time is a bit wrong)
141 2014-07-14 15:26:54 <wumpus> I doubt windows runs ntpd specifically, they use some NTP implemention of course
142 2014-07-14 15:27:14 <gmaxwell> yea, windows doesn't. I believe everything else does. All the gnu/linux distros set it up by default.
143 2014-07-14 15:27:26 <wumpus> my ubuntu doesn't have ntpd running either
144 2014-07-14 15:27:31 <gmaxwell> wild
145 2014-07-14 15:27:46 <gmaxwell> In any case thus the reason to detect if its happy.
146 2014-07-14 15:27:47 <hearn> seems like my mac does
147 2014-07-14 15:28:08 <sipa> gmaxwell: feel free to port/copy/steal/... some gnunet code then :)
148 2014-07-14 15:28:24 <sipa> but meh
149 2014-07-14 15:28:28 <sipa> do we really need to bother?
150 2014-07-14 15:28:38 <sipa> we have very light synchronization requirements
151 2014-07-14 15:29:01 <sipa> you could be an hour off and survive, i guess...
152 2014-07-14 15:29:05 <gmaxwell> we're due some timing cleanup, but I'll worry about it. I've wanted to work on it for a while but haven't had time and should have some soon.
153 2014-07-14 15:29:15 <maaku> i thought windows did npt sync with msft's servers?
154 2014-07-14 15:29:16 <xenog> gmaxwell: I believe Windows does run NTP
155 2014-07-14 15:29:26 <xenog> Ubuntu synchronizes upon network connection via ntpdate
156 2014-07-14 15:29:28 <wumpus> windows obviously runs ntp, but not ntpd
157 2014-07-14 15:29:33 <gmaxwell> xenog: sntp normally but it's just a periodic set so it doesn't know if its right or not.
158 2014-07-14 15:29:34 <maaku> ah
159 2014-07-14 15:30:05 <gmaxwell> sipa: right now there are some annoying attacks where you push a miner and a users clocks in opposite directions to partition them.
160 2014-07-14 15:30:16 <gmaxwell> they're not terribly concerning but should be closed.
161 2014-07-14 15:30:41 <sipa> well yes, which is a problem with the current network-based time offset guessing
162 2014-07-14 15:30:44 <kuzetsa> wumpus: technically, windows time protocol supports the proprietary "windows time" protocol relating to how domain controllers work... but also does SNTP, yeah.
163 2014-07-14 15:30:51 <sipa> but is it a problem if we just trust local systems?
164 2014-07-14 15:30:56 <gmaxwell> we only need to allow large corrections because it's _very_ common for hosts to have the wrong timezone (e.g. windows hosts)
165 2014-07-14 15:31:07 <kuzetsa> hmm, I mangled that grammar, but I think my point survived mostly O_O
166 2014-07-14 15:31:38 <gmaxwell> e.g. people set their timezone to something off, then set the local time to the local time, so they're off by an hour. Also +/- summer time.
167 2014-07-14 15:32:06 <kuzetsa> I'm certain that's not a windows-specific issue
168 2014-07-14 15:32:13 <hearn> we did an experiment to measure this once at google
169 2014-07-14 15:32:15 <kuzetsa> ANY user who manually sets their clock does that
170 2014-07-14 15:32:28 <hearn> the degree to which people are in the wrong timezone seems to be huge and varies around the world
171 2014-07-14 15:32:40 <gmaxwell> we get people complaining about it on IRC with non-trivial frequency when they end up outside of the window bitcoin-qt will adjust.
172 2014-07-14 15:33:00 <wumpus> in that case it can just complain that the time/timezone is wrong
173 2014-07-14 15:33:12 <xenog> well, the bitcoind code will accept if you are one hour off, but not more than 70 minutes, at which point it displays a warning, and sets the offset to zero, but I am not sure it actually disconnects from the network, although it stops updating the offset
174 2014-07-14 15:33:20 <gmaxwell> in any case, if the local host thinks it's right we should just make the network adjustment small... closes off most of the obnoxious stuff without making the software burdensom for joe-user.
175 2014-07-14 15:33:35 <gmaxwell> wumpus: I can show you some logs, this is really hard for the users.
176 2014-07-14 15:33:35 <wumpus> I don't see it as a responsibility of bitcoind to correct the user's time
177 2014-07-14 15:33:49 <gmaxwell> "It's right, what the f@#$@ is wrong with you!  I told you my time is right!"
178 2014-07-14 15:34:05 <gmaxwell> (dramatization)
179 2014-07-14 15:34:08 <kuzetsa> :)
180 2014-07-14 15:34:32 <sipa> we'll just create a separate p2p network for each timezone
181 2014-07-14 15:34:38 <sipa> and use local time in the protocol
182 2014-07-14 15:34:41 <kuzetsa> O_O
183 2014-07-14 15:34:46 <sipa> at startup you connect to all, and you see what sticks :p
184 2014-07-14 15:34:49 <sipa> (j/k)
185 2014-07-14 15:34:51 <kuzetsa> sipa: satire / sarcasm?
186 2014-07-14 15:34:53 <gmaxwell> heh, in any case. pulls to review.
187 2014-07-14 15:35:02 <wumpus> gmaxwell: you have a point, but there are so many things that can be wrongly configured on a computer system that may be frustrating
188 2014-07-14 15:35:38 <wumpus> by adding our own layer of guesses and compensations on top, it may become more frustrating instead of less
189 2014-07-14 15:36:30 <wumpus> (especially if there is a small undetected bug somewhere in barely tested code, as turns out to be in the current time handling code...)
190 2014-07-14 15:39:48 <gmaxwell> well thats a reason that the nits we were aware of haven't been fixed.
191 2014-07-14 15:40:15 <kuzetsa> *cough*  #2990
192 2014-07-14 15:41:17 <wumpus> so it may be best solved by adding a clear error message, in which wrong time, the timezone and summer/winter time are mentioned as possible reasons for the deviation
193 2014-07-14 15:42:32 <kuzetsa> yeah, and some debug-transparency showing which & how many, or otherwise specifically which datapoints are being used to decide the time is suspected to be wrong
194 2014-07-14 15:43:08 <kuzetsa> I've never used the debug logging features to see if "wrong time" details show up in the logs or not
195 2014-07-14 15:44:41 <kuzetsa> transparency and being able to examine datapoints is better than guessing and making assumptions and then generically reporting the common assumptions to the user
196 2014-07-14 15:44:56 <xenog> I'd argue that you should merge my pull request anyway, even if you later remove the code, because if you want to revert, you revert to a version that works
197 2014-07-14 15:46:32 <kuzetsa> xenog: this one? --> https://github.com/bitcoin/bitcoin/pull/4526
198 2014-07-14 15:46:46 <xenog> yup
199 2014-07-14 15:48:01 <gmaxwell> please don't go removing time corrections right now. :)  (but I'm all for adding gui on time nagging!)
200 2014-07-14 15:48:38 <dgenr8> Getting an accurate absolute time is hard.  But for some uses it is possible to require only that local clock runs at an accurate RATE over the periods involved.
201 2014-07-14 15:49:14 <jaakkos> people with wrong timezone on their phone makes it fun to configure TOTP authentication in your company :(
202 2014-07-14 15:49:16 <kuzetsa> dgenr8: yes, frequency stability is unlikely to drift by more than 5 minutes per day even in the worst conditions.
203 2014-07-14 15:50:01 <gmaxwell> dgenr8: computer osc have such large frequency errors ... alas.
204 2014-07-14 15:50:13 <kuzetsa> jaakkos: hehe, yeah. I use TOTP on like almost everything which supports it :)
205 2014-07-14 15:52:05 <kuzetsa> gmaxwell: I can't tell if you were being sarastic or not --- I've usually seen in my own observations that an undisciplined clock drift of over a thousand PPM is VERY rare
206 2014-07-14 15:52:39 <dgenr8> If your clock runs fast or slow, you'll have to get absolute adjustments terribly often to make up for it in any absolute scheme.
207 2014-07-14 15:53:17 <gwillen> I had a computer with very irritatingly large clock drift once, but it was nowhere near 5 minutes per day
208 2014-07-14 15:53:49 <kuzetsa> gwillen: I get irritated if the drift is even 1 second per month
209 2014-07-14 15:54:06 <gwillen> mine was on the order of double-digit minutes per month
210 2014-07-14 15:54:09 <gwillen> it was irritating as hell
211 2014-07-14 15:54:15 <kuzetsa> 
ACTION nods

212 2014-07-14 15:54:33 <gwillen> (the actual problem, of course, being that my ntpd was not fixing this, and eventually I fixed whatever the configuration issue was, and then it did.)
213 2014-07-14 15:54:46 <kuzetsa> my "house clock" (frequency reference) has a stability measured in parts per trillion
214 2014-07-14 15:57:33 <kuzetsa> at some point I plan to resume work on building one capable of keeping in phase matched down at the femtoseconds scale... it's just not really needed at this time since I'm not doing anything crazy with signal processing or measurement in over a year. </offtopic>
215 2014-07-14 16:04:14 <kuzetsa> it occurs to me pool.ntp.org allows vendor zones for things like linux distros
216 2014-07-14 16:04:55 <kuzetsa> we could see about adding an SNTP implementation to bitcoin and maybe operate a "bitcoin" vendor zone under pool.ntp.org
217 2014-07-14 16:05:15 <kuzetsa> just a thought
218 2014-07-14 16:06:45 <ahmed_> anyone have any ideas why bitcoind would just die?
219 2014-07-14 16:07:25 <jrick> is it intentional or an oversight that the codes used by bitcoind for the reject messages don't match those in BIP0061?
220 2014-07-14 16:07:58 <jrick> for example, 0x12 (reject duplicate) is used for duplicate txs or double spends by mempool, but the bip says it's for duplicate version messages
221 2014-07-14 16:08:47 <hearn> it's probably bugs
222 2014-07-14 16:08:50 <hearn> i mean, bugs in the spec :)
223 2014-07-14 16:11:36 <jrick> spec == bip or spec == reference implementation?
224 2014-07-14 16:13:25 <hearn> bip, i guess, as that's easier to change than the code now :)
225 2014-07-14 16:13:27 <hearn> ask gavinandresen
226 2014-07-14 16:14:11 <jrick> there might be others, haven't gone through them all, but that's the one that I noticed
227 2014-07-14 16:15:00 <gmaxwell> kuzetsa: we could call it "compromise_this_totally_unathenticated_service_to_goof_with_bitcoin_and_only_bitcoin.pool.ntp.org"
228 2014-07-14 16:15:12 <jrick> actually now that I look closer, the bip does use some of the same codes for different situations
229 2014-07-14 16:15:22 <jrick> so it might just be missing from that table for the tx reject reasons
230 2014-07-14 16:15:29 <hearn> ah ok
231 2014-07-14 16:15:33 <sipa> i think the whole idea of reject codes is silly
232 2014-07-14 16:15:47 <sipa> it's not like another implementaion can act upon them
233 2014-07-14 16:15:53 <sipa> it's purely for debugging
234 2014-07-14 16:16:09 <hearn> and debugging is silly because ... ?
235 2014-07-14 16:16:23 <gmaxwell> kuzetsa: drift on the order of 1000 ppm on normal PC server hardware is pretty typical in my expirence, never mind that 0.5 ppm tcxos cost like a buck.
236 2014-07-14 16:16:36 <sipa> hearn: it's not
237 2014-07-14 16:16:50 <sipa> but i would prefer just a string messages "you're being disconnected because X"
238 2014-07-14 16:17:14 <sipa> as for seeing why a block or tx isn't accepted, look at debug.log
239 2014-07-14 16:17:37 <hearn> i come across cases quite frequently where someone says "my app doesn't work" and i say "what does debug.log say" and they say .... well you can guess what they say next
240 2014-07-14 16:17:51 <hearn> not to mention that debugging problem reports from logs submitted by users is infinitely easier with reject messages
241 2014-07-14 16:21:21 <kuzetsa> gmaxwell: I'm not sure how you define "normal" PC server hardware, but the sort of frequency corrections I see in NTP are rarely over 50ppm
242 2014-07-14 16:22:24 <kuzetsa> gmaxwell: do you mean anonymous grey boxes or actual server hardware from reputable server vendors?
243 2014-07-14 16:22:38 <hearn> sipa: in LastCommonAncestor() is it ever valid to hit the return null at the bottom? surely they'll always have the genesis block at least?
244 2014-07-14 16:24:53 <dgenr8> hearn: what they say next is nothing.  That's when they disappear, right?
245 2014-07-14 16:24:59 <hearn> heh
246 2014-07-14 16:27:47 <dgenr8> sipa: in another project I have taken that tack ... issuing only string errors and no codes.  it's not popular with clients but it's really expecting too much for them to have specialized error handling for different codes.  when something fails, it's the string message that usually gets shown in a stack trace and leads to some action
247 2014-07-14 16:28:33 <dgenr8> not to question all the intricate exception type hierarchies out there
248 2014-07-14 16:38:33 <sipa> dgenr8: my point is that nobody will or should do handling of specific codes
249 2014-07-14 16:38:38 <sipa> dgenr8: it's only for debugging
250 2014-07-14 16:38:48 <sipa> if you get them, something is wrong
251 2014-07-14 16:41:38 <hearn> sipa: or it can be used to detect buggy remote nodes, reimplementations that aren't compliant, etc
252 2014-07-14 16:41:46 <hearn> it's good practice to have error codes. what would the web be without 404 :)
253 2014-07-14 16:44:36 <hearn> sipa: do we actually distinguish between BLOCK_VALID_CHAIN and BLOCK_VALID_SCRIPTS? is this due to multi-threaded signature checking ?
254 2014-07-14 16:46:35 <hearn> oh nooooo. did github really just eat my review comments
255 2014-07-14 16:46:36 <sipa> hearn: we don't currently distinguish between those
256 2014-07-14 16:46:44 <hearn> :( :( :(
257 2014-07-14 16:46:47 <sipa> yeah, commit/line/change comments randomly disappear
258 2014-07-14 16:46:53 <hearn> gah
259 2014-07-14 16:46:55 <hearn> github sucks
260 2014-07-14 16:46:56 <sipa> if you want them permanent, comment on the PR itself
261 2014-07-14 16:46:58 <sipa> it hate it
262 2014-07-14 16:47:03 <hearn> did you get any emails from my comments?
263 2014-07-14 16:47:03 <sipa> anyway, thanks for the review!
264 2014-07-14 16:47:05 <sipa> yes
265 2014-07-14 16:47:07 <hearn> ah good
266 2014-07-14 16:47:10 <hearn> well that's what matters
267 2014-07-14 16:47:14 <gwillen> it's not random
268 2014-07-14 16:47:29 <gwillen> any time you force-push an updated version
269 2014-07-14 16:47:29 <hearn> the disk-fill attack DoS fix is especially nice
270 2014-07-14 16:47:35 <gwillen> the line comments on the old version get eaten
271 2014-07-14 16:47:36 <sipa> gwillen: no it's not
272 2014-07-14 16:47:38 <hearn> gwillen: in this case i just made the comments, and now i can't find them
273 2014-07-14 16:47:41 <gwillen> oh :-\
274 2014-07-14 16:47:44 <hearn> like, literally a few minutes ago
275 2014-07-14 16:47:47 <sipa> gwillen: there are still comments left on lines that were rebased since
276 2014-07-14 16:48:03 <sipa> hearn: i've responded quickly to many of your comments, but i'll make changes to the code too
277 2014-07-14 16:48:19 <sipa> (i really like comments of the form "i don't understand this, explain it better in the code")
278 2014-07-14 16:50:54 <hearn> i'm very good at saying "i don't understand this" :-)
279 2014-07-14 16:54:25 <dermiste> hey folks, on the protocol spec page (https://en.bitcoin.it/wiki/Protocol_specification)
280 2014-07-14 16:54:48 <dermiste> in the version message I see a 64-bit timestamp
281 2014-07-14 16:55:10 <dermiste> and in the address datatype I see a 32-bit timestamp
282 2014-07-14 16:55:14 <dermiste> is this normal ?
283 2014-07-14 16:55:39 <dermiste> on a side note, is this page authoritative on the protocol state ?
284 2014-07-14 16:57:38 <hearn> sipa: i wonder if we should take out BLOCK_VALID_SCRIPTS if we don't use it. if in future those states become usefully separate it can always be added back in
285 2014-07-14 16:57:52 <hearn> dermiste: the protocol is a bit weird in places. Core C++ is the only authoritative reference
286 2014-07-14 16:59:19 <dermiste> hearn: ok, thank you
287 2014-07-14 18:11:18 <jcrubino> what guides are available to manually create a block for submission ?
288 2014-07-14 20:59:48 <jokoon> hi
289 2014-07-14 21:00:48 <jokoon> can I use the bitcoin protocol to do some decentralized network programming ?
290 2014-07-14 21:05:59 <lianj> sipa: max possible m-of-n is 20-of-20 right?
291 2014-07-14 21:07:45 <sipa> lianj: http://bitcoin.stackexchange.com/questions/23893/what-are-the-limits-of-m-and-n-in-m-of-n-multisig-addresses/28092#28092
292 2014-07-14 21:11:02 <lianj> sipa: jesus so much rules :D
293 2014-07-14 21:11:10 <lianj> but thanks