1 2014-07-20 01:39:44 <Polyatomic> Hello, how are you?. May I please ask someone why I'm failing to build bitcoind `v0.8.6` see paste here http://sprunge.us/JjWR
 2 2014-07-20 01:40:59 <goosoodude> Do you have all of the boost packages installed for your OS?
 3 2014-07-20 01:41:18 <Polyatomic> yes
 4 2014-07-20 01:41:28 <sipa> #bitcoin please
 5 2014-07-20 01:42:47 <Polyatomic> Was that wrong to ask in here sipa
 6 2014-07-20 01:43:04 <Polyatomic> ?
 7 2014-07-20 01:51:21 <sipa> this is not a helpdesk
 8 2014-07-20 02:15:37 <jcorgan> leveldb signedness warnings: http://pastebin.com/kCGTJ1Lh
 9 2014-07-20 02:16:02 <jcorgan> not sure if these matter or are just annoying
10 2014-07-20 05:17:44 <wumpus> jcorgan: if it's in leveldb, in general we don't touch it
11 2014-07-20 05:20:58 <jcorgan> got it
12 2014-07-20 06:44:12 <wumpus> jcorgan: of course that doesn't mean that they don't indicate problems :)
13 2014-07-20 06:45:09 <wumpus> the arm/x86 incompatibility in the bloom filter that I managed to find is also due to a signedness issue (although not one that raises a warning)
14 2014-07-20 06:46:08 <wumpus> (https://github.com/bitcoin/bitcoin/issues/2293)
15 2014-07-20 13:30:08 <zigz> hi
16 2014-07-20 13:30:21 <zigz> how do i pass nHeight to Gethash()?
17 2014-07-20 13:30:35 <zigz> or what's best practice for that
18 2014-07-20 13:32:23 <sipa> what are you trying to do?
19 2014-07-20 13:32:30 <sipa> the height is not commonly hashed
20 2014-07-20 13:48:38 <roybadami> Could someone tell me, where is it documented that multisig transactions in P2SH redeem scripts aren't subject to the BIP 11 three signature limit for standardness?
21 2014-07-20 14:06:30 <sipa> roybadami: nowhere
22 2014-07-20 14:06:38 <sipa> it was accidental
23 2014-07-20 14:09:45 <roybadami> Ah, thank you.  So it's been like this since BIP16 was first implemented?
24 2014-07-20 14:11:02 <sipa> yes
25 2014-07-20 14:11:29 <sipa> (though for 0.10 the standardness rules are intentionally being weakened further for p2sh)
26 2014-07-20 14:11:35 <roybadami> Would it make sense to update BIP16 to reflect reality, then?
27 2014-07-20 14:12:10 <sipa> i'm very much against updating bips... they're not references, but proposed changes
28 2014-07-20 14:12:16 <sipa> if it needs a bip, it will need a new one
29 2014-07-20 14:12:28 <sipa> but standardness is not consensus-critical, and a local client decision anyway
30 2014-07-20 14:14:50 <roybadami> I suppose I'd prefer it if bips could be considered references. Surely BIP70 is intended to be regarded as a reference for implementors of the payment protocol?  There is no other reference that I'm aare of
31 2014-07-20 14:17:55 <sipa> well, sure
32 2014-07-20 14:18:30 <sipa> but it is still just a list of proposed changes, that individually people or pieces of infrastructure accept or not
33 2014-07-20 14:18:39 <roybadami> It's very confusing, to have BIP16, written by Gavin, status Accepted, with no indication that this doesn't correspond to what was actually implemented.
34 2014-07-20 14:18:40 <sipa> the whole purpose is to give a unique id to an idea
35 2014-07-20 14:18:59 <sipa> if you change the idea, you need to use a new number
36 2014-07-20 14:19:18 <sipa> yeah, we need reference documentation for that
37 2014-07-20 14:19:55 <sipa> yes, the change proposed by bip16 was accepted by the network
38 2014-07-20 14:20:12 <sipa> that doesn't mean that there were no further changes to similar pieces of the rules afterwards
39 2014-07-20 14:21:21 <roybadami> But if the standardness rule in BIP16 was never implemented, surely it doesn't hurt to add a note to that affect
40 2014-07-20 14:21:40 <sipa> ok, clarifications, sure
41 2014-07-20 14:22:18 <sipa> but having a full reference would be nice; for example the haskell standard is written as chapters/paragraphs, and its proposed changes contain a section that describes which paragraphs in the standard are modified when that proposed change takes effect
42 2014-07-20 14:23:01 <sipa> unfortunately, for a consensus system we can't really have an authoritative reference (ultimately, the actual rules are just what is running in the network)
43 2014-07-20 14:23:40 <roybadami> Transactions that redeem these pay-to-script outpoints are only considered standard if the serialized script [...] is, itself, one of the other standard transaction types. [Historical note: due to a bug in the reference implementation, the reference client did not enforce the n<=3 rule for standardness of BIP11 transactions.]
44 2014-07-20 14:23:46 <roybadami> something like that
45 2014-07-20 14:24:01 <sipa> but imho standardness rules don't belong in bips in the first place, as they're local client policy
46 2014-07-20 14:24:25 <sipa> sometimes they're relevant to mention as they're part of how a consensus rule change can be done safely
47 2014-07-20 14:25:14 <roybadami> I don't necessarily disagree with you, but BIP11 and BIP16 purport to define standardness for multisig transactions
48 2014-07-20 14:25:42 <sipa> fair enough
49 2014-07-20 14:26:15 <roybadami> And if there was a note there explaining the mismatch with reality I wouldn't have had to waste your time asking about it :-)
50 2014-07-20 14:26:31 <sipa> ok, point taken :)
51 2014-07-20 14:26:42 <sipa> i just dislike the idea of retroactively changing ideas
52 2014-07-20 14:27:12 <roybadami> I thought the decision with putting BIPs in git was that it was OK to revise them
53 2014-07-20 14:27:14 <sipa> (you may have someone mentioning "the bip16 standardness rule", which after the 'note' may be interpreted differently)
54 2014-07-20 14:27:39 <sipa> clarifications, typos, ...
55 2014-07-20 14:27:44 <sipa> but not changing the meaning
56 2014-07-20 14:27:55 <sipa> (unless they're draft, in which case it doesn't matter)
57 2014-07-20 14:28:12 <sipa> also, putting them in git was done to prevent rogue editing in the wiki
58 2014-07-20 14:29:05 <sipa> (also, all this is mostly my own opinion - and i don't participate in approving bip changes)
59 2014-07-20 14:33:49 <roybadami> Maybe we need informational BIPs (or another document series) for stuff like this.  There are a lot of places where learning about Bitcoin is hard due to lack of documentation
60 2014-07-20 14:34:34 <sipa> https://bitcoin.org/en/developer-documentation
61 2014-07-20 14:37:20 <roybadami> Oh, that looks pretty good - I didn't know that existed yet
62 2014-07-20 14:39:41 <sipa> also, ignore me if i'm unnecessarily terse - i haven't slept for over 24 hours
63 2014-07-20 14:40:25 <roybadami> np, I'll stop bothering you
64 2014-07-20 14:46:37 <gwillen> sipa: I agree about not editing BIPs materially, but they should be updated with like, a Superseded-by header and a note at the top of the body
65 2014-07-20 14:47:31 <sipa> gwillen: agree there
66 2014-07-20 16:14:33 <maaku> sipa: you make it home alright?
67 2014-07-20 16:36:02 <hearn> good evening
68 2014-07-20 17:08:27 <AmThatsMe> Hi everyone !
69 2014-07-20 17:10:26 <AmThatsMe> I'm having trouble debugging the reference client. I'm using Eclipse on OSX. I configured the build with "./configure --enable-debug=true" to add the debugging flags. When i install a breakpoint in eclipse, i'm getting on of 2 problems: 1) source not found or 2)cannot install breakpoint.
70 2014-07-20 17:10:37 <AmThatsMe> anyone can help ?
71 2014-07-20 17:33:10 <hearn> sipa: around?
72 2014-07-20 20:25:31 <ronkrt1> what would the best os for a mining pool be Linux wise?
73 2014-07-20 20:25:50 <daybyter> debian?
74 2014-07-20 20:26:15 <daybyter> I use debian on servers in general. Don't want to compile stuff.
75 2014-07-20 20:26:29 <daybyter> I prefer gentoo for desktops.
76 2014-07-20 20:26:39 <ronkrt1> ok daybyter, thanks, also are there any premade scripts that can be used for multi-mining, autoswitching and auto convert/payouts?
77 2014-07-20 20:28:39 <tommygunner> and thats when it isnt a bitcoin question anymore :>
78 2014-07-20 20:29:38 <ronkrt1> it is when you want to payout in btc :P
79 2014-07-20 21:13:08 <dgenr8> AmThatsMe: are you launching the process to be debugged from inside eclipse?
80 2014-07-20 21:52:48 <benkay> merged mining: could any previous hash from, say, bitcoin satisfying a merge-mined coin's difficulty be submitted as a coinbase on that merge-mined coin?
81 2014-07-20 21:55:29 <benkay> i guess if merged mining is happening than any merge-mined coin's difficulty'll be way higher than past blocks from btc duh
82 2014-07-20 21:56:25 <benkay> thanks for being my rubber chicken #bitcoin-dev
83 2014-07-20 21:56:45 <justanotheruser> benkay: no
84 2014-07-20 21:57:19 <justanotheruser> you have to prove you are merged mining for the coin before you merged mine for it
85 2014-07-20 21:57:40 <justanotheruser> #bitcoin
86 2014-07-20 21:58:02 <benkay> justanotheruser: uh, pardon?
87 2014-07-20 21:58:35 <justanotheruser> join #bitcoin, it is a more appropriate channel I think
88 2014-07-20 21:59:56 <justanotheruser> I think I misinterpreted your question as asking "can any bitcoin mined be applied to an altchains merged mine"
89 2014-07-20 22:00:50 <BlueMatt> what is the status of corey rewriting pull-testing stuff?
90 2014-07-20 22:01:04 <BlueMatt> how much effort should I invest in makin pull-tester work properly?
91 2014-07-20 22:01:07 <BlueMatt> wumpus: ^
92 2014-07-20 22:42:48 <gmaxwell> hearn: trickling is mostly not a privacy feature, it saves a pretty significant amount of bandwidth.
93 2014-07-20 22:43:02 <gmaxwell> (something like 40% of the inv bandwidth)
94 2014-07-20 22:55:12 <hearn> gmaxwell: was that measured or the result of some simulation?
95 2014-07-20 22:58:57 <gmaxwell> Measured. A simulation would probably be useful for parameter twiddling.
96 2014-07-20 23:01:27 <kazcw> gmaxwell: the only mechanism by which trickling saves bandwidth is preventing two nodes exchanging the same invs, since invs that are deferred are eventually sent unless setInventoryKnown changes before that node becomes the trickleSend node, right?
97 2014-07-20 23:04:54 <kazcw> trickling saving 40% of inv bandwidth means that without trickling most invs would pass each other in transit, but agreeing on who sends via the odd/even mechanism should solve the same thing more effectively