1 2015-11-29 01:11:58 <wizkid057> yeah, Eligius will be v4 within the next couple of hours
  2 2015-11-29 01:12:31 <gmaxwell> wizkid057: cool.
  3 2015-11-29 01:32:14 <btcdrak> wizkid057: +1
  4 2015-11-29 03:10:39 <wizkid057> alright, all set.  next block will be v4 :)
  5 2015-11-29 03:13:59 <Newyorkadam> wizkid057: grats :p
  6 2015-11-29 03:14:38 <wizkid057> thanks.  I don't want to hold up the show like I did with v2->v3 :P
  7 2015-11-29 06:20:44 <jtoomim> what is the default nSequence value for transactions created by Core?
  8 2015-11-29 06:20:54 <jtoomim> what is the default nSequence value for transactions created by other wallets?
  9 2015-11-29 06:24:02 <gmaxwell> INT_MAX, and INT_MAX-1 (e.g. neigher are implicated by opt in rbf)
 10 2015-11-29 06:25:13 <jtoomim> k, thanks
 11 2015-11-29 06:42:25 <jtoomim> by the way, i coded up an RPC a couple of days ago into XT to change the block size soft limit for a mining full node without restarting bitcoind. should i submit it as a PR for Core?
 12 2015-11-29 06:42:37 <jtoomim> do you guys think it would be useful and uncontroversial?
 13 2015-11-29 06:43:52 <jtoomim> the code would need to be slightly different from what I used for XT, but it would look mostly like this: https://github.com/jtoomim/bitcoinxt/commit/86b978a42b0a5bd3d47e0b0b29e8dadf90b274b8
 14 2015-11-29 06:51:06 <gmaxwell> jtoomim: quick glance at your patch .. what lock protects nBlockMaxSize?
 15 2015-11-29 06:51:53 <jtoomim> cs_main
 16 2015-11-29 06:52:17 <jtoomim> locked either in CNB or GBT, IIRC
 17 2015-11-29 06:52:19 <jtoomim> i think GBT
 18 2015-11-29 06:52:32 <jtoomim> also locked in setblockmaxsize()
 19 2015-11-29 06:52:40 <gmaxwell> Luke-Jr: and jtimon might have more opinions around making mining parameters runtime settable (e.g. should there be an rpc or a setpolicy call?) but beyond correctness and interface considerations, I don't think there is anything controversial with making existing settings runtime settable.
 20 2015-11-29 06:53:18 <gmaxwell> For non-settable things there may be deeper assumptions; for existing settings the only extra thing to worrk about is locking.
 21 2015-11-29 06:53:38 <Luke-Jr> jtoomim: sounds reasonable, but I suggest making a setconfig RPC that can change any mapArgs
 22 2015-11-29 06:54:02 <gmaxwell> Luke-Jr: thats going to end up data racy.
 23 2015-11-29 06:54:14 <Luke-Jr> gmaxwell: with a mutex?
 24 2015-11-29 06:54:38 <jtoomim> each variable might have a different mutex
 25 2015-11-29 06:54:43 <gmaxwell> Luke-Jr: it means you'd need to go add a lock on all use of args in the code, which might have performance implications.
 26 2015-11-29 06:54:58 <gmaxwell> (though if so, they should probably be hoisted from innerloops)
 27 2015-11-29 06:55:04 <Luke-Jr> hm, they're not already in cs_main?
 28 2015-11-29 06:55:08 <jtoomim> i think it's probably safer to code each one individually
 29 2015-11-29 06:55:16 <gmaxwell> There may be other assumptions that they don't change, e.g. we have data structures that are init-time sized from them.
 30 2015-11-29 06:55:24 <gmaxwell> Luke-Jr: we have code that runs without cs_main.
 31 2015-11-29 06:55:25 <jtoomim> many of them would be under cs_main right now, but we might not want everything under one lock for all eternity
 32 2015-11-29 06:55:33 <gmaxwell> Maybe all the args accesses have it? I dunno.
 33 2015-11-29 06:55:37 <Luke-Jr> gmaxwell: yes, we don't need to support using it in every possible way; it's just simpler to code
 34 2015-11-29 06:56:20 <gmaxwell> Luke-Jr: I'm sympathetic to that thinking, but it's also a bit of a trap. What happens when somethign is sized at init time (changing doesn't work,okay) AND that size is used again later?
 35 2015-11-29 06:56:38 <gmaxwell> would be a lot of work to review. might be best but not a small change at least.
 36 2015-11-29 06:56:44 <Luke-Jr> gmaxwell: we tell the user "don't do that" :p
 37 2015-11-29 06:57:18 <Luke-Jr> (or fix it, if we want to support it going forward)
 38 2015-11-29 06:57:30 <jtoomim> reviewing each variable might be close to the same amount of work as coding each variable individually.
 39 2015-11-29 06:57:41 <jtoomim> there probably aren't that many variables that people would want to change on-the-fly anyway
 40 2015-11-29 06:58:04 <jtoomim> block size, dust limit, maybe a couple others
 41 2015-11-29 06:58:49 <Luke-Jr> I'm suggesting we don't have to explicitly prevent changing things that won't work. It can simply be documented as only supported for a known set, use at own risk
 42 2015-11-29 06:59:38 <jtoomim> well, i'm not going to code that.
 43 2015-11-29 07:03:37 <gmaxwell> jtoomim: I think there are very few settings that it wouldn't be good to be able to change on the fly. But some are just not realistic.
 44 2015-11-29 07:06:25 <David__> I want read source code of bitcoin, where to start?
 45 2015-11-29 07:06:35 <David__> does is open source?
 46 2015-11-29 07:06:53 <jtoomim> https://github.com/bitcoin/bitcoin/tree/master/src
 47 2015-11-29 07:07:19 <jtoomim> perhaps main.cpp or init.cpp
 48 2015-11-29 07:08:50 <jtoomim> gmaxwell luke-jr i'm not saying that having one RPC to change them all would be a bad thing. I'm just saying that it's more work than i want to put into it at the moment.
 49 2015-11-29 07:09:38 <Luke-Jr> jtoomim: in other words "I'm done, take it or leave it" or "that sounds much more difficult" ?
 50 2015-11-29 07:09:43 <gmaxwell> jtoomim: yes, nothing wrong with that.
 51 2015-11-29 07:09:51 <gmaxwell> Luke-Jr: I think you're reading too much tone into jtoomim's words.
 52 2015-11-29 07:10:16 <Luke-Jr> gmaxwell: I think you're reading too much tone into my own? :P
 53 2015-11-29 07:10:19 <gmaxwell> He was asking if we're interested and if it would be controversial. The latter, no, but perhaps it's too minor to bother.
 54 2015-11-29 07:10:34 <gmaxwell> Luke-Jr: okay, then: jtoomim: please don't read too much into luke's tone.
 55 2015-11-29 07:11:52 <tulip> David__: if you're interested in the system, not the current state, the wxBitcoin 0.1 source is considerably easier to read and significantly shorter. it's consensus-incompatible with the network now but the concepts are still the same.
 56 2015-11-29 07:12:42 <gmaxwell> tulip: it should actually sync the chain with a bdb config change and a version message protocol adapter. Have you tried lately?
 57 2015-11-29 07:13:50 <gmaxwell> The splitting of script execution was probably an unintentional hard fork. but afaik no one has crated a transaction that would trip up on it.
 58 2015-11-29 07:14:12 <tulip> I'm tempted to give it a go. the node it is syncing to might need the p2p message size relaxed too, or was that a later change than 0.1?
 59 2015-11-29 07:14:49 <gmaxwell> the misbehavior trigger is getheaders, which 0.1 doesn't have at all, IIRC.
 60 2015-11-29 07:15:06 <David__> Hi Tulip, got it. thanks. I am java coder, hope it is not so difficult.
 61 2015-11-29 07:15:08 <tulip> you're right, it doesn't have that p2p message.
 62 2015-11-29 07:15:19 <gmaxwell> though it may get stuck for lack of the 'continue' support when 500 blocks won't fit in 2mb.
 63 2015-11-29 07:15:47 <tulip> I'll see how it goes, I imagine this will take weeks of CPU time to even find out though.
 64 2015-11-29 07:16:14 <Luke-Jr> huh, was 0.1 really more readable? O.o
 65 2015-11-29 07:16:18 <gmaxwell> Yea, it was a lot slower.
 66 2015-11-29 07:16:23 <gmaxwell> I think it was a lot more readable.
 67 2015-11-29 07:16:34 <tulip> 0.1 is tiny compared with the size of the code now
 68 2015-11-29 07:16:47 <gmaxwell> Some of it is style preference, but it actually did a lot less.. so there is a lot less distractions.
 69 2015-11-29 07:17:14 <tulip> of the stuff there you can ignore things like irc.cpp and market.cpp, suddenly there's not even many files remaining.
 70 2015-11-29 07:17:39 <jtoomim> luke-jr: mostly the former. I added dynamic blocksize adjustment because i needed it for my testing.
 71 2015-11-29 07:18:06 <jtoomim> as for tone: let me know if we need to settle this through interpretive dance.
 72 2015-11-29 07:18:15 <Luke-Jr> lol
 73 2015-11-29 07:19:02 <sipa> Luke-Jr, gmaxwell: args are not protrcted by any lock. you can't just go change them on the fly in general
 74 2015-11-29 07:20:12 <gmaxwell> jtoomim: heh sorry for the meta tangent, I just thought it sounded like luke was yelling at you. My bad. :)
 75 2015-11-29 07:22:49 <jtoomim> talk about meta. it sounds like we're now arguing about whether we were having an argument about arguments
 76 2015-11-29 07:22:50 <sipa> Luke-Jr: several are parsed into local variables, or have complex sanity checks done on them, conflict with others, ...
 77 2015-11-29 07:23:58 <sipa> Luke-Jr: i would absolutely love to be able to change all variables on the fly, but it would first require revamping most of the option code, to make it aware of all those checks, interactions, and parsings
 78 2015-11-29 07:24:04 <gmaxwell> jtoomim: You hurt my feelings!!!
 79 2015-11-29 07:24:47 <Luke-Jr> gmaxwell: when have you ever heard me yell? :P
 80 2015-11-29 07:25:04 <gmaxwell> Luke-Jr: in any case, in your long sought quest to get people to actually set settings, getting them runtime configurable would no doubt help.
 81 2015-11-29 07:25:12 <gmaxwell> Luke-Jr: online? do you do anything but? :P
 82 2015-11-29 07:25:28 <Luke-Jr> yelling would be quite out of character for me
 83 2015-11-29 07:25:41 <jtoomim> it's a LOCK2(cs_main, mempool.cs); in CreateNewBlock() that protects the one and only use of nBlockMaxSize, by the way.
 84 2015-11-29 07:25:44 <gmaxwell> Only someone who's met you in person would know this.
 85 2015-11-29 07:26:02 <sipa> jtoomim: in another channel i'm in, there is a bot to which you can tell "oa on" or "oa off", to put the channel in or out of overanalysis mode; "oa off" always fails with an error
 86 2015-11-29 07:26:42 <gmaxwell> do people study the error?
 87 2015-11-29 07:26:43 <sipa> jtoomim: cs_main is fine then
 88 2015-11-29 07:26:56 <sipa> gmaxwell: it has been the topic of discussion for sure
 89 2015-11-29 07:27:10 <jtoomim> sipa i bet that's just because the author of the code for that channel tried to perform excessive abstraction in their arbitrary argument getting-and-setting code
 90 2015-11-29 07:29:44 <David__> what is the difference of bitcoinJ and bitcoin core?
 91 2015-11-29 07:30:04 <Luke-Jr> jtoomim: have we met in person?
 92 2015-11-29 07:30:31 <jtoomim> nope
 93 2015-11-29 07:30:31 <Luke-Jr> David__: Bitcoin Core is literally Bitcoin itself, plus a wallet, and some other stuff; BitcoinJ is just a client library
 94 2015-11-29 07:30:37 <tulip> David__: BitcoinJ is a complete re-write in Java with slightly different aims, generally it is used in "SPV" mode which does very weak validation of network rules.
 95 2015-11-29 07:30:53 <gmaxwell> There is a more complete implementation of the protocol in bitcoinj but it's not normally used and its author will tell you not to use it.
 96 2015-11-29 07:43:03 <Lightsword> does it look the CNB rewrite https://github.com/bitcoin/bitcoin/pull/6898 will make it into 0.12?
 97 2015-11-29 07:43:31 <Lightsword> look like*
 98 2015-11-29 07:43:45 <gmaxwell> Lightsword: as you can see, it's milestoned 0.12
 99 2015-11-29 07:45:42 <Lightsword> I see, is it mainly just awaiting code review?
100 2015-11-29 07:48:41 <midnightmagic> also, it's not actually SPV.
101 2015-11-29 08:03:56 <Lightsword> since TestBlockValidity is the largest source of delay in #6898 would it be safe enough to skip the TestBlockValidity check for the first GBT call after a block change?
102 2015-11-29 08:05:15 <Lightsword> or to at least do the check after responding to the GBT call so that you know there was a failure
103 2015-11-29 08:05:26 <jtoomim> lightsword: my proposal is to run TBV in a background thread asynchronously
104 2015-11-29 08:05:41 <jtoomim> as long as no previous failures of TBV have been observerd
105 2015-11-29 08:06:27 <jtoomim> i don't think i've ever seen TBV fail
106 2015-11-29 08:06:33 <gmaxwell> I certantly have.
107 2015-11-29 08:06:47 <jtoomim> i guess i need to try harder then
108 2015-11-29 08:07:11 <Lightsword> jtoomim, would you wait for TBV to complete before responding to the GBT call?
109 2015-11-29 08:07:24 <gmaxwell> I think returning early and running it in the background is reasonable, I don't thing anyone cares if they get one unit of bad work before the processes asserts.
110 2015-11-29 08:07:27 <jtoomim> lightsword, no i would not
111 2015-11-29 08:07:43 <Lightsword> gmaxwell, a failed TBV results in a shutdown of core right?
112 2015-11-29 08:07:48 <gmaxwell> But thats still not as good as just returning an empty template when the whole thing hasn't been precomputed.
113 2015-11-29 08:08:04 <gmaxwell> Lightsword: yes.
114 2015-11-29 08:08:08 <jtoomim> if TBV has not failed in, say, the last 24 hours, then i would optimisticly return the blocktemplate via RPC before waiting for TBV to complete
115 2015-11-29 08:08:36 <gmaxwell> jtoomim: I don't see any reason for that 24 hours, that just results in undiagnosable mysterious behavior changes. :)
116 2015-11-29 08:08:44 <jtoomim> gmaxwell: pool software can easily create an empty template without GBT
117 2015-11-29 08:09:15 <jtoomim> gmaxwell: oh, i didn't realize TBV closes bitcoind
118 2015-11-29 08:09:19 <gmaxwell> jtoomim: sure, from the notify. But it's extra work and things to get right (and people have gotten that stuff wrong in the past. :( )
119 2015-11-29 08:09:31 <Lightsword> gmaxwell, from the looks of it with #6898 the delay difference between the empty template and one with transactions would be negligable if the TBV check is skipped
120 2015-11-29 08:10:02 <gmaxwell> Lightsword: we've talked before about having some kinds of failures write a file that inhibits startup until erased. "YOUR_BITCOIN_NODE_IS_SERIOUSLY_BUSTED_DO_NOT_REMOVE_UNTIL_YOU_FIGURE_OUT_WHY.txt"
121 2015-11-29 08:10:09 <jtoomim> i asked ckolivas and kano about it a while ago, and they said that bitcoind should *not* return an empty template under any circumstances
122 2015-11-29 08:10:32 <jtoomim> i think the pool software authors have already done that extra work
123 2015-11-29 08:10:38 <gmaxwell> jtoomim: Then they gave you bad advice.
124 2015-11-29 08:11:04 <Lightsword> before the spam attacks I don’t think it was a major delay source
125 2015-11-29 08:11:24 <gmaxwell> I believe the only pool software publically available that does dummy work generation is eloipool.
126 2015-11-29 08:11:54 <jtoomim> i think that's true
127 2015-11-29 08:12:07 <jtoomim> and i think ckpool's authors actively chose not to do it
128 2015-11-29 08:12:18 <Lightsword> it’s not just them who actively chose not to do it
129 2015-11-29 08:12:19 <jtoomim> i think it would be fine if it were a configurable option
130 2015-11-29 08:12:36 <jtoomim> though it makes me feel a little dirty
131 2015-11-29 08:12:36 <Lightsword> eleuthria had similar thoughts on the matter
132 2015-11-29 08:13:09 <jtoomim> but i think we can make CNB fast enough that there's no incentive to make empty blocks at all
133 2015-11-29 08:13:11 <Lightsword> if the benchmarks on #6898 are accurate it shouldn’t really matter
134 2015-11-29 08:13:21 <Lightsword> if the TBV check is skipped
135 2015-11-29 08:13:55 <jtoomim> lightsword the numbers i saw from my own partial rewrite of CNB suggest that those numbers are plausible
136 2015-11-29 08:14:10 <gmaxwell> jtoomim: maybe, but I am not willing to increase the non-validated blocks to avoid a few harmless empty ones.
137 2015-11-29 08:14:59 <Lightsword> the other thing I’m thinking is that returning non-empty templates may encourage full validation for those doing the stratum based SPV mining
138 2015-11-29 08:15:16 <gmaxwell> Empty blocks are harmless, they still drive consensus on the longest validated chain, and they at worse a fraction of a percent capacity loss-- not even when blocks aren't all totally full.  Blocks are a posson process so one block being found doesn't at all delay the next (until retargeting)
139 2015-11-29 08:15:59 <gmaxwell> Lightsword: if its even a few miliseconds slower it will do the opposite though.
140 2015-11-29 08:16:53 <Lightsword> gmaxwell, fully validating will always be slower than the stratum based validation skipping mining so there is little advantage unless you have transactions
141 2015-11-29 08:17:01 <jtoomim> empty blocks increase the difficulty but don't carry any transactions, so they reduce the max tps of the bitcoin network
142 2015-11-29 08:17:46 <gmaxwell> Lightsword: There is no reason why it needs to be non-trivially slower; as normally the entirety of a block is verfied before you ever got it, whats left is hashing, but thats it.
143 2015-11-29 08:18:22 <jtoomim> i think a getblocktemplate interface that blocks until the new template is actually ready is easier to work with than an interface that gives different behavior at different times
144 2015-11-29 08:18:23 <gmaxwell> jtoomim: a negligible amount, e.g. a fraction of a percent. And even small amounts of validation skipping make lite clients far more risky.
145 2015-11-29 08:18:31 <Lightsword> gmaxwell, well you have to download the block to validate it which the stratum based mining does not do
146 2015-11-29 08:18:42 <gmaxwell> Lightsword: thats not true.
147 2015-11-29 08:18:58 <gmaxwell> You already have the content of the block-- it's all the transactions that came before.
148 2015-11-29 08:18:59 <jtoomim> i.e. if you get an empty result you have to guess about whether the mempool is empty or not, and if it's empty you poll every few ms until you get a full template back? awkward.
149 2015-11-29 08:19:04 <sipa> Lightsword: the miner creating it does not need to download
150 2015-11-29 08:19:11 <gmaxwell> This is precisely the optimization that the relay node client does.
151 2015-11-29 08:19:36 <Lightsword> sipa, I’m talking about non-self created blocks
152 2015-11-29 08:19:41 <sipa> ok
153 2015-11-29 08:19:43 <gmaxwell> jtoomim: everyone already does things like N second polling to get updated transactions.
154 2015-11-29 08:19:59 <jtoomim> n second, yes, but n millisecond?
155 2015-11-29 08:20:19 <jtoomim> polling for a few more transactions out of a thousand is one thing. polling for 1 tx versus 1000 is a different thing.
156 2015-11-29 08:20:36 <jtoomim> those two scenarios have quantitatively vastly different economic incentives
157 2015-11-29 08:21:11 <gmaxwell> why do you care about n millisecond. 1 second is a < 1% capacity loss.
158 2015-11-29 08:21:22 <jtoomim> block validation in UpdateTip should take longer than CreateNewBlock/getblocktemplate
159 2015-11-29 08:21:42 <Lightsword> gmaxwell, I’m talking about the system where pools mine off of each others stratum headers before downloading and validating the block
160 2015-11-29 08:21:44 <jtoomim> once CNB is fully optimized, it should take under 100 ms, i think
161 2015-11-29 08:21:56 <gmaxwell> jtoomim: no it shouldn't; considering that you cannot CNB until the update has happened, they're cumulative.
162 2015-11-29 08:22:33 <jtoomim> yes, they're cumulative, which is why returning an empty block is not very helpful
163 2015-11-29 08:22:38 <gmaxwell> Lightsword: I know you are. And you claimed that to validate a block you must download it. And this just isn't true, today in practice.
164 2015-11-29 08:22:49 <jtoomim> there is a very short period of time when bitcoind knows what the previous valid block is but doesn't know what transactions can go in the next one
165 2015-11-29 08:23:36 <gmaxwell> jtoomim: 100ms is a signficant fraction of the updatetip time. E.g. it can make the difference between miners gutting validation and not;  if it doesn't it doesn't sure, and no reason to return an empty result then.
166 2015-11-29 08:24:10 <Lightsword> gmaxwell, I’m confused about how you already could have the content of the block especially when a number of pools are mining unseen transactions
167 2015-11-29 08:24:29 <sipa> Lightsword: they're not 100% unseen, right?
168 2015-11-29 08:24:36 <Lightsword> sipa, some are AFAIK
169 2015-11-29 08:24:43 <Lightsword> I think 21 Inc and f2pool
170 2015-11-29 08:24:55 <Lightsword> maybe btcchina as well
171 2015-11-29 08:25:09 <sipa> i have a hard time believing that
172 2015-11-29 08:25:18 <Lightsword> f2pool apparently self-mines all their payouts
173 2015-11-29 08:25:34 <gmaxwell> 21inc is about half unseen, it's weird. or at least what bc.i says is 21inc.
174 2015-11-29 08:25:34 <sipa> but that's not the only thing they mine
175 2015-11-29 08:25:49 <tulip> sipa: I don't have numbers but they do mine some number of unseen transactions.
176 2015-11-29 08:25:57 <sipa> ok
177 2015-11-29 08:26:01 <Lightsword> gmaxwell, I was the one who tagged them on bc.i it is accurate
178 2015-11-29 08:26:04 <gmaxwell> Lightsword: Unseen things are unseen and have to be transfered, but miners that do that will suffer higher orphan rates for their blocks (for several reasons)
179 2015-11-29 08:26:33 <gmaxwell> Lightsword: I contacted them and they claimed they run unmodified software with stock settings, so I wondered if maybe it wasn't really their own blocks.
180 2015-11-29 08:26:51 <sipa> gmaxwell: i'm confused by what you said above; for what amount of time (for TBV) do you think it's reasonable to not do it before CNB returns?
181 2015-11-29 08:27:04 <tulip> sipa: I've been working on extending -debug=bench to write stats for EC cache hitrates, which is where that is from.
182 2015-11-29 08:27:21 <sipa> tulip: i see :)
183 2015-11-29 08:27:23 <Lightsword> gmaxwell, they also couldn’t really be any other pool on bc.i due to the amount of unknowns being incredibly small
184 2015-11-29 08:27:37 <sipa> tulip: i wrote code for that too, maybe it's still in some branch
185 2015-11-29 08:27:40 <Lightsword> could they be running some weird relay settings?
186 2015-11-29 08:28:08 <tulip> sipa: might try and find it and see how you implemented it.
187 2015-11-29 08:28:18 <sipa> probably not pushed it
188 2015-11-29 08:28:37 <gmaxwell> sipa: if the output is being continually tested then I don't think about it in terms of time. Its just that if a node of yours is producing bad results you want it to fail immediately so you can fail over to another work source.
189 2015-11-29 08:28:57 <gmaxwell> a single bad block showing up on the network isn't the end of the world, so long as no one will extend it.
190 2015-11-29 08:29:32 <Lightsword> gmaxwell, anyways my point is that in practice and even with relay network there is no real way to beat the stratum based method since it completely bypasses bitcoind
191 2015-11-29 08:30:02 <gmaxwell> sipa: so 'e.g. before the next one', if you ever give bad work you're guarenteed to shut down 'promotly'.
192 2015-11-29 08:30:14 <sipa> Lightsword: there is absolute no way to beat it, which is said
193 2015-11-29 08:30:37 <sipa> Lightsword: but there are certainly configurations in which the benefit is marginal enough to hopefully not matter
194 2015-11-29 08:30:43 <sipa> *sad
195 2015-11-29 08:31:06 <gmaxwell> Lightsword: thats the whole point of optimizing bitcoind;  To be clear: there are many locally profit maximixing things miners could do at the expense of users of bitcoin, if most miners do them bitcoin _cannot_ work.
196 2015-11-29 08:31:55 <Lightsword> sipa, yeah that’s why I think there needs to be more of an advantage(like having transactions) to fully validating and why returning an empty template would not help much
197 2015-11-29 08:32:06 <gmaxwell> So our excercise has always been about optimizing things so that the benefit of rational behavior over alturistic is so small that the other benefits of alturism (like a healthier bitcoin system, decreased risk of attack, friendly relations with professionals, etc.) dominate them.
198 2015-11-29 08:32:27 <sipa> gmaxwell: imho TBV should run outside of the CNB loop, and just test some fraction of work produced; its just is detecting broken software/comnfiguration; not finding imdividual bad results
199 2015-11-29 08:33:00 <sipa> Lightsword: well there may be incentives that promote having more transactions
200 2015-11-29 08:33:33 <gmaxwell> sipa: I don't think there is any reason to bother only checking a fraction, once it's not latency critical it doesn't matter. And random sampling is not so effective at systemic errors. :)
201 2015-11-29 08:35:15 <Lightsword> sipa, well the incentive would be fees mainly IMO and as long as GBT is close enough to the stratum method in terms of delay it could make sense economically to just use GBT and mine those fees rather than sending out blank templates
202 2015-11-29 08:35:20 <gmaxwell> Lightsword: in any case, my obvjective is only to eliminate incentives to not validate; and minimize fairness disadvantages that smaller miners suffer with higher delays.
203 2015-11-29 08:36:08 <gmaxwell> Lightsword: unfortunately one downside is that right after a block the pools has been drained of the highest value transactions. Though hopefully the anti-sniping may help some in the future.
204 2015-11-29 08:37:19 <gmaxwell> Lightsword: another possibility would be to return only the top of the mempool (assuming that ended up considerably faster). Keep in mind that more transactions also take more time to distribute work out to devices; though I don't know if anyone has well characterized those delays.
205 2015-11-29 08:37:43 <Lightsword> gmaxwell, true although if the transactions aren’t filling the block then CNB should be faster right since it will terminate sooner?
206 2015-11-29 08:37:46 <sipa> gmaxwell: not a problem if there is not much fee variation, and a consistent backlog of a few blocks wortg
207 2015-11-29 08:38:08 <sipa> Lightsword: CNB should run in milliseconds, ignoring TBV
208 2015-11-29 08:38:40 <gmaxwell> Lightsword: yes, it's faster (and the TBV too) with less data.
209 2015-11-29 08:38:45 <Lightsword> the changes in #6898 should make it so that CNB times are no longer dependent on mempool size right?
210 2015-11-29 08:39:15 <sipa> they still are for the priority space
211 2015-11-29 08:39:48 <tulip> sipa: doesn't look like you pushed it, never mind.
212 2015-11-29 08:40:07 <Lightsword> would it make sense to skip priority on the first GBT call?
213 2015-11-29 08:40:28 <sipa> Lightsword: it would make sense to set the priority space to 0 imho
214 2015-11-29 08:40:47 <Lightsword> gmaxwell, stratum delays should be minimal expecially with proxy systems often used by farms
215 2015-11-29 08:41:02 <Lightsword> sipa, I already do that actually
216 2015-11-29 08:41:27 <Lightsword> well I just block free transaction relay
217 2015-11-29 08:42:07 <jtoomim> stratum just includes the merkle root hash, right? that should be basically O(1) vs number of transactions
218 2015-11-29 08:42:23 <tulip> no, it includes the whole merkle path to the coinbase.
219 2015-11-29 08:42:50 <jtoomim> ok, so log(n)
220 2015-11-29 08:52:45 <gmaxwell> Lightsword: Don't be so sure, a lot of software has never been tested for latency...
221 2015-11-29 08:55:37 <Lightsword> gmaxwell, yeah, I’m probably generalizing a bit but it shouldn’t be an issue for optimized stratum servers, some of the pools like antpool do seem to be pretty inconsistant about block updates even for self-found blocks, although that could just be an internal misconfiguration
222 2015-11-29 13:33:18 <niggs> Starting a new project guys. Need some fundings
223 2015-11-29 13:33:35 <niggs> Shares 20%
224 2015-11-29 13:35:04 <niggs> ?
225 2015-11-29 13:35:42 <pigeons> not here
226 2015-11-29 13:36:45 <niggs> Need investment for new project guys
227 2015-11-29 13:36:55 <root-investment> what project?
228 2015-11-29 13:37:04 <root-investment> and how much do u want?
229 2015-11-29 13:37:13 <niggs> 1k btc
230 2015-11-29 13:37:18 <root-investment> lol
231 2015-11-29 13:37:41 <root-investment> explain me the pros.and proj
232 2015-11-29 13:42:13 <root-investment> anybody wants to contribute for a genuine development project of a new bitcoin wallet service????
233 2015-11-29 13:43:33 <phantomcircuit> niggs, root-investment you know we know you're the same person right?
234 2015-11-29 13:45:10 <root-investment> need investment for a new wallet project??
235 2015-11-29 16:54:50 <btcdrak> I spoke with G1lius and harding. We can get the weekly dev summaries on bitcoin.org https://github.com/bitcoin-dot-org/bitcoin.org/issues/1147
236 2015-11-29 17:20:40 <harding> (Subject to me doing some technical things and the regular PR discussion, of course.)
237 2015-11-29 17:24:34 <btcdrak> harding it would also be cool if we could somehow get a feed of merged PRs somewhere.
238 2015-11-29 17:25:02 <harding> btcdrak: that's available on GitHub.  I subscribe to it myself.
239 2015-11-29 17:25:32 <btcdrak> yeah, but get that on this "what's happeing in dev" section we're talking about. So people can get a feel for how much work and progress is getting done.
240 2015-11-29 17:26:51 <btcdrak> do we have links to the new bitcoin-discuss list on the website yet?
241 2015-11-29 17:27:35 <harding> btcdrak: No.  Please feel free to PR those, or open an issue and I'll do it.
242 2015-11-29 17:27:58 <btcdrak> harding: ok cool. just came to mind
243 2015-11-29 18:33:21 <Luke-Jr> harding: what are your thoughts on extending the Core stuff to cover other full nodes? (LJR, addrindex, RBF, etc)
244 2015-11-29 18:41:26 <harding> Luke-Jr: I think Bitcoin.org should publish any contributed material that is factual and reasonably uncontroversial amongst experts, and that all sounds like it fits the bill.  We can always split stuff out to separate pages later if people don't like having X on the page about Y.
245 2015-11-29 18:42:21 <Luke-Jr> harding: think any of the web experts working on Bitcoin.org would be interested?
246 2015-11-29 18:43:07 <Luke-Jr> (web design isn't really my area)
247 2015-11-29 18:44:19 <harding> Mine neither.  I don't think there's any harm in opening an issue and seeing who responds.  That's worked pretty well for us in the past, e.g. when neither saivann nor I wanted to do wallet reviews any more, someone stepped up and started doing a better job than either of us had ever done.
248 2015-11-29 19:41:58 <airik> I've had a transaction stuck for several hours, and trying to sign a double-spend (one that pays less change, to give it a higher fee) but bitcoin-cli signrawtransaction keeps just giving "Input not found or already spent"
249 2015-11-29 19:42:03 <airik> I've cleared my mempool as well
250 2015-11-29 19:43:25 <sipa> your wallet will resubmit the old one to the wallet
251 2015-11-29 19:43:42 <sipa> eh, to the mempool
252 2015-11-29 19:44:01 <airik> Ah, so I should restart it in offline mode?
253 2015-11-29 19:44:20 <sipa> no, you should use the manual signrawtransaction
254 2015-11-29 19:44:26 <airik> I am using signrawtransaction
255 2015-11-29 19:44:35 <sipa> where you give the output to soend as an argument
256 2015-11-29 19:44:50 <sipa> the problem is not that signrawtransaction doesn't allow you to doublespend
257 2015-11-29 19:45:02 <sipa> it's that it can't find the output to sign for
258 2015-11-29 19:45:33 <airik> ah i see, thanks
259 2015-11-29 19:45:54 <sipa> there's no reason for that though; it should ignore the mempool, because it could easiky find it in the chainstate
260 2015-11-29 19:46:02 <sipa> do you mind filing a bug for that?
261 2015-11-29 19:46:17 <airik> don't have a github account :(
262 2015-11-29 19:46:24 <airik> deleted mine, sorry :(
263 2015-11-29 19:47:38 <sipa> ok, will try to remember this myself
264 2015-11-29 19:57:30 <airik> sipa: Never mind, it was a bug in my code, not bitcoin. It seems to be handling it fine =)
265 2015-11-29 20:01:07 <sipa> ok!
266 2015-11-29 21:57:38 <kenrestivo> it always turns out to be a bug in my code. it's never lupus.