1 2014-10-24 01:49:57 <nickodell> If an OP_RETURN transaction is included in the blockchain, does the miner get to collect the bitcoins from that output as fees?
 2 2014-10-24 01:51:51 <jgarzik> nickodell, no
 3 2014-10-24 01:53:47 <nickodell> So, this guy is wrong, then? "As a side effect, a coin linked to an OP_RETURN challenge script becomes unspendable. Interestingly, any value associated with the coin can be claimed as a miner fee." http://bitzuma.com/posts/op-return-and-the-future-of-bitcoin/
 4 2014-10-24 02:24:33 <SomeoneWeird> nickodell: by the looks of it, yes
 5 2014-10-24 02:25:11 <nickodell> SomeoneWeird: Odd! Got a line or commit I could look at?
 6 2014-10-24 02:25:21 <SomeoneWeird> for?
 7 2014-10-24 02:25:43 <nickodell> SomeoneWeird: Or did you mean 'yes, that guy is wrong' ?
 8 2014-10-24 02:26:00 <SomeoneWeird> yeah, he's wrong
 9 2014-10-24 02:26:08 <nickodell> Ok, thanks.
10 2014-10-24 02:26:17 <SomeoneWeird> bad wording on my part, sorry
11 2014-10-24 06:10:18 <wumpus> BlueMatt: yes I accidentally the github merge there
12 2014-10-24 06:11:05 <wumpus> BlueMatt: I'm sure that's the only unsigned merge  in a loong time
13 2014-10-24 06:11:16 <wumpus> (by me, at least)
14 2014-10-24 17:12:21 <gavinandresen> sipa: I’m seeing weirdness with a regression test I’m writing, maybe related to headers-first. Wondering if it is a known bug. Here’s what’s up:
15 2014-10-24 17:12:54 <gavinandresen> sipa: running the forknotify regression test, which creates a long chain and makes sure -alertnotify triggers
16 2014-10-24 17:13:23 <sipa> ok
17 2014-10-24 17:13:38 <gavinandresen> sipa: all is well, unless I create an initial chain full of blocks with old (Jan 1, 2014) timestamps. Then one of the nodes seems to never sync.
18 2014-10-24 17:13:39 <sipa> i have never tested alertnotify wrt headersfirst
19 2014-10-24 17:14:05 <gavinandresen> Could be I have a bug in the regression test code, I had to modify CreateBlock so it can create blocks with arbitrary timestamps
20 2014-10-24 17:14:40 <sipa> so initial block sync (determined by the timestamp of the most recent block, iirc) is only done from outgoing peers
21 2014-10-24 17:15:14 <gavinandresen> That could be it… thanks, gives me a place to start debugging
22 2014-10-24 17:15:38 <sipa> that was a problem for compairson tool as well
23 2014-10-24 17:15:46 <sipa> can't remember how we avoided it
24 2014-10-24 17:16:22 <sipa> so there are two places in the code where blocks are actually requested
25 2014-10-24 17:16:54 <sipa> one is inside the "inv" Processmessage handler, for immediately-advertized blocks - but this is only done if we believe we're synced
26 2014-10-24 17:17:07 <sipa> and is done from the first peer that advertizes (incoming or not)
27 2014-10-24 17:17:22 <sipa> the other is in SendMessages, which is the background parallel fetcher
28 2014-10-24 17:17:50 <sipa> and that one should be used for IBD mostly, and is restricted to outgoing peers
29 2014-10-24 17:18:13 <gavinandresen> sipa: I might be running into an edge case in the “believe we’re synced” case— initial chain is 200 blocks from January, then get a current-timestamp block...
30 2014-10-24 17:18:53 <sipa> search for 'fFetch'; that's the condition under which the background downloader works
31 2014-10-24 17:18:58 <gavinandresen> cool
32 2014-10-24 17:19:32 <sipa> the direct fetcher uses timestamps
33 2014-10-24 20:50:24 <Luke-Jr> coryfields_: shouldn't we disable ccache use by default? Gentoo at least seems to have experience with ccache quietly breaking builds..
34 2014-10-24 20:55:17 <coryfields_> Luke-Jr: have there been any reports?
35 2014-10-24 20:55:49 <Luke-Jr> coryfields_: not for bitcoin afaik, but I did get a report of ccache being enabled when it ought not (Gentoo has their own setup for enabling it) ;)
36 2014-10-24 20:55:59 <Luke-Jr> easily worked around on my end for that, but just a thought
37 2014-10-24 20:57:06 <coryfields_> Luke-Jr: imo it's safe enough these days to leave on by default. Ofc I'd happily reconsider that stance if issues surfaced
38 2014-10-24 20:57:17 <coryfields_> how was it enabled in that case?
39 2014-10-24 20:57:30 <Luke-Jr> coryfields_: the configure script detected ccache and enabled it
40 2014-10-24 20:57:34 <coryfields_> i suppose gentoo uses env vars?
41 2014-10-24 20:57:50 <Luke-Jr> oh, in Gentoo's case - ccache is setup with symlinks to all the compilers in PATH
42 2014-10-24 20:57:53 <coryfields_> Luke-Jr: right, i meant: how did it break gentoo's assumptions
43 2014-10-24 20:57:57 <Luke-Jr> oh
44 2014-10-24 20:58:15 <Luke-Jr> well, when the user doesn't have ccache enabled, he doesn't want it used either
45 2014-10-24 20:58:33 <Luke-Jr> in this case, it was flagged by trying to access /var/tmp/ccache, outside its sandbox
46 2014-10-24 20:59:10 <coryfields_> so, ccache's override path gets priority if ccache is on globally?
47 2014-10-24 20:59:39 <Luke-Jr> anyway, the reason I was suggesting we disable it by default, is because Bitcoin is very sensitive, and silent corruption can be especially dangerous to us, if there's still risk of it (maybe it's an old comment?)
48 2014-10-24 20:59:54 <Luke-Jr> coryfields_: ?
49 2014-10-24 21:00:18 <Luke-Jr> coryfields_: if ccache is off globally, the user doesn't want it used, and our attempt to use it was flagged as a sandbox violation
50 2014-10-24 21:01:30 <coryfields_> Luke-Jr: i'm trying to determine how ccache is set to be used if the flag is on. I assume it modified the path like: PATH="$CCACHE_PATH:$PATH" ?
51 2014-10-24 21:02:38 <Luke-Jr> coryfields_: probably; I can't say for certain. it does work with --disable-ccache
52 2014-10-24 21:03:59 <Luke-Jr> (I confirmed it is working with --disable-ccache by grepping `ps ax` for it)
53 2014-10-24 21:04:39 <coryfields_> well depending on how it's activated, it may be possible for us to tell that it's unwanted
54 2014-10-24 21:04:40 <coryfields_> for ex
55 2014-10-24 21:05:23 <coryfields_> there's CCACHE_DISABLE, which does the obvious
56 2014-10-24 21:05:40 <coryfields_> so if that was set during configure by gentoo's build, but not set during make, it'd still end up disabled
57 2014-10-24 21:05:53 <coryfields_> we could (should) check for that in the case that enable/disable wasn't specified, and disable if that's found
58 2014-10-24 21:06:17 <coryfields_> *it'd still end up enabled
59 2014-10-24 21:06:33 <Luke-Jr> can't hurt I guess, though IMO that is something the distro(s) can/should be expected to handle. my only concern upstream is whether there are risks we're taking by default that we ought not.
60 2014-10-24 21:07:41 <coryfields_> understood, i'm not skipping over that, just going to the easier discussion first :)
61 2014-10-24 21:08:46 <coryfields_> i understand your concern completely, and i don't disagree entirely. thing is that we've had it on by default for quite a while now with no (known) ill-effects
62 2014-10-24 21:25:26 <Luke-Jr> coryfields_: well, there's still like 40% of nodes failing to sync it appears: http://luke.dashjr.org/programs/bitcoin/files/charts/bestblocks.html
63 2014-10-24 21:26:23 <Luke-Jr> I kinda doubt 40% are compiling themselves though
64 2014-10-24 21:27:49 <Luke-Jr> 
ACTION ponders hacking bitcoin-seeder to do the comparison at crawl-time

65 2014-10-24 21:33:35 <goosoodude> Uhm... We might have a slight problem...
66 2014-10-24 21:34:03 <gwillen> goosoodude: hm?
67 2014-10-24 21:34:29 <goosoodude> Some altcoin dev just copyrighted Scrypt... and the word "Coin."
68 2014-10-24 21:34:58 <gwillen> going to go with "lol" as my response to that, but: link?
69 2014-10-24 21:34:59 <coryfields_> you mean trademarked?
70 2014-10-24 21:35:16 <goosoodude> http://tsdr.uspto.gov/#caseNumber=86214943&caseType=SERIAL_NO&searchType=statusSearch
71 2014-10-24 21:35:35 <goosoodude> And, yeah coryfields_.
72 2014-10-24 21:35:36 <coryfields_> *patent
73 2014-10-24 21:36:26 <gwillen> goosoodude: the only mark that claims is "IMPERIAL COIN"
74 2014-10-24 21:36:31 <gwillen> it doesn't appear to claim "COIN" or "SCRYPT"
75 2014-10-24 21:38:03 <goosoodude> Look over the documents. He's basically claiming the coin as well as any other coin using scrypt...
76 2014-10-24 21:39:04 <goosoodude> He didn't claim the word scrypt, he claimed the algorithm.
77 2014-10-24 21:40:18 <coryfields_> where specifically?
78 2014-10-24 21:41:09 <goosoodude> http://tsdr.uspto.gov/documentviewer?caseId=sn86214943&docId=FTK20140311075043#docIndex=14&page=1
79 2014-10-24 21:44:00 <coryfields_> goosoodude: i suggest you read up on the difference between copyright/trademark/patent, unless you're intentionally trying to spread misinformation
80 2014-10-24 21:45:19 <goosoodude> Scroll down. He states "a scrypt-based virtual cryptocurrency." The wording is too broad. Does it mean IPC? Does it mean only his coin? Does it mean the entrie field of Scrypt currencies? Nobody really knows.
81 2014-10-24 21:45:30 <goosoodude> At this point, all we can do is wait and see what happens.
82 2014-10-24 21:45:53 <gwillen> goosoodude: this is a trademark. The _only_ thing he's claiming is the thing listed at the top.
83 2014-10-24 21:46:01 <coryfields_> goosoodude: no, it's already happened. he has a trademark. that's not interesting.
84 2014-10-24 21:46:04 <gwillen> goosoodude: all of the other stuff in that document is just describing the thing he's using with that trademark.
85 2014-10-24 21:46:20 <gwillen> goosoodude: there is literally NO claim to anything anywhere in that document except "imperial coin". I don't know what else to tell you.
86 2014-10-24 21:46:44 <goosoodude> hmm... Well, ok then. I guess I just overreacted.
87 2014-10-24 21:47:21 <gwillen> 
ACTION nods

88 2014-10-24 21:47:59 <coryfields_> goosoodude: i assume several scamcoins have been granted trademarks by now, they'd be silly not to apply
89 2014-10-24 21:48:01 <goosoodude> To be honest, the entire thing was about him trying to ruin my coin of a very similar name "ImperialCoin," which he really didn't do since I'm shutting it down soon. But, that's off topic.
90 2014-10-24 21:48:27 <goosoodude> But, on-topic, how's Bitcoin's development going?