1 2015-08-19 00:30:32 <maaku> I have a definition which *should* be in main.h (defines flags for a function defined in main.h), but needs to be referenced in policy/policy.h; where should it go?
 2 2015-08-19 00:37:56 <maaku> adding a dependency on main.h in policy.h seems like something that might annoy people
 3 2015-08-19 01:49:13 <AdrianG> so whats the easiest way to start contributing to bitcoin code?
 4 2015-08-19 01:49:22 <AdrianG> like where do i even begin.
 5 2015-08-19 01:49:28 <AdrianG> there seems so much to do.
 6 2015-08-19 01:50:37 <phantomcircuit> AdrianG, start by reviewing pull requests
 7 2015-08-19 01:51:40 <AdrianG> whats the end goal?
 8 2015-08-19 01:51:52 <AdrianG> to learn about submitters and whats needed?
 9 2015-08-19 01:52:34 <phantomcircuit> AdrianG, reviewing other peoples code is one of the things you can do with relatively little experience
10 2015-08-19 01:53:06 <AdrianG> i guess.
11 2015-08-19 01:53:22 <AdrianG> i could write up some tests too, i guess.
12 2015-08-19 01:53:27 <AdrianG> tests are always needed.
13 2015-08-19 01:53:42 <phantomcircuit> AdrianG, yes, generally that's harder to get right though
14 2015-08-19 01:54:51 <AdrianG> is there demand for more tests?
15 2015-08-19 02:00:29 <kanzure> i second the review suggestion
16 2015-08-19 02:00:32 <kanzure> AdrianG: do review things
17 2015-08-19 02:01:08 <AdrianG> mmkay :(
18 2015-08-19 02:01:54 <phantomcircuit> andytoshi, more tests is always good but it really is much harder to do than to review
19 2015-08-19 02:02:12 <kanzure> wrong nickname
20 2015-08-19 02:02:15 <AdrianG> phantomcircuit: i do test development professionally for security products
21 2015-08-19 02:02:27 <AdrianG> im pretty sure i'd manage
22 2015-08-19 02:02:41 <AdrianG> but ofc, it is a different code base.
23 2015-08-19 02:03:21 <AdrianG> my questions were more along the lines where is the greatest demand for effort right now
24 2015-08-19 02:03:36 <kanzure> also reviewing bitcoin-dev email is also useful
25 2015-08-19 02:03:50 <AdrianG> i might have a few spare cycles in the future
26 2015-08-19 02:05:26 <phantomcircuit> AdrianG, i know it sounds condescending, but bitcoin really is harder to get right than virtually everything else you can think of
27 2015-08-19 02:06:07 <Sporklin> It isn't that hard o.o
28 2015-08-19 02:09:15 <morcos> AdrianG: if you want something a bit more challenging.  take on 6557.  its a lot of new code that needs review, testing and probably more tests included.
29 2015-08-19 02:10:38 <morcos> In general spending a lot of time on the issues/PR lists is beneficial, there are some outstanding issues out there that probably aren't too hard to solve if you want to write new code.  but always better to start with the simpler things, so you can find other people to review your changes.
30 2015-08-19 02:17:01 <phantomcircuit> AdrianG, here review my code
31 2015-08-19 02:17:06 <phantomcircuit> https://github.com/bitcoin/bitcoin/pull/6374
32 2015-08-19 02:17:14 <morcos> ha ha, that was my idea
33 2015-08-19 02:17:14 <phantomcircuit> please be hyper critical :)
34 2015-08-19 02:17:33 <AdrianG> it sucks, i can tell right now
35 2015-08-19 02:17:34 <AdrianG> j/k
36 2015-08-19 02:17:35 <phantomcircuit> morcos, lol
37 2015-08-19 02:19:05 <morcos> phantomcircuit: speaking of 6374, can you explain to me exactly how the keyed group protection works?
38 2015-08-19 02:19:26 <morcos> is the idea, you just can't predict what group will be protected?
39 2015-08-19 02:19:40 <morcos> why is it 4 nodes?
40 2015-08-19 02:21:18 <phantomcircuit> morcos, the idea is that an attacker cannot predict which ips will be protected so the attacker would need to get lots more ips
41 2015-08-19 02:22:27 <phantomcircuit> it's only 4 because... uh because it shouldn't be a huge number as it's not an obvious "good peer" and 4 seems better than 1
42 2015-08-19 02:22:45 <phantomcircuit> i've not got a strong justification for it really
43 2015-08-19 02:23:21 <morcos> ok, so the intention isn't necessarily to protect 4 different groups or even 2 different groups
44 2015-08-19 02:23:48 <morcos> i was just thinking that if you protected some from one end and some from the other you'd at least have different groups, but i guess that doesn't matter realy
45 2015-08-19 02:25:20 <phantomcircuit> morcos, well i've had two different versions
46 2015-08-19 02:25:25 <phantomcircuit> one had overlapping groups
47 2015-08-19 02:25:42 <phantomcircuit> but this version seems better since it's guaranteed to protect a specific number of peers
48 2015-08-19 02:26:13 <morcos> ok, i didn't have any objection, just wanted to make sure i understood.  thanks.
49 2015-08-19 02:42:29 <gmaxwell> AdrianG: Obviously reviewing is good, but also just find something you're interested in working on and try. Just don't expect your first attempts to be a huge success. There is a flow and a zen to participating that takes time to pick up on.  Think of it like a lottery, in that you're still participating if you don't win. :)
50 2015-08-19 03:08:16 <CodeShark> AdrianG: my advice is start with small incremental changes rather than trying to build anything too much in a single PR :)
51 2015-08-19 03:08:31 <CodeShark> especially changes that are easy to review :)
52 2015-08-19 03:09:31 <CodeShark> if you do this and your change does offer some fairly noncontroversial improvement, that will significantly increase your chances of getting merged :)
53 2015-08-19 03:10:01 <gmaxwell> yea, keep in mind your own state, you want to be successful, if making a big patch and having it languish is going to demotivate you, don't set youself up for failure that way.
54 2015-08-19 03:10:35 <gmaxwell> because big invasive, complex, patches really langish badly. Some of this is our fault, .. but some is just inherent to the nature of the work.
55 2015-08-19 03:11:04 <CodeShark> if you have greater ambitions to build out something bigger, break it up into small parts that each individually offers some improvement
56 2015-08-19 03:11:31 <CodeShark> stucture your commits to make it as easy as possible to review and to test
57 2015-08-19 03:12:09 <gmaxwell> I think it's helpful to akso take on the attitude that you're coming to the project as an artist, working to refine your art as well as getting something done. So when you get feedback it's not a rejection but rather a avenue to expand your skills by considering different approaches and negoiating with others.
58 2015-08-19 03:13:09 <gmaxwell> Some of the most fun I've had programming is when someone blew up my work in review, I learned so much. But only because I was mentally prepared to handle it productively, a lot of people are not when they make their first contributions.
59 2015-08-19 03:13:30 <CodeShark> also, avoid changing any of the consensus code unless you also plan on changing the genesis block ;)
60 2015-08-19 03:14:09 <CodeShark> that's the last place you want to start trying to contribute, methinks :)
61 2015-08-19 08:32:12 <Nicolas__> For core devs, can you provide a PGP signed message about your position on various BIPs on http://bipsxdevs.azurewebsites.net/ ? (I also want to add major exchanges and other devs later on)
62 2015-08-19 08:32:39 <Nicolas__> I explain how it works on btctalk : https://bitcointalk.org/index.php?topic=1156164
63 2015-08-19 10:46:59 <sadoshi> hi, would be great to get some opinions about https://goo.gl/mcNtE5 before even touching the mailing list. thoughts?
64 2015-08-19 11:10:57 <wumpus> Adlai: OP_RETURN is at 80 bytes as of 0.11
65 2015-08-19 11:11:39 <wumpus> (for isStandard at least)
66 2015-08-19 13:51:27 <ebfull> is a 75% threshold of approval for a block size increase considered acceptable in other proposals or by other core devs?
67 2015-08-19 13:51:42 <ebfull> or is this unique to Gavin's plan
68 2015-08-19 14:00:14 <zooko> ebfull: are you asking about the 75% or about the block size increase?
69 2015-08-19 14:00:34 <zooko> There've been several changes which had thresholds built in, that got widespread consensus and went in.
70 2015-08-19 14:00:36 <zooko> (Note: not hard forks.)
71 2015-08-19 14:00:44 <zooko> I don't remember which specific thresholds they used.
72 2015-08-19 14:01:37 <ebfull> the 75%
73 2015-08-19 14:02:06 <ebfull> i'm curious to know the thresholds that other core devs/experts would support for a final plan
74 2015-08-19 14:04:06 <zooko> *nod*
75 2015-08-19 14:29:56 <wumpus> there is no threshold for a hard fork, 75% would just leave 25% on one side and 75% on the other side
76 2015-08-19 14:36:01 <wumpus> any block-count threshold implies that everyone is running by the same rules, and has decided to let miners vote on the issue. Which makes sense for softforks, but less for hardforks.
77 2015-08-19 16:14:42 <divi_> exit
78 2015-08-19 16:14:45 <divi_> exit
79 2015-08-19 16:14:46 <divi_> exit
80 2015-08-19 16:20:42 <ThomasV> what error is returned by bitcoind when a tx is larger than the max transaction size?
81 2015-08-19 16:44:24 <Magicking> Failed to create transaction or something
82 2015-08-19 16:44:35 <Magicking> In the log
83 2015-08-19 16:45:51 <Magicking> Wait was the question about when a transaction is checked or when it's going to the mempool ?
84 2015-08-19 16:55:39 <drian> midnightmagic: please reply to my message on the wiki, thanks
85 2015-08-19 17:04:45 <Adlai> wumpus: thanks. it's good to see that people haven't immediately inflated their usage to the full 80... although some have started using 42 bytes
86 2015-08-19 19:17:37 <kanzure> btcdrak: have any other comments been deleted on github before?
87 2015-08-19 19:21:18 <btcdrak> kanzure: gavin also threatened to ban me in a private email when I called out Mike on the list. I was very polite, no need for his response, but I was very near the truth so....
88 2015-08-19 19:22:30 <kanzure> btcdrak: i mean specifically, do we know of any other deleted github comments, possibly not involving you?
89 2015-08-19 19:22:42 <kanzure> for example- what happens when spammers spam on github pull requests etc., are those comments deleted too?
90 2015-08-19 19:25:15 <btcdrak> kanzure: I would assume spam is cleaned up. I dont know, I've not been looking closely
91 2015-08-19 19:26:36 <kanzure> yeah i'm sort of surprised to see a constructive comment deleted at all.