1 2015-10-19 00:41:24 <bedeho> is dust limit a consensus rule?
  2 2015-10-19 00:41:38 <phantomcircuit> no
  3 2015-10-19 00:41:56 <gmaxwell> bedeho: Can you please explain why you're asking?
  4 2015-10-19 00:42:03 <gmaxwell> It's a weird question that you'd even think that.
  5 2015-10-19 00:44:02 <bedeho> gmaxwell, will a block with a tx with a dust output be rejected? why is that weird question?
  6 2015-10-19 00:44:49 <gmaxwell> bedeho: because the definition of dust is not fixed, it _cannot_ be a consensus rule.
  7 2015-10-19 00:45:03 <gmaxwell> So no, as phantomcircuit said, it isn't and a block will never be rejected on that basis.
  8 2015-10-19 00:45:47 <bedeho> I must be misunderstanding what the dust test checks then, I thought it just checks if the #satoshies was below some magic number?
  9 2015-10-19 00:46:53 <gmaxwell> bedeho: sort of, it checks if its below some small multiple of the minimum feerate a node would relay as a non-free transaction.
 10 2015-10-19 00:47:16 <bedeho> ah ok
 11 2015-10-19 00:47:17 <gmaxwell> (In other words "this pays so little, that spending it would be a loss for the reciever, according to my current behavior")
 12 2015-10-19 00:47:38 <bedeho> good to know
 13 2015-10-19 00:47:43 <phantomcircuit> bedeho, there are two classes of rules; consensus rules (ie the block is invalid) and policy (ie you refuse to relay those transactions)
 14 2015-10-19 00:47:46 <gmaxwell> (and it uses a very permissive estimate of what would be a loss)
 15 2015-10-19 00:47:51 <phantomcircuit> the dust limit is a policy not a consensus rule
 16 2015-10-19 00:48:19 <bedeho> yes, I get that, I thought the test was not related to relay policy
 17 2015-10-19 00:48:22 <bedeho> but thank you
 18 2015-10-19 00:48:27 <bedeho> why were those two things even linked?
 19 2015-10-19 00:48:31 <gmaxwell> anything to do with fees and amounts is policy; as embedding something with arbritary economic scaling (price of bitcoin) in consensus would be crazy.
 20 2015-10-19 00:48:50 <bedeho> yes thats a good point
 21 2015-10-19 00:49:15 <gmaxwell> bedeho: for the rational I just gave-- that no fee paying spend of it would even get relayed by the node without causing a loss for the spender... (e.g it would be a bad idea to ever spend the txout)
 22 2015-10-19 00:49:41 <gmaxwell> which means unending utxo set bloat then its better for people to just forget about or delete wallets than spend all the coins in them.
 23 2015-10-19 00:52:04 <bedeho> hmm, but just because you wouldnt relay a spend doesnt mean someone else wouldnt mine it, at which point it would not bloat your utxo when you see the block with that spend?
 24 2015-10-19 00:53:23 <gmaxwell> bedeho: you wouldn't relay a non-funds losing spend, so you don't relay the thing creating the mess the spend wouldn't clean up..  Other people might relay/mine both.
 25 2015-10-19 00:53:39 <gmaxwell> It matches them up, if no one will relay/mine the spend, then no one will relay/mine the bloat.
 26 2015-10-19 00:54:31 <gmaxwell> (well kind of-- it's very permissive, and allows outputs a significant amount smaller than it should; "just in case")
 27 2015-10-19 00:57:42 <bedeho> I see, thank you.
 28 2015-10-19 04:18:45 <kyuupichan> Why do the mining pools continue to add txs to blocks that pay almost no fees (0.0001 BTC) and create dozens or hundreds of dust UTXOs.  I don't understand why they persist in doing this.
 29 2015-10-19 04:22:46 <kuzetsa> kyuupichan: some of the miners feel that the "dust" UTXOs being created aren't "way too cheapskate" enough to add (price per kilobyte) to the block chain to be considered spammy or whatever
 30 2015-10-19 04:39:27 <kyuupichan> kuzetsa: May be so, but 0.0001 BTC seems cheap to create > 100 utxos.  Apparently they don't care about chain size.
 31 2015-10-19 04:39:59 <kyuupichan> IMO creation of new UTXOs is underpriced
 32 2015-10-19 05:35:37 <Luke-Jr> kyuupichan: I don't know how many miners care about Bitcoin anymore.
 33 2015-10-19 06:47:20 <phantomcircuit> kyuupichan, they are profit maximizing of course
 34 2015-10-19 06:47:29 <phantomcircuit> exactly as any sane person would expect
 35 2015-10-19 07:06:58 <kyuupichan> phantomcircuit: I doubt scraping 0.0001 BTC to make your block 20-50k bigger is a good long-term profit-maximising plan
 36 2015-10-19 07:12:52 <sturles> kyuupichan: No sane pools do this.  Only some Chineese pools that I know of.  Don't use them.
 37 2015-10-19 07:13:10 <kyuupichan> sturles: Slush seems to do it too
 38 2015-10-19 07:13:18 <sturles> Hmm.
 39 2015-10-19 07:14:44 <zexos> If any developers with the knowledge of crypto daemons, php, sql etc are interested in creating a platform (blackhat project) that has proven profitability in the past (proof available), I am looking for a partnership. Previous partner is no longer around, need new partner to carry on with these projects. PM if interested, i'll give you contact info there.
 40 2015-10-19 07:14:52 <phantomcircuit> kyuupichan, what makes you think they're optimizing for long term?
 41 2015-10-19 07:15:13 <kyuupichan> phantomcircuit: It's true in the short term too
 42 2015-10-19 07:16:16 <phantomcircuit> kyuupichan, no it's not
 43 2015-10-19 07:21:02 <kyuupichan> phantomcircuit: Oh, so what's breakeven additional space for 0.0001 BTC according to you?
 44 2015-10-19 07:25:29 <phantomcircuit> kyuupichan, roughly zero when you're connected to >50% of the network over a lan
 45 2015-10-19 07:26:02 <zexos> phantom
 46 2015-10-19 07:26:04 <zexos> whats your problem?
 47 2015-10-19 07:27:52 <phantomcircuit> zexos, you're a criminal
 48 2015-10-19 07:28:04 <zexos> nope
 49 2015-10-19 07:28:10 <zexos> found a loophole
 50 2015-10-19 07:28:14 <zexos> and i am exploiting it
 51 2015-10-19 07:28:53 <phantomcircuit> a loophole in....
 52 2015-10-19 07:29:08 <phantomcircuit> there's virtually no chance you can answer that question without you being a criminal
 53 2015-10-19 07:29:10 <phantomcircuit> !ops
 54 2015-10-19 07:29:48 <phantomcircuit> BlueMatt, ^
 55 2015-10-19 07:29:54 <zexos> actually it isn't a loophole
 56 2015-10-19 07:30:01 <zexos> simply stating the obvious in terms and conditions
 57 2015-10-19 07:30:03 <kyuupichan> phantomcircuit: Hard to take you seriously.  Also given your scaling bitcoin talk.
 58 2015-10-19 07:30:03 <zexos> which no one reads
 59 2015-10-19 07:30:10 <zexos> that is the loophole
 60 2015-10-19 07:30:17 <zexos> it is completely legal
 61 2015-10-19 07:30:24 <phantomcircuit> first it's blackhat, then you're selling black hats, then it's a scam, now it's a loophole, BUT WAIT NO ITS NOT!
 62 2015-10-19 07:30:29 <zexos> so now i say [fuck off] to you :)
 63 2015-10-19 07:30:41 <phantomcircuit> lol timing
 64 2015-10-19 07:33:25 <phantomcircuit> gmaxwell, btw i've seen lots of nonsense from that datacenter so i banned it's entire range in #bitcoin
 65 2015-10-19 07:37:12 <phantomcircuit> kyuupichan, uhh my talk was entirely serious
 66 2015-10-19 07:38:09 <phantomcircuit> if you disagree with the results please present your own findings
 67 2015-10-19 07:44:05 <phantomcircuit> thought so..
 68 2015-10-19 11:07:58 <jtimon> CodeShark: let's discuss C API (the currently implemented option) vs C++ API for libconsensus here
 69 2015-10-19 11:09:08 <jtimon> it was already decided (and partially implemented) that a C API was simplest for some languages to interface with
 70 2015-10-19 11:09:39 <CodeShark> While I agree that it's easier for some languages to interface with a C API, I don't think that's what's most important right now for Bitcoin Core
 71 2015-10-19 11:09:39 <Diablo-D3> I agree with that decision and I dont even know what libconsensus is
 72 2015-10-19 11:09:39 <jtimon> I'm sorry that you missed that discussion, but I really see no good arguments in favor of making it a C++ API instead...
 73 2015-10-19 11:09:48 <Diablo-D3> and btw
 74 2015-10-19 11:09:52 <Diablo-D3> you CAN have a c++ api
 75 2015-10-19 11:09:57 <Diablo-D3> just call the c one with it
 76 2015-10-19 11:10:17 <jtimon> Diablo-D3: currently libconsensus is just one C function: https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.h#L56
 77 2015-10-19 11:10:21 <CodeShark> it's a huge stylistic change that distracts from far more important issues of dependencies, a layered architecture, and better code organization
 78 2015-10-19 11:10:45 <CodeShark> nobody is really asking for a C libconsensus - this is for our own use. we can always write C wrappers
 79 2015-10-19 11:10:56 <Diablo-D3> jtimon: lol
 80 2015-10-19 11:11:24 <jtimon> CodeShark: currently it's not so huge, really (unless we make it harder like you are doing with #6816)
 81 2015-10-19 11:11:26 <CodeShark> I'm not opposed to eventually supporting a C API - I just think trying to force a C API right now is getting the priorities backwards
 82 2015-10-19 11:12:23 <jtimon> CodeShark: when we discussed what the API for libconsensus should be, we decided for C, at least cfields_ sipa BlueMatt and wumpus were involved in that discussion
 83 2015-10-19 11:12:41 <Diablo-D3> yeah and they all probably said C for the same reason I did
 84 2015-10-19 11:12:47 <Diablo-D3> if you want to have wrappers in other languaes
 85 2015-10-19 11:12:53 <Diablo-D3> C is literally your only choice
 86 2015-10-19 11:13:23 <CodeShark> it's like deciding on what paint color you're going to use before you've got solid foundations for your house
 87 2015-10-19 11:13:41 <jtimon> Diablo-D3: exactly, simpler wrappers in other languages was precisely the main reason to decide for C
 88 2015-10-19 11:13:44 <btcdrak> jtimon: I also think it's not the right time to be trying to marshall every PR to conform to something that is not yet even created or finalised. When we work on libconsensus in earnest that is the time for refactoring.
 89 2015-10-19 11:13:49 <CodeShark> API wrappers and language bindings can always be added to a good architecture - it's VERY hard to go in the other direction
 90 2015-10-19 11:14:20 <Diablo-D3> CodeShark: uh, wrong
 91 2015-10-19 11:14:25 <Diablo-D3> you cant add wrappers to c++
 92 2015-10-19 11:14:54 <Diablo-D3> you clearly have never looked at how the c++ abi works
 93 2015-10-19 11:15:07 <CodeShark> you're missing the point completely
 94 2015-10-19 11:15:16 <Diablo-D3> a shitload of wrappers in other languages write their wrappers in c and just call the c++ from them
 95 2015-10-19 11:15:19 <Diablo-D3> which is idiotic as hell
 96 2015-10-19 11:15:23 <Diablo-D3> CodeShark: not at all
 97 2015-10-19 11:15:29 <btcdrak> jtimon: it's hard enough to get code reviewed as it is, without complicating it with not yet existing libconsensus nits.
 98 2015-10-19 11:15:49 <Diablo-D3> your argument is "with well written code, it doesnt matter how big of a mistake you make early on, it can be fixed"
 99 2015-10-19 11:16:09 <btcdrak> jtimon: I think there is a time and a place for it, but that it isnt now. We havent even agreed a highlevel plan for refactoring yet.
100 2015-10-19 11:16:11 <CodeShark> ok, if you want to believe that's what I said go ahead...I am not going to argue this
101 2015-10-19 11:16:11 <Diablo-D3> my argument is "its easier to just not make a mistake in the first place"
102 2015-10-19 11:16:15 <CodeShark> I have other stuff to do
103 2015-10-19 11:16:39 <Diablo-D3> CodeShark: okay so, which one of us has experience in a dozen different languages, and has made a shitton of money as a professional programmer?
104 2015-10-19 11:16:41 <Diablo-D3> hint: its me
105 2015-10-19 11:16:51 <jtimon> btcdrak: I believe I was relatively close to a finalised libconsensus (with a C API) in March (see #5946), but it will never happen if we keep undoing the work that's been already merged
106 2015-10-19 11:16:52 <Diablo-D3> I agree with any decision that involves making a highly portable library in C.
107 2015-10-19 11:17:02 <Diablo-D3> you dont even need to use C for the whole library
108 2015-10-19 11:17:05 <Diablo-D3> just for the public functions
109 2015-10-19 11:17:13 <btcdrak> Diablo-D3: that;s a really poor argument, "I made lots of money so I'm right"
110 2015-10-19 11:17:29 <btcdrak> Diablo-D3: let's not degenerate into logical fallacies please.
111 2015-10-19 11:17:29 <Diablo-D3> let me rephrase
112 2015-10-19 11:17:31 <jtimon> I'm working on a document with a detailed plan for libconsensus (with pictures, as suggested by CodeShark)
113 2015-10-19 11:17:39 <Diablo-D3> the bitcoin community paid me a lot of money because Im right.
114 2015-10-19 11:18:17 <jtimon> Diablo-D3: that's still an argument of authority (fallacy)
115 2015-10-19 11:19:03 <Diablo-D3> okay fine, Ive written an absolute fuckton of C, and Ive also written wrappers of libraries in other languages
116 2015-10-19 11:19:19 <Diablo-D3> calling anything but C, well, its easier to just commit suicide, less pain too
117 2015-10-19 11:19:30 <jtimon> Diablo-D3: and we don't need fallacies because we have the right arguments for a C API instead of a C++ API (so far I haven't heard any valid argument from CodeShark in favor of a C++ API fr libconsensus)
118 2015-10-19 11:19:52 <btcdrak> jtimon: we are coming towards the end of the 0.12 development cycle, I think we should make a decision and enforce them after we branch 0.12 off. Until then, let's not get in the way of progress. I find all this libconsensus stuff very distracting from getting things done.
119 2015-10-19 11:20:37 <jtimon> btcdrak: I think not having consensus code currently encapsulated is a great barrier for progress
120 2015-10-19 11:21:08 <Diablo-D3> jtimon: the thing is, you COULD have native c++ and a c++ api... but just also have a built in c api, ie, the c++ code is written with the c api in mind
121 2015-10-19 11:21:24 <Diablo-D3> jtimon: a few c++ libraries have done this
122 2015-10-19 11:21:43 <jtimon> you can have c++ implementation and c API, right (that's what we currently have)
123 2015-10-19 11:21:59 <CodeShark> I already offered to help with a C API if it turns out there's demand for it - but I don't want any distractions from getting this stuff merged right now
124 2015-10-19 11:22:02 <Diablo-D3> as long as the c api is a first class citizen, you're fine
125 2015-10-19 11:22:03 <jtimon> but #6816 is not done with a C API in mind
126 2015-10-19 11:22:13 <CodeShark> I don't think I need a better argument than that
127 2015-10-19 11:22:17 <Diablo-D3> but it means the c++ api cant do anything magic
128 2015-10-19 11:22:34 <Diablo-D3> the c api HAS to be able to do everything the c++ api can with the same amount of effort
129 2015-10-19 11:22:43 <jtimon> CodeShark: "i there's demand" there's currently some users of libconsensus and they're using the C API (the only one it has!!)
130 2015-10-19 11:25:54 <jtimon> anyway, I'll focus on my document and finishing libconsensus on my own branch, so that people can't say " is not yet even created or finalised" anymore
131 2015-10-19 11:26:11 <jtimon> it could have been finalized long ago if there was more interest in it
132 2015-10-19 11:27:09 <jtimon> when I publish my document and still no code movements are done before 0.12, I will start my own fork
133 2015-10-19 11:27:30 <jtimon> maybe before 6816 if it gets merged as is
134 2015-10-19 11:27:56 <jtimon> mhmm, maybe I should create a libconsensus-friendly alternative to 6816 myself...
135 2015-10-19 11:29:41 <jtimon> given that CodeShark doesn't want to follow my suggestion of using just a static-sized array of a methodless struct in Consensus::Params
136 2015-10-19 11:29:57 <CodeShark> jtimon: have you even looked at the SoftForkDeployments class?
137 2015-10-19 11:30:49 <jtimon> CodeShark: yes, have you even looked at  #5995  ?
138 2015-10-19 11:37:15 <CodeShark> jtimon, I'll help you with all this refactoring stuff after 0.12. For now please don't let these nits get in the way of deploying stuff we really need
139 2015-10-19 11:37:34 <btcdrak> ^
140 2015-10-19 11:40:00 <btcdrak> jtimon: there's a good compromise, let's not get overly worried until the libconsensus plan is finalised, and you have a promise from CodeSkark he will help you a lot with the refactoring necessary come the time. Meantime, let's really focus on getting stuff we need now, merged.
141 2015-10-19 11:41:14 <btcdrak> jtimon: I know all this has been quite frustrating for you for a good year regarding this stuff, but there is definitely light at the end of the tunnel once we have a set plan for post 0.12.
142 2015-10-19 14:19:03 <wumpus> we all had a frustrating year, can't wait for it to end...
143 2015-10-19 14:35:44 <btcdrak> wumpus: well at least we're getting our momentum back.
144 2015-10-19 14:36:08 <jtimon> CodeShark: thanks for the offer, but my goal is not to delay versionbits. If you think that waht I'm asking for is too hard, I will try to do it myself using your code
145 2015-10-19 14:36:44 <jtimon> but so far you didn't said it is too hard, just that having a C API instead of a C++ API was a mistake in libconsensus in your opinion
146 2015-10-19 14:38:15 <jtimon> btcdrak: the plan I''m working on has 6 phases and I still have a little hope that the first (mostly move-only) phase can be merged before 0.12 is branched
147 2015-10-19 14:38:24 <CodeShark> jtimon: I don't think a C API ultimately is a bad thing - I just think now is not the time for it. I'd be happy to help you with all the libconsensus refactoring stuff after 0.12
148 2015-10-19 14:39:23 <btcdrak> jtimon: I think the IRC meeting was pretty clear that there would be no big changes this late into the release cycle. We'll get a refactoring window right after branching.
149 2015-10-19 14:40:06 <jtimon> btcdrak: I have had a plan for libconsenus for very long, it's just that I haven't been able to articulate it correctly (and people have failed to review the relevant PRs, ask the relevant questions and participate in the relevant ml threads), meanwhile we can slightly modify code that has not been merged yet to avoid creating more unnecessary work in the future
150 2015-10-19 14:40:17 <btcdrak> jtimon: there's just no way to justify big code moves at the end of a release cycle, it's really dangerous no matter how careful we are (and I'm pretty liberal minded when it comes to moveonly commits).
151 2015-10-19 14:40:34 <jtimon> CodeShark: "it's not the time for it" please, again libconsensus' API is currently C!!!!
152 2015-10-19 14:40:47 <CodeShark> jtimon: I think you're overestimating the amount of work required to create a C API and underestimating the amount of work to release this stuff if we insist on a C API right now
153 2015-10-19 14:41:44 <jtimon> btcdrak: those movements before forking 0.12 are much better for anyone rebasing from release to release than doing the same changes after 0.12 is released (on the master branch)
154 2015-10-19 14:41:50 <btcdrak> jtimon: the meeting we had about it was really really helpful for your goal because it got you criterion for others to agree on. Things will go more smoothly for you, but definitely we need a merge window where we can have more disruptive changes and then let the dust settle for the rest of the development cycle.
155 2015-10-19 14:42:23 <jtimon> CodeShark: I'm not asking for a complete C API now, I'm just asking for not making it harder than it currently is for later
156 2015-10-19 14:42:31 <btcdrak> jtimon: I would agree with you, but I'm I very much doubt it will happen. If I were you I would not hold up any hope for that.
157 2015-10-19 14:43:23 <btcdrak> jtimon: but I dont think any software project of this magnitude would tolerate big refactoring at the end of a release cycle.
158 2015-10-19 14:43:28 <jtimon> CodeShark: and I think you're overestimating the disadvantages of following my suggestion (even though you have not told them to me, besides vague arguments regardging readability and "ease of development")
159 2015-10-19 14:44:07 <CodeShark> jtimon: it's an obstacle to getting this stuff deployed which doesn't help functionality nor review in any way whatsoever...and we can always do it later
160 2015-10-19 14:44:31 <jtimon> CodeShark: everything can be done later, including versionbits
161 2015-10-19 14:44:59 <btcdrak> jtimon: and if we have a planned time when it can happen, and we know nothing else will get merged except refactoring, then you'll have all hands on deck. You cant rub against the grain and not expect friction. The plan we discussed at the first IRC meeting seems more palatable for everyone
162 2015-10-19 14:45:03 <jtimon> the thing is, we're doing versionbits now, it's not merged yet. we still can modify it to make things easier later
163 2015-10-19 14:45:12 <btcdrak> jtimon: absolutely not, versionbits is a huge priority
164 2015-10-19 14:46:27 <jtimon> btcdrak: we've suggested many "right times for refactors" but this "nothing else will get merged except refactoring," has never happen and I doubt that it will ever happen (and I personally don't think it's the best way to do things)
165 2015-10-19 14:47:01 <CodeShark> please trust me on this one, jtimon - I think this way is easier overall...and I will definitely help you with the refactoring after 0.12. I know it's very frustrating to have PRs sitting for months without making any inroads - I'll help you put together an effective plan
166 2015-10-19 14:47:05 <btcdrak> versionbits will remove a huge amount of friction to deploying softforks and it looks like there are a lot of things cuing up, stuff we really need in order to improve functionality. libconsensus is very important long term, but it's not more important than enabling the protocol to be extended efficiently
167 2015-10-19 14:47:27 <jtimon> CodeShark: can you please tell me the disadvantages of my suggestion in https://github.com/bitcoin/bitcoin/pull/6816#issuecomment-148043500 ?
168 2015-10-19 14:47:57 <btcdrak> jtimon: CodeSkark is a man of his word, he will help, and I think you'll need as many hands and eyes looking at refactoring as you can get.
169 2015-10-19 14:48:08 <jtimon> CodeShark: " I think this way is easier overal" and I disagree, please trust me on this one and follow my suggestion
170 2015-10-19 14:48:48 <jtimon> I'm not asking for help later, I'm asking to get answers to my review of #6816
171 2015-10-19 14:49:44 <jtimon> btcdrak: libconsensus (specially the encapsulation it requires) is a huge priority that will remove a lot friction too
172 2015-10-19 14:51:18 <jtimon> CodeShark: if you can't answer that question but you still reject to follow my suggestion I can simply create an alternative to #6816 so people can compare (even though it may be hard to undesrtand why my version will be more future-proof with rewards to completing libconsensus)
173 2015-10-19 14:53:58 <CodeShark> jtimon: I wrote a class called SoftForkDeployments that handles dynamic addition of new soft fork deployments which makes it very clean to initialize in CChainParams. If we want to put that behind a C API, we can always expose it as a regular function and hide the singleton objects behind the C API
174 2015-10-19 14:54:32 <CodeShark> point is nothing outside of the consensus stuff should have deep knowledge of this stucture except what's needed to initialize it
175 2015-10-19 14:54:45 <jtimon> CodeShark: in my suggestion, Consensus::Params would be still initialized very cleanly in chainparams.cpp
176 2015-10-19 14:55:18 <jtimon> CodeShark: when you say singleton you mean globals, and no, globals are not library friendly
177 2015-10-19 14:55:42 <jtimon> not for libconsensus nor for lib-bitcoin (if we ever get to that)
178 2015-10-19 14:56:34 <CodeShark> but point is SoftForkDeployments does a whole heck of a lot more than just hold an array or a vector - it has high level accessor methods that I use copiously elsewhere...and I don't want to expose the individual SoftFork objects as simple structs because it breaks all the safety measures afforded by the encapsulation
179 2015-10-19 14:57:19 <CodeShark> I tried to make the integration as simple as possible - and designed these classes accordingly
180 2015-10-19 14:57:36 <CodeShark> you're asking me to sacrifice all that to conform to some spec for something that doesn't even exist yet
181 2015-10-19 14:57:47 <jtimon> CodeShark: you can encapsulate things behind functions just as easily as you can encapsulate it behind classes, remember abstract data types https://en.wikipedia.org/wiki/Abstract_data_type ? those are older than classes
182 2015-10-19 14:58:31 <CodeShark> and we can do that after 0.12
183 2015-10-19 14:58:37 <CodeShark> what's the rush to do it now?
184 2015-10-19 14:58:47 <jtimon> CodeShark: can you at least understand that what you think it's "as simple as possible" may actually not be "as simple as possible" or "easier overall"
185 2015-10-19 14:58:48 <CodeShark> doesn't add any functionality, complicates review, delays deployment
186 2015-10-19 14:58:49 <jtimon> ?
187 2015-10-19 14:59:19 <davec> yeah
188 2015-10-19 14:59:47 <jtimon> "doesn't add any functionality", agree "complicates review" disagree, "delays deployment" not much and not in total (doing it wrong now will make libconsensus harder to complete later)
189 2015-10-19 15:01:00 <jtimon> CodeShark: the rush is we're reviewing #6816 now and we cannot change its commits once it's merged (we can fix newly introduced libconsensus-unfriendly changes later, but with new commtis)
190 2015-10-19 15:01:44 <jtimon> still no disadvantages of using my suggestion besides "I think it's simpler this way"
191 2015-10-19 15:02:39 <CodeShark> I think it's a LOT simpler overall...and will take less time and effort in the long run to do it this way. I think that's a pretty good reason
192 2015-10-19 15:03:14 <CodeShark> I told you, I'll help you with the refactor stuff during a dedicated time window when we look specifically at that
193 2015-10-19 15:03:26 <CodeShark> I don't think it's a good idea to mix the refactor stuff with this PR
194 2015-10-19 15:04:25 <CodeShark> I don't think it will add that much more work on your end to do it this way - perhaps what's bugging you is the friction you're experiencing with others
195 2015-10-19 15:10:20 <jtimon> "I think it's a LOT simpler overall" exactly, you think, and I disagree
196 2015-10-19 15:10:37 <jtimon> " I'll help you with the refactor stuff" thanks again but that's orthogonal
197 2015-10-19 15:11:12 <jtimon> CodeShark: I'm not suggesting to mux refactor stuff with this PR, read my suggestion again: https://github.com/bitcoin/bitcoin/pull/6816#issuecomment-148043500
198 2015-10-19 15:12:34 <jtimon> CodeShark: what's bugging me is making things harder for libconsensus than they're currently are when we can chose a more libconsensus-friendly alternative for free
199 2015-10-19 15:13:09 <jtimon> honestly, if you're doing it like this I would even prefer that you don't touch Consensus::Params and use CChainParams and its globals instead
200 2015-10-19 15:14:14 <jtimon> anyway, it seems this discussion is going nowhere and I will have to implement my suggestion myself
201 2015-10-19 15:14:55 <jtimon> it will delay my libconsensus plan document further but who cares (apart from me)?
202 2015-10-19 15:22:54 <jtimon> CodeShark: could you do that? move softForkDeployments from Consensus::Params to CChainParams ?
203 2015-10-19 15:24:15 <jtimon> exposing VerifyTx may end up being easier to do than exposing VerifyHeader after all and having that libconsensus-unfriendly code in consensus/params may be a barrier to expose VerifyTx
204 2015-10-19 15:35:33 <jtimon> CodeShark: for example, how can introducing a new unnecessary global to later remove it be "simpler overall" than just not introducing new globals and not having to remove them later?
205 2015-10-19 15:36:21 <jtimon> instead of helping me remove globals later, why don't you avoid introducing them now?
206 2015-10-19 15:37:20 <jtimon> or introduce the global in main, but don't use it as a global within consensus code
207 2015-10-19 16:33:39 <waxwing> why is the 'basic' multiplication (in ecmult_impl.h) function of the form 'aB +cD', and then the tweak_mult is used for doing a single multiply? (in secp256k1). i guess it's just about optimizations? just curious.
208 2015-10-19 16:35:13 <gmaxwell> waxwing: not just aB + cD but  aG + cD -- one point is fixed the other is variable. And the reason is because multiexp is considerably faster than doing seperate multiplies and adding them.
209 2015-10-19 16:35:28 <gmaxwell> waxwing: as they can share doubling work.
210 2015-10-19 16:36:22 <waxwing> ok, thanks. and yes, good point, G not anything.
211 2015-10-19 16:36:57 <gmaxwell> because  2*x + 2*y = 2*(x+y)  (distributive property)
212 2015-10-19 16:37:09 <gmaxwell> and G is fixed because it uses a precomputed table for multiples of G.
213 2015-10-19 16:37:27 <waxwing> yes. alles klar.
214 2015-10-19 16:38:31 <gmaxwell> waxwing: there is a #secp256k1 for the library, incidentally.
215 2015-10-19 16:38:41 <waxwing> oh, will do, cheers
216 2015-10-19 16:48:36 <cfields_> jtimon_: yes, we agreed on an external C API for libbitcoinconsensus. That has nothing to do with what it's written in though.
217 2015-10-19 16:58:28 <jtimon_> cfields_: yes, they are related, Params::Consensus will be much harder to be C-API-compatible after introducing Consensus::VersionBits::SoftForkDeployments softForkDeployments in it
218 2015-10-19 16:59:25 <jtimon_> cfields_: also CodeShark used "libconsensus' API should be C++" as an argument to avoid following my suggestion in https://github.com/bitcoin/bitcoin/pull/6816#issuecomment-148043500
219 2015-10-19 16:59:38 <CodeShark> no
220 2015-10-19 16:59:43 <CodeShark> that's not the argument I gave at all
221 2015-10-19 17:00:20 <jtimon_> <CodeShark> and nobody is asking for a C libconsensus right now
222 2015-10-19 17:00:20 <jtimon_> <CodeShark> the main user will be the core devs...who are now using C++
223 2015-10-19 17:00:48 <CodeShark> that's actually an entirely separate issue we can delve into after 0.12
224 2015-10-19 17:01:07 <CodeShark> fwiw, I don't mind so much maintaining g_blockRuleIndex in main...although I'd much prefer to move ALL of those globals to a unit that can manage them with strict accessors
225 2015-10-19 17:01:17 <CodeShark> I really don't like including main.h anywhere, though
226 2015-10-19 17:01:21 <jtimon_> but if you agree now that libconsensus' API should be a C API (what it currently is), then we can move on and forget that part of our discussion
227 2015-10-19 17:01:39 <CodeShark> there is no libconsensus, really
228 2015-10-19 17:02:06 <CodeShark> but anyhow...
229 2015-10-19 17:02:13 <CodeShark> I'm willing to defer that discussion
230 2015-10-19 17:02:14 <jtimon_> CodeShark: I dislike including main.h anywhere too, I really like to remove includes of main.h, but you said yourself that we shouldn't mix refactor changes with versionbits
231 2015-10-19 17:02:31 <jtimon_> CodeShark: yes, there is a libconsensus
232 2015-10-19 17:02:47 <jtimon_> it's not complete but it exists, please stop saying there's no libconsensus
233 2015-10-19 17:04:10 <jtimon_> CodeShark: see https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.h#L56 and https://github.com/bitcoin/bitcoin/blob/master/src/Makefile.am#L387 what is that if not the current libconsensus (with a C API) ?
234 2015-10-19 17:05:26 <jtimon_> CodeShark: I would prefer to just remove the use of globals completely, but I wouldn't complain about moving them to globals/server.o, globals/common.o etc in the meantime
235 2015-10-19 17:05:38 <CodeShark> right
236 2015-10-19 17:06:02 <jtimon_> CodeShark: globals are bad with or without "strict accessors"
237 2015-10-19 17:06:14 <CodeShark> well, they are singletons, strictly speaking
238 2015-10-19 17:06:46 <jtimon_> not really, they are globals, but terminology...
239 2015-10-19 17:07:13 <CodeShark> accessors at least can make sure they don't get strangely modified in some random place
240 2015-10-19 17:07:40 <CodeShark> the point is to avoid side effects
241 2015-10-19 17:08:05 <jtimon_> unless you can use the accessor from any random place just like you could use the global directly, but whatever...
242 2015-10-19 17:08:28 <CodeShark> but the accessors can ensure internal structure consistency or make it read-only
243 2015-10-19 17:08:45 <CodeShark> or allow you to add tracers
244 2015-10-19 17:09:05 <CodeShark> all in all, debuging is a hell of a lot easier
245 2015-10-19 17:09:06 <jtimon_> yes, and passing the variables directly anbd explicitly to the functions that need them is the way to remove the globals, not "strict accessors"
246 2015-10-19 17:09:31 <CodeShark> I don't disagree
247 2015-10-19 17:09:42 <jtimon_> function parameters can also be read-only (see my changes to your patch)
248 2015-10-19 17:10:48 <jtimon_> for example https://github.com/jtimon/bitcoin/commit/6971b23a47840842f1e67f065d77ff13893c19a4#diff-5d812cf49e92aa2ce97088ba68121c4cR30
249 2015-10-19 17:11:40 <jtimon_> CodeShark: if you don't disagree, please don't use globals inside new functions/methods (like your patch is currently doing)
250 2015-10-19 17:12:41 <jtimon_> for old methods...well, we can fix that later. But introducing things that you already know you will want to change and in which way makes no sense IMO
251 2015-10-19 17:13:09 <CodeShark> jtimon_: I fully agree with getting rid of the globals and passing stuff as parameters
252 2015-10-19 17:15:24 <jtimon_> CodeShark: Great, feel free to squash or use my code the way you think it's best
253 2015-10-19 17:17:35 <jtimon_> I will keep working on making your patch more libconsensus-friendly (without changing functionality) before it is merged
254 2015-10-19 18:28:24 <warren> jgarzik: you there?
255 2015-10-19 18:28:26 <warren> jgarzik: which GPG key is current?  I have exmulti.com and bitpay.com
256 2015-10-19 18:28:30 <warren> I'll just send it to wumpus for now and he'll send it to whoever he thinks should have it.
257 2015-10-19 18:50:34 <jgarzik> warren, jgarzik@pobox.com, the one on bitcoin.org & has been used in open source for 20 years :)
258 2015-10-19 18:50:45 <jgarzik> warren, bitpay.com one works also
259 2015-10-19 18:51:47 <jgarzik> warren, Cross-signed security envelope: https://github.com/bitcoin-dot-org/bitcoin.org/pull/1074
260 2015-10-19 19:36:39 <jcorgan> warren: commit 7d325b9de is signed by the right key
261 2015-10-19 22:28:40 <warren> jgarzik: where is the key on bitcoin.org?  I looked for your key in bitcoin source https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-downloader but it's missing here
262 2015-10-19 22:32:24 <jgarzik> warren, This PR gives the link https://github.com/bitcoin-dot-org/bitcoin.org/pull/1074
263 2015-10-19 22:33:07 <jtimon_> has anyone else been able to reproduce the memory losses issue? is there an issue for it on github?
264 2015-10-19 22:33:31 <EagleTM> jtimon_: memory losses? like large mempool?
265 2015-10-19 22:35:19 <gmaxwell> jtimon_: the people going on about memory leaks on the list are very likely confused.
266 2015-10-19 22:35:41 <gmaxwell> they're seeing mempool bloat and the fact that prior to (git master) the mempool stats command didn't report overheads.
267 2015-10-19 22:35:58 <gmaxwell> One of the people reporting ran under valgrind, and, as expected saw no leak.
268 2015-10-19 22:36:25 <gmaxwell> The numbers they're reporting sound typical for nodes without relay fee increased.
269 2015-10-19 22:37:05 <EagleTM> even minrelaytxfee=0.000011 helps quite a bit :)
270 2015-10-19 23:52:45 <brand0> if they're running old versions of bitcoind that would explain it